Distributed wordpress attacks/scans
We have many cPanel shared hosting servers (all fully updated). Over the past month I've seen a very large increase in POSTS to wp-login.php from thousands of unique IPs. They come in waves. It has proven very difficult to block because the IPs are unique and they never hit more than a couple times per IP so they don't typically trip any firewall rules or brute force rules. They are also directed at multiple wordpress sites on the shared server, so it's not a single target domain or IP either.
When these scans/posts occur it tends to shoot up the load on the server quite substantially. The servers are very high end with a lot of ram and CPU but this amount of requests will take its toll in the long run. I did switch to nginx which handles the amount of requests much better but doesn't fully resolve the problem always.
I have mod security rules in place for blocking POSTS to wp-login.php if they come from a non-referrer, I also have modsec blocking on xmlrpc as well as CSF.
Csf works somewhat but as I said before these types of POST look like legit traffic because they come from a unique IP and aren't hitting more than 2 times per attack so CSF doesn't typically trigger on it and when they all come in at once the load shoots up before CSF even has a chance to start blocking ips.
The last time a POST wave hit I counted over 3,000 unique Ips posting to various wp-login.php files on the server. It's not just this one particular shared server either, but I've seen it across multiple other servers as well.
Has anyone else been seeing these large DDOS like wordpress hack attempts and if so how are you dealing with them? I'm finding it difficult to block this type of attack without restricting legit access to wordpress for shared clients.
The only thing that has helped somewhat has been me manually looking for these in the logs and mass banning IPs but the unique Ips never seem to stop, I get up to thousands of bans in the firewall and it starts to degrade performance
-
On the basis that Wordpress is one of the most popular, and therefore exploited, scripts in the known universe, it shouldn't be much of a surprise to see so many exploit attempts. Stopping them entirely is probably unrealistic, unless all your WP admins happen to log in from static IPs that can be controlled in htaccess. o_O You may find this article useful Preventing Brute Force Attacks Against WordPress Websites On a personal note, I can recommend CloudLinux to monitor resource usage and allocate and throttle server resources, so that spikes of heavy load against one or more websites do not compromise the other sites on the server. I also deploy IPSET on my dedicated servers (as recommended by CSF) which allows one to add thousands of IP's to the firewall without degrading the server or firewall performance. Some colleagues have reported difficulties with IPSET on virtualised servers, so do take care before you attempt to deploy it. 0 -
Thanks for the info, ipset sounds like it would be helpful. Unfortunately unsupported in our openvz environment, but may be possible to implement on a box higher up the chain. also appears to be supported in virtuzzo7 which is still relatively new but I'm considering migrating our VMs to it in the future once stable 0 -
You are not alone in this. The ModSecurity rules for no referer etc are the most important but as noted can't stop it all. If it's to the point where brute force logins are effectively DoSing you, I would look honestly into sucuri's cloud firewall. I am in no way affiliated with Sucuri, but they do tons of work with their WAF to prevent this kind of stuff. That way, the processing overhead of blocked requests is offloaded to a 3rd party resource. Unfortunately this may not be economical with tons of domains. One idea however, which I do with my own modsec rules in cases like this, is change the action from 'deny' to 'drop'. This does a TCP reset instead of finishing the connection and can alleviate load, because your server doesn't even have to send response headers/body. You can also do 'drop,nolog' if it's really bad, which would also make CSF not even notice the request (because the drop action wasn't logged). This can be tricky if you have to troubleshoot a false positive though, so use nolog carefully. The reason I bring up drop/nolog is because in many cases, 'deny' creates more load when errordocs are missing. For example if your default status for deny is 406, and 406.shtml doesn't exist, the 404 for the request searching for the errordocument causes the homepage of the WP site to load. In other words, this series of events happens: The request is blocked, The server tries to send 406.shtml, but can't find it Server then sends 404 instead WP takes over 404 handling, and renders the whole site with PHP. The simple fix there is to use a odd status like 411 (i.e. 'deny,status:411,id:###') and add a htaccess in /home/.htaccess that contains only the line "errordocument 411 default". This can significantly reduce overhead from processing requests that are denied to begin with, because you're only sending back a plaintext errordoc rather than a PHP rendered page. Edit; one other idea because you seem knowledgeable enough to understand this # Block POST requests based on Spamhaus sbl-xbl. Don't use zen since it lists dynamic space. # Whitelist file too just in case. SecRule REQUEST_URI "wp-login.php|xmlrpc.php" "chain,id:12345,log,t:normalisePath,deny,status:411,msg:'IP on RBL: sbl-xbl.spamhaus.org'" SecRule REQUEST_METHOD "POST" "chain" SecRule REMOTE_ADDR "!@ipMatchFromFile /usr/local/apache/conf/modsec2/ip_whitelist.txt" "chain" SecRule REMOTE_ADDR "@rbl sbl-xbl.spamhaus.org"
This would filter wp-logins against spamhaus RBL, skpping zen (because that lists all home/dynamic IP's; obviously we don't want to do that.) You might want to make sure your data center has a spamhaus mirror, otherwise you may have issues with the volume of lookups. If you try this you need to create the file /usr/local/apache/conf/modsec2/ip_whitelist.txt first. You can add IP's (one per line) to exclude from this rule in case you have users working from dirty IP ranges.0 -
Hello @jfall123, The previous posts to this thread describe the best options available to address this issue. Let us know if you have any additional questions, or if we can be of any further help. Thank you. 0 -
You are not alone in this. The ModSecurity rules for no referer etc are the most important but as noted can't stop it all. If it's to the point where brute force logins are effectively DoSing you, I would look honestly into sucuri's cloud firewall. I am in no way affiliated with Sucuri, but they do tons of work with their WAF to prevent this kind of stuff. That way, the processing overhead of blocked requests is offloaded to a 3rd party resource. Unfortunately this may not be economical with tons of domains. One idea however, which I do with my own modsec rules in cases like this, is change the action from 'deny' to 'drop'. This does a TCP reset instead of finishing the connection and can alleviate load, because your server doesn't even have to send response headers/body. You can also do 'drop,nolog' if it's really bad, which would also make CSF not even notice the request (because the drop action wasn't logged). This can be tricky if you have to troubleshoot a false positive though, so use nolog carefully. The reason I bring up drop/nolog is because in many cases, 'deny' creates more load when errordocs are missing. For example if your default status for deny is 406, and 406.shtml doesn't exist, the 404 for the request searching for the errordocument causes the homepage of the WP site to load. In other words, this series of events happens: The request is blocked, The server tries to send 406.shtml, but can't find it Server then sends 404 instead WP takes over 404 handling, and renders the whole site with PHP. The simple fix there is to use a odd status like 411 (i.e. 'deny,status:411,id:###') and add a htaccess in /home/.htaccess that contains only the line "errordocument 411 default". This can significantly reduce overhead from processing requests that are denied to begin with, because you're only sending back a plaintext errordoc rather than a PHP rendered page. Edit; one other idea because you seem knowledgeable enough to understand this
# Block POST requests based on Spamhaus sbl-xbl. Don't use zen since it lists dynamic space. # Whitelist file too just in case. SecRule REQUEST_URI "wp-login.php|xmlrpc.php" "chain,id:12345,log,t:normalisePath,deny,status:411,msg:'IP on RBL: sbl-xbl.spamhaus.org'" SecRule REQUEST_METHOD "POST" "chain" SecRule REMOTE_ADDR "!@ipMatchFromFile /usr/local/apache/conf/modsec2/ip_whitelist.txt" "chain" SecRule REMOTE_ADDR "@rbl sbl-xbl.spamhaus.org"
This would filter wp-logins against spamhaus RBL, skpping zen (because that lists all home/dynamic IP's; obviously we don't want to do that.) You might want to make sure your data center has a spamhaus mirror, otherwise you may have issues with the volume of lookups. If you try this you need to create the file /usr/local/apache/conf/modsec2/ip_whitelist.txt first. You can add IP's (one per line) to exclude from this rule in case you have users working from dirty IP ranges.
Hello quizknows, Thank you for your post, using RBl to block wp attack is amazing. I've tested this and it works. I am using our own spamhaus mirrored rbl data, it has xbl, sbl and pbl. I am using this for Exim email and it works great. When I changed the "@rbl sbl-xbl.spamhaus.org" to "@rbl rbl.ourdomain.com", I found that some ISP(comcast) IPs are also blocked. I've checked those IPs on mxtoolbox but found they were on pbl list but not on xbl and sbl. I am wondering how to use xbl and sbl only. I suppose either the address sbl-xbl.spamhaus.org or sbl-xbl.ourdomain.com is the one, but I've tried it and it didn't work, those IPs still get blocked. Thank you for any help.0 -
As it seems you have figured out, your issue is because PBL is included; PBL will list all dynamic space (i.e. comcast, ATT). If you can figure out a way to mirror just sbl/XBL then it should work as intended, but unfortunately I may not be of help there. Someone else in our data center handles our spamhaus mirrors. I think we use our resolvers to hijack the DNS for it to our mirrored zones. 0 -
As it seems you have figured out, your issue is because PBL is included; PBL will list all dynamic space (i.e. comcast, ATT). If you can figure out a way to mirror just sbl/XBL then it should work as intended, but unfortunately I may not be of help there. Someone else in our data center handles our spamhaus mirrors. I think we use our resolvers to hijack the DNS for it to our mirrored zones.
Thank you. I think I know how to handle this now since I manage the spamhaus mirror and resolvers.0
Please sign in to leave a comment.
Comments
7 comments