Nếu đang điều tra một website security incident, đừng chỉ lấy access log. Tối thiểu nên xem theo nhiều lớp: CDN/WAF, web server, application/WordPress, authentication, hosting/system, file/deployment, database và DNS/registrar. Thứ tự ưu tiên phụ thuộc incident, nhưng nguồn có retention ngắn hoặc dễ bị rotate nên được thu trước. Mục tiêu không phải “gom thật nhiều log”, mà là tạo đủ evidence để trả lời: ai/nguồn nào đã làm gì, trên asset nào, vào thời điểm nào, và hành vi đó có liên hệ thế nào với compromise đang điều tra.
Một nguồn log đơn lẻ hiếm khi đủ để kết luận. Access log có thể cho biết request đã xảy ra; audit log có thể cho biết account nào thực hiện thay đổi; file/deploy evidence có thể cho biết thay đổi nào thực sự xuất hiện. Confidence tăng khi các nguồn này khớp nhau về thời gian, identity và hành vi.
Ma trận log cần thu thập
| Nguồn | Dùng để trả lời | Ưu tiên | Retention risk | Output cần giữ |
|---|---|---|---|---|
| CDN/WAF | Request nào bị chặn/cho qua, rule nào hit, nguồn traffic nào bất thường? | P0 | Thường phụ thuộc provider/gói | Raw export + timezone + filter/query |
| Web access/error | URL nào được gọi, status gì, request nào gắn với exploitation/upload/admin action? | P0 | Có thể rotate nhanh | Access/error log read-only + window rõ |
| Authentication | Login, reset, MFA/session/privilege thay đổi khi nào? | P0 | Tùy WordPress/hosting/IdP | Login/reset/session/role events |
| WordPress audit | Ai đổi plugin/theme/user/role/content/config? | P1 | Tùy audit plugin | Application security events |
| System/SSH/hosting | Có shell/session/sudo/service/process activity bất thường không? | P1 | Có thể rotate | Auth/session/service/process logs |
| File/deployment | File nào đổi, thay đổi có trùng release hợp lệ hay không? | P1 | Khác nhau theo stack | Hash/mtime/deploy/change owner |
| Database | Có login/query/change bất thường hoặc record quan trọng bị sửa không? | P1 | Query/audit log có thể không bật | Audit/query log nếu có + snapshot cần thiết |
| DNS/registrar/external service | Domain, DNS, CDN, email hoặc control plane có bị đổi không? | P1 | Tùy provider | Change history + account events |
P0/P1 ở đây là thứ tự collection gợi ý, không phải severity cố định. Nếu evidence ban đầu cho thấy DNS hijack hoặc SSH compromise thì nguồn tương ứng phải được đẩy lên trước.
1. CDN/WAF log: nhìn incident từ lớp edge
CDN/WAF thường cho visibility trước khi request tới origin: source IP, ASN, country, bot score, rule hit, blocked/allowed action, URI, method và một số request metadata. Đây là nguồn rất hữu ích khi cần biết attack pattern đã bắt đầu từ lúc nào, request nào bị chặn và request nào vẫn đi qua.
Nếu website đang dùng WAF, đối chiếu với WAF Monitoring để phân biệt attack trend mới với traffic pattern vốn đã tồn tại trước incident.
2. Web server access và error log: dựng request timeline ở origin
Access log giúp xác định URL, method, response status, IP, user-agent và đôi khi request/upstream time. Hãy tìm chuỗi request quanh initial alert: reconnaissance, exploit attempt, upload, request tới file mới, admin endpoint hoặc các route xuất hiện ngay trước khi compromise được quan sát.
Error log bổ sung PHP error, permission failure, missing file, upstream failure hoặc stack trace. Một error riêng lẻ không chứng minh exploitation, nhưng khi nó xuất hiện đúng lúc với request đáng ngờ và thay đổi file/account thì giá trị evidence tăng đáng kể.
3. WordPress audit log: nối request với hành động trong application
Application log có thể cho biết login/logout, user hoặc role change, plugin/theme install, configuration change, content modification và các action quản trị khác. Đây là context mà access log thường không thể cung cấp đầy đủ.
Nếu site đã có audit trail, dùng Audit log WordPress cho admin activity và security event để kiểm tra event nào có owner hợp lệ và event nào cần đưa vào incident timeline.
4. Authentication và account log: theo dõi identity thay vì chỉ theo IP
Thu login history từ WordPress, hosting control panel, SSH/SFTP, cloud account và identity provider nếu có. Những event đáng chú ý gồm login thành công từ nguồn mới, failed-login pattern, password reset, MFA change, session creation/revocation và privilege change.
Không nên kết luận một IP là attacker chỉ từ access log. Identity event, session event và action sau đăng nhập thường giúp kiểm chứng giả thuyết tốt hơn.
5. System, SSH và hosting log: tìm hoạt động ngoài application
Với VPS/server, auth log, sudo event, SSH session, service/process log và deployment/automation event có thể rất quan trọng. Với shared hoặc managed hosting, khả năng truy cập log phụ thuộc provider; nếu retention ngắn, cần yêu cầu đúng time window trước khi dữ liệu bị rotate.
6. File integrity và deployment/change log: phân biệt compromise với thay đổi hợp lệ
File Integrity Monitoring giúp xác định file nào thay đổi, thời điểm và baseline trước đó. Deployment log giúp trả lời thay đổi có thuộc release hợp lệ hay không. Khi hai nguồn này khớp nhau, false positive giảm đáng kể.
Đối chiếu với WordPress File Integrity Monitoring nếu hệ thống đã có baseline hoặc manifest trước incident.
7. Database evidence: chỉ thu những gì phục vụ hypothesis
Nếu database audit/query log đã được bật phù hợp, chúng có thể giúp tìm login, query bất thường hoặc thay đổi dữ liệu. Nếu không có query log, vẫn có thể cần snapshot hoặc export có kiểm soát của những bảng liên quan trực tiếp tới hypothesis, chẳng hạn users, options, cron hoặc content.
Không nên bật logging nặng trên production chỉ để “có thêm evidence” nếu thay đổi đó có thể làm hệ thống chậm, ghi đè dữ liệu cũ hoặc làm sai trạng thái đang điều tra.
8. DNS, registrar và external service history
Nếu incident có redirect, domain hijack, email compromise hoặc thay đổi routing, cần kiểm tra DNS change history, registrar login, CDN configuration, SMTP/email events và các control-plane service liên quan. Đây là nhóm evidence dễ bị bỏ sót khi đội điều tra chỉ tập trung vào WordPress.
Khóa time window trước khi collection
Đừng chỉ export vài phút quanh alert. Bắt đầu từ event đã biết, rồi mở rộng về trước để tìm initial access và mở rộng về sau để tìm persistence hoặc action tiếp theo. Khi có evidence mới, time window có thể phải mở rộng thêm.
Các nguồn có thể dùng UTC, timezone local hoặc format timestamp khác nhau. Trước correlation, ghi timezone gốc của từng nguồn và chuẩn hóa về một chuẩn chung. Sau đó dùng Incident Timeline để nối các event giữa edge, origin, application, identity và system.
Checklist collection và provenance
- Ghi incident ID, collector, thời gian collection và timezone.
- Khóa time window ban đầu và lý do chọn window đó.
- Ưu tiên nguồn có retention ngắn hoặc đang rotate.
- Lưu bản gốc read-only khi có thể; phân tích trên bản copy.
- Ghi rõ filter/query/export method để người khác có thể tái lập collection.
- Với evidence quan trọng, tạo checksum nếu quy trình điều tra yêu cầu.
- Không bỏ qua nguồn chỉ vì “chưa thấy IOC”; scope/hypothesis mới quyết định nguồn nào cần kiểm tra.
- Không sửa/xóa log hoặc file evidence để “làm sạch” trước khi hoàn tất preservation.
Xem thêm cách bảo toàn evidence khi website bị hack trước khi thực hiện cleanup hoặc thay đổi có thể làm mất dấu vết.
Evidence Handoff Record mẫu
Đây là worksheet để đội phản ứng điền bằng evidence thật; không phải kết quả điều tra đã có sẵn.
incident_id: INC-YYYY-NNN
collection_time_utc: YYYY-MM-DDTHH:MM:SSZ
collector: ...
source: waf|access|error|auth|audit|system|file|database|dns
asset: ...
window_start_utc: ...
window_end_utc: ...
timezone_original: ...
raw_file_or_export: ...
sha256: ...
collection_method: ...
filter_query: ...
retention_note: ...
evidence_ref: ...
notes: ...
Cách correlate nhiều nguồn log
Một workflow thực tế có thể đi theo chuỗi sau:
- Triage alert hoặc IOC ban đầu.
- Xác định asset/account liên quan và phạm vi ảnh hưởng.
- Tìm request/event tương ứng ở CDN/WAF và origin.
- Pivot sang authentication/audit log để xác định identity và action.
- Pivot sang file/deployment/database evidence để kiểm tra thay đổi thực tế.
- Đưa các event có confidence đủ cao vào incident timeline.
- Mở rộng hoặc thu hẹp scope dựa trên evidence mới, không dựa vào phỏng đoán.
Quy trình nên bắt đầu bằng Incident Triage, sau đó mới collection có mục tiêu. Export mọi log không có hypothesis dễ tạo nhiều dữ liệu nhưng ít khả năng trả lời câu hỏi điều tra.
PASS/FAIL cho bước log collection
- PASS: các nguồn ưu tiên đã được bảo toàn trong time window phù hợp; timezone/provenance rõ; evidence đủ để tiếp tục timeline, scoping hoặc RCA.
- FAIL: chỉ có một nguồn log, không biết timezone, không biết ai export, retention window bị mất, hoặc collection không gắn với câu hỏi điều tra cụ thể.
- Không được coi là PASS chỉ vì “đã tải rất nhiều log”. Task hoàn tất khi evidence có thể được truy vết, correlate và dùng để kiểm chứng hypothesis.
Nguồn tham khảo
OWASP Logging Cheat Sheet nhấn mạnh application logging và tính nhất quán của event data. NIST SP 800-61 Rev. 3 đặt log/evidence trong quy trình Incident Response liên tục gắn với detection, response và recovery.