SysAdmin Skills · Technology Blog

Blog công nghệ cho SysAdmin, DevOps và vận hành hạ tầng

Bài viết mới, hướng dẫn thực chiến, checklist triển khai và ghi chú troubleshooting được cập nhật tự động từ các chuyên mục trên website.

Linux · Cloud · DevOps · SecurityKnowledge base thực chiến, cập nhật theo bài viết mới.

Bắt đầu từ đây

Lộ trình học SysAdmin/DevOps

Anh muốn học theo thứ tự từ Linux nền tảng đến production thì vào roadmap trước. Em đã đẩy mục này lên trên khu bài viết mới để người đọc thấy ngay.

Xem lộ trình

Bài viết mới

Trượt ngang để xem các bài mới nhất.

System Admin19/05/2026

Quản lý sudo Linux an toàn: phân quyền admin, audit lệnh và giảm rủi ro production

Quản lý sudo Linux an toàn: thiết kế nhóm admin, cấu hình sudoers, audit lệnh, giới hạn quyền, troubleshooting lỗi thường gặp và checklist nghiệm thu.

Tin Công Nghệ19/05/2026

AI trong vận hành hệ thống: dùng LLM để giám sát, phân tích log và hỗ trợ incident response

AI trong vận hành hệ thống giúp sysadmin phân tích log, cảnh báo và xử lý sự cố nhanh hơn. Hướng dẫn áp dụng LLM an toàn trong production.

WordPress19/05/2026

WordPress Security Hardening: Gia cố website trước khi lên production

WordPress security hardening thực chiến: checklist bảo mật, cấu hình wp-config, phân quyền file, plugin, WAF, backup và kiểm tra trước production.

Cloud Platform19/05/2026

Cloud Cost Optimization: Giảm chi phí cloud mà không làm yếu production

Cloud cost optimization giúp giảm chi phí cloud an toàn: gắn tag, đo usage, rightsizing, autoscaling, reserved capacity và kiểm soát ngân sách production.

System Admin14/05/2026

Quản lý log Linux bằng journald: đọc log, lọc sự cố và xây runbook vận hành

Quản lý log Linux bằng journald từ cơ bản đến thực chiến: journalctl, lọc lỗi theo service, theo thời gian, persistent log, troubleshooting và checklist…

Tin Công Nghệ14/05/2026

Đánh giá bản vá bảo mật trước khi triển khai: quy trình thực chiến cho đội IT

Đánh giá bản vá bảo mật trước khi triển khai giúp giảm rủi ro downtime. Hướng dẫn quy trình lab, kiểm thử, rollback và checklist nghiệm thu cho đội IT.

Cloud Platform12/05/2026

Cloud Backup Strategy: Thiết kế sao lưu an toàn cho hạ tầng production

Cloud backup strategy giúp SysAdmin thiết kế sao lưu production an toàn: 3-2-1, RPO/RTO, mã hóa, kiểm thử restore và xử lý lỗi thường gặp.

WordPress11/05/2026

