Access log là nhật ký các yêu cầu mà máy chủ web đã nhận. Khi website WordPress bị xâm nhập, log có thể giúp trả lời ba câu hỏi quan trọng: request nào xảy ra trước thay đổi trái phép, URL nào bị khai thác và hoạt động tiếp theo đến từ đâu. Tuy nhiên, một dòng log đơn lẻ hiếm khi đủ để kết luận.
Bắt đầu từ thời điểm phát hiện tệp, tài khoản hoặc nội dung lạ rồi mở rộng cửa sổ thời gian về trước và sau. Không tìm “IP xấu” trước; hãy tìm chuỗi hành vi có quan hệ nhân quả.
Một dòng access log thường cho biết gì?
Tùy cấu hình Nginx hoặc Apache, log thường có địa chỉ nguồn, thời gian, phương thức và đường dẫn request, mã phản hồi, dung lượng, referer và user-agent. Nếu website đi qua Cloudflare hoặc reverse proxy, cần biết máy chủ đang ghi IP proxy hay IP khách đã được chuẩn hóa. Nếu không, việc quy hoạt động cho một nguồn sẽ sai.
Bắt đầu từ một mốc thời gian đáng tin
Mốc tốt có thể là thời gian tệp PHP mới được tạo, lúc tài khoản Administrator lạ đăng ký, lúc Google phát hiện URL spam hoặc thời điểm khách báo chuyển hướng. Hãy ghi timezone của log và hệ điều hành; lệch múi giờ là nguyên nhân phổ biến khiến đội xử lý nối sai sự kiện.
Những mẫu request cần ưu tiên điều tra
- POST tới plugin, theme hoặc endpoint AJAX ngay trước khi tệp mới xuất hiện.
- Request tới tệp PHP trong uploads hoặc thư mục không nên thực thi mã.
- Chuỗi đăng nhập thành công sau nhiều lần thất bại, đặc biệt ngoài giờ vận hành.
- Request có tham số dài, mã hóa hoặc payload khác hẳn lưu lượng bình thường.
- Request lặp lại tới một backdoor sau khi website đã được làm sạch.
Đọc theo phiên thay vì đọc từng dòng
Nhóm log theo IP, cookie, user-agent và khoảng thời gian để dựng một phiên tương đối. Một chuỗi có thể bắt đầu bằng quét phiên bản, tiếp theo là POST khai thác, gọi tệp vừa tạo, đăng nhập hoặc chèn nội dung. IP có thể thay đổi và user-agent có thể giả, vì vậy cần đối chiếu cả URL, timing và hậu quả trên file/database.
Các mã trạng thái nói gì?
200 không chứng minh request thành công về mặt khai thác; 404 cũng không có nghĩa vô hại. Mã 302 có thể phản ánh chuyển hướng, 403 cho thấy request bị chặn, 500 có thể xuất hiện khi payload gây lỗi. Giá trị chỉ rõ hơn khi đặt cạnh response size, đường dẫn và thay đổi hệ thống cùng thời điểm.
Giữ log đúng cách
Sao chép log sang nơi chỉ đọc trước khi lọc, giữ file gốc và ghi lại thời gian lấy. Nếu log đã rotate hoặc nén, thu thập cả các phiên bản liên quan. Không đưa IP, cookie, token hoặc dữ liệu cá nhân nguyên trạng vào công cụ công cộng.
Log không được bật, bị giữ quá ngắn, sai timezone hoặc thiếu header từ proxy có thể làm mất dấu vết. Khi đó cần kết hợp file timestamp, audit log, database và log của CDN/hosting.
Nguồn tham khảo chính thức
Nginx mô tả `access_log`, `log_format` và các biến như request, status, referer, user-agent trong ngx_http_log_module. Quy trình WordPress sau xâm nhập nhấn mạnh việc ghi nhận triệu chứng và timeline trong FAQ My site was hacked.
Log không nói “đây là attacker”, nhưng kể được chuỗi hành động
Một request 200 riêng lẻ không đáng ngờ. Nhưng upload file, gọi file đó, đăng nhập admin rồi sửa plugin trong vài phút tạo thành câu chuyện khác. Điều tra cần tương quan theo thời gian, IP, user, request ID và đường dẫn.
Khoảng trống log cũng là một phát hiện
Rotation quá ngắn, timestamp lệch, CDN che IP gốc hoặc log chỉ nằm trên server bị chiếm đều làm mất khả năng kết luận. Ghi rõ dữ liệu nào không có và mức độ chắc chắn; đừng biến suy đoán thành nguyên nhân chính thức.
Ưu tiên các mốc thay đổi trạng thái
- Login thất bại rồi thành công.
- Upload, POST hoặc response bất thường trước lúc file đổi.
- Tạo user, cron, plugin hoặc API token.
- Kết nối outbound và email tăng đột biến.
Giữ bản sao log tách biệt, đồng bộ thời gian và giới hạn quyền đọc. Log vừa là bằng chứng bảo mật vừa có thể chứa dữ liệu nhạy cảm.
Khi IP không còn là danh tính
Proxy, NAT, botnet và VPN khiến một IP không đủ kết luận. Hãy kết hợp session, user-agent, request pattern, tài khoản và hành động tiếp theo. Báo cáo nên nói “nguồn quan sát được” thay vì khẳng định ai đứng sau khi chưa có bằng chứng.
Cụm điều tra mã độc WordPress
Đi từ dấu vết kỹ thuật đến kết luận có thể kiểm chứng.
Câu hỏi thường gặp
Access log có chứng minh chính xác ai tấn công không?
Không. IP và user-agent có thể qua proxy hoặc bị giả; log chủ yếu giúp dựng chuỗi request và đối chiếu hành vi.
Mã trạng thái 200 có nghĩa khai thác thành công không?
Không nhất thiết. Cần đối chiếu response, file/database và hoạt động tiếp theo.
Nên giữ access log bao lâu?
Tùy rủi ro và yêu cầu vận hành, nhưng phải đủ dài hơn thời gian trung bình phát hiện sự cố và tuân thủ quy định dữ liệu.
Cần điều tra website theo dữ liệu thực tế?
WebAnToan có thể rà log, file, database, cron và tài khoản để xác định phạm vi cùng thứ tự xử lý.
