Cấu hình Auditd để giám sát truy cập Database
Bước đầu tiên là đảm bảo dịch vụ auditd đang chạy và sẵn sàng nhận rule. Chúng ta cần khởi động service và kích hoạt nó tự động khi boot để đảm bảo tính liên tục của hệ thống giám sát.
Khởi động auditd giúp kernel bắt đầu ghi nhận các sự kiện hệ thống theo quy tắc đã định. Nếu không bật, các rule cấu hình sau sẽ không có tác dụng.
Dịch vụ auditd sẽ chuyển sang trạng thái "active (running)".
systemctl enable --now auditd
Chúng ta cần xác định đường dẫn tuyệt đối đến binary của database đang sử dụng. Ví dụ ở đây dùng MySQL/MariaDB, bạn cần thay thế bằng PostgreSQL hoặc Oracle nếu cần.
Xác định chính xác đường dẫn binary giúp auditd biết chính xác file nào cần theo dõi, tránh việc ghi log thừa thãi làm ảnh hưởng hiệu năng server.
Thu được đường dẫn đầy đủ như /usr/sbin/mysqld hoặc /usr/bin/postgres.
which mysqld
Theo dõi file binary của Database
Sử dụng lệnh auditctl để thêm rule giám sát file binary. Rule này sẽ theo dõi mọi sự kiện mở file (open) với quyền đọc hoặc viết trên file binary của database.
Việc giám sát file binary giúp phát hiện các nỗ lực thay thế (trojan) hoặc cố gắng load module độc hại vào quá trình chạy của database. Flag -F auid>=1000 đảm bảo không ghi log cho user system (root) trong các tác vụ bảo trì bình thường, chỉ tập trung vào user người dùng.
Rule được thêm vào danh sách hiện hành. Khi có truy cập bất thường vào file này, log sẽ xuất hiện trong /var/log/audit/audit.log.
auditctl -w /usr/sbin/mysqld -p warx -k db_binary_access
Cần kiểm tra lại danh sách các rule đang chạy để xác nhận rule vừa tạo đã được kernel chấp nhận.
Việc verify giúp đảm bảo syntax của lệnh auditctl đúng và rule đang active. Nếu không thấy rule này, các bước sau sẽ thất bại.
Đầu ra hiển thị đường dẫn file, các quyền (warx) và key (db_binary_access) tương ứng.
auditctl -l | grep db_binary_access
Bắt các Syscall liên quan đến IO (Read/Write)
Cấu hình rule để giám sát các hệ thống gọi (syscall) đọc và viết file. Chúng ta sẽ theo dõi syscall 'open', 'openat', 'read', và 'write' khi chúng được gọi bởi quá trình database.
Giám sát syscall IO giúp phát hiện hành vi đọc dữ liệu nhạy cảm hoặc ghi log trái phép, ngay cả khi file binary không bị thay đổi. Điều này phát hiện các hành vi "data exfiltration" hoặc "log tampering".
Rule mới được thêm vào, gắn với key 'db_io_ops'. Các hoạt động IO của quá trình mysqld sẽ được ghi log chi tiết.
auditctl -a exit,always -F arch=b64 -S open -S openat -S read -S write -F comm=mysqld -k db_io_ops
Tương tự, cần thêm rule cho kiến trúc 32-bit (b32) nếu server của bạn hỗ trợ hoặc chạy trong môi trường container legacy.
Trên Linux 64-bit, các chương trình 32-bit vẫn có thể chạy và tạo syscall 32-bit. Thiếu rule này sẽ tạo lỗ hổng cho kẻ tấn công chạy payload 32-bit để lẩn tránh.
Rule cho kiến trúc 32-bit được thêm vào danh sách giám sát.
auditctl -a exit,always -F arch=b32 -S open -S openat -S read -S write -F comm=mysqld -k db_io_ops
Verify kết quả bằng cách kiểm tra toàn bộ danh sách rule exit để đảm bảo cả hai kiến trúc đều đã được cấu hình.
Xác minh rằng cả hai rule (b64 và b32) đều hiện diện và có cùng key 'db_io_ops'.
Đầu ra hiển thị hai dòng rule riêng biệt cho b64 và b32.
auditctl -l | grep db_io_ops
Giám sát quá trình khởi động và đóng dịch vụ Database
Cấu hình rule để ghi nhận sự kiện khi dịch vụ database được khởi động hoặc dừng. Chúng ta sử dụng syscall 'execve' để bắt việc thực thi binary khi start.
Giám sát sự kiện start/stop giúp phát hiện các lần khởi động bất thường (ví dụ: khởi động thủ công bằng root thay vì systemd) hoặc việc tắt dịch vụ đột ngột để phá hoại.
Rule 'db_service_start' được tạo, ghi log mỗi khi mysqld được thực thi.
auditctl -a exit,always -F arch=b64 -S execve -F comm=mysqld -k db_service_start
Để giám sát việc đóng dịch vụ, chúng ta theo dõi syscall 'exit' hoặc 'exit_group' của quá trình mysqld.
Việc này giúp xác định thời điểm chính xác dịch vụ dừng, kết hợp với log của systemd để phân tích nguyên nhân (crash, kill, hay stop thủ công).
Rule 'db_service_stop' được thêm vào danh sách.
auditctl -a exit,always -F arch=b64 -S exit -S exit_group -F comm=mysqld -k db_service_stop
Thực hiện lệnh restart dịch vụ database để kích hoạt các rule vừa tạo và sinh ra log mẫu.
Hành động này sẽ tạo ra các sự kiện thực tế: một sự kiện execve khi start và một sự kiện exit khi stop (nếu restart nhanh).
Trong audit.log sẽ xuất hiện các dòng log với key 'db_service_start' và 'db_service_stop'.
systemctl restart mysqld
Verify bằng cách tra cứu log audit theo key vừa tạo.
Khẳng định rằng auditd đã bắt được sự kiện thực tế ngay sau khi cấu hình.
Đầu ra hiển thị các dòng log chi tiết bao gồm thời gian, user, và quá trình thực hiện.
ausearch -k db_service_start
Cấu hình Logrotate và lưu trữ Audit Logs an toàn
Tạo file cấu hình logrotate riêng cho audit logs để đảm bảo log không bị tràn đĩa và được luân chuyển an toàn.
Logrotate mặc định có thể không phù hợp với auditd vì audit logs cần được nén và giữ lại lâu dài để phân tích pháp lý (forensics). Cấu hình này đảm bảo log cũ được nén và giữ lại 6 tháng.
File cấu hình được tạo tại /etc/logrotate.d/audit với các tham số tùy chỉnh.
cat > /etc/logrotate.d/audit
Thiết lập quyền sở hữu và permission nghiêm ngặt cho thư mục chứa audit log.
Đảm bảo chỉ có user root mới có quyền đọc/ghi vào thư mục này. Điều này ngăn chặn việc kẻ tấn công đã xâm nhập vào server (với quyền user thường) xóa hoặc sửa log để che giấu dấu vết.
Thư mục /var/log/audit sẽ có quyền 0700 và owner root:root.
chown root:root /var/log/audit && chmod 700 /var/log/audit
Thiết lập quyền cho file log hiện tại để đảm bảo tính nhất quán sau khi cấu hình logrotate.
File audit.log phải chỉ được root đọc, tránh rò rỉ thông tin nhạy cảm trong log.
File audit.log có quyền 0600.
chmod 600 /var/log/audit/audit.log
Thực hiện lệnh rotate thủ công để kiểm tra xem cấu hình có hoạt động không.
Khởi động lại logrotate giúp kiểm tra script postrotate (khởi động lại auditd) có chạy đúng không mà không cần chờ đến chu kỳ tuần.
File audit.log cũ sẽ được đổi tên thành audit.log.1 và nén thành audit.log.1.gz.
logrotate -f /etc/logrotate.d/audit
Phân tích Log Audit để phát hiện truy cập bất thường
Sử dụng lệnh ausearch để lọc các sự kiện liên quan đến truy cập file binary của database.
Phân tích log giúp xác định ai đã truy cập, từ đâu, và vào thời gian nào. Key 'db_binary_access' sẽ tập trung vào các nỗ lực mở file mysqld.
Đầu ra hiển thị danh sách các sự kiện với thông tin chi tiết: uid, auid (user đăng nhập), và path của file.
ausearch -k db_binary_access -f 1
Tìm kiếm các hành vi đọc dữ liệu (syscall read) từ các file config hoặc data của database.
Phát hiện các trường hợp user không phải admin cố gắng đọc file config (my.cnf) hoặc file data (ibdata1) thông qua syscall read. Đây là dấu hiệu của reconnaissance hoặc data theft.
Log hiển thị các dòng sự kiện với syscall 'read' và path của file bị đọc.
ausearch -k db_io_ops -f read
Sử dụng lệnh aureport để tạo báo cáo tóm tắt về các hoạt động của database trong khoảng thời gian nhất định.
Báo cáo này giúp sysadmin nhanh chóng nắm bắt tổng quan: ai là user truy cập nhiều nhất, file nào bị truy cập nhiều nhất, và syscall nào được gọi thường xuyên.
Đầu ra là bảng thống kê dạng bảng (table) với các cột: user, count, và file.
aureport -f -i /var/log/audit/audit.log | grep -A 20 "File name"
Kết hợp grep để tìm các sự kiện từ các user cụ thể hoặc từ các địa chỉ IP cụ thể (nếu đã cấu hình network audit).
Giúp lọc nhiễu và tập trung vào các sự kiện đáng ngờ, ví dụ: user 'nobody' hoặc 'www-data' truy cập vào binary của database.
Đầu ra chỉ hiển thị các dòng log khớp với user hoặc điều kiện tìm kiếm.
ausearch -k db_binary_access | grep "auid=1000"
Điều hướng series:
Mục lục: Series: Triển khai Database chống tấn công với Linux eBPF và Kernel Audit
« Phần 2: Giới thiệu cơ chế hoạt động của Linux eBPF và Audit
Phần 4: Xây dựng eBPF program đầu tiên để chặn truy cập trái phép »