Server Audit Logging là việc ghi lại các sự kiện đủ để trả lời khi có incident: ai đăng nhập, ai dùng quyền đặc biệt, service/config nào thay đổi, package nào được cài, process nào lỗi và activity nào xảy ra quanh thời điểm sự cố. Mục tiêu không phải log mọi byte, mà là giữ đúng evidence với timestamp, identity, outcome và retention phù hợp.
Linux Audit có thể ghi security-relevant events gắn với user identity và outcome; Red Hat lưu ý audit không tự làm hệ thống an toàn hơn, nhưng giúp phát hiện vi phạm policy và điều tra hành động. Vì vậy logging phải đi cùng access control, alerting, review và incident response.
Time, identity và system-change evidence
1. Trước hết phải có thời gian chính xác
Log từ SSH, web server, database và audit chỉ correlate được khi clock đúng. Kiểm tra:
timedatectlTime sync failure là finding vận hành/security vì timeline incident có thể sai.
2. Authentication events
Cần ghi được login success/failure, user, source và authentication method khi platform hỗ trợ. Với SSH, event thường nằm trong journal hoặc auth log tùy distro. Cấu hình authentication, allowed users/groups và source access của SSH thuộc SSH Hardening; logging ở đây giữ vai trò evidence cho những policy đó.
Không chỉ alert failed login; successful login từ source/time bất thường đôi khi quan trọng hơn.
3. Privileged actions
sudo/root escalation cần gắn với identity ban đầu. Nếu mọi admin dùng shared root account, audit trail mất giá trị. Kết hợp với Root, sudo và Least Privilege.
4. User/group và access-policy changes
Ghi hoặc giám sát thay đổi:
- User/group tạo/xóa.
- SSH authorized_keys.
- sudoers.
- Service account.
- Authentication config.
Đây là persistence/privilege path quan trọng.
5. Service lifecycle
Start/stop/restart/failure của web server, database, PHP-FPM, SSH, firewall agent và security agent cần có evidence. Service restart ngoài change window có thể là incident signal hoặc operational drift.
6. Package/software changes
Package install/update/remove có thể thay attack surface. Red Hat Audit có rule mẫu cho software installers ở một số release. Dù distro nào, patch/change record nên cho biết package nào đổi và khi nào. Quy trình ưu tiên, rollout, restart/reboot và rollback của patch thuộc Linux Patch Management; audit log chỉ giữ evidence cho change đó.
Network, application, data và backup evidence
7. Firewall/network changes
Firewall rule, listening port và network service thay đổi nên được theo dõi theo change process. Không cần log mọi packet; ưu tiên control-plane change và deny/drop signal có giá trị. Intended inbound policy và read-back ruleset thuộc Linux Firewall cho Web Server.
8. SSH configuration changes
Thay đổi sshd_config, include, authorized key và login policy có blast radius lớn. File-change auditing có thể hữu ích, nhưng phải test volume và rule scope.
9. Web server/application config changes
Nginx/Apache/PHP-FPM config, virtual host, document root và runtime settings cần change trail. Nếu config management quản lý chúng, source repository + deployment log có thể là evidence tốt hơn chỉ file mtime.
10. Secret access và rotation
Không log plaintext secret. Thay vào đó log metadata: secret ID, consumer/identity, action, result và rotation/revocation time. Xem Server Secrets Management.
11. Web access/error logs
Web logs hỗ trợ điều tra request path, status, source và upstream errors. Nếu sau CDN/proxy, client-IP trust chain phải đúng. Không đưa Authorization header, password hoặc sensitive token vào log format.
12. Database logs
Giữ error/startup/authentication/admin events theo need. General query log có thể quá verbose và chứa sensitive data; không bật vô hạn chỉ để “audit”. Chọn database audit facility phù hợp risk/compliance.
13. Backup/restore events
Ai tạo/download/restore backup là event security quan trọng vì backup chứa dữ liệu và secret. Restore production cũng là change có blast radius lớn.
Audit pipeline, retention và alerting
14. Auditd khi nào cần?
Linux Audit hữu ích khi cần kernel/audit-rule level evidence cho file, syscall, identity hoặc compliance control. Không copy một bộ rules hàng nghìn dòng nếu không có storage/analysis capacity. Rule quá rộng tạo noise và có thể ảnh hưởng vận hành.
15. Journal và audit log khác nhau
systemd journal tập hợp log từ service/process; Linux Audit là security auditing subsystem riêng. Chúng bổ sung nhau. Một incident timeline thường cần cả service logs, journal, application logs và audit events.
16. Retention và disk-full policy
Log giữ quá ngắn làm mất evidence; giữ quá lâu không kiểm soát tăng cost/privacy risk. Audit log volume cần storage policy, rotation và action khi gần đầy. Red Hat khuyến nghị đặc biệt quan tâm filesystem chứa audit log trong môi trường nghiêm ngặt.
17. Centralize log khi risk yêu cầu
Nếu attacker đạt root, local log có thể bị sửa/xóa. Forward log tới hệ thống khác có thể tăng khả năng giữ evidence. Nhưng central logging cũng cần TLS/access control, retention và clock sync.
18. Alert phải dựa trên actionability
Các signal đáng alert có thể gồm:
- Privileged login từ source mới.
- User/sudoers/SSH key changes.
- Security service disabled.
- Unexpected package install.
- Firewall rule mở admin/database port.
- Repeated auth failures + successful login.
- Log pipeline stopped hoặc disk gần đầy.
19. Không biến log thành secret leak
Review debug mode, stack trace, request dump và CI/CD output. Secret xuất hiện trong log cần rotation/revocation, không chỉ masking ở dashboard.
20. Test logging trước incident
Tạo một event hợp lệ có kiểm soát, ví dụ login test hoặc service restart trong maintenance window, rồi xác minh event xuất hiện ở đúng nơi, timestamp đúng và operator tìm được nó. Sau production, sức khỏe của logging pipeline nên được kiểm tra định kỳ trong Server Security Maintenance thay vì chỉ test một lần khi go-live.
Audit Logging Register mẫu
Đây là template evidence, không phải trạng thái logging thực tế của SecureWebOps.
| Event | Source | Retention | Owner | Alert | Validation |
|---|---|---|---|---|---|
| SSH login | Journal/auth log | Policy-defined | Ops/Security | Risk-based | PASS/FAIL |
| sudo action | Journal/audit | Policy-defined | Ops/Security | Privileged anomalies | PASS/FAIL |
| Config change | Audit/CM/deploy log | Policy-defined | Platform | Unexpected change | PASS/FAIL |
Checklist Server Audit Logging
- Clock/time sync đúng.
- SSH login success/failure có evidence.
- sudo/privileged actions gắn identity.
- User/group/key/sudoers changes được theo dõi.
- Service lifecycle có log.
- Package/software change có trail.
- Firewall/control-plane change observable.
- Web/database logs phù hợp.
- Secret không bị log plaintext.
- Backup/restore có trail.
- Audit rules có purpose rõ.
- Retention/rotation/disk-full policy rõ.
- Central forwarding khi threat model yêu cầu.
- Alert dựa trên actionability.
- Logging được test định kỳ.
Nguồn kỹ thuật tham khảo
Kết luận
Audit logging có giá trị khi nó giúp reconstruct một timeline và gắn action với identity. Log volume lớn nhưng không ai tìm được event quan trọng thì không phải control tốt.
Ưu tiên authentication, privilege, identity/config/package/network changes, backup và control health; giữ timestamp/retention đúng và test retrieval trước khi incident xảy ra.