Làm chủ Kiểm toán Bảo mật Linux với Auditd: Thiết lập Rule, Giám sát File và Phân tích Log

Table of Contents

Vấn đề Thực tế: Bí ẩn về Các File Production Bị Chỉnh sửa

Một web server production đột nhiên hoạt động bất thường. Một public key lạ xuất hiện trong /root/.ssh/authorized_keys, hoặc một tiến trình không rõ nguồn gốc đọc file .env chứa secret của database. Bạn kiểm tra /var/log/syslog và .bash_history nhưng không tìm thấy thông tin hữu ích nào. Kẻ tấn công đã xóa lịch sử shell bằng lệnh unset HISTFILE, trong khi syslog chỉ ghi lại các cron job thông thường và việc khởi động lại dịch vụ.

Các log hệ thống mặc định của Linux chỉ ghi nhận việc một dịch vụ đã khởi động lại hoặc khi nào một phiên làm việc được mở. Chúng không thể trả lời những câu hỏi quan trọng phục vụ điều tra sự cố (forensics):

Ai là người chạy lệnh? Syslog không thể phân biệt chính xác giữa tài khoản đăng nhập thực tế và phiên leo thang đặc quyền qua sudo.
Đường dẫn file hoặc system call chính xác nào đã bị tác động?
Process ID hoặc file thực thi nào đã kích hoạt thay đổi?
Một tiến trình trái phép đã đọc file nhạy cảm mà không chỉnh sửa nội dung vào thời điểm nào?

Nếu không có dữ liệu đo kiểm (telemetry) ở cấp độ kernel, việc điều tra sự cố bảo mật sẽ rơi vào bế tắc. Bạn hoàn toàn bị động trước các hành vi leo thang đặc quyền hay mối đe dọa từ nội bộ (insider threat).

Phân tích Nguyên nhân Gốc rễ: Vì sao Log Tiêu chuẩn Không Đủ Đáp ứng

Cơ chế ghi log ở tầng ứng dụng phụ thuộc vào việc phần mềm chủ động gửi thông điệp đến các daemon như rsyslog hay systemd-journald. Nếu kẻ xâm nhập chỉnh sửa /etc/passwd bằng vim hoặc thực thi một binary lạ từ /dev/shm, các bộ ghi log ở tầng userland sẽ hoàn toàn im lặng. Các thao tác trực tiếp trên file không bao giờ giao tiếp với syslog.

Kẻ tấn công thường xuyên làm giả timestamp của file bằng lệnh touch -r hoặc xóa các biến môi trường để xóa dấu vết. Một giải pháp giám sát đáng tin cậy phải hoạt động bên dưới userland, ngay trong chính Linux kernel. Mọi thao tác đọc file, thực thi tiến trình và mở kết nối mạng đều phải đi qua các system call—chẳng hạn như openat(), execve() và unlinkat(). Linux Audit Framework (auditd) can thiệp trực tiếp vào các syscall này, ghi lại các bản ghi sự kiện bất biến trước khi không gian người dùng kịp chỉnh sửa chúng.

So sánh Các Giải pháp: Lựa chọn Cơ chế Kiểm toán Phù hợp

Các quản trị viên Linux thường cân nhắc ba hướng tiếp cận chính để theo dõi hoạt động hệ thống:

1. Process Accounting (`psacct` / `acct`)

Ưu điểm: Cài đặt tối giản, tiêu tốn cực ít RAM (< 10 MB), theo dõi việc kết thúc lệnh cơ bản.
Nhược điểm: Rất dễ bị người dùng root vô hiệu hóa. Công cụ này chỉ ghi lại tên lệnh đã thực thi mà bỏ qua đường dẫn file, thao tác đọc file, các lệnh gọi mạng và thuộc tính file bị thay đổi.

2. eBPF Security Engine (Falco / Tetragon)

Ưu điểm: Khả năng lập trình linh hoạt, độ trễ syscall gần như bằng 0, cảnh báo theo thời gian thực, được thiết kế chuyên biệt cho Kubernetes và môi trường container.
Nhược điểm: Yêu cầu Linux kernel 5.8+ để có đầy đủ tính năng, tiêu thụ nhiều bộ nhớ hơn (thường từ 200–500 MB mỗi node) và mất nhiều thời gian học hỏi hơn để viết policy tùy chỉnh.

3. Linux Audit Daemon (`auditd`)

