WordPress security plugins do useful things: they scan for malware, monitor file changes, block known bad user agents, and add two-factor authentication. But they operate inside WordPress — meaning PHP has already loaded, your database has already been queried, and resources have already been consumed before the plugin decides whether to allow a request.
Server-level security operates before any of that happens.
flame-guardian: Blocking After Repeated Failures
We run flame-guardian on all servers. It monitors the SSH auth log and nginx access log in real time, and bans IP addresses that trigger defined abuse patterns.
Repeated failed WordPress login attempts to wp-login.php, SSH brute-force attempts, and probes for known-hostile paths (.env, /phpmyadmin, xmlrpc.php abuse, etc.) trigger bans at the nftables firewall level. Banned IPs don't make a TCP connection to nginx — their requests are dropped before they consume PHP workers, run database queries, or appear in your application logs.
Bans escalate automatically through 10 tiers with increasing durations. Persistent offenders end up in Guardian Jail: a permanent ban with no expiry. Bans propagate across all fleet nodes within seconds — an IP blocked on one node is blocked everywhere.
On top of that, Guardian-X runs an XDP kernel-bypass layer that drops the highest-volume abusers before their packets even reach nftables.
nginx Rate Limiting
Brute-force attacks against WordPress login pages are common — automated scripts hammer wp-login.php hundreds of times per second. Even if all attempts fail, they consume PHP workers and slow the site for legitimate visitors.
We apply nginx rate limits to wp-login.php and xmlrpc.php before requests reach PHP. The limit allows a normal human login rate and rejects anything above it with a 429 response. The rejection happens in nginx, before PHP starts.
Sandboxed PHP Execution
Each customer's PHP runs as a dedicated system user inside a bwrap (bubblewrap) sandbox. Your PHP code can only write to directories you own. It cannot read other customers' files, cannot write to system directories, and cannot execute system commands outside a restricted set.
This matters for the most common WordPress attack vector: a malicious plugin or theme that tries to write a backdoor file or read another customer's configuration. The sandbox stops this at the filesystem level, below anything WordPress can control.
What Your Security Plugin Still Handles
Server-level controls handle volume attacks and known patterns. Your security plugin handles application-layer concerns: malware scanning, file integrity monitoring, known-vulnerable plugin detection, and user behaviour monitoring.
A lightweight security plugin on WordPress provides defence in depth. The server and the plugin together cover different attack surfaces. Neither is a substitute for the other.