Logrotate Và Audit Log Trên Linux: Thiết Kế Vòng Đời Log An Toàn Cho Production

Trong production, log không chỉ để “xem lỗi”. Log là bằng chứng vận hành, nguồn dữ liệu cho SIEM, căn cứ điều tra incident và đôi khi là yêu cầu tuân thủ. Nếu để log phình vô hạn, máy chủ có thể đầy disk và ngừng dịch vụ. Nếu rotate quá sớm hoặc xóa quá nhanh, đội vận hành mất dấu vết khi cần truy vết sự cố. Vì vậy logrotate audit log Linux là một chủ đề nhỏ nhưng cực kỳ thực chiến với sysadmin.

Bài này hướng dẫn cách thiết kế vòng đời log trên Linux: phân loại log, cấu hình logrotate, nén và retention, phối hợp với journald/auditd, gửi log về SIEM, kiểm tra lỗi thường gặp và checklist nghiệm thu trước khi áp dụng cho server production.

1. Bối cảnh production: vì sao quản lý vòng đời log quan trọng?

Một máy chủ web bình thường có thể sinh ra access log, error log, application log, system log, audit log và log của agent monitoring. Khi traffic tăng hoặc ứng dụng bị lỗi lặp, log có thể tăng từ vài trăm MB lên hàng chục GB trong vài giờ. Điều nguy hiểm là sự cố đầy disk thường kéo theo lỗi dây chuyền: database không ghi được, service không tạo socket, backup fail và monitoring cũng ngừng gửi metric.

• Giữ đủ log để điều tra incident và đáp ứng yêu cầu audit.
• Không để log chiếm toàn bộ phân vùng / hoặc /var.
• Nén log cũ để tiết kiệm dung lượng.
• Không làm mất log khi service vẫn đang ghi file.
• Chuẩn hóa retention theo mức độ quan trọng của từng loại log.

2. Phân loại log trước khi cấu hình

Đừng áp một chính sách rotate cho mọi thứ. Access log có thể rất lớn nhưng ít nhạy cảm hơn audit log. Application debug log có thể giữ ngắn ngày. Security log cần retention dài hơn và nên đẩy về hệ thống tập trung.

