What are hosts doing to combat Wordpress BruteForce Attempts?

ughosting

ughosting

HD Community Advisor
Staff member
Other than educating users about good passwords, regular updates, "limit login" plugins etc, what techniques are hosts using to limit attacks against their customers Wordpress blogs.

We've seen huge waves of wp-login.php attacks over christmas, and we can see constant "slow" Brute Force attempts now, which mod_sec rules just don't see.

Luckily cloud linux, stopped the boxes from getting anywhere near crashing, but performance of a number of our servers became sub optimal for a while.

Any further techniques would be greatly appreciated.
 
I'll redirect the login page of the wordpress to another website, based on user (admin) ip location, country. So like this they will go to let's say to 404 (or another website like redirect.com) instead to the login page. To avoid loading of server I'll use mod_geoip, or PHP geoip extension, and some paid database (IP info, GeoIP.dat) from Maxmind. Or automaticly ban the IP address that is trying to access the login file in firewall, but with this method you'll waste time.

Regards
 
We suggest our customers to use Cloudflare, but we have inhouse mod_sec rules that does the job quiet nicely.
We gave them to Melih (Comodo CEO) for their next WAF release.
 
I would be interested in how your mod_sec rules handle slow attacks.

We've written some log file analysis tools which can spot when an IP accesses multiple blogs, which belong to different resellers, and bans them. It's proving to be very effective, but it's far from elegant.
 
Plugins are not what I am after, I already a a script that will retro-fit limit-login-attempts to any wordpress blogs without it installed, and ask that users put a "CapCha" plugin as an optional extra.

These, however, help stop the blogs getting hacked, but they don't reduce the load on the server as the attempts are repeated by robots, these plugins make the attempt unsucessful, like a failure. The robots just see this as a failure and keep trying regardless of whether they need a capture or a maths question, or whether wordpress itself is "ignoring them".

I'm looking more for server level, than application level.
 
My very crude solution

logins.list

Wordpress:wp-login.php
Joomla:administrator/index.php


logins.sh#!/bin/bash

for APP in $(cat logins.list)
do

APP_NAME=$(echo ${APP} | awk -F':' '{print $1}')
APP_PATN=$(echo ${APP} | awk -F':' '{print $2}')

