Bảo mật website5 phút đọc

Cách kiểm tra file WordPress bị sửa trái phép bằng checksum

Kiểm tra file WordPress bị sửa hoặc tạo mới bằng checksum, nguồn sạch và timeline; hiểu giới hạn của WP-CLI verify-checksums.

Kỹ sư WebAnToan so sánh file WordPress với checksum và bản nguồn sạch
Checksum giúp phát hiện khác biệt với bản phát hành nhưng không thay thế việc rà toàn bộ wp-content.

Kiểm tra tính toàn vẹn tệp là so sánh website hiện tại với một nguồn chuẩn đáng tin để phát hiện tệp bị sửa, tệp mới hoặc tệp thiếu. Đây là bước mạnh để rà WordPress core và plugin từ WordPress.org, nhưng không thể tự chứng minh toàn bộ website đã sạch.

Nguyên tắc WebAnToan

Checksum trả lời “tệp có giống bản phát hành không?”, không trả lời “mọi tệp trên hosting có an toàn không?”. wp-content, code tùy biến, uploads, database và cron vẫn phải được rà riêng.

Tạo snapshot trước khi so sánh

Ghi lại phiên bản WordPress, locale, danh sách plugin/theme và thời gian lấy mẫu. Sao chép tệp cùng metadata sang vùng điều tra. Không chạy hàng loạt lệnh xóa ngay trên production vì tệp bị thay đổi có thể là bằng chứng cho đường xâm nhập.

Chụp snapshot
So sánh nguồn sạch
Theo dõi thay đổi lại
Checksum giúp phát hiện khác biệt với bản phát hành nhưng không thay thế việc rà toàn bộ wp-content.

Xác minh WordPress core bằng WP-CLI

wp core verify-checksums --include-root

Lệnh đối chiếu core với checksum từ WordPress.org. Cần dùng đúng version và locale. Cảnh báo “file should not exist” có thể chỉ ra tệp lạ trong core/root; còn lỗi checksum cho biết nội dung khác bản chuẩn. Hãy lưu output trước khi thay tệp.

Kiểm tra plugin từ WordPress.org

wp plugin verify-checksums --all --strict

Plugin premium hoặc plugin tùy biến thường không có checksum công khai, nên cảnh báo không tự động nghĩa là nhiễm. Với nhóm này, đối chiếu package từ nhà phát hành, repository nội bộ hoặc bản triển khai đã ký nhận.

Rà tệp mới và tệp vừa sửa

Liệt kê theo thời gian chỉ là cách thu hẹp phạm vi. Cập nhật hợp lệ, cache và uploads cũng tạo timestamp mới. Hãy đối chiếu với lịch deploy, access log và owner/quyền tệp. Đặc biệt chú ý PHP trong uploads, tệp ẩn, tên gần giống core và file cấu hình bị chèn rewrite.

Thay thế thay vì “vá” mã nhiễm

Với core, plugin và theme có nguồn sạch, thay toàn bộ package thường đáng tin hơn việc xóa vài dòng. Với code tùy biến, review diff và xây lại artifact từ repository sạch. Không ghi đè wp-content một cách mù quáng vì có thể làm mất dữ liệu hoặc giữ lại tệp lạ không tồn tại trong package.

Theo dõi thay đổi sau làm sạch

Tạo baseline mới sau khi xác minh. Nếu tệp bị tạo lại, hãy đối chiếu thời gian với cron, request và tài khoản đăng nhập. Đây là tín hiệu persistence hoặc đường vào còn mở, không phải lý do để lặp lại thao tác xóa vô hạn.

Không dùng checksum như máy quét mã độc duy nhất

Một tệp hoàn toàn mới ngoài phạm vi checksum, mã trong database hoặc plugin premium bị chèn vẫn có thể bị bỏ qua.

Nguồn tham khảo chính thức

Xem tài liệu wp core verify-checksums và bài Website security checks bằng WP-CLI của WordPress Developer Resources.

File lạ thường cố trông thật quen

Backdoor có thể mang tên gần giống core, nằm trong thư mục cache, uploads hoặc mu-plugins và đặt timestamp giống file bên cạnh. Chỉ tìm tên “shell.php” hoặc chuỗi eval sẽ bỏ qua mã được chia nhỏ, tải từ xa hoặc chèn vào file hợp lệ.

So sánh với nguồn sạch nhưng đừng ghi đè ngay

Checksum và package chính thức giúp nhận diện sai lệch core/plugin. Trước khi replace, lưu hash, owner, mtime và mẫu file; đối chiếu log quanh thời điểm thay đổi. Ghi đè quá sớm làm mất manh mối về request và persistence.

Nhìn cụm thay đổi thay vì từng file

  • Nhiều file đổi cùng phút có thể là update hoặc deploy.
  • Một PHP mới do user web server tạo ngoài change window đáng ưu tiên.
  • File ảnh chứa PHP hoặc đuôi kép cần cách ly.
  • File sạch bị chèn vài dòng ở đầu/cuối dễ bị bỏ qua.

Sau làm sạch, file integrity monitoring phải dùng baseline đã xác minh, nếu không hệ thống chỉ báo rằng “mã độc cũ vẫn giống hôm qua”.

Đừng quên artifact từ quy trình triển khai

Package build, file ZIP cũ, repository và máy của lập trình viên có thể là nguồn đưa mã trở lại. Nếu production được làm sạch nhưng pipeline tiếp tục deploy artifact nhiễm, sự cố sẽ lặp lại đúng lúc phát hành tiếp theo.

Kiểm tra sau khi thay file sạch

So sánh chức năng, permission, owner và error log; theo dõi file có bị sửa lại không. Một bản core sạch không sửa được plugin dễ tổn thương hoặc credential đã lộ, nên replacement luôn phải đi cùng xử lý nguyên nhân.

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

Checksum core đạt có nghĩa website đã sạch không?

Không. Mã độc có thể nằm trong wp-content, database, cron, tài khoản hoặc tệp mới ngoài core.

Plugin premium có kiểm tra checksum được không?

Thường không qua WordPress.org; cần so sánh với package chính thức hoặc repository tin cậy.

Có nên xóa mọi file lạ ngay không?

Nên lưu bằng chứng và xác định owner/ngữ cảnh trước; file hợp lệ tùy biến cũng có thể không nằm trong package chuẩn.

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ý.

Gửi tình trạng website →

Website đang có dấu hiệu tương tự?

Ưu tiên xác minh trước khi sửa

Gửi URL, thời điểm và triệu chứng đang thấy. WebAnToan sẽ giúp phân loại phạm vi trước khi làm thay đổi bằng chứng.

← Tất cả bài viết

Tiếp tục theo chủ đề

Bài viết liên quan

Hỗ trợ kỹ thuật website

Gửi tình trạng website cần hỗ trợ

Gửi 3 thông tin dưới đây để kỹ thuật viên kiểm tra sơ bộ và liên hệ lại.

Chỉ cần gửi tên miền và lỗi đang thấy. Không nhập mật khẩu hay mã OTP.