Bỏ qua để biên tập Đường dẫn: https://sysadminskills.com/ bao-mat-wordpres…cklist-hardening / ‎ Chỉnh sửa bao-mat-wordpress-production-checklist-hardening Thêm tệp <p><strong>Bảo mật WordPress production</strong> không chỉ là cài một plugin security rồi để đó. Với website doanh nghiệp, WordPress thường là điểm tiếp xúc trực tiếp với Internet: có form đăng nhập, API, plugin bên thứ ba, theme, upload media, tài khoản biên tập viên và đôi khi còn kết nối CRM, email marketing hoặc thanh toán. Một lỗi nhỏ như plugin quá hạn, quyền file sai hoặc backup không kiểm tra khôi phục có thể biến thành sự cố thật.</p> <p>Bài này là một hướng dẫn thực chiến để hardening WordPress trên môi trường production. Anh có thể dùng như checklist triển khai mới, checklist rà soát định kỳ hoặc runbook sau khi website vừa bị tấn công. Nội dung tập trung vào các bước có thể kiểm tra được: cập nhật, tài khoản, phân quyền, file permission, WAF, brute force protection, backup, logging, staging và nghiệm thu.</p> <h2>1. Bối cảnh production: WordPress bị tấn công theo cách nào?</h2> <p>Trước khi hardening, cần hiểu rủi ro chính. Với WordPress public Internet, các cuộc tấn công phổ biến gồm:</p> <ul> <li><strong>Brute force đăng nhập</strong>: bot thử mật khẩu vào <code>/wp-login.php</code> hoặc XML-RPC.</li> <li><strong>Khai thác plugin/theme lỗi thời</strong>: nhiều lỗ hổng WordPress nằm ở plugin hơn là core.</li> <li><strong>Upload webshell</strong>: lợi dụng form upload, plugin lỗi hoặc quyền thư mục sai để ghi file PHP độc hại.</li> <li><strong>Tài khoản admin dùng lại mật khẩu</strong>: mật khẩu rò rỉ từ dịch vụ khác rồi bị credential stuffing.</li> <li><strong>Supply chain</strong>: theme/plugin nulled, package không rõ nguồn gốc.</li> <li><strong>Backup không an toàn</strong>: file backup chứa database bị đặt trong webroot và có thể tải trực tiếp.</li> </ul> <p>Vì vậy, <strong>bảo mật WordPress production</strong> phải đi theo nhiều lớp: giảm bề mặt tấn công, cập nhật nhanh, hạn chế quyền, theo dõi log và luôn có đường khôi phục.</p> <h2>2. Lab/production mẫu trong bài</h2> <p>Giả sử website chạy theo mô hình phổ biến:</p> <ul> <li>OS: Ubuntu Server 22.04/24.04 hoặc Debian 12.</li> <li>Web server: Nginx hoặc Apache.</li> <li>PHP-FPM 8.2/8.3.</li> <li>Database: MariaDB/MySQL.</li> <li>WordPress đặt tại <code>/var/www/example.com/public</code>.</li> <li>Có CDN/WAF như Cloudflare hoặc WAF phía hosting nếu khả dụng.</li> </ul> <p>Nếu anh dùng hosting quản trị sẵn, một số lệnh server-level có thể không chạy được. Khi đó hãy áp dụng phần tương đương trong control panel: file manager, backup, WAF, PHP version, cron và log viewer.</p> <h2>3. Nguyên tắc nền: cập nhật có kiểm soát, không cập nhật mù</h2> <p>Cập nhật là việc quan trọng nhất, nhưng production không nên cập nhật bừa lúc cao điểm. Quy trình tối thiểu:</p> <ol> <li>Kiểm tra backup gần nhất có khôi phục được.</li> <li>Clone sang staging nếu site quan trọng.</li> <li>Cập nhật core, plugin, theme trên staging.</li> <li>Test login, form, checkout, search, cache, sitemap, bài viết và trang chủ.</li> <li>Triển khai production vào khung giờ ít truy cập.</li> <li>Theo dõi error log 30-60 phút sau cập nhật.</li> </ol> <p>Với WP-CLI, có thể kiểm tra phiên bản như sau:</p> <pre><code>cd /var/www/example.com/public wp core version wp plugin list wp theme list</code></pre> <p>Output mẫu:</p> <pre><code>+———————-+———-+———–+———+ | name | status | update | version | +———————-+———-+———–+———+ | wordpress-seo | active | available | 24.8 | | litespeed-cache | active | none | 6.5.4 | +———————-+———-+———–+———+</code></pre> <p>Plugin có update security nên được ưu tiên. Nếu plugin không còn duy trì, hãy lập kế hoạch thay thế thay vì chỉ “để đó vì vẫn chạy”.</p> <h2>4. Tài khoản admin: ít quyền, bắt buộc 2FA</h2> <p>Không nên dùng chung một tài khoản admin cho nhiều người. Checklist tài khoản:</p> <ul> <li>Mỗi người một tài khoản riêng.</li> <li>Chỉ cấp role Administrator cho người thật sự cần.</li> <li>Biên tập nội dung dùng Editor/Author, không dùng admin.</li> <li>Bật 2FA cho admin và editor quan trọng.</li> <li>Xóa tài khoản cũ của nhân sự đã nghỉ.</li> <li>Không dùng username dễ đoán như <code>admin</code> cho tài khoản quản trị mới.</li> </ul> <p>Dùng WP-CLI để liệt kê user:</p> <pre><code>wp user list –fields=ID,user_login,user_email,roles</code></pre> <p>Nếu cần hạ quyền một user:</p> <pre><code>wp user set-role editor_user editor</code></pre> <p>Việc này giảm thiệt hại khi một tài khoản biên tập bị lộ. Đây là nguyên tắc least privilege trong vận hành.</p> <h2>5. Chống brute force và giới hạn bề mặt đăng nhập</h2> <p>WordPress mặc định có endpoint đăng nhập rất dễ bị bot quét. Một cấu hình production nên có ít nhất ba lớp:</p> <ul> <li>Rate limit tại WAF/CDN hoặc web server.</li> <li>Plugin giới hạn login attempt hoặc security suite đáng tin cậy.</li> <li>2FA cho tài khoản có quyền cao.</li> </ul> <p>Nếu dùng Nginx, có thể rate limit cơ bản cho <code>wp-login.php</code>:</p> <pre><code>limit_req_zone $binary_remote_addr zone=wplogin:10m rate=5r/m; server { location = /wp-login.php { limit_req zone=wplogin burst=10 nodelay; include fastcgi_params; fastcgi_pass unix:/run/php/php8.2-fpm.sock; } }</code></pre> <p>Giải thích:</p> <ul> <li><code>rate=5r/m</code>: mỗi IP khoảng 5 request/phút.</li> <li><code>burst=10</code>: cho phép một lượng request ngắn hạn trước khi chặn.</li> <li>Cần test kỹ để tránh chặn nhầm admin thật, đặc biệt nếu website đứng sau proxy/CDN.</li> </ul> <p>Nếu dùng Cloudflare, nên tạo rule riêng cho <code>/wp-login.php</code> và <code>/xmlrpc.php</code>: Managed Challenge, rate limit hoặc chỉ allow IP quản trị nếu mô hình vận hành cho phép.</p> <h2>6. XML-RPC: chỉ bật khi thật sự cần</h2> <p><code>xmlrpc.php</code> thường bị dùng để brute force hoặc DDoS amplification. Nếu website không dùng Jetpack, app mobile hoặc tích hợp cũ cần XML-RPC, nên chặn.</p> <p>Nginx:</p> <pre><code>location = /xmlrpc.php { deny all; access_log off; log_not_found off; }</code></pre> <p>Apache <code>.htaccess</code>:</p> <pre><code><Files xmlrpc.php> Require all denied </Files></code></pre> <p>Sau khi chặn, test:</p> <pre><code>curl -I https://example.com/xmlrpc.php</code></pre> <p>Kỳ vọng nhận <code>403 Forbidden</code> hoặc bị WAF challenge, không phải <code>200 OK</code>.</p> <h2>7. File permission: không để web server ghi lung tung</h2> <p>Quyền file sai là nguyên nhân phổ biến khiến attacker ghi webshell sau khi khai thác một plugin. Mục tiêu là chỉ cho PHP/web server ghi nơi cần thiết, thường là <code>wp-content/uploads</code>, cache và một số thư mục plugin cụ thể.</p> <p>Baseline tham khảo:</p> <pre><code>cd /var/www/example.com/public find . -type d -exec chmod 755 {} \; find . -type f -exec chmod 644 {} \; chmod 600 wp-config.php</code></pre> <p>Owner nên tách rõ user deploy và user web server. Ví dụ:</p> <pre><code>sudo chown -R deploy:www-data /var/www/example.com/public sudo find /var/www/example.com/public -type d -exec chmod 755 {} \; sudo find /var/www/example.com/public -type f -exec chmod 644 {} \;</code></pre> <p>Lưu ý: đây là baseline. Một số plugin cache cần quyền ghi vào thư mục riêng. Đừng cấp <code>777</code> để “cho chạy được”; hãy xác định đúng thư mục cần ghi.</p> <h2>8. Chặn PHP execution trong uploads</h2> <p>Thư mục upload không nên thực thi PHP. Đây là lớp bảo vệ quan trọng nếu attacker upload được file độc hại.</p> <p>Nginx:</p> <pre><code>location ~* /wp-content/uploads/.\.php$ { deny all; }</code></pre> <p>Apache, tạo file <code>wp-content/uploads/.htaccess</code>:</p> <pre><code><FilesMatch "\.php$"> Require all denied </FilesMatch></code></pre> <p>Test bằng cách tạo file PHP giả trong môi trường staging, truy cập URL và xác nhận bị chặn. Không test kiểu này trên production nếu không kiểm soát chặt.</p> <h2>9. Bảo vệ wp-config.php và khóa salt</h2> <p><code>wp-config.php</code> chứa credential database, salt và cấu hình quan trọng. Kiểm tra:</p> <pre><code>ls -lah wp-config.php grep -E "AUTH_KEY|SECURE_AUTH_KEY|LOGGED_IN_KEY|NONCE_KEY" wp-config.php</code></pre> <p>Nếu nghi ngờ bị lộ phiên đăng nhập, thay salt bằng giá trị mới từ công cụ chính thức của WordPress:</p> <ul> <li><a href="https://api.wordpress.org/secret-key/1.1/salt/" target="_blank" rel="noopener">WordPress.org Secret Key Service</a></li> </ul> <p>Thay salt sẽ buộc user đăng nhập lại. Đây là thao tác hữu ích sau sự cố tài khoản hoặc nghi ngờ cookie/session bị lộ.</p> <h2>10. Tắt chỉnh sửa file từ dashboard</h2> <p>Không nên cho phép sửa theme/plugin trực tiếp trong wp-admin trên production. Thêm vào <code>wp-config.php</code>:</p> <pre><code>define('DISALLOW_FILE_EDIT', true);</code></pre> <p>Nếu muốn chặn cài/cập nhật từ dashboard và chỉ deploy qua pipeline, có thể dùng:</p> <pre><code>define('DISALLOW_FILE_MODS', true);</code></pre> <p>Tùy mô hình vận hành mà chọn. Với site nhỏ, <code>DISALLOW_FILE_EDIT</code> gần như luôn nên bật; <code>DISALLOW_FILE_MODS</code> cần cân nhắc vì nó ảnh hưởng update plugin/theme.</p> <h2>11. Backup: phải có restore test, không chỉ có file backup</h2> <p>Backup không được xem là hoàn thành nếu chưa từng restore thử. Một chiến lược tối thiểu:</p> <ul> <li>Database backup hằng ngày.</li> <li>File/media backup hằng ngày hoặc theo tần suất cập nhật.</li> <li>Giữ nhiều phiên bản: 7 ngày gần nhất, 4 tuần, 3-6 tháng tùy yêu cầu.</li> <li>Lưu một bản ngoài server chính: S3/Object Storage, backup server, hoặc dịch vụ backup.</li> <li>Mã hóa backup nếu chứa dữ liệu nhạy cảm.</li> </ul> <p>Ví dụ backup database bằng WP-CLI:</p> <pre><code>mkdir -p /backup/example.com wp db export /backup/example.com/db-$(date +%F-%H%M).sql</code></pre> <p>Nén thư mục upload:</p> <pre><code>tar -czf /backup/example.com/uploads-$(date +%F).tar.gz wp-content/uploads</code></pre> <p>Kiểm tra file backup:</p> <pre><code>ls -lh /backup/example.com gzip -t /backup/example.com/uploads-2026-05-11.tar.gz</code></pre> <p>Quan trọng: không đặt backup trong webroot như <code>/public/backup.zip</code>. Nếu bắt buộc lưu tạm, phải chặn truy cập web và xóa ngay sau khi tải.</p> <h2>12. Logging và giám sát dấu hiệu bất thường</h2> <p>Một site WordPress production nên theo dõi ít nhất:</p> <ul> <li>Web server access/error log.</li> <li>PHP-FPM error log.</li> <li>WordPress debug log khi cần điều tra, không bật debug hiển thị ra màn hình.</li> <li>Log đăng nhập thất bại/thành công bất thường.</li> <li>File integrity hoặc thay đổi file trong core/plugin/theme.</li> </ul> <p>Cấu hình debug an toàn trong <code>wp-config.php</code> khi cần troubleshooting:</p> <pre><code>define('WP_DEBUG', true); define('WP_DEBUG_LOG', true); define('WP_DEBUG_DISPLAY', false); @ini_set('display_errors', 0);</code></pre> <p>Sau khi xử lý xong, nên tắt debug nếu không còn cần. Log debug có thể chứa thông tin nhạy cảm hoặc làm đầy disk.</p> <p>Kiểm tra lỗi PHP gần nhất:</p> <pre><code>sudo journalctl -u php8.2-fpm –since "1 hour ago" –no-pager sudo tail -100 /var/log/nginx/error.log</code></pre> <h2>13. Kiểm tra file lạ và webshell cơ bản</h2> <p>Khi nghi ngờ bị tấn công, kiểm tra file PHP trong uploads:</p> <pre><code>find wp-content/uploads -type f -name ".php" -print</code></pre> <p>Kiểm tra file mới thay đổi trong 2 ngày:</p> <pre><code>find . -type f -mtime -2 -print | sort</code></pre> <p>Tìm các pattern nguy hiểm thường gặp trong webshell:</p> <pre><code>grep -RIn –include="*.php" "eval(base64_decode\|shell_exec\|passthru\|assert(" wp-content 2>/dev/null | head -50</code></pre> <p>Lưu ý: grep chỉ là bước sàng lọc, có thể false positive hoặc bỏ sót mã độc obfuscation phức tạp. Với sự cố nghiêm trọng, nên restore từ bản sạch, thay toàn bộ credential và rà soát log truy cập.</p> <h2>14. WAF/CDN: lớp phòng thủ trước khi request vào server</h2> <p>WAF không thay thế cập nhật và hardening, nhưng giúp giảm đáng kể bot, exploit phổ biến và brute force. Checklist WAF:</p> <ul> <li>Bật managed rules cho WordPress nếu nhà cung cấp hỗ trợ.</li> <li>Challenge hoặc rate limit <code>/wp-login.php</code>.</li> <li>Block hoặc challenge <code>/xmlrpc.php</code> nếu không dùng.</li> <li>Chặn truy cập trực tiếp vào file nhạy cảm: <code>.env</code>, backup zip/sql, git directory.</li> <li>Cho phép IP thật đi qua header đúng nếu server nằm sau proxy.</li> </ul> <p>Tài liệu nên đọc thêm:</p> <ul> <li><a href="https://wordpress.org/documentation/article/hardening-wordpress/" target="_blank" rel="noopener">Hardening WordPress – WordPress.org</a></li> <li><a href="https://developer.wordpress.org/advanced-administration/security/hardening/" target="_blank" rel="noopener">WordPress Developer Resources: Security hardening</a></li> <li><a href="https://owasp.org/www-project-top-ten/" target="_blank" rel="noopener">OWASP Top 10</a></li> <li><a href="https://developers.cloudflare.com/waf/" target="_blank" rel="noopener">Cloudflare WAF documentation</a></li> </ul> <h2>15. Troubleshooting lỗi thường gặp sau khi hardening</h2> <h3>Admin không đăng nhập được sau khi bật WAF/rate limit</h3> <ul> <li>Kiểm tra IP thật có bị nhận nhầm do proxy/CDN không.</li> <li>Whitelist IP quản trị tạm thời để xử lý.</li> <li>Giảm rule từ block sang challenge/log trước khi block cứng.</li> </ul> <h3>Plugin không upload hoặc không ghi cache</h3> <ul> <li>Kiểm tra thư mục plugin/cache cần quyền ghi cụ thể.</li> <li>Không cấp quyền toàn site thành <code>777</code>.</li> <li>Xem log PHP-FPM và web server để biết permission denied ở path nào.</li> </ul> <h3>Chặn XML-RPC làm Jetpack/app mobile lỗi</h3> <ul> <li>Xác nhận website có thật sự cần XML-RPC không.</li> <li>Nếu cần, chỉ allow IP/dải IP của dịch vụ liên quan hoặc dùng rule challenge phù hợp.</li> </ul> <h3>Backup chạy thành công nhưng restore lỗi</h3> <ul> <li>Kiểm tra charset/collation database.</li> <li>Kiểm tra thiếu file upload hoặc thiếu plugin mu-plugin.</li> <li>Kiểm tra domain hard-code trong database bằng <code>wp search-replace</code> trên staging.</li> </ul> <h2>16. Checklist nghiệm thu bảo mật WordPress production</h2> <ul> <li>Core, plugin, theme đang ở phiên bản được hỗ trợ.</li> <li>Không có plugin/theme nulled hoặc không rõ nguồn.</li> <li>Admin có 2FA, không dùng chung tài khoản.</li> <li>Role user đúng theo nhu cầu, ít quyền nhất có thể.</li> <li><code>DISALLOW_FILE_EDIT</code> đã bật.</li> <li><code>xmlrpc.php</code> bị chặn nếu không dùng.</li> <li><code>wp-content/uploads</code> không thực thi PHP.</li> <li>File permission không dùng <code>777</code>.</li> <li>Backup có bản ngoài server và đã restore test.</li> <li>WAF/rate limit bảo vệ endpoint đăng nhập.</li> <li>Log web/PHP/WordPress được theo dõi sau thay đổi lớn.</li> <li>Có runbook xử lý khi nghi ngờ bị hack: cô lập, backup forensic, restore sạch, đổi credential, rà soát log.</li> </ul> <h2>17. Bài tập lab cuối bài</h2> <ol> <li>Dựng một site WordPress staging hoặc local.</li> <li>Bật <code>DISALLOW_FILE_EDIT</code> và xác nhận menu sửa file biến mất.</li> <li>Chặn PHP execution trong <code>wp-content/uploads</code>, rồi test bằng file PHP giả trên staging.</li> <li>Tạo backup database bằng WP-CLI, restore sang một database lab.</li> <li>Bật 2FA cho tài khoản admin test.</li> <li>Tạo rule WAF hoặc rate limit cho <code>/wp-login.php</code>.</li> <li>Ghi lại checklist nghiệm thu và kết quả từng mục.</li> </ol> <p><strong>Kết luận:</strong> bảo mật WordPress production là một quy trình vận hành liên tục, không phải một lần cài plugin. Khi anh kết hợp cập nhật có kiểm soát, phân quyền chặt, file permission đúng, WAF, backup có restore test và theo dõi log, website sẽ có khả năng chống chịu tốt hơn rất nhiều trước bot tự động lẫn sự cố vận hành thật.</p>

Bảo mật WordPress production từ nền tảng: cập nhật, phân quyền, WAF, backup, chống brute force, file permission, log và checklist nghiệm thu.

System Admin10/05/2026

Linux Patch Management: Quy trình cập nhật an toàn cho server production

Linux patch management giúp SysAdmin cập nhật server an toàn: phân loại bản vá, backup, kiểm thử, reboot, troubleshooting, rollback và checklist nghiệm…