Few days ago one of my sites got brute force attacked. The site is hosted on a shared server, and the webhosting shut my site down for consuming too much resources. After that I decided to dig into this issue a little deeper, so I started a discussion on a LinkedIn Group called “WordPress Developers.”
My question is: “My site got brute force attacked. Anyone had the same experiences, would you please share how your hosting company dealt with it? Any suggestions on preventing DDOS or brute force attacks, or hosting recommendation are welcome!”
I get 11 comments from others so far, there are several WordPress security plugins are recommended:
I actually installed a Sucuri security plugin (a premium version for their customer) on the site was attacked, it sends notification when login attempt fails, and it could block the suspicious IPs in their blacklist. But I guess it couldn’t defence a mass attack my site encountered, and maybe made it even worse for keep sending notification mails. So here are some suggestions for anyone who’s looking for non-plugin solution to brute force attacks:
- Whitelist your IPs in .htaccess
- Set a second password for your wp-admin if you don’t have static IP to whitelist
- Blacklist suspicious IPs in .htaccess if you don’t have static IP to whitelist
If you noticed, I added “preventing DDoS” to my question. I learned from great folks who gave me valued information included:
- “As far as I know there’s no reliable DDoS protection at the application level. I mean you can’t prevent a DDoS attack on your WordPress site by using a plugin or such. “
- “You could have load balancing in place to ensure availability by having additional infrastructure in place, or a hardware firewall with DDoS protection.”
- “DDOS is almost impossible to prevent. If they really want to take your site down by DDos they will probably get it right.”
- “captcha is for reducing spam on your site, and logically a spammer does not wants the website to go down – as he wants to be able to post, while in case of a a DDoS attack the attacker wants to put the site down. “
- “I’ve found the most success using CloudFlare, which sits in front of your site and takes on all the bad hits and knows from multiple sites across their enterprise which IP addresses are causing mayhem. This significantly reduces how much of that traffic hits your server/site. They also filter out other known bad guys, including bad crawler bots.”
That really help me a lot cause I’m kinda confused by the difference between brute force attacks and DDoS. Now suppose answers from my group folks are right, I have a new question: “Should webhosting service provide DDoS protection on a shared hosting since it can’t be prevented at the application level?”
According to my chat script with MediaTemple support, he responded: “Unfortunately, we don’t have ddos protection or a IP ban available on a (gs) Grid-Service.” I’m okay with it, I just don’t understand – WHY NOT?
Let me try to figure it out and share with you in the future posts. 🙂
5 thoughts on “Lessons learned after brute force attacks”
Thanks for quoting me in your blog post.
Regarding your question, most of the hosting companies started their business a while ago when DDoS attacks where a theoretical threat – not a practical one.
They could offer this, but it will also mean additional costs in resources, both infrastructure and people.
Is still quite hard for someone to achieve it, and yes temporarily banning an IP address would help protecting from a brute-force attack but not from a DDoS attack.
If you have a critical service, than needs 100% uptime you can benchmark it with various amounts of traffic in an enclosed environment, and then when you’re confident release it to the public.
Adrian, thanks for answering my question again! I could understand the DDoS is hard to prevent, just think it would be great for a webhosting, to show the customers that you’re taking care of them even the it’s technically impossible.