grep "${APP_PATN}" /var/log/httpd/domains/*.log | grep -v error.log > /tmp/logins.tmp

for IPFREQ in $(grep "${APP_PATN}" /tmp/logins.tmp | awk -F':' '{print $2}' | awk '{print $1}' | sort -n | uniq -c | awk '{print $1":"$2}' | sort -rn)
do

IP_FREQ=$(echo ${IPFREQ} | awk -F':' '{print $1}')
IP_ADDR=$(echo ${IPFREQ} | awk -F':' '{print $2}')

grep -q ${IP_ADDR} /var/lib/csf/csf.tempban

if [ $? -ne 0 ]
then

NUM_LOG=$(grep ${IP_ADDR} /tmp/logins.tmp | awk -F':' '{print $1}' | awk -F'/' '{print $NF}' | sort -u | wc -l)

cat /dev/null > /tmp/logins.resellers

for DOMAIN in $(grep ${IP_ADDR} /tmp/logins.tmp | awk -F':' '{print $1}' | awk -F'/' '{print $NF}' | awk -F'.log' '{print $1}' | sort -u)
do

USER=$(grep ${DOMAIN} /usr/local/directadmin/data/users/*/domains.list | awk -F'/' '{print $7}')
RESELLER=$(grep "^${USER}$" /usr/local/directadmin/data/users/*/users.list | awk -F'/' '{print $7}')
echo ${RESELLER} >> /tmp/logins.resellers

done

RESELLERS=$(cat /tmp/logins.resellers | uniq | wc -l)
cat /dev/null > /tmp/logins.resellers

if [ ${RESELLERS} -ge 2 ]
then

grep -q ${IP_ADDR} /etc/csf/csf.deny

if [ $? -ne 0 ]
then

/usr/sbin/csf -d ${IP_ADDR} "lfd - (${APP_NAME}) IP Blocked for ${IP_FREQ} login attempts on ${RESELLERS} resellers & ${NUM_LOG} sites" > /dev/null 2>&1

fi
fi

if [ ${IP_FREQ} -ge 2 ]
then


if [ ${IP_FREQ} -ge 20 ] || ([ ${IP_FREQ} -ge $((${NUM_LOG}+4)) ] && [ ${NUM_LOG} -ge 4 ]) || ([ ${IP_FREQ} -ge $((${NUM_LOG}*2)) ] && [ ${NUM_LOG} -ge 3 ])
then

/usr/sbin/csf -td ${IP_ADDR} 604800 -p 80 "lfd - (${APP_NAME}) IP Blocked for ${IP_FREQ} login attempts on ${NUM_LOG} site(s)" > /dev/null 2>&1

fi

else

break

fi
fi
done
done
rm -f /tmp/logins.tmp /tmp/logins.resellers


It looks complicated (and is for DirectAdmin) but essentially it is looking for people making particular combination attempts at loging into blogs.
Particularly if an IP is logins into blogs owned by different resellers, in which case it's pretty certain they are up to no good.
 
I agree CloudFlare is an excellent line of defense and they are only getting better. You can see their recent blog about their 2014 plans along with how they have expanded their Data Center connections around the world. It is easily enabled on shared and reseller servers through the client's cPanel access. Now if just more hosting users would recognize what a security and performance tool it can be.
 
The first thing you should do is make sure to .htaccess block by HTTP_REFERER – so if the request for wp-login does not come from your site, it will be blocked. This should stop most automated attacks without needing to invoke mod_security, your firewall or PHP.

Code: 
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{REQUEST_METHOD} =POST
RewriteCond %{HTTP_REFERER} !^http://(.*)?.yoursite.com [NC]
RewriteCond %{REQUEST_URI} ^/wp-login\.php(.*)$ [OR]
RewriteCond %{REQUEST_URI} ^/wp-admin$
RewriteRule ^(.*)$ - [R=403,L]
</IfModule>
NOTE: Replace 'yoursite.com' with your actual domain name!

Your clients should all be using a different username than 'admin' as well. Unfortunately, most users will leave this as default. A good way around this is to use a simple script that will find all WP sites installed on the server which are still using the username 'admin' and then changes the usernames to 'wpsecretadmin' or something else of your choosing.

These attacks depend on using a lot of computing power to "guess" the password for the user "admin" so if that user is not found, it will make the bot try elsewhere. You will need to inform your clients of the forced change, of course. Another fast and easy fix I found was to rename wp-login.php altogether, and then creating a new blank wp-login.php to save the server from having to display a 404 error. This however has to be repeated every time WP gets updated.

You can also read the steps recommended by WP in order to handle brute force attacks HERE. If you implement them all + educate your clients and constantly remind them about security, your server will stay up and your customers will stay happy. :)
 
This is a good example, but how would I force users to do this on ALL of their blogs.

Also not all users want to use Cloudflare. More often than not, within Europe, adding cloudflare will produce a page load slower than directly from our servers, so this is not something many users will want.

I'm looking at this from a service providers perspective, so it needs to work without changing a customers website.

Our solution works, but there but be something better, more elegant.
 
ughosting said:
I'm looking at this from a service providers perspective, so it needs to work without changing a customers website.
Click to expand...

I completely understand, however, there is only so much a provider can do before the client has to get involved and start taking responsibility for hardening/securing their own site. :agree: Don't be afraid to "slap your customer's hands" once in a while if they start slacking in securing on their end. You would be surprised at how many of them will be grateful that you did.
 
We run cloudflare on the majority of our WP sites and have it on our cPanel hosting for our customers..
 
We have tweaked the login procedures and Mod Security to prevent brute force attacks.
We also do not create new WP installations with "admin" user but others.
We have significantly decreased the amount of hacked customer wordpress sites to almost 0.
 
Hello, It is difficult to safe guard your self from brutal force without paying to any good brutal force protection company. Cloudflare is also a good choice but their rates are high.
 
You must log in or register to reply here.

Supporters

Back
Top