So as I’ve mentioned previously I’ve moved to the world of a VPS which for all intents in purposes is much like being self-hosted. I used to do this stuff a long time ago, I still do it but not nearly as intensively and for the most part my shell-fu has gotten rusty.
I spent the first part of Saturday getting the server setup and figuring out WHM and cPanel, both unbelievably easy. The biggest issue was making sure I had things locked down. I just set up this server though, who could possibly be attacking it?
You can see where I turned the server on on the 13th. Notice that big spike shortly there after, yeah that was a huge influx of traffic. It caused the server to grind to a halt. At the time I thought it was related to me bringing up my site since it locked up within minutes and I had tweaked some server settings an thought that caused the instability.
Come Monday morning I have an email from A Girl that she cannot get in and 2 from the data-center that they rebooted the server after it ran out of memory and locked up.
You cant see it as well except for the latest incident in those images but there is a serious proc-load spike when those bandwidth spikes occur. I promptly switched from APF to CSF for my firewall so I could gain use of the LFD. I spent my time installing and configuring it last night.
There you can see the proc spike from an an incident last night. I did a few more tweaks to the CSF and you can see things were better when they tried again about an hour later. In the middle of all of this I also discover that there is a way to have Apache watch all the wp-login pages for failed logins. When they happen, block and ban the IP after numerous failed attempts. This is why I called myHosting lazy and was so pissed about their approach in handling the problem.
If you are a server administrator and want to protect against the WordPress brute force attack it is quite simple, doubly so if you have WHM.
Login to WHM, goto Software-EasyApache. Follow the onscreen instructions and rebuild Apache but make sure the modsec2 module is selected. Build Apache.
Once built, log in to your shell and edit /usr/local/apache/conf/modsec2.user.conf and add the following.
#Block WP logins with no referring URL
SecRule REQUEST_METHOD “POST” “deny,status:401,id:5000211,chain,msg:’wp-login request blocked, no referer’”
SecRule &HTTP_REFERER “@eq 0″
#Wordpress Brute Force detection
# Setup brute force detection.
# React if block flag has been set.
SecRule ip:bf_block “@gt 0″ “deny,status:401,log,id:5000213,msg:’ip address blocked for 5 minutes, more than 10 login attempts in 3 minutes.’”
# Setup Tracking. On a successful login, a 302 redirect is performed, a 200 indicates login failed.
SecRule RESPONSE_STATUS “^302″ “phase:5,t:none,nolog,pass,setvar:ip.bf_counter=0,id:5000214″
SecRule RESPONSE_STATUS “^200″ “phase:5,chain,t:none,nolog,pass,setvar:ip.bf_counter=+1,deprecatevar:ip.bf_counter=1/180,id:5000215″
SecRule ip:bf_counter “@gt 10″ “t:none,setvar:ip.bf_block=1,expirevar:ip.bf_block=300,setvar:ip.bf_counter=0″
Save the file and restart Apache. This will help stop the brute force attacks. If it wasn’t for the off chance of false positives, I’d be good with a perma-ban and dropping that axe like a rock….
Funny story, I dropped that !@#$ing ax on myself tonight. Most of the other services are watched by LFD and when you get multiple login failures, it drops the ax and hard. I screwed up logging in and paid the price. I was just going along minding my own business and tried to login a couple times with the wrong password and bam there I am behind a curtain with some asshole molesting my balls. Man, when I describe it like that it sounds like my intrusion detection system works for the TSA.
In the mean time the folks I got the VPS from (they’ve been fantastic support wise, unlike that previous host) are looking into trying to figure out what’s causing the load spikes. The bummer is it randomly happens so it’s a paint to catch in the act. The good news is the past couple slams the server has actually survived so it’s almost there. Security wise it isn’t a concern, it’s just and issue with service.