wp-login.php<\/code>. Brute-force login attempts against WordPress are extremely common \u2014 automated bots probe wp-login.php<\/code> on virtually any publicly discoverable WordPress site around the clock, and without protection like this, your server logs will fill up with thousands of these attempts over time, some of which will eventually succeed against weak credentials if left unaddressed.<\/p>\n\n\n\nCSF<\/strong> (ConfigServer Security & Firewall) is a popular firewall and intrusion-detection suite used widely on CentOS and cPanel servers. Out of the box, it blocks common attacks like failed SSH and IMAP logins, but WordPress-specific login protection isn’t built in by default \u2014 it requires adding a custom detection rule, which is exactly what this guide walks through, including two steps that are easy to miss and will leave the rule silently non-functional if skipped.<\/p>\n\n\n\n
\n\n\n\nImplementation<\/h2>\n\n\n\nI. Prerequisites<\/h3>\n\n\n\n
Before you block WordPress login attacks on CSF, make sure you have:<\/p>\n\n\n\n
\n- A CentOS server<\/li>\n\n\n\n
- A web server (Apache or LiteSpeed) serving your WordPress site<\/li>\n\n\n\n
- A WordPress installation with a known access log location<\/li>\n\n\n\n
- CSF firewall already installed and running<\/li>\n<\/ul>\n\n\n\n
II. How CSF and lfd Work Together<\/h3>\n\n\n\n
Before editing any files, it’s worth understanding the two components involved, since this guide touches both:<\/p>\n\n\n\n
\n- CSF<\/strong> is the firewall component \u2014 it manages the actual iptables (or firewalld) rules that allow or block traffic<\/li>\n\n\n\n
- lfd<\/strong> (Login Failure Daemon) is a separate background service that continuously watches log files for suspicious patterns \u2014 like repeated failed SSH logins \u2014 and instructs CSF to add a temporary or permanent block when a threshold is exceeded<\/li>\n<\/ul>\n\n\n\n
Custom detection rules, like the one this guide adds for WordPress, work by teaching lfd<\/code> a new pattern to watch for in a specified log file. This is why restarting only CSF itself isn’t enough to activate a new custom rule \u2014 lfd<\/code> is the service that actually needs to reload the updated pattern, which Step VII covers in detail after a lot of guides skip it entirely.<\/p>\n\n\n\n![\"\"](\"https:\/\/pheonixsolutions.com\/blog\/wp-content\/uploads\/2017\/08\/csf_lfd_wordpress_architecture-1024x512.png\")
<\/a><\/figure>\n\n\n\nIII. Understand How the Detection Rule Works<\/h3>\n\n\n\n
Add the following block to CSF’s custom regex file. Open it with a text editor:<\/p>\n\n\n\n
vi \/usr\/local\/csf\/bin\/regex.custom.pm\n<\/pre>\n\n\n\nAdd this rule:<\/p>\n\n\n\n
if (($globlogs{CUSTOM1_LOG}{$lgfile}) and ($line =~ \/(\\S+).*\\] \"POST \\\/wp-login\\.php.*\" 200\/)) {\n return (\"Failed WordPress login from\",\"$1\",\"wordpress\",\"5\",\"80,443\",\"3600\");\n}\n<\/pre>\n\n\n\n\nNote:<\/strong> If you’re copying this from an older source, double-check that any quotation marks are straight quotes (\"<\/code>), not curly\/smart quotes (\"<\/code> \"<\/code>). Smart quotes are a common artifact of copying text out of a word processor or certain web pages, and Perl (which regex.custom.pm<\/code> is written in) will fail to parse the file correctly if they slip in.<\/p>\n<\/blockquote>\n\n\n\nWhat the return values mean<\/strong>, in order: a description shown in block notifications, the captured IP address ($1<\/code>), a label used to group this rule’s blocks, the failure count threshold (5<\/code> \u2014 meaning 5 matched failures trigger a block), the ports to block (80,443<\/code>), and the block duration in seconds (3600<\/code> = 1 hour).<\/p>\n\n\n\nIV. Why This Rule Matches on HTTP Status 200<\/h3>\n\n\n\n
This is the part that confuses a lot of people at first glance, since a 200<\/code> status code normally means “success” \u2014 so why would it indicate a failed<\/em> login? Here’s the actual mechanism:<\/p>\n\n\n\n\n- When a WordPress login succeeds<\/strong>, WordPress issues an HTTP 302 redirect<\/strong> to
wp-admin<\/code> \u2014 the browser is sent somewhere else, not shown a rendered page directly<\/li>\n\n\n\n- When a WordPress login fails<\/strong>, WordPress re-renders the login page itself, showing an error message \u2014 which returns a standard 200 OK<\/strong> status, since a full page was successfully served, just one containing a login error rather than a dashboard<\/li>\n<\/ul>\n\n\n\n
So counterintuitively, a 200<\/code> response to a POST \/wp-login.php<\/code> request specifically indicates a failed attempt, while a 302<\/code> indicates success \u2014 which is exactly why the regex pattern above filters for 200<\/code> rather than 302<\/code>. This detail is worth understanding rather than just copying blindly, since it’s the entire basis for how this rule distinguishes real failed logins from successful ones in the log.<\/p>\n\n\n\nV. Configure the Custom Log Path<\/h3>\n\n\n\n
Now tell lfd<\/code> which log file to actually watch. Open CSF’s main configuration file:<\/p>\n\n\n\nvi \/etc\/csf\/csf.conf\n<\/pre>\n\n\n\nFind (or add) the CUSTOM1_LOG<\/code> setting and point it at your actual WordPress site’s access log:<\/p>\n\n\n\nCUSTOM1_LOG = \"\/home\/*\/access-logs\/*\"\n<\/pre>\n\n\n\nThe correct path depends on your hosting setup. Common examples:<\/p>\n\n\n\n
cPanel server (domain-specific log):<\/strong><\/p>\n\n\n\nCUSTOM1_LOG = \"\/home\/username\/access-logs\/domain.com\"\n<\/pre>\n\n\n\nPlain Apache server with combined logging:<\/strong><\/p>\n\n\n\nCUSTOM1_LOG = \"\/var\/log\/apache2\/access.log\"\n<\/pre>\n\n\n\n\nImportant:<\/strong> The wildcard example from the original quick-reference version (\/home\/*\/access-logs\/*<\/code>) works across all cPanel accounts on a server, but it’s broader than necessary if you’re only protecting one specific domain \u2014 pointing directly at the specific log file for the domain you’re protecting reduces the log-scanning overhead and avoids accidentally matching unrelated sites’ login attempts against the same threshold count.<\/p>\n<\/blockquote>\n\n\n\nVI. Restart Both CSF and lfd<\/h3>\n\n\n\n
This is the step most commonly missed, and it’s the reason a correctly written rule sometimes appears to do nothing. Restarting csf<\/code> alone reloads firewall rules, but lfd<\/code> \u2014 the actual process reading log files and applying custom regex rules \u2014 needs to be restarted separately to pick up the new pattern and log path:<\/p>\n\n\n\ncsf -r\nsystemctl restart lfd\n<\/pre>\n\n\n\n\nIf lfd<\/code> isn’t running as a systemd service on your specific CentOS version, use service lfd restart<\/code> instead.<\/p>\n<\/blockquote>\n\n\n\nVII. Verify the Rule Is Active<\/h3>\n\n\n\n
Confirm both services restarted cleanly:<\/p>\n\n\n\n
systemctl status lfd\ncsf -l\n<\/pre>\n\n\n\ncsf -l<\/code> lists currently active firewall rules; while this won’t show the custom regex rule directly (since no IP has been blocked yet), it confirms CSF itself is running correctly before you move on to testing.<\/p>\n\n\n\nVIII. Test the Rule<\/h3>\n\n\n\n
From a separate machine (not one you rely on for legitimate site access, in case something goes wrong), intentionally fail to log in to wp-login.php<\/code> on your WordPress site five times in a row \u2014 matching the threshold set in Step III.<\/p>\n\n\n\nThen check whether the IP was blocked:<\/p>\n\n\n\n
csf -g <TEST_IP_ADDRESS>\n<\/pre>\n\n\n\nThis searches CSF’s active rules for the specified IP. If it’s found, the rule is working correctly. You can also check lfd<\/code>‘s own log for confirmation:<\/p>\n\n\n\ntail -f \/var\/log\/lfd.log\n<\/pre>\n\n\n\nWatching this file live while triggering test failures is the most direct way to confirm the entire pipeline \u2014 log line, regex match, and block \u2014 is functioning end to end.<\/p>\n\n\n\n
IX. Whitelist Your Own IP First<\/h3>\n\n\n\n
Before relying on this in production, whitelist your own administrative IP address to avoid accidentally locking yourself out during legitimate troubleshooting or repeated password attempts:<\/p>\n\n\n\n
csf -a <YOUR_IP_ADDRESS> \"Admin - always allow\"\n<\/pre>\n\n\n\n\nImportant:<\/strong> Do this before<\/em> extensive testing, not after. It’s a genuinely common mistake to test a new brute-force protection rule from your own IP, get blocked by your own rule, and then be unable to reach the server’s control panel or SSH to fix it \u2014 plan around this in advance.<\/p>\n<\/blockquote>\n\n\n\nX. Unban an IP (If Needed)<\/h3>\n\n\n\n
If a legitimate user or your own IP gets blocked unexpectedly, remove the block with:<\/p>\n\n\n\n
csf -dr <IP_ADDRESS>\n<\/pre>\n\n\n\nXI. Troubleshooting Common Issues<\/h3>\n\n\n\n
The rule doesn’t trigger even after repeated failed logins:<\/strong> This is almost always one of two things: lfd<\/code> wasn’t restarted after the configuration change (Step VI), or CUSTOM1_LOG<\/code> doesn’t actually point to a log file that’s receiving WordPress access log entries. Confirm the log path is correct by checking it directly: tail -f \/path\/to\/your\/access-log<\/code> while triggering a test failure, and confirm you see matching POST \/wp-login.php<\/code> lines with a 200<\/code> status.<\/p>\n\n\n\nLegitimate users are getting blocked too easily:<\/strong> Consider raising the threshold from 5<\/code> to a higher number in the regex rule’s return statement, especially if your users are prone to typos, or pair this with a WordPress-side login limiting plugin that shows a warning before CSF’s threshold is reached.<\/p>\n\n\n\nThe rule blocks successful logins too:<\/strong> Double-check that the regex pattern specifically matches 200<\/code>, not a broader pattern that could also catch 302<\/code>. If you modified the original rule, verify the status code condition wasn’t accidentally altered or removed.<\/p>\n\n\n\nXII. Monitoring Blocked IPs Over Time<\/h3>\n\n\n\n
Once the rule is active, it’s worth periodically reviewing what it’s actually catching, both to confirm it’s working and to spot patterns worth acting on further.<\/p>\n\n\n\n
View all currently blocked IPs:<\/strong><\/p>\n\n\n\ncsf -l\n<\/pre>\n\n\n\nSearch specifically for WordPress-related blocks<\/strong>, using the label defined in the rule (wordpress<\/code>):<\/p>\n\n\n\ngrep wordpress \/var\/log\/lfd.log\n<\/pre>\n\n\n\nThis shows a running history of every IP that triggered the rule, which can reveal useful patterns \u2014 for example, a large number of attempts from a specific country or hosting provider’s IP range might justify a broader block using CSF’s country-blocking feature (CC_DENY<\/code> in csf.conf<\/code>), rather than relying solely on the per-IP threshold to catch each attacker individually.<\/p>\n\n\n\nCheck overall lfd activity and confirm the service remains healthy:<\/strong><\/p>\n\n\n\nsystemctl status lfd\n<\/pre>\n\n\n\nIf lfd<\/code> has crashed or stopped for any reason, no custom rules \u2014 including this one \u2014 will be enforced until it’s restarted, so periodic verification that the service is actually running is a worthwhile habit, not just a one-time setup check.<\/p>\n\n\n\nXIII. Best Practices for WordPress Login Security<\/h3>\n\n\n\n\n- Combine this with a WordPress-side login limiter plugin<\/strong> (like Limit Login Attempts Reloaded) for defense in depth \u2014 CSF blocks at the network\/firewall level, while a plugin can add account-level lockouts and user notifications, covering scenarios where an attacker rotates IP addresses faster than CSF’s threshold catches them<\/li>\n\n\n\n
- Consider renaming or restricting access to wp-login.php<\/strong> entirely for an additional layer, though be aware this can break some plugins or workflows that expect the default login path<\/li>\n\n\n\n
- Enable two-factor authentication<\/strong> on WordPress admin accounts, which meaningfully reduces the impact even if a brute-force attempt eventually succeeds against a weak password<\/li>\n\n\n\n
- Review
\/var\/log\/lfd.log<\/code> periodically<\/strong> to understand attack patterns and confirm the rule continues functioning correctly over time, especially after any CSF or server updates<\/li>\n<\/ul>\n\n\n\nXIV. Conclusion<\/h3>\n\n\n\n
Blocking WordPress login attacks with CSF comes down to teaching lfd<\/code> a custom pattern that correctly distinguishes failed logins (HTTP 200) from successful ones (HTTP 302), pointing it at the right access log file, and \u2014 critically \u2014 restarting lfd<\/code> itself, not just CSF, for the new rule to actually take effect. With your own IP whitelisted first and the rule verified through a real test, this becomes a reliable, low-maintenance layer of protection against the automated brute-force attempts that virtually every public WordPress site experiences continuously.<\/p>\n\n\n\nFor more on CSF’s configuration options and custom rule syntax, see the official CSF documentation<\/a>.<\/p>\n\n\n\n
\n\n\n\nFrequently Asked Questions<\/h2>\n\n\n\n
Why does my rule need lfd restarted, not just CSF?<\/strong> lfd<\/code> is the separate background process responsible for actually reading log files and matching custom regex patterns \u2014 CSF itself only manages firewall rules. Restarting CSF alone reloads firewall state but doesn’t make lfd<\/code> re-read the updated regex.custom.pm<\/code> file or the new CUSTOM1_LOG<\/code> path.<\/p>\n\n\n\nDoes this work with LiteSpeed or Nginx instead of Apache?<\/strong> Yes, as long as the web server’s access log uses a similar combined log format containing the HTTP method, request path, and status code \u2014 just point CUSTOM1_LOG<\/code> at that server’s actual access log path instead of Apache’s default location.<\/p>\n\n\n\nWill this block legitimate users who mistype their password a few times?<\/strong> It’s possible if they fail 5 times in a row within the tracking window, which is why whitelisting known-good IPs (Step IX) and considering a slightly higher threshold for sites with less security-conscious users are both worth considering based on your specific situation.<\/p>\n\n\n\nIs CSF’s custom rule approach better than using a WordPress security plugin instead?<\/strong> They solve the problem at different layers and work well together rather than being an either\/or choice \u2014 CSF blocks at the firewall level before the request even fully reaches WordPress, reducing server load from repeated attempts, while a WordPress plugin can add account-specific protections and admin notifications that a firewall-level rule can’t provide on its own.<\/p>\n\n\n\n
\n\n\n\nIf you have any questions about this setup or run into an issue not covered here, feel free to reach out to us at Pheonix Solutions<\/a> \u2014 we’re happy to help.<\/p>\n\n\n\nRelated Articles:<\/p>\n\n\n\n
How to Manage the CSF Firewall in WHM\/cPanel<\/a><\/p>\n\n\n\n
![\"\"](\"https:\/\/pheonixsolutions.com\/blog\/wp-content\/uploads\/2017\/08\/csf_lfd_wordpress_architecture-scaled.png\")
<\/a><\/figure>\n\n\n\n