Ưu điểm: Được tích hợp sẵn trực tiếp trong kernel, cài sẵn trên các bản phân phối doanh nghiệp (RHEL, Debian, Ubuntu, Rocky Linux), đáp ứng các tiêu chuẩn tuân thủ nghiêm ngặt (PCI-DSS 10.2, CIS Benchmark, SOC 2, HIPAA) và đi kèm các công cụ truy vấn chuyên dụng (ausearch, aureport).
Nhược điểm: Gây tải I/O cao và làm đầy dung lượng ổ đĩa nhanh chóng nếu các quy tắc (rule) quá rộng hoặc không được tinh chỉnh hợp lý.

Giải pháp Tốt nhất: Triển khai và Cấu hình Auditd Từng bước

Trên các máy chủ production bận rộn xử lý hơn 500 request/giây, những audit rule không được giới hạn phạm vi cẩn thận có thể tạo ra hàng gigabyte log mỗi giờ. Hãy làm theo quy trình có cấu trúc dưới đây để triển khai, cấu hình và xác minh auditd một cách an toàn mà không làm quá tải bộ nhớ lưu trữ.

Bước 1: Cài đặt và Kích hoạt Audit Daemon

Cài đặt các package cần thiết trên Ubuntu hoặc Debian:

sudo apt update
sudo apt install auditd audispd-plugins -y

Trên RHEL, Rocky Linux hoặc AlmaLinux:

sudo dnf install audit -y

Khởi động và kích hoạt dịch vụ chạy cùng hệ thống khi khởi động:

sudo systemctl enable --now auditd
sudo systemctl status auditd

Bước 2: Định nghĩa các Audit Rule Bền vững

Các lệnh cấu hình trực tiếp qua auditctl sẽ có hiệu lực ngay lập tức nhưng sẽ mất đi sau khi reboot. Để lưu cấu hình vĩnh viễn, hãy viết các rule dạng module trong thư mục /etc/audit/rules.d/. Script augenrules sẽ biên dịch các file này thành /etc/audit/audit.rules.

Các rule được chia thành hai nhóm chính:

File Watch: Theo dõi truy cập vào file hoặc thư mục để phát hiện các thao tác đọc (r), ghi (w), thực thi (x) hoặc thay đổi thuộc tính (a).
Syscall Rule: Chặn bắt các hàm ở cấp độ kernel như execve, settimeofday hoặc ptrace.

Tạo một file cấu hình riêng tại /etc/audit/rules.d/security.rules:

sudo nano /etc/audit/rules.d/security.rules

Thêm các rule chuẩn dùng cho môi trường production:

## Xóa các rule hiện có và cấp phát buffer kernel (8.192 thông điệp)
-D
-b 8192
-f 1

## 1. Giám sát các thay đổi trong cơ sở dữ liệu user và group
-w /etc/passwd -p wa -k identity_changes
-w /etc/shadow -p wa -k identity_changes
-w /etc/group -p wa -k identity_changes
-w /etc/gshadow -p wa -k identity_changes

## 2. Theo dõi việc thêm SSH key và thay đổi cấu hình daemon
-w /root/.ssh/ -p wa -k ssh_key_tamper
-w /etc/ssh/sshd_config -p wa -k sshd_config_change

## 3. Giám sát các tác vụ theo lịch và quy tắc leo thang đặc quyền
-w /etc/crontab -p wa -k cron_tamper
-w /etc/cron.d/ -p wa -k cron_tamper
-w /etc/sudoers -p wa -k sudo_privilege_escalation
-w /etc/sudoers.d/ -p wa -k sudo_privilege_escalation

## 4. Phát hiện can thiệp đồng hồ hệ thống (thường dùng để làm sai lệch thứ tự log)
-a always,exit -F arch=b64 -S adjtimex,settimeofday,clock_settime -k system_time_change

## 5. Bắt hành vi leo thang đặc quyền: các lệnh được chạy bởi user thường với EUID root
-a always,exit -F arch=b64 -S execve -C uid!=euid -F euid=0 -k elevated_priv_exec

Giải thích chi tiết các tham số của rule:

-b 8192: Đặt bộ đệm audit của kernel lên 8.192 thông điệp. Điều này giúp ngăn chặn việc mất sự kiện khi phát sinh lượng ghi đột biến.
-w <path>: Xác định đường dẫn file hoặc thư mục mục tiêu cần theo dõi.
-p wa: Kích hoạt bất cứ khi nào một tiến trình ghi (write) vào file hoặc thay đổi các thuộc tính (attribute – quyền, quyền sở hữu) của file.
-k <key_name>: Gắn nhãn bản ghi bằng một khóa lọc tùy chỉnh để lập chỉ mục và tìm kiếm nhanh chóng.
-a always,exit: Ghi lại sự kiện audit ngay khi syscall được chỉ định hoàn tất thực thi.
-F arch=b64: Giới hạn việc lọc cho các system call thuộc kiến trúc 64-bit.