• System log: syslog, messages, kern.log, auth.log — thường giữ 30-90 ngày tùy môi trường.
• Application log: /var/log/myapp/*.log — retention phụ thuộc SLA điều tra lỗi.
• Web log: nginx/apache access/error log — rotate hằng ngày hoặc theo size.
• Audit log: /var/log/audit/audit.log — nhạy cảm, cần bảo vệ quyền đọc và gửi về SIEM.
• Agent log: monitoring, backup, EDR — tránh để debug mode chạy quá lâu.

3. Kiểm tra hiện trạng log trên server

Trước khi chỉnh cấu hình, hãy đo hiện trạng. Mục tiêu là biết thư mục nào tăng nhanh, file nào chưa được rotate và phân vùng nào có rủi ro đầy.

# Kiểm tra dung lượng phân vùng
 df -h

# Top thư mục/file log lớn nhất
sudo du -xh /var/log | sort -h | tail -30
sudo find /var/log -type f -size +500M -printf '%s %p
' | sort -n | tail

# Kiểm tra file đang được process giữ mở nhưng đã bị xóa
sudo lsof +L1 | grep '/var/log' || true

Nếu thấy file log đã xóa nhưng process vẫn giữ descriptor, dung lượng disk có thể chưa được giải phóng. Khi đó cần reload/restart đúng service thay vì chỉ xóa file.

4. Cấu hình logrotate cơ bản

Trên hầu hết distro, logrotate chạy qua cron hoặc systemd timer. File chính là /etc/logrotate.conf, còn cấu hình từng ứng dụng nằm trong /etc/logrotate.d/. Ví dụ dưới đây dành cho application log.

# /etc/logrotate.d/myapp
/var/log/myapp/*.log {
    daily
    rotate 14
    missingok
    notifempty
    compress
    delaycompress
    dateext
    create 0640 myapp adm
    sharedscripts
    postrotate
        systemctl reload myapp >/dev/null 2>&1 || true
    endscript
}

• daily: rotate hằng ngày.
• rotate 14: giữ 14 bản cũ.
• compress/delaycompress: nén log cũ nhưng chờ một vòng để tránh nén file service còn ghi.
• create: tạo file mới với quyền/user/group đúng.
• postrotate: reload service để mở file log mới nếu ứng dụng không tự xử lý signal.

5. Rotate theo dung lượng cho log tăng nhanh

Với access log hoặc debug log tăng bất thường, rotate theo ngày có thể chưa đủ. Khi cần giới hạn rủi ro disk, dùng thêm size hoặc maxsize.

/var/log/nginx/*.log {
    daily
    maxsize 500M
    rotate 30
    missingok
    notifempty
    compress
    delaycompress
    sharedscripts
    postrotate
        [ -s /run/nginx.pid ] && kill -USR1 $(cat /run/nginx.pid)
    endscript
}

Với nginx, tín hiệu USR1 yêu cầu master process mở lại log file mới mà không cần restart toàn bộ dịch vụ. Đây là cách an toàn hơn trong production so với restart nóng vội.

6. Kiểm thử logrotate trước khi áp dụng

Sai cấu hình logrotate có thể làm log không được rotate, mất quyền ghi hoặc spam lỗi mỗi ngày. Luôn kiểm thử bằng chế độ debug trước, sau đó force rotate trên môi trường lab hoặc maintenance window.

# Debug, không thực thi thay đổi
sudo logrotate -d /etc/logrotate.d/myapp

# Force rotate để kiểm tra thực tế
sudo logrotate -f /etc/logrotate.d/myapp

# Xem trạng thái lần rotate gần nhất
sudo cat /var/lib/logrotate/status | grep myapp -A3

Output debug cần cho thấy đúng file match, đúng policy và không báo lỗi permission. Sau khi force, kiểm tra service vẫn ghi vào file log mới.

7. Journald: đừng quên log của systemd

Nhiều service ghi log vào journald thay vì file riêng. Nếu không giới hạn journald, /var/log/journal cũng có thể tăng lớn. Cấu hình nằm ở /etc/systemd/journald.conf.

# /etc/systemd/journald.conf
[Journal]
SystemMaxUse=2G
SystemKeepFree=5G
MaxRetentionSec=30day
Compress=yes

sudo systemctl restart systemd-journald
journalctl --disk-usage
journalctl -u nginx --since "1 hour ago" --no-pager | tail -50

Trong production, nên đặt SystemKeepFree để journald tự nhường dung lượng khi disk gần đầy. Tuy nhiên đừng xem đây là thay thế cho log tập trung; journald local vẫn có thể mất khi server hỏng.

8. Auditd và log bảo mật

Audit log ghi nhận hành vi nhạy cảm như thay đổi file cấu hình, sudo, login, thay đổi user/group hoặc truy cập file quan trọng. Đây là loại log cần bảo vệ kỹ hơn application log.

# Kiểm tra auditd
sudo systemctl status auditd --no-pager
sudo auditctl -s

# Ví dụ rule theo dõi thay đổi file sudoers
sudo auditctl -w /etc/sudoers -p wa -k sudoers_change
sudo ausearch -k sudoers_change | tail -50

Với auditd, cần xem thêm /etc/audit/auditd.conf vì auditd có cơ chế rotate riêng như max_log_file, num_logs, space_left_action. Đừng cấu hình chồng chéo khiến logrotate và auditd cùng tranh nhau file audit.log.

9. Gửi log về SIEM hoặc log central

Retention local chỉ là lớp đầu tiên. Với hệ thống quan trọng, log nên được ship về Loki, Elasticsearch/OpenSearch, Splunk, Wazuh hoặc SIEM tương đương. Khi server bị compromise, log local có thể bị xóa; log đã gửi ra ngoài giúp giữ bằng chứng.

• Đặt timestamp chuẩn UTC hoặc timezone thống nhất.
• Gắn hostname, environment, service, application version vào log.
• Mask dữ liệu nhạy cảm như password, token, Authorization header.
• Theo dõi lag của log shipper để biết khi nào log không được gửi đi.
• Có cảnh báo khi log volume tăng bất thường hoặc đột ngột bằng 0.

10. Lỗi thường gặp và cách xử lý

10.1. Log đã rotate nhưng service vẫn ghi vào file cũ

Nguyên nhân là service giữ file descriptor cũ. Cần postrotate đúng cách: reload service, gửi signal USR1 cho nginx hoặc cấu hình ứng dụng reopen log. Kiểm tra bằng lsof.

sudo lsof | grep deleted | grep log
sudo systemctl reload myapp
sudo lsof | grep '/var/log/myapp' | head

10.2. Permission sai làm ứng dụng không ghi được log

Sau rotate, file mới được tạo bởi logrotate. Nếu create sai user/group/mode, ứng dụng có thể lỗi permission denied. Xác định user chạy service bằng systemctl status hoặc unit file.

10.3. Log chứa dữ liệu nhạy cảm

Đây không phải lỗi logrotate mà là lỗi thiết kế logging. Cần sửa application để mask secret trước khi ghi log. Log đã lộ secret nên được xử lý như incident bảo mật: rotate secret, giới hạn quyền truy cập log và ghi nhận phạm vi ảnh hưởng.

11. Runbook triển khai an toàn

• Bước 1: đo dung lượng hiện tại bằng du/find/journalctl.
• Bước 2: phân loại log theo system, app, web, audit, agent.
• Bước 3: viết cấu hình trong /etc/logrotate.d/ theo từng service.
• Bước 4: chạy logrotate -d để debug.
• Bước 5: force rotate trên lab/staging hoặc server ít rủi ro.
• Bước 6: xác nhận service vẫn ghi log mới và không còn file deleted bị giữ mở.
• Bước 7: cấu hình cảnh báo disk, log volume và log shipper lag.
• Bước 8: cập nhật tài liệu retention và owner của từng loại log.

12. Checklist nghiệm thu

• Không có file log tăng vô hạn ngoài chính sách.
• Phân vùng /var còn đủ dung lượng theo ngưỡng vận hành.
• Logrotate chạy không lỗi trong debug mode.
• File log mới có đúng owner/group/mode.
• Service reload/reopen log không gây downtime.
• Audit log không bị rotate chồng chéo sai cơ chế.
• Log quan trọng đã được gửi về hệ thống tập trung.
• Có cảnh báo khi disk gần đầy hoặc log shipper dừng gửi.
• Retention phù hợp yêu cầu điều tra và tuân thủ.

13. Bài lab cuối bài

• Tạo thư mục /var/log/labapp và sinh file labapp.log khoảng 200MB bằng dd hoặc script.
• Viết file /etc/logrotate.d/labapp rotate theo size 50M, giữ 5 bản, nén log cũ.
• Chạy logrotate -d để xem kế hoạch rotate.
• Chạy logrotate -f và kiểm tra file .gz được tạo.
• Mô phỏng process giữ file cũ rồi dùng lsof +L1 để phát hiện.
• Cấu hình journald SystemMaxUse nhỏ trên máy lab và kiểm tra journalctl –disk-usage.

Kết luận

Quản lý log tốt không phải là xóa log cho nhẹ máy. Đó là thiết kế vòng đời log có chủ đích: giữ đủ để điều tra, nén và rotate để bảo vệ disk, bảo vệ audit log, gửi dữ liệu quan trọng về hệ thống tập trung và kiểm tra định kỳ. Với sysadmin, logrotate audit log Linux là một nền tảng vận hành nhỏ nhưng giúp tránh rất nhiều sự cố production khó chịu.