WordPress chiếm hơn 40% web toàn cầu. Điều đó cũng có nghĩa là nó là mục tiêu phổ biến nhất. Chúng tôi đã xử lý nhiều website WordPress bị hack — mã độc chèn vào core files, redirect sang trang lừa đảo, backdoor ẩn trong plugin. Bài viết này chia sẻ checklist bảo mật mà chúng tôi áp dụng cho mọi website khách hàng.
Đây không phải lý thuyết. Mỗi mục trong checklist này đều có nguồn gốc từ một sự cố thực tế mà chúng tôi đã gặp và xử lý.
1. File Permissions
Sai file permissions là nguyên nhân phổ biến nhất khiến mã độc có thể ghi file lên server. Chuẩn cho WordPress:
- Thư mục:
755(owner đọc/ghi/execute, group và others chỉ đọc/execute) - Files:
644(owner đọc/ghi, group và others chỉ đọc) wp-config.php:600hoặc640— file này chứa database credentials, không ai ngoài owner cần đọc
Nhiều hosting shared đặt permissions là 777 cho thư mục uploads — bất kỳ ai trên server đều có thể ghi file vào đó. Đây là mời hacker vào nhà.
# Fix permissions cho toàn bộ WordPress
find /path/to/wordpress -type d -exec chmod 755 {} \;
find /path/to/wordpress -type f -exec chmod 644 {} \;
chmod 600 /path/to/wordpress/wp-config.php2. Bảo vệ đăng nhập
Brute force là phương thức tấn công đơn giản nhất — bot thử hàng ngàn tổ hợp username/password. Biện pháp:
- Giới hạn số lần đăng nhập sai. Plugin Limit Login Attempts Reloaded — miễn phí, hiệu quả. Sau 3 lần sai, khóa IP 15 phút. Sau 3 lần bị khóa, khóa 24 giờ.
- Không dùng username "admin". Bot luôn thử "admin" đầu tiên. Tạo username khó đoán.
- Đổi URL đăng nhập. Mặc định là
/wp-login.phpvà/wp-admin/. Đổi sang URL tùy chỉnh. Không phải bảo mật tuyệt đối — nhưng loại bỏ 90% bot. - Two-factor authentication. Cho admin accounts, 2FA nên là bắt buộc. Plugin WP 2FA hoạt động tốt.
3. Khóa XML-RPC
XML-RPC (/xmlrpc.php) là API cũ của WordPress — cho phép đăng bài từ ứng dụng bên ngoài. Hầu hết website không cần, nhưng nó vẫn mở mặc định. Vấn đề: XML-RPC cho phép thử nhiều password trong một request (system.multicall) — bypass giới hạn đăng nhập.
# Trong .htaccess (Apache)
<Files xmlrpc.php>
Require all denied
</Files>Hoặc trong Nginx:
location = /xmlrpc.php {
deny all;
return 403;
}Nếu bạn cần XML-RPC (ví dụ cho Jetpack), whitelist IP cụ thể thay vì mở cho toàn bộ.
4. HTTP Security Headers
Headers không ngăn được mã độc trên server — nhưng bảo vệ người dùng khỏi các cuộc tấn công phía client (XSS, clickjacking, MIME sniffing):
# Thêm vào .htaccess hoặc nginx config
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()Content-Security-Policy (CSP) hiệu quả nhất nhưng cũng phức tạp nhất — dễ gây lỗi nếu thiết lập sai. Chúng tôi thêm CSP từ từ, test kỹ trước khi enforce.
5. Vô hiệu hóa chỉnh sửa file trong admin
WordPress mặc định cho phép chỉnh sửa plugin và theme files từ admin panel. Nếu tài khoản admin bị compromised, hacker có thể chèn mã độc trực tiếp từ giao diện web.
// Thêm vào wp-config.php
define('DISALLOW_FILE_EDIT', true);
define('DISALLOW_FILE_MODS', true); // Cả install/update plugin từ adminDISALLOW_FILE_MODS cũng tắt update plugin/theme từ admin — bạn sẽ cần update qua WP-CLI hoặc SFTP. Đây là trade-off an toàn: bất tiện hơn, nhưng bảo mật hơn đáng kể.
6. Database security
- Đổi prefix bảng. Mặc định là
wp_. Đổi sang prefix ngẫu nhiên khiến SQL injection attacks khó hơn (không bất khả thi, nhưng thêm một lớp). - Database user riêng cho WordPress. Không dùng root. User chỉ có quyền SELECT, INSERT, UPDATE, DELETE trên database WordPress — không có DROP, ALTER, GRANT.
- Xóa bảng không dùng. Plugin cũ có thể để lại bảng không còn sử dụng trong database. Nên dọn dẹp định kỳ.
7. Plugin và theme hygiene
Plugin và theme lỗi thời là vector tấn công phổ biến nhất. Quy tắc:
- Xóa plugin không dùng — không chỉ deactivate. Plugin inactive vẫn có thể bị khai thác nếu có lỗ hổng.
- Xóa theme mặc định không dùng. Giữ lại theme đang dùng + một theme mặc định (Twenty Twenty-Four) cho fallback.
- Không dùng plugin nulled/cracked. 100% chứa mã độc. Không có ngoại lệ.
- Kiểm tra plugin trước khi cài. Xem lần update cuối, số lượng active installs, rating. Plugin không được update >1 năm = rủi ro.
- Auto-update cho minor versions. WordPress minor updates (5.9.1 → 5.9.2) chủ yếu là security patches. Nên bật auto-update.
8. Backup — lớp phòng thủ cuối cùng
Mọi biện pháp bảo mật đều có thể bị vượt qua. Backup là thứ duy nhất cho phép bạn phục hồi khi mọi thứ khác thất bại.
- Backup hàng ngày — cả files và database
- Lưu trữ offsite — không chỉ trên cùng server. Nếu server bị compromise, backup trên server cũng bị.
- Giữ 30 ngày — đôi khi malware chỉ được phát hiện sau vài tuần. Cần backup sạch từ trước khi bị nhiễm.
- Test restore — backup vô nghĩa nếu không restore được. Test ít nhất mỗi quý.
9. Tối ưu tốc độ — bảo mật gián tiếp
Website chậm thường là dấu hiệu của vấn đề bảo mật — mã độc chèn code, database queries bất thường, hoặc đơn giản là hosting yếu khiến không thể chạy security plugins.
- Page caching — giảm tải PHP processing. WP Super Cache hoặc W3 Total Cache.
- Object caching — Redis hoặc Memcached cho database query cache.
- CDN — Cloudflare miễn phí, giảm tải server và thêm WAF cơ bản.
- Image optimization — ảnh chưa nén chiếm 50-80% page weight. WebP conversion + lazy loading.
- PHP version — PHP 8.2+ nhanh hơn đáng kể so với 7.4. Upgrade PHP là cách tối ưu nhanh nhất.
Khi website đã bị hack
Nếu website đã bị nhiễm mã độc, checklist trên không đủ. Quy trình xử lý:
- Cách ly — đưa website offline hoặc vào maintenance mode ngay. Ngăn malware lây lan và bảo vệ người dùng.
- Quét toàn bộ filesystem — tìm files bất thường, files mới tạo gần đây, code obfuscated.
wp-clicó lệnhwp core verify-checksumsso sánh core files với bản gốc. - Cài lại WordPress core —
wp core download --force. Giữ nguyênwp-content/và database. - Kiểm tra từng plugin và theme — so sánh với bản gốc từ wordpress.org. Bất kỳ file nào bị modified = nghi ngờ.
- Kiểm tra database — tìm JavaScript/iframe injection trong posts, options, user metadata.
- Đổi tất cả credentials — admin passwords, database password, SFTP, hosting panel.
- Áp dụng checklist bảo mật — tất cả các mục ở trên.
- Submit lại Google Search Console — yêu cầu gỡ cảnh báo "This site may be hacked".
Toàn bộ quy trình mất 2-4 giờ cho website đơn giản, 1-2 ngày cho website phức tạp. Nhưng quan trọng hơn là ngăn tái nhiễm — đó là lý do checklist bảo mật phải được áp dụng ngay sau khi dọn dẹp.
Kết luận
Bảo mật WordPress không khó — nhưng cần kỷ luật. Hầu hết website bị hack không phải vì hacker giỏi, mà vì chủ website quên update plugin, dùng password yếu, hoặc cài theme cracked.
Checklist này không phải bất khả xâm phạm. Nhưng nó loại bỏ 95% vector tấn công phổ biến — và đó là sự khác biệt giữa website an toàn và website sẽ bị hack trong 6 tháng tới.