Bước 3: Tải và Kiểm tra các Rule

Biên dịch và nạp các rule mới mà không cần khởi động lại daemon:

sudo augenrules --load

Liệt kê các rule đang hoạt động trong kernel để xác minh chúng đã được nạp chính xác:

sudo auditctl -l

Bước 4: Truy vấn và Lọc Log với `ausearch` và `aureport`

Các bản ghi log thô được lưu trong /var/log/audit/audit.log. Những bản ghi này chứa các đường dẫn dạng hex thô và ID dạng số. Hãy sử dụng ausearch để trích xuất và chuyển đổi chúng thành thông tin dễ đọc.

1. Lọc theo key của rule với các ID đã được chuyển đổi:

sudo ausearch -k identity_changes -i

Cờ -i (interpret) tự động chuyển đổi các UID, GID dạng số và chuỗi mã hóa hex thành các tên định danh dễ đọc như ubuntu, root và /etc/passwd.

2. Tìm kiếm sự kiện trong một khoảng thời gian cụ thể:

sudo ausearch -k ssh_key_tamper -ts today -te now -i

3. Lọc các hành động được khởi tạo bởi một user cụ thể (UID 1000):

sudo ausearch -ua 1000 -i

4. Tạo báo cáo tóm tắt nhanh chóng với aureport:

# Tổng hợp tất cả các thay đổi file trên toàn hệ thống
sudo aureport -f -i --summary

# Liệt kê tất cả các lần xác thực và lệnh sudo thất bại
sudo aureport -au -i --failed

# Đếm tổng số lệnh đã thực thi theo từng file binary
sudo aureport -x -i --summary

Bước 5: Cấu trúc Chi tiết của một Bản ghi Audit Log

Khi ai đó chỉnh sửa một file đang được giám sát, auditd sẽ ghi lại một bản ghi gồm nhiều dòng. Chạy lệnh ausearch -k identity_changes -i sẽ cho ra kết quả tương tự như sau:

type=SYSCALL msg=audit(10/03/2026 10:15:22.412:128) : arch=x86_64 syscall=openat success=yes exit=3 a0=0xffffff9c a1=0x55dc87a21390 a2=0x241 a3=0x1b6 items=2 ppid=1420 pid=2105 auid=ubuntu uid=root euid=root exe=/usr/bin/nano key="identity_changes"
type=PATH msg=audit(10/03/2026 10:15:22.412:128) : item=0 name="/etc/passwd" inode=264104 dev=fc:01 mode=file,644 ouid=root ogid=root rdev=00:00 nametype=NORMAL

Các trường quan trọng cần lưu ý khi điều tra sự cố:

auid=ubuntu: Audit User ID. Trường này lưu giữ danh tính đăng nhập ban đầu. Ngay cả khi người dùng thực hiện sudo su để chuyển sang root, auid vẫn duy trì danh tính thực sự của họ (ubuntu).
uid=root / euid=root: User có hiệu lực thực thi file nhị phân tại thời điểm chạy.
exe=/usr/bin/nano: Đường dẫn chính xác của file nhị phân được gọi.
name="/etc/passwd": File mục tiêu cụ thể đã bị truy cập hoặc chỉnh sửa.
key="identity_changes": Nhãn quy tắc khớp với cấu hình của bạn.

Tóm tắt & Lưu ý Tăng cường Bảo mật cho Production

Kiểm toán ở tầng kernel cung cấp bằng chứng xác thực và không thể chối cãi về những gì đã diễn ra trên hệ thống của bạn. Hãy duy trì các biện pháp bảo vệ vận hành sau:

Ngăn chặn tràn dung lượng đĩa: Chỉnh sửa file /etc/audit/auditd.conf và thiết lập max_log_file = 50 (MB), num_logs = 5 cùng max_log_file_action = ROTATE. Cấu hình này giới hạn dung lượng lưu trữ audit log ở mức tối đa 250 MB.
Tránh tạo log rác (noise): Tuyệt đối không đặt watch ghi không giới hạn trên các thư mục có tần suất thay đổi cao như /tmp, /var/log hoặc các thư mục lưu dữ liệu database đang hoạt động.
Khóa bộ quy tắc: Thêm -e 2 vào dòng cuối cùng của /etc/audit/rules.d/security.rules sau khi đã kiểm thử xong. Thao tác này sẽ đặt các rule ở chế độ bất biến (immutable); không người dùng nào—kể cả root—có thể sửa đổi hoặc dừng quá trình kiểm toán nếu không khởi động lại toàn bộ server.