View Sidebar

Post Tagged with: hosting

Preventing WordPress Brute Force Attacks with Fail2Ban

Preventing WordPress Brute Force Attacks with Fail2Ban

I have been experiencing a high number of brute force attacks on the admin pages of some of my WordPress blogs.  Generally, I don’t worry too much about this.  I utilize multiple levels of security controls to prevent access to the admin sites, but the increase in bandwidth and load on my system during these attacks was a concern and I wanted a clean way to prevent it from happening.

I looked into some type of WordPress Plugin to stop the attacks, but I soon realized it wouldn’t stop my main concern, the bandwidth and CPU load the attacks caused.  I wanted a reactive, IP address block against the offending systems.  I already used Fail2Ban for SSH, FTP and other types of brute force attacks.  Why can’t I used Fail2Ban for WordPress logins as well?

I did some searching and found the following web site that gave me the base for my filter and jail configs (Check that site for all the technical details, I won’t steal directly from him).  But, there were some problems that I had to customize to get it work for on my site.

First, the configs mentioned do not use my preferred method of blocking access, IPTABLES nor does it send an email when a IP is blocked. Second, my hosting server is using cPanel as a management system and it uses multiple access log files for all the different sites.

First Problem — Using IPTABLES and sending email alert
Here is the way I edited my /etc/fail2ban/jail.local file to support the changes I wanted to make.  The most important addition I have is the action line that lists iptables-multiport.  This blocks the IP at the TCP/IP level, never letting them touch the server again during the ban time.  In addition, I added the sendmail-whois line to the action to get the email out the door.   (Note, items in <> were removed by me to prevent private data from going public)

# Added for WordPress Brute Force
[apache-wp-login]

enabled = true
port = http,https
action = iptables-multiport[name=Wordpress, port=”http,https”, protocol=tcp]
sendmail-whois[name=Wordpress, dest=<email>, sender=fail2ban@<host>]
filter = apache-wp-login
logpath = /usr/local/apache/domlogs*/*.*
maxretry = 10
bantime = 86400
findtime = 120

Second Problem — Supporting cPanel multiple log files
As listed above, the logpath command is a tricky one.  Fail2Ban wants a direct path to the Apache access_log file.  Since I use cPanel and it splits out each host/site with it’s own log file, it was tough to set this up.  I could have manually entered each log file.  But, this would have required me to remember to add the log file in for each new host.  By using the logpath line item as listed, I was able to monitor all the log files in the directory, all the time.

logpath = /usr/local/apache/domlogs*/*.*

And that’s it!  I modified the maxretry and bantime (10 attempts and 24 hour ban time) to my preferred settings, restarted fail2ban and tested.  Success!