WordPress security plugins protect your application. But your server has attack surfaces that no plugin can see — SSH, exposed ports, system-level malware, and OS vulnerabilities.
Most WordPress security guides focus exclusively on the application level — install a plugin, enable 2FA, keep plugins updated. Tools like MalCare and Sucuri work at this level. That's necessary but incomplete. Attackers target your server just as aggressively as your WordPress installation.
Covered by: Wordfence, Sucuri, iThemes Security
Not covered by any WordPress plugin
A compromised server means a compromised WordPress installation — no matter what plugins you have. If an attacker gets SSH access, they can modify any file, dump your database, and install persistent backdoors that no plugin will detect. Most WordPress servers run nginx or Apache — see our nginx security guide for web server hardening steps.
These are the hardening steps you should apply to any server hosting WordPress. They work regardless of your WordPress version, theme, or plugins.
PermitRootLogin no
PasswordAuthentication no
MaxAuthTries 3
$ sudo ufw default deny incoming
$ sudo ufw allow 22/tcp
$ sudo ufw allow 80/tcp
$ sudo ufw allow 443/tcp
$ sudo ufw enable
# Block xmlrpc.php completely (rarely needed by modern WP)
location = /xmlrpc.php {
deny all;
return 403;
}
# Rate limit wp-login.php
location = /wp-login.php {
limit_req zone=login burst=3 nodelay;
include fastcgi_params;
fastcgi_pass unix:/run/php/php-fpm.sock;
}
bind-address = 127.0.0.1
If your database is on the same server as WordPress, there's no reason for MySQL to listen on a public interface. Verify with: ss -tlnp | grep 3306
These two endpoints receive the most attack traffic on any WordPress server. Based on Defensia WAF telemetry, a typical WordPress server sees hundreds of wp-login.php brute force attempts per day — often from botnets with thousands of source IPs.
45.83.64.11 - - "POST /wp-login.php HTTP/1.1" 200 4523
45.83.64.11 - - "POST /wp-login.php HTTP/1.1" 200 4523
103.145.13.90 - - "POST /xmlrpc.php HTTP/1.1" 200 674
91.108.4.30 - - "GET /wp-content/plugins/revslider/temp/update_extract/ HTTP/1.1" 404
185.220.101.7 - - "POST /wp-admin/admin-ajax.php?action=duplicator_download HTTP/1.1" 403
… every day, from hundreds of different IPs
xmlrpc.php is especially dangerous because it supports system.multicall — an attacker can try hundreds of credentials in a single HTTP request, bypassing most rate limiters.
Defensia's WAF detects these patterns from your nginx/Apache access logs and blocks the attacking IP at the firewall level. Unlike application-level plugins, the block happens before the request reaches PHP, saving server resources.
The wp-content/uploads/ directory is the most common hiding place for WordPress malware. It's writable by the web server process, and attackers exploit vulnerable plugins to upload PHP backdoors disguised as images.
$ find /var/www/*/wp-content/uploads -name "*.php" -type f
$ find /var/www/*/wp-content/uploads -name "*.php*" -newer /etc/passwd
Any PHP file inside uploads/ is suspicious — WordPress stores only images, PDFs, and other media there. PHP files are almost always web shells or backdoors.
Defensia's malware scanner checks upload directories automatically with 64,000+ hash signatures and 684 dynamic detection patterns. It identifies known web shells (WSO, C99, FilesMan, Alfa Shell), obfuscated PHP backdoors, and even files that match known malware hashes from MalwareBazaar.
Beyond file-level malware, attackers inject malicious content directly into your WordPress database. This is harder to detect because the files on disk look clean.
SQL injection attacks through vulnerable plugins (Contact Form 7, WPForms, Elementor Pro, and others) can insert <script> tags, iframe redirects, or encoded PHP payloads directly into post content and wp_options. These persist across plugin updates and are invisible to file-based scanners.
Wordfence and Defensia complement each other. Wordfence protects the WordPress application; Defensia protects the server underneath. Together they cover both attack levels.
| Protection | Wordfence Free | Defensia |
|---|---|---|
| wp-login.php brute force protection | ✓ | ✓ |
| WordPress plugin vulnerability scanning | ✓ | ✕ |
| Login 2FA (Google Authenticator) | ✓ | ✕ |
| SSH brute force protection | ✕ | ✓ |
| OS-level firewall (iptables) | ✕ | ✓ |
| File malware scanning | ✓ | 64K+ hashes |
| Database malware scanning | ✕ | ✓ |
| Cryptominer detection | ✕ | ✓ |
| Rootkit detection | ✕ | ✓ |
| CVE scanning (OS packages) | ✕ | ✓ |
| Real-time attack dashboard | Basic | ✓ |
| Multi-server management | ✕ | ✓ |
| Geoblocking | Premium only | ✓ |
| Bot management | ✕ | 70+ fingerprints |
For a full comparison, see Wordfence vs Defensia.
Yes. Wordfence operates at the PHP/WordPress level. It cannot see SSH attacks, protect exposed database ports, detect OS-level rootkits, or scan for cryptominers. If an attacker gains SSH access, Wordfence is irrelevant — they have full control of the server. Defensia covers the server layer that Wordfence cannot reach.
Defensia scans the entire WordPress installation from the OS level — it checks wp-content/uploads for PHP backdoors, theme/plugin directories for known malware hashes (64K+ signatures), and even the WordPress database for injected JavaScript and rogue admin accounts. It also detects cryptominers, reverse shells, and rootkits that WordPress plugins cannot see.
By volume, wp-login.php brute force attacks are the most common. By severity, exploiting vulnerable plugins is the most dangerous — attackers scan for known CVEs in popular plugins (e.g., Elementor, WPForms, Contact Form 7) and exploit them within hours of public disclosure. Server-level SSH brute force attacks are equally common but often overlooked by WordPress-focused security guides.
Yes. One Defensia agent protects all websites on the server — WordPress, Laravel, static sites, anything. The WAF reads nginx/Apache access logs for all virtual hosts. The malware scanner checks all web directories. Free plan: 1 server. Pro: unlimited servers at EUR 9/server/month.
They solve different problems. Wordfence is better for WordPress-specific protections: login 2FA, plugin vulnerability database, and application-level firewall rules. Defensia is better for server-level security: SSH protection, OS-level WAF, malware scanning with 64K+ hashes, CVE scanning, and multi-server management. The ideal setup is both: Wordfence Free inside WordPress + Defensia on the server.
Defensia WAF telemetry: aggregated wp-login.php and xmlrpc.php attack data from 9 production servers (2025-2026)
WordPress.org Plugin Vulnerabilities: https://www.wordfence.com/threat-intel/vulnerabilities/
OWASP WordPress Security Implementation Guideline: https://owasp.org/www-project-web-security-testing-guide/
Sucuri Hacked Website Report: https://sucuri.net/reports/website-hacking-statistics/
WPScan Vulnerability Database: https://wpscan.com/statistics
SSH protection, WAF, malware scanner, and CVE scanning. One command install.
Free for 1 server. No credit card required.