Linux Kernel Lockdown: Cách ngăn chặn các cuộc tấn công cấp Root

Table of Contents

Vượt qua quyền Root: Câu chuyện sống sót lúc 2 giờ sáng

Bảng điều khiển giám sát của tôi vọt lên các lỗi 5xx vào lúc 2 giờ sáng. Một kẻ tấn công đã khai thác lỗ hổng ứng dụng web và leo thang lên quyền root. Trước đây, điều này đồng nghĩa với việc mọi thứ đã kết thúc. Người dùng root có thể tải các module kernel độc hại, trích xuất bộ nhớ nhạy cảm hoặc ẩn một backdoor vĩnh viễn trong image của kernel để duy trì sau mỗi lần khởi động lại.

Nhưng máy chủ này vẫn đứng vững. Ngay cả với uid=0, kẻ tấn công cũng không thể ẩn mình. Mọi nỗ lực chèn rootkit đều thất bại với lỗi “Operation not permitted” (Thao tác không được phép). Lý do? Tôi đã kích hoạt Linux Kernel Lockdown. Tính năng này thay đổi mô hình bảo mật của Linux bằng cách chứng minh rằng ngay cả siêu người dùng (superuser) cũng không nên có toàn quyền sửa đổi trái tim của hệ điều hành.

Bắt đầu nhanh: Xác minh và kích hoạt Lockdown trong 5 phút

Hầu hết các bản phân phối hiện đại, bao gồm Ubuntu 20.04+, RHEL 8+ và Debian 10+, đều hỗ trợ Lockdown trong kernel. Tuy nhiên, nó thường ở trạng thái ngủ theo mặc định. Bạn có thể xác minh trạng thái và kích hoạt nó chỉ trong vài bước.

Bước 1: Kiểm tra trạng thái hiện tại

Trước tiên, hãy xem kernel của bạn có hỗ trợ tính năng này không và xác định chế độ nào đang hoạt động. Chạy lệnh sau:

cat /sys/kernel/security/lockdown

Bạn sẽ thấy kết quả tương tự như sau:

none [integrity] confidentiality

Giá trị nằm trong dấu ngoặc vuông [] là chế độ đang hoạt động. Nếu nó hiển thị [none], kernel của bạn đang mở toang cho các can thiệp cấp root. Nếu file không tồn tại, có thể kernel của bạn quá cũ (trước bản 5.4) hoặc thiếu flag CONFIG_SECURITY_LOCKDOWN_LSM.

Bước 2: Kích hoạt vĩnh viễn qua GRUB

Để kích hoạt lockdown vĩnh viễn, hãy truyền một tham số vào kernel lúc khởi động. Mở cấu hình GRUB của bạn:

sudo nano /etc/default/grub

Tìm dòng GRUB_CMDLINE_LINUX_DEFAULT và thêm lockdown=integrity. Dòng của bạn sẽ trông như thế này:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash lockdown=integrity"

Lưu file, cập nhật bootloader và khởi động lại hệ thống:

sudo update-grub
sudo reboot

Khi tối ưu bảo mật cho các môi trường này, tôi thường tạo mật khẩu máy chủ phức tạp bằng toolcraft.app/vi/tools/security/password-generator. Nó chạy cục bộ trong trình duyệt, đảm bảo không có chuỗi nhạy cảm nào bị gửi qua mạng. Đây là một thói quen đơn giản giúp giữ an toàn cho vòng ngoài của bạn.

Integrity so với Confidentiality: Chọn cấp độ phù hợp

Lockdown không chỉ là một công tắc bật/tắt đơn giản. Nó cung cấp hai cấp độ bảo vệ riêng biệt. Việc chọn đúng cấp độ đòi hỏi sự cân bằng giữa nhu cầu bảo mật và nhu cầu debug hệ thống.

Chế độ Integrity (Tính toàn vẹn)

Thiết lập lockdown=integrity sẽ chặn các tính năng cho phép các tiến trình ở không gian người dùng (user-space) sửa đổi kernel đang chạy. Đây là lựa chọn tiêu chuẩn cho 95% máy chủ production. Chế độ này thực thi một số hạn chế:

Vô hiệu hóa /dev/mem và /dev/kmem để chặn ghi trực tiếp vào bộ nhớ.
Hạn chế kexec để ngăn khởi động vào các kernel không được ký, không đáng tin cậy.
Chặn tải các module kernel không được ký (thiết yếu để ngăn chặn rootkit).
Giới hạn quyền ghi vào MSR (Model-Specific Register) có thể làm suy yếu CPU.

