What is a hardening playbook?

A hardening playbook is a tested, repeatable set of configuration changes that removes a specific class of weakness, such as PHP running in upload folders or password logins over SSH. PatientZero ships playbooks built from real incident response, applies them consistently across every site, and verifies each one after it runs.

Manual hardening tends to drift. One site gets the upload rule, another is forgotten; SSH is locked down on the live server but not on staging. Playbooks apply the same standard every time and leave an audit trail of exactly what was changed. For a do-it-yourself reference, see our WordPress hardening checklist.

What do the playbooks actually change?

The playbooks change server and application configuration that attackers rely on: how PHP runs, who owns which files, whether uploads can execute code, how SSH authenticates and what WordPress allows from its dashboard. Each change is small and well understood, and together they remove the paths most real-world compromises use.

# /etc/ssh/sshd_config
PermitRootLogin yes
PermitRootLogin no
PasswordAuthentication no

# wp-content/uploads/.htaccess (Apache) or equivalent Nginx location rule
<FilesMatch "\.(php|phtml|phar)$"> Require all denied </FilesMatch>

# wp-config.php
define( 'DISALLOW_FILE_EDIT', true );

PHP-FPM pool isolation matters most on shared servers. When every site runs as www-data, a webshell in one site can write to all of them. Separate pools and users contain an infection to the site where it started.

Will hardening break my site?

Hardening is designed not to break working sites, but some plugins and deployment habits rely on loose settings, such as editing theme files from the dashboard. PatientZero checks for these before applying a playbook, records the previous values, and can roll a change back if a legitimate feature depends on it.

  1. Clean first. Hardening an infected server can lock malware in; run a clean-up before applying playbooks.
  2. Stage where possible. Apply to staging first for complex sites, then production.
  3. Keep access. SSH lockdown confirms your key works before password login is disabled.
  4. Verify. Each playbook reports pass or fail, and the sites are checked afterwards.

Hardening is included on every plan. See pricing, or server malware removal if the server needs cleaning first.