View Sidebar

Post Tagged with: cpanel

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!

PTY allocation request failed

PTY allocation request failed

My hosting provider, Razor Servers, recently moved hosted centers from the 401 North Broad St location in Philadelphia to a building right next door.  As part of my VM move to the new location, I was no longer able to SSH into the device.  I got this strange error about PTY allocation request failed.  In addition, the SPAMD process was not running on the box.  I tried to re-install SpamAssassin, I tried to re-install Exim and I even tried a complete upgrade of cPanel.  No go.  I thought the two might be related so a Googling I went…

After a good long while of Googling the problem, I found this site with my exact error message.  Via the web console, I checked to see if /dev/ptmx existed, it didn’t.  I ran the command as noted on the page:

sbin/MAKEDEV -d /dev ptmx

Restarted the ssh daemon:

service sshd restart

And, presto, I was able to SSH back into my box.  No idea why that file would disappear after a VM move, but it is all fixed now.