Chế độ Confidentiality (Tính bảo mật)

Chế độ lockdown=confidentiality là thiết lập ở mức tối đa. Nó bao gồm mọi thứ từ chế độ Integrity nhưng cũng ngăn người dùng trích xuất dữ liệu từ kernel. Chế độ này bổ sung các lệnh chặn gắt gao hơn:

Truy cập vào /proc/kcore bị hạn chế hoàn toàn.
Chặn các hoạt động eBPF (Berkeley Packet Filter) có thể soi vào bộ nhớ kernel.
Ngăn các trình debug (debugger) gắn vào kernel.

Chỉ sử dụng chế độ này trong các môi trường bảo mật cực cao. Nếu bạn cần khắc phục sự cố kernel panic hoặc nghẽn hiệu năng, chế độ này có thể sẽ gây cản trở.

Chuỗi tin cậy (Chain of Trust): Lockdown và UEFI Secure Boot

Các bản phân phối hiện đại thường tự động kích hoạt Lockdown nếu UEFI Secure Boot được bật trong BIOS. Điều này tạo ra một Chuỗi tin cậy (Chain of Trust) vững chắc. Phần cứng xác minh bootloader, bootloader xác minh kernel, và kernel sử dụng Lockdown để đảm bảo người dùng root không thể phá vỡ sự tin cậy đó. Kiểm tra trạng thái của bạn bằng mokutil:

mokutil --sb-state

Nếu Secure Boot được bật, kernel của bạn có thể đã mặc định ở chế độ integrity rồi. Nếu bạn cần ghi đè thiết lập này trên một máy production, bạn thường phải tắt Secure Boot trong cài đặt phần cứng, điều mà tôi hiếm khi khuyến nghị.

Các vấn đề thực tế: Điều gì có thể bị lỗi?

Lockdown rất mạnh mẽ nhưng nó có thể gây gián đoạn. Tôi đã dành nhiều giờ để debug các lỗi “Permission Denied” trên các script vốn đã chạy ổn định trong nhiều năm cho đến khi tôi bật tính năng này.

Driver độc quyền: Các driver không được ký, chẳng hạn như driver Nvidia cũ hoặc các module điều khiển RAID chuyên dụng, sẽ không tải được. Bạn phải ký chúng thủ công bằng Machine Owner Key (MOK).
Hibernation (Ngủ đông): Chế độ Suspend-to-disk thường bị vô hiệu hóa. Điều này là do trạng thái hệ thống đã lưu có thể bị sửa đổi trong khi tắt nguồn, tiềm ẩn nguy cơ gây hại cho kernel khi khởi động lại.
Công cụ phần cứng: Các tiện ích như dmidecode hoặc các cảm biến đọc trực tiếp từ địa chỉ bộ nhớ có thể ngừng hoạt động hoặc trả về kết quả trống.
Khả năng quan sát (Observability): Các công cụ nâng cao như bcc hoặc bpftrace sẽ mất khả năng thăm dò một số hàm nhất định nếu bạn đang ở chế độ confidentiality.

Cách tìm ra “thủ phạm” gây lỗi

Khi kernel chặn một hành động, nó sẽ ghi lại sự kiện đó. Nếu một dịch vụ thất bại một cách bí ẩn, hãy kiểm tra log ngay lập tức:

dmesg | grep -i "Lockdown"

Bạn sẽ thấy các dòng như Lockdown: systemd-udevd: /dev/mem is restricted (Lockdown: systemd-udevd: /dev/mem bị hạn chế). Dòng log này chính là người bạn tốt nhất của bạn. Nó cho bạn biết chính xác hệ thống đã chặn lời gọi hệ thống (system call) hoặc quyền truy cập thiết bị nào.

Lời kết

Kernel Lockdown là một bước tiến lớn cho bảo mật Linux. Nó thừa nhận rằng tài khoản root có thể và sẽ bị xâm nhập. Bằng cách thu hẹp bề mặt tấn công, bạn đảm bảo rằng một dịch vụ bị tấn công đơn lẻ sẽ không dẫn đến việc mất hoàn toàn sự tin cậy của phần cứng. Hãy bắt đầu với chế độ integrity trên máy staging, kiểm tra các script giám sát, sau đó triển khai cho production. Bản thân bạn trong tương lai sẽ cảm ơn vì đã làm điều này.