Cấu hình Linux Auditd: Giám sát file nhạy cảm và phát hiện lệnh trái phép

Table of Contents

Sự cố thực tế: Cảnh báo can thiệp hệ thống production lúc 2 giờ sáng

Vào lúc 2:14 sáng ngày thứ Ba, máy nhắn tin của tôi rung bần bật trên đầu giường. Một node thanh toán production đang xử lý 450 giao dịch mỗi giây bất ngờ kích hoạt cảnh báo mức độ nghiêm trọng cao. Một web daemon đã tạo phiên interactive bash shell trái phép, ngay sau đó là sự cố sai lệch checksum trên /etc/pam.d/common-auth. Chỉ trong vòng tám phút, các yêu cầu thanh toán bắt đầu đổ về hàng loạt lỗi 401 Unauthorized.

Tôi lập tức remote vào hệ thống qua bastion WireGuard, nheo mắt nhìn vào các cửa sổ terminal. Quy trình điều tra sự cố truyền thống nhanh chóng đi vào ngõ cụt. Lệnh history chỉ trả về các dòng trống rỗng vì kẻ xâm nhập đã mở session bằng thủ thuật khoảng trắng ở đầu dòng và hủy gán biến HISTFILE. Kiểm tra timestamp bằng ls -la cho thấy file bị thay đổi lúc 02:11 UTC. Nhưng nó không thể cho tôi biết ai đã sửa đổi, tiến trình cha nào đã thực hiện lệnh ghi, hay tài khoản nào đã leo thang đặc quyền.

File /var/log/syslog tập trung chứa tới 14 GB dữ liệu nhiễu từ các log truy cập Nginx thông thường và health check của microservice. Kẻ tấn công đã thay đổi thông tin xác thực ngay trước mắt chúng tôi, còn hệ thống logging mặc định của Linux thì hoàn toàn bất lực.

Phân tích nguyên nhân gốc rễ: Vì sao log Linux mặc định thất bại khi điều tra số

Nguyên nhân bắt nguồn từ thiết kế kiến trúc: các log tiêu chuẩn nằm ở userland. Application log, lịch sử shell và cơ chế syslog đều dựa trên việc tự nguyện ghi nhận. Nếu một daemon không có đặc quyền tạo ra reverse shell hoặc bỏ qua việc gọi syslog(), tiến trình thực thi đó sẽ không bao giờ xuất hiện trong log ở userland.

Các công cụ ở userland cũng không thể giám sát ranh giới của system call. Khi kẻ tấn công gọi execve, mở shell qua Python hoặc đọc /etc/shadow bằng openat, các công cụ như ps hay lsof chỉ ghi lại được snapshot tại một thời điểm nhất định. Chúng bỏ sót các tiến trình bộc phát trong thời gian ngắn. Hơn nữa, kẻ tấn công chiếm được quyền root qua cấu hình sai của sudoer có thể xóa sạch /var/log/auth.log chỉ trong ba giây.

Để đảm bảo tính giải trình đáng tin cậy, hệ thống cần các hook ở cấp độ kernel. Chúng ta cần những hook ghi lại chính xác từng syscall, theo dõi định danh đăng nhập ban đầu (auid) và ghi log chống giả mạo trước khi các tiến trình độc hại kịp dọn sạch dấu vết.

So sánh giải pháp: Công cụ Userland vs. Kiểm tra tính toàn vẹn file vs. Kernel Auditing

Các đội ngũ kỹ sư thường cân nhắc ba lựa chọn khi giám sát hệ thống production:

Process Accounting (psacct / acct): Ghi lại các lệnh cùng mức tiêu thụ CPU và bộ nhớ. Tuy nhiên, công cụ này bỏ qua thao tác đọc, ghi file và kết nối socket. Kẻ tấn công có thể dễ dàng qua mặt bằng cách đổi tên file nhị phân trước khi chạy.
File Integrity Monitoring (AIDE / Tripwire): Định kỳ so sánh cơ sở dữ liệu với mã băm mật mã. Dù có thể cảnh báo việc ai đó đã can thiệp vào /etc/pam.d/common-auth, nhưng nó lại chạy dưới dạng cron job—thường trễ nhiều tiếng đồng hồ. Nó không thể chỉ ra process descriptor đang hoạt động hay cho biết user nào đã thực hiện lệnh ghi.
Linux Audit Daemon (Auditd): Nằm trực tiếp trong audit pipeline của nhân Linux. Mọi system call đều phải đi qua các bộ lọc audit trước khi quá trình thực thi hoàn tất. Nó giữ nguyên UID đăng nhập gốc (auid)—ngay cả khi dùng các lệnh như sudo -i hay su—đồng thời ghi lại chính xác đường dẫn binary, thư mục làm việc và PID tiến trình cha theo thời gian thực.

Phương pháp tối ưu: Cấu hình Linux Auditd chuẩn Production

Dưới đây là phương án triển khai Auditd bảo mật cao mà chúng tôi đã áp dụng trên 120 node production để triệt tiêu các điểm mù điều tra số.

1. Cài đặt và kích hoạt Auditd

Auditd có sẵn trong kho package chính thức của hầu hết các bản phân phối Linux phổ biến. Trên Debian và Ubuntu:

sudo apt update && sudo apt install -y auditd audispd-plugins
sudo systemctl enable auditd
sudo systemctl start auditd

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

sudo dnf install -y audit audit-libs
sudo systemctl enable auditd
sudo systemctl start auditd

2. Thiết lập quy tắc bảo mật cho Auditd

