Vượt xa các bản ghi cơ bản: Tại sao History và Auth.log là chưa đủ
Nếu bạn từng cố gắng chắp vá một sự cố bảo mật chỉ bằng lệnh history, bạn sẽ biết nó gây ức chế thế nào. Lịch sử shell cơ bản rất dễ bị can thiệp. Một người dùng am hiểu có thể xóa nó chỉ bằng một lệnh duy nhất, và nó không bao giờ hiển thị kết quả thực tế của những gì họ đã chạy. Ngay cả /var/log/auth.log cũng chỉ cho bạn biết rằng một lệnh đã được thực thi, chứ không phải những gì đã diễn ra bên trong phiên làm việc đó.
Nhiều quản trị viên hệ thống cố gắng sử dụng lệnh script để ghi lại hoạt động. Tuy nhiên, điều đó yêu cầu người dùng phải tự nguyện bắt đầu việc ghi lại. Sudo I/O Logging khắc phục điều này bằng cách đưa cơ chế ghi vào chính tiện ích sudo. Nó hoạt động giống như một đầu ghi DVR cho terminal của bạn, ghi lại mọi phím nhấn, phím xóa (backspace) và mọi dòng đầu ra với mốc thời gian chính xác.
Hãy cùng so sánh ba phương pháp theo dõi phổ biến nhất:
- Shell History: Dễ dàng bị xóa (
history -c), không ghi lại đầu ra và không có giá trị bảo mật thực tế. - Auditd: Tuyệt vời để theo dõi truy cập tệp và các lời gọi hệ thống (system calls). Tuy nhiên, việc cố gắng tái hiện một phiên làm việc trực quan từ các bản ghi audit thô giống như cố gắng xem một bộ phim bằng cách đọc siêu dữ liệu (metadata) thô của tệp video.
- Sudo I/O Logging: Ghi lại toàn bộ tương tác TTY. Gần như không thể để một người dùng không có quyền root vượt qua và cung cấp khả năng phát lại phiên làm việc một cách trực quan hoàn hảo.
Những đánh đổi khi ghi lại phiên làm việc
Triển khai ghi lại phiên làm việc không phải là một nhiệm vụ “thiết lập xong rồi quên”. Tôi đã triển khai tính năng này trong các môi trường từ startup vài node đến các trung tâm dữ liệu hàng nghìn máy chủ, và tác động của nó phụ thuộc rất nhiều vào khối lượng công việc của bạn.
Ưu điểm
- Trách nhiệm giải trình tuyệt đối: Bạn không chỉ thấy người dùng đã chạy
rm -rf /; bạn còn thấy chính xác chuỗi lệnh và những sai lầm dẫn đến thời điểm đó. - Khắc phục sự cố nhanh hơn: Khi một thay đổi cấu hình làm hỏng dịch vụ đang chạy (production), bạn có thể xem lại phiên làm việc để thấy chính xác cú pháp đã sử dụng, bao gồm cả các thông báo lỗi mà quản trị viên có thể đã bỏ qua.
- Sẵn sàng tuân thủ: Thiết lập này đáp ứng các yêu cầu khắt khe về giám sát truy cập đặc quyền theo các khung tiêu chuẩn như PCI-DSS, SOC2 và HIPAA.
Nhược điểm
- Tăng trưởng lưu trữ: Vì bạn đang ghi lại tất cả đầu ra, các bản ghi có thể phình to. Chạy lệnh
cattrên một tệp log 500MB sẽ tạo ra một bản ghi phiên làm việc dung lượng 500MB. - Lộ dữ liệu nhạy cảm: Mọi thứ đều được ghi lại. Nếu người dùng nhập mật khẩu vào một lời nhắc không ẩn ký tự nhập, mật khẩu đó hiện được lưu trữ dưới dạng văn bản thuần túy (plain text) trong các bản ghi kiểm tra của bạn.
- Ảnh hưởng hiệu năng: Việc ghi từng byte I/O vào đĩa sẽ gây ra một độ trễ nhỏ. Trong thử nghiệm của tôi trên một thực thể Ubuntu 22.04 với 4GB RAM, mức chiếm dụng CPU vẫn dưới 1%, nhẹ hơn đáng kể so với các agent của bên thứ ba.
Kiến trúc thiết lập khuyến nghị
Mặc dù bạn có thể truyền các bản ghi này đến một máy chủ trung tâm, chúng ta sẽ bắt đầu với một cấu hình cục bộ vững chắc. Chúng ta muốn đảm bảo rằng mọi lệnh sudo đều được tự động ghi vào một thư mục được bảo vệ. Để giữ mọi thứ ngănắp, chúng ta sẽ phân loại log theo tên người dùng và ID phiên làm việc.
Cấu hình dựa trên ba tham số cốt lõi:
iolog_dir: Đường dẫn cơ sở nơi lưu trữ các bản ghi.iolog_file: Quy ước đặt tên cho mỗi phiên.LOG_OUTPUTvàLOG_INPUT: Các luồng dữ liệu xác định những gì chúng ta ghi lại.
Hướng dẫn triển khai: Thiết lập Sudo I/O Logging
Hướng dẫn này giả định bạn đang sử dụng một bản phân phối hiện đại như Ubuntu, Debian hoặc RHEL. Bạn cần phiên bản Sudo 1.8.7 trở lên, vốn đã là tiêu chuẩn trong gần một thập kỷ qua.
Bước 1: Tạo thư mục log bảo mật
Chúng ta cần một không gian riêng cho các bản ghi. Thư mục này phải thuộc sở hữu riêng của root để ngăn người dùng can thiệp vào lịch sử phiên làm việc của chính họ.
sudo mkdir -p /var/log/sudo-io
sudo chmod 0700 /var/log/sudo-ioBước 2: Cấu hình Sudoers an toàn
Đừng bao giờ chỉnh sửa trực tiếp /etc/sudoers nếu bạn có thể tránh được. Thay vào đó, hãy tạo một tệp cấu hình dạng module trong /etc/sudoers.d/. Điều này giúp cấu hình chính của bạn sạch sẽ và ngăn các bản cập nhật gói làm hỏng cài đặt của bạn.
sudo visudo -f /etc/sudoers.d/audit-logsDán cấu hình sau vào tệp:
# Tổ chức log theo người dùng và máy chủ
Defaults iolog_dir="/var/log/sudo-io/%{user}/%H"
Defaults iolog_file="%D-%T"
# Ghi lại cả những gì người dùng nhập và những gì họ thấy
Defaults log_output
Defaults log_input
# Thông báo cho người dùng rằng họ đang bị giám sát
Defaults mail_badpass
Defaults lecture="always"
Defaults lecture_file="/etc/sudo_lecture"Các biến này có tác dụng gì:
%{user}: Tạo một thư mục con duy nhất cho mỗi người dùng.%H: Bao gồm hostname, điều này rất quan trọng nếu sau này bạn tổng hợp log từ nhiều máy chủ.%D-%T: Gắn dấu thời gian cho phiên làm việc để dễ dàng tìm kiếm.log_output: Ghi lại đầu ra màn hình (phần “hình ảnh”).log_input: Ghi lại mọi phím nhấn, bao gồm cả phím xóa và các ký tự ẩn.
Bước 3: Tạo cảnh báo pháp lý (Tùy chọn)
Ở nhiều khu vực, luật pháp yêu cầu bạn phải thông báo cho người dùng rằng hoạt động của họ đang được ghi lại. Tạo tệp lecture đã đề cập trong cấu hình:
sudo nano /etc/sudo_lectureThêm một thông báo rõ ràng:
CHÚ Ý: Để đảm bảo an ninh và tuân thủ, tất cả các hoạt động được thực hiện dưới quyền sudo đều được ghi lại.Bước 4: Kiểm tra việc ghi lại
Chuyển sang một tài khoản người dùng bình thường và chạy một vài lệnh để tạo dữ liệu.
sudo apt update
sudo tail /var/log/syslog
exitBây giờ, hãy kiểm tra thư mục log với quyền root. Bạn sẽ thấy một cấu trúc thư mục mới chứa các tệp nhị phân như ttyin và ttyout. Đừng cố đọc chúng bằng lệnh cat; chúng yêu cầu một trình phát chuyên dụng.
Phát lại các phiên làm việc
Để xem một phiên làm việc chính xác như nó đã diễn ra, hãy sử dụng công cụ sudoreplay. Để xem danh sách tất cả các phiên đã ghi trên hệ thống, hãy chạy:
sudo sudoreplay -lĐể phát lại một phiên cụ thể, hãy cung cấp đường dẫn tìm thấy trong danh sách:
sudo sudoreplay /var/log/sudo-io/myuser/myhost/2023-10-27-14:30:05Mẹo chuyên nghiệp: Nếu người dùng ở trạng thái chờ lâu, đừng ngồi xem sự im lặng đó. Sử dụng cờ -s để tăng tốc độ (ví dụ: -s 5 cho tốc độ 5x) hoặc nhấn phím > trong khi phát lại để bỏ qua đoạn tiếp theo.
Bảo trì và Bảo mật
Nếu không được quản lý, thư mục /var cuối cùng sẽ bị đầy. Một quản trị viên chạy journalctl -f trong một giờ có thể tạo ra vài megabyte log.
1. Tự động dọn dẹp log
Sudo I/O log không tự động xoay vòng (rotate). Tôi khuyên bạn nên thiết lập một công việc cron đơn giản để xóa các bản ghi cũ hơn 90 ngày. Đối với một nhóm gồm năm quản trị viên hoạt động tích cực, 90 ngày log thường chiếm từ 1GB đến 5GB dung lượng.
# Chạy hàng ngày lúc 2:00 sáng để xóa các log cũ quá 90 ngày
0 2 * * * find /var/log/sudo-io -type d -mtime +90 -exec rm -rf {} +2. Tăng cường tính toàn vẹn của log
Kẻ tấn công có quyền root sẽ ngay lập tức cố gắng xóa các bản ghi này để che giấu dấu vết. Mặc dù bạn không thể ngăn chặn hoàn toàn người dùng root trên máy cục bộ, bạn nên truyền các bản ghi này đến một máy chủ từ xa, chỉ cho phép ghi (write-only) bằng rsyslog. Điều này đảm bảo rằng ngay cả khi máy chủ cục bộ bị xâm nhập, bằng chứng vẫn an toàn trên một máy khác.
3. Ghi log có chọn lọc
Nếu dung lượng lưu trữ hạn hẹp, bạn không nhất thiết phải ghi lại mọi thứ trên toàn hệ thống. Bạn có thể áp dụng log_output cho các bí danh lệnh (command aliases) cụ thể trong tệp sudoers của mình. Tuy nhiên, việc ghi log toàn cục hầu như luôn tốt hơn cho bảo mật nếu bạn có đủ dung lượng đĩa.
Sudo I/O logging là một sự bổ sung có tác động lớn nhưng ít tốn công sức cho bất kỳ ngăn xếp bảo mật Linux nào. Cho dù bạn đang chứng minh rằng một thay đổi trái phép đã xảy ra hay chỉ đơn giản là lần lại các bước của chính mình sau một đêm dài khắc phục sự cố, mức độ chi tiết mà nó cung cấp là “cứu cánh” cho bất kỳ quản trị viên hệ thống nào.
