Tại sao kẻ tấn công lại ưa thích Shared Memory
Vài năm trước, một trong những máy chủ của tôi đã bị tấn công dồn dập bởi hơn 50.000 nỗ lực SSH brute-force chỉ trong một đêm. Trải nghiệm đó đã dạy tôi một bài học quan trọng: kẻ tấn công không chỉ muốn tìm cách xâm nhập; chúng còn muốn tìm một nơi để ẩn náu lâu dài. Một khi đã có được chỗ đứng, chúng sẽ tìm kiếm những góc khuất để giấu công cụ của mình. Một trong những nơi ẩn nấp thường bị bỏ qua nhất trong hệ thống Linux là /dev/shm.
Theo mặc định, /dev/shm (Shared Memory – Bộ nhớ dùng chung) là một hệ thống lưu trữ tệp tạm thời (tmpfs) nằm hoàn toàn trên RAM. Nó được xây dựng để phục vụ giao tiếp hiệu suất cao giữa các tiến trình. Tuy nhiên, nó thường có quyền ghi cho tất cả mọi người (world-writable) và cho phép thực thi theo mặc định. Điều này tạo ra một lỗ hổng bảo mật lớn. Kẻ tấn công có thể tải xuống một tệp thực thi (binary) độc hại, chạy nó trực tiếp từ bộ nhớ và xóa tệp ngay lập tức. Điều này không để lại dấu vết trên đĩa vật lý để các công cụ pháp chứng (forensic) truyền thống có thể tìm thấy.
Tôi vẫn thấy nhiều quản trị viên hệ thống để thư mục này mở toang. Chúng ta sẽ khắc phục điều đó ngay bây giờ bằng cách tăng cường bảo mật (hardening) các tùy chọn mount để đảm bảo không ai có thể chạy mã trái phép từ bộ nhớ.
Hướng dẫn tăng cường bảo mật trong 5 phút
Nếu bạn cần bảo mật phân vùng của mình ngay lập tức, hãy làm theo ba bước sau. Phương pháp này là tiêu chuẩn cho Ubuntu, Debian, RHEL và hầu hết các bản phân phối hiện đại.
Bước 1: Kiểm tra trạng thái mount hiện tại
Kiểm tra cách hệ thống của bạn hiện đang xử lý bộ nhớ dùng chung bằng lệnh sau:
mount | grep /dev/shmHầu hết các thiết lập mặc định sẽ trả về (rw,nosuid,nodev). Nếu thiếu flag noexec, hệ thống của bạn đang gặp nguy hiểm. Nó sẽ sẵn sàng thực thi bất kỳ script hoặc tệp binary nào được đặt trong thư mục đó.
Bước 2: Cập nhật /etc/fstab để duy trì thiết lập
Để các thiết lập bảo mật của bạn vẫn còn hiệu lực sau khi khởi động lại, bạn phải chỉnh sửa bảng hệ thống tệp. Mở tệp bằng trình soạn thảo bạn chọn:
sudo nano /etc/fstabTìm dòng chứa /dev/shm. Nếu không có, hãy thêm dòng này vào cuối tệp:
tmpfs /dev/shm tmpfs defaults,noexec,nosuid,nodev 0 0Bước 3: Áp dụng thay đổi ngay lập tức
Bạn không cần phải khởi động lại máy chủ. Chỉ cần mount lại phân vùng để áp dụng các quy tắc mới:
sudo mount -o remount /dev/shmChạy lại lệnh mount | grep /dev/shm. Bây giờ bạn sẽ thấy noexec trong danh sách tùy chọn. Mọi nỗ lực chạy một tệp từ đây giờ đây sẽ dẫn đến lỗi “Permission denied”.
Logic đằng sau các Flag bảo mật
Khi lần đầu quản lý các cụm máy chủ lớn, tôi muốn biết chính xác tại sao các flag này lại quan trọng. Mỗi flag đóng vai trò như một rào cản cụ thể chống lại các kỹ thuật khai thác khác nhau.
Flag “noexec”
Đây là lớp phòng thủ chính của bạn. Nó ngăn chặn bất kỳ tệp nào trong /dev/shm được thực thi như một chương trình. Ngay cả khi hacker thiết lập một script thành chmod 777, kernel cũng sẽ từ chối chạy nó. Điều này vô hiệu hóa hiệu quả khoảng 90% các bộ công cụ khai thác tự động (exploit kits) dựa vào không gian thực thi tạm thời.
Flag “nosuid”
Các bit SUID (Set User ID) cho phép một chương trình chạy với đặc quyền của chủ sở hữu tệp, thường là root. Kẻ tấn công sử dụng các bit này để leo thang đặc quyền từ người dùng tiêu chuẩn lên siêu người dùng (superuser). Việc thiết lập nosuid yêu cầu kernel bỏ qua hoàn toàn các bit này trên phân vùng này.
Flag “nodev”
Flag này ngăn chặn việc tạo các thiết bị ký tự hoặc thiết bị khối đặc biệt. Vì /dev/shm chỉ dành cho việc chia sẻ bộ nhớ, nên không có lý do chính đáng nào để nó chứa các nút thiết bị phần cứng. Việc chặn điều này ngăn kẻ tấn công cố gắng tương tác với kernel hoặc phần cứng thông qua các tệp thiết bị giả mạo.
Khi bảo mật làm gián đoạn ứng dụng
Việc khóa chặt /dev/shm đôi khi có thể gây ra sự cố với các phần mềm cụ thể. Tôi đã gặp trường hợp này với các cơ sở dữ liệu Oracle cũ và các trình duyệt dựa trên Chromium chạy trong các container Docker không giao diện (headless), vốn thường mặc định chỉ có 64MB bộ nhớ dùng chung.
Thay đổi kích thước /dev/shm
Nếu một ứng dụng bị sập vì hết dung lượng — chứ không phải do quyền hạn — bạn có thể tăng kích thước trong /etc/fstab. Để nâng lên 2GB, hãy sử dụng cú pháp sau:
tmpfs /dev/shm tmpfs defaults,noexec,nosuid,nodev,size=2G 0 0Cách kiểm tra các nỗ lực thực thi bị chặn
Nếu bạn nghi ngờ noexec đang làm hỏng một dịch vụ, hãy kiểm tra nhật ký hệ thống. Hầu hết các bản phân phối hiện đại đều ghi lại các sự kiện này. Bạn cũng có thể sử dụng strace để tìm các lời gọi hệ thống execve bị thất bại nhắm vào đường dẫn bộ nhớ dùng chung.
# Kiểm tra các lần chặn thực thi ở cấp độ kernel
sudo journalctl -k | grep -i "resizing"Các mẹo bảo trì chủ động
Tăng cường bảo mật điểm mount là một khởi đầu tuyệt vời, nhưng bảo mật là một quá trình liên tục. Đây là cách tôi giữ cho môi trường của mình sạch sẽ về lâu dài.
Theo dõi sự tích tụ tệp
Thiết lập một cron job đơn giản để cảnh báo cho bạn nếu /dev/shm bắt đầu đầy. Thông thường, nó chỉ nên chứa các tệp nhỏ từ các dịch vụ như PulseAudio hoặc PostgreSQL. Nếu bạn thấy các tệp binary lớn, có tên lạ, hãy điều tra ngay lập tức.
# Kiểm tra nhanh các tệp ẩn nghi vấn
ls -lhA /dev/shmTự động hóa với Ansible
Đừng cấu hình thủ công từng máy chủ. Sử dụng một task Ansible để đảm bảo mọi node mới đều được bảo mật ngay khi nó được khởi tạo. Việc này an toàn hơn nhiều so với việc cố gắng nhớ lại các bước này sau sáu tháng nữa.
- name: Bảo mật điểm mount /dev/shm
mount:
path: /dev/shm
fstype: tmpfs
src: tmpfs
opts: "defaults,noexec,nosuid,nodev"
state: mountedHiểu rõ các giới hạn
Mặc dù noexec rất mạnh mẽ, nhưng nó không phải là một lá chắn hoàn hảo. Một kẻ tấn công quyết tâm vẫn có thể chạy một script bằng cách truyền nó trực tiếp vào một trình thông dịch, chẳng hạn như python3 /dev/shm/malware.py. Đây là lý do tại sao bạn phải áp dụng các nguyên tắc tăng cường bảo mật tương tự cho /tmp và /var/tmp. Bảo mật thực sự phụ thuộc vào nhiều lớp; việc thắt chặt /dev/shm sẽ loại bỏ con đường dễ dàng nhất cho kẻ tấn công, buộc chúng phải nỗ lực nhiều hơn nữa để xâm nhập hệ thống của bạn.
