Firewalls and updates are table stakes. Every competent agency handles them, yet client sites still get compromised. The attacks that succeed rarely knock on the front door. They brute-force SSH in the small hours, hammer wp-login thousands of times before breakfast, slip in through a nulled plugin, or exploit the one extension nobody got around to patching. What follows is the layered playbook we run for every site under management.
1. SSH: keys only, and read the logs
Password authentication on SSH is an open invitation, so every server we manage accepts key-based login exclusively, with password auth disabled outright. Moving SSH off the default port will not deter a targeted attacker, but it eliminates nearly all background scanning noise, which means genuine anomalies stand out in the logs instead of drowning in static.
Authentication telemetry should also be shared, not siloed. Every SSH failure on our fleet feeds into CrowdSec, so a host caught scanning one client site is blocked across all of them within minutes. Agencies managing dozens of servers should treat SSH signals as fleet intelligence, not per-server trivia.
2. Brute-force attacks never sleep
Coordinated brute-force campaigns against wp-login.php and xmlrpc.php are the background radiation of WordPress hosting. A single burst can pack hundreds of blocked attempts from a handful of addresses into a few minutes. That traffic is harmless while WordPress and the firewall refuse it, and catastrophic the moment a single weak credential gives way.
- Require strong passwords plus two-factor authentication on every administrator account, without exception.
- Rate-limit login endpoints at the edge, so junk traffic never reaches PHP workers.
- Disable XML-RPC wherever nothing depends on it. Where something does, restrict it to known addresses.
- Alert on anomalies, such as a login burst from an unfamiliar network, rather than on each blocked attempt.
3. Malware: assume breach, verify integrity
Malware seldom arrives through the firewall. It ships inside a nulled theme, rides a compromised administrator account, or enters through the supply chain when a legitimate plugin turns hostile. Scheduled scanning catches known signatures, while file-integrity monitoring catches the unknowns: when a core file changes outside an update window, investigate first and debate later.
Cleanup without closing the entry point is theater. Every malware removal must answer three questions: how it arrived, which credential or plugin permitted it, and what changed to prevent recurrence. Confirm there are no rogue administrator accounts, malicious cron entries, or unfamiliar must-use plugins before declaring the incident resolved.
4. A WAF is not a firewall
A network firewall decides which packets may arrive. A web application firewall decides which requests are legitimate. For WordPress, that means managed rulesets that understand login abuse, plugin-specific exploit patterns, and bot behavior, stopping hostile requests at the edge before they ever boot PHP.
Run the WAF in blocking mode on login and API endpoints, log everything it stops, and review those logs on a schedule. A WAF firing constantly against the same patterns is pointing directly at your next hardening investment. Remember its limits: a WAF complements patching but never replaces it. It cannot fix vulnerable code. It only narrows the window of exposure.
5. Patching as a process, not an event
Most WordPress compromises trace to a known vulnerability for which a patch already existed. Agencies that stay clean treat patching as operations: a weekly pass across plugins and themes, same-day action on security releases, staging verification for high-traffic or commerce sites, and pre-update snapshots that make every change reversible.
Track vulnerability intelligence per plugin across the fleet, not per site. When a critical CVE lands for a plugin installed on forty client sites, a single query should stand between you and a fleet-wide incident, not forty separate logins.
The checklist
SSH keys only. Brute-force defenses on every login surface. Malware scanning paired with integrity monitoring. A tuned WAF. Patching on rails. None of these measures is exotic. The agencies that suffer breaches are simply the ones running three of the five and assuming that is sufficient.
