For about a week now, our plugin store for Advanced Ads is attacked by bots. It looks like a massive brute force attack on our client’s login pages and few on our WordPress login. Our biggest problem is not that accounts get captured, but that the sheer size of the requests simply brings our server down. So far, this meant
- users and we often see a Database connection failed error and can not access the manual and the store
- automatic payments fail/are not recognized by the store after being made with the payment provider
- I can not access the FTP account
While I am not an expert on server side issues, I thought it might be interesting and helpful for others to see what I did so far and what helped and what did not. The following is more or less in chronological order.
Being contacted by our hosting provider
I am not sure what came first, us noticing that the site was not available sometimes or our hosting company informing us that they moved our site to another server to handle the increased traffic.
I had to contact their support to learn that there were a lot of requests on our site. They also told me which URL – the /account page.
They are helpful in giving me all information I am looking for – like log files – and also suggested some commercial services to use that provide protection.
I was a bit surprised to see that they don‘t have any in-house solution for protection. On the other hand, another hosting company shut our store down completely when something similar happened last time, so I am happy that they found a solution to keep our site online.
Asking Easy Digital Downloads
When I figured out that most requests go to the store login page, I contacted Easy Digital Downloads, the solution we use to sell our plugins.
They suggested to use a third-party solution to secure the login with a captcha, but I found it to be outdated and not to work with the reCaptcha API anymore. Anyway, this might not protect us much from massive requests anyway.
Moving the login page
If the attack is only hitting /account , why not moving the login to another page?
I just went to edit the account page, which is a static one and changed the URL to /your-account.
Then I added the following line into the .htaccess to block access to the previous account page.
RewriteRule ^(account)($|/) - [F]
I felt very clever about this solution, but only a few seconds later, the bots started to attack that new page.
Still trying to protect the accounts first, I contacted someone I know from a WordPress conference who also happens to use Easy Digital Downloads, but without a login to ask if their smart solution is available as a plugin. It wasn’t, be he suggested to contact a service called Sucuri to protect my website.
I already had an account with Sucuri from a while ago when they helped to remove this very site from a blacklist some time ago.
Their Website Firewall looked like the solution I needed now, so I ordered it after a not very productive chat about what I might need because they didn’t even bother to check my URL to see if I had SSL running and in fact needed a larger package.
Two days after the purchase, I still haven’t enabled it, since I either have to pay three times more to keep my expensive SSL certificate or use theirs after a downtime of the store for a few hours.
I decided to wait til next Sunday to install their firewall since there is less traffic on the site then. Disabling SSL on the manual is not a problem, but the payments won’t work then.
In the meantime, I ordered a malware check with them, just in case.
A colleague suggested using the 6G Firewall script to protect the site. I couldn’t test it because my FTP access was not working, so I installed a plugin that has this included. Unfortunately, that didn’t help.
Still, I think this is a decent script to offer security for many malicious attacks.
Since I was already testing plugins, I moved on to All In One WP Security & Firewall. I didn’t find a starting point with it, so I moved on to WordFence, which I know from many other sites.
The plugin did a slightly better job with onboarding. The Live Traffic option that shows who is currently accessing which site gave a good starting point.
It showed the constantly changing IPs, but that User Agent strings were only slightly different. Most mimicking an older version of the Internet Explorer.
WordFence allowed me to set up rules to stop these user agents and right after I found the correct pattern for this, the attacks stopped.
Well, at least there was not a single database connection error anymore, and I was able to connect via FTP again without any interruptions.
However, as I learned from my hosting provider, the attempts didn’t stop on the server, and since WordFence performs actions on the database as well, too much performance is used.
WordFence now also checks the WordPress login for failed login attempts, so this feels a bit more secure, too.
Looking again at the access log, I noticed that even though I moved my login to /account again, most attacks still went to /your-account.
After it didn’t work to block the login page, because bots just moved on, I now tested redirecting them directly to https://google.com using the following rule in my .htaccess .
Redirect /your-account https://google.com/
My hope is that the bots won’t notice that they are no longer on our site and don’t bother looking for an alternative.
So far, it seems to work. /your-account does still show up in the access logs which is normal as my hosting provider confirmed. They still suggest using some anti DDoS-attack service like CloudFlare or Sucuri to make sure the bot traffic does not even hit our server and slows it down.
Enabling Sucuri Firewall – just in case
When I checked the log files on the bespoken Sunday when I wanted to enable the Firewall service, I noticed that there was no attack going on anymore.
The bots seem to have given up. I feel a bit proud about having outsmarted them. For a moment, I thought about asking for my money back at Sucuri, but then I moved to their firewall anyway. There is still bot traffic to the main WordPress login form, and other files and I don’t want to be nervous about another attack.
I decided to go with the Let’s Encrypt SSL offered by Sucuri. At first, it looked like everything was running smoothly. The DNS records changed within an hour, and also HTTPS worked quickly for me. Then, more and more users complained that they saw a warning from Sucuri and weren’t able to access the site, so I reverted the settings. The manual once said that SSL is enabled automatically, another page mentioned that I should reach out to support for this.
Going back and forth with Sucuri’s support for a few days about the best workflow to prevent downtime. I decided to go with the larger Professional package to keep my SSL certificate and avoid any downtime. Uploading the certificate seemed to work, but to be sure, I contacted them again. It turned out that it wasn’t working properly and they had to fix something manually. After that, I was able to switch the DNS entry with no downtime.
After enabling Sucuri, I disabled my custom User Agent rules in WordFence just in case real humans are using those.
Btw., the malware check I issued earlier came back negative, so no harm was done yet.
The bot attacked kept me busy for more than a week. It forced me to think more about security in general and hopefully resulted in a decision by having a firewall and a security plugin in place. I am also going on adding another security layer to the customer login form in the next days.
Comments? If you have neat suggestions for more security, then please let me know about them in the comments. Please be aware, that I am no expert in this field and won’t be able your specific questions though. I rather hope that the outline of what I did helps you to find your solution.