Quản trị viên hệ thống đặt các file quy tắc tùy chỉnh trong thư mục /etc/audit/rules.d/. Tuyệt đối không chỉnh sửa trực tiếp /etc/audit/audit.rules; quá trình khởi động hệ thống sẽ định kỳ tạo lại file đó bằng augenrules. Hãy tạo một file cấu hình tùy chỉnh tại /etc/audit/rules.d/99-security-hardening.rules:

sudo nano /etc/audit/rules.d/99-security-hardening.rules

Thêm các chỉ thị sau vào file:

# Xóa toàn bộ quy tắc cũ trong bộ nhớ
-D

# Thiết lập kích thước buffer cho kernel audit (giá trị từ 8192 đến 32768 phù hợp với các node lưu lượng cao)
-b 8192

# Xử lý khi tràn buffer: 1 = cảnh báo syslog, 2 = kernel panic
-f 1

# Giám sát thay đổi đối với file định danh và cơ sở dữ liệu xác thực
-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
-w /etc/security/ -p wa -k pam_security
-w /etc/pam.d/ -p wa -k pam_security
-w /etc/sudoers -p wa -k sudoers_tampering
-w /etc/sudoers.d/ -p wa -k sudoers_tampering

# Giám sát cấu hình SSH server và vị trí authorized key
-w /etc/ssh/sshd_config -p wa -k ssh_config_tampering
-w /root/.ssh/ -p wa -k root_ssh_keys

# Theo dõi việc thực thi binary (không phải daemon) bởi người dùng tương tác (UID >= 1000)
-a always,exit -F arch=b64 -S execve -F auid>=1000 -F auid!=4294967295 -k command_execution
-a always,exit -F arch=b32 -S execve -F auid>=1000 -F auid!=4294967295 -k command_execution

# Theo dõi việc gọi các công cụ leo thang đặc quyền
-w /bin/su -p x -k priv_escalation
-w /usr/bin/sudo -p x -k priv_escalation
-w /usr/bin/passwd -p x -k password_mod

# Khóa cấu hình audit vào bộ nhớ kernel cho đến khi reboot
-e 2

Dưới đây là ý nghĩa của các cờ này. Cờ -w chỉ định đường dẫn cần theo dõi, còn -p wa giám sát các thao tác ghi và thay đổi thuộc tính của file. Cờ -k gắn nhãn sự kiện khớp bằng một chuỗi định danh có thể tìm kiếm. Đối với giám sát tiến trình, -S execve ghi lại các lệnh được gọi từ tài khoản có UID từ 1000 trở lên, bỏ qua các phiên kernel chưa được gán UID (UID 4294967295). Cuối cùng, -e 2 khóa cấu hình trực tiếp trong bộ nhớ. Sau khi thiết lập, ngay cả người dùng root cũng không thể xóa quy tắc hay vô hiệu hóa daemon mà không khởi động lại máy chủ.

Biên dịch và áp dụng file quy tắc mới:

sudo augenrules --load

3. Bảo mật vận hành & Kiểm soát truy cập

Kernel auditing cho bạn biết điều gì đã xảy ra, nhưng chính sách thông tin xác thực nghiêm ngặt mới là thứ ngăn chặn cuộc tấn công ngay từ đầu. Kẻ tấn công thu thập hoặc brute-force thông tin xác thực quản trị có thể vượt qua hoàn toàn các lớp kiểm soát truy cập thông thường.

Khi khởi tạo jump box hay tài khoản production bastion, hãy tạo mật khẩu dài và ngẫu nhiên bằng công cụ tạo mật khẩu tại toolcraft.app/vi/tools/security/password-generator — quá trình thực thi Web Cryptography phía client đảm bảo không truyền dữ liệu qua mạng. Sử dụng mật khẩu mạnh kết hợp với các quy tắc kernel bất biến sẽ loại bỏ hoàn toàn các con đường xâm nhập ban đầu dễ dàng.

4. Điều tra sự cố với ausearch và aureport

Tránh tìm kiếm trực tiếp trong các dòng log thô của /var/log/audit/audit.log bằng grep. Các bản ghi log này rất dày đặc và mã hóa tham số dưới dạng chuỗi thập lục phân. Thay vào đó, hãy truy vấn theo tag bằng ausearch và aureport.

Truy vấn mọi sự kiện được ghi nhận dưới key pam_security:

sudo search -k pam_security -i

Thêm tùy chọn -i sẽ chuyển đổi ID system call thô và UID dạng số sang tên định danh dạng văn bản rõ ràng. Một sự kiện xâm nhập sẽ hiển thị metadata mạch lạc:

type=PROCTITLE msg=audit(10/22/2026 02:14:18.102:491) : proctitle=nano /etc/pam.d/common-auth
type=SYSCALL msg=audit(10/22/2026 02:14:18.102:491) : arch=x86_64 syscall=openat success=yes exit=3 a0=0x7ffd9b8 ... exe=/usr/bin/nano key="pam_security" auid=deployer uid=root

Hãy quan sát kỹ các ID. Trong khi UID hiện tại hiển thị uid=root, ID audit bất biến lại ghi rõ auid=deployer. Dù kẻ tấn công đã leo thang lên toàn quyền root, kernel vẫn ghi nhớ phiên làm việc này bắt nguồn từ tài khoản deployer. Chỉ một dòng log đó đã xác định chính xác vector tấn công.

Để xem bản tóm tắt tổng hợp các lần đăng nhập thất bại và các lệnh đã thực thi trong ngày hôm qua, hãy chạy:

sudo aureport --start yesterday --executable --summary
sudo aureport --auth --failed

Việc cấu hình Auditd chỉ mất khoảng mười phút cho mỗi máy chủ. Sự đầu tư ngắn ngủi này giúp biến các sự cố hỗn loạn lúc nửa đêm thành quy trình hậu kiểm có cấu trúc và đầy đủ chứng cứ xác thực.