We have a web application and that's been frequently hit with random username and password to find a successful login attempt. We introduced CAPTCHA, random token generation but that didn't stop the hacker hitting our web server. Our web server CPU reaches 99% usage level and it slows down the website for genuine users.

We need to know whether there are any ways to stop hitting the web server(maybe on the client side itself). I don't know whether it's possible. Can someone tell how to handle this?

Additional info - hacker hits our site from 1000 diff IPs, we blocked all those but he is coming with new set of IPs every time. Also, he has million+ username and passwords stolen from some website and he is using those on our site.

Did u mean DDOS?there were many anti ddos firms like cloudflare does this for u,Else implement honeypot and redirect the webserver users to their localhost,if its with respective to single user account log the ip's in db which the users hitting up
– BlueBerry - Vignesh4303Mar 24 '17 at 6:57

3 Answers
3

What you have is not so much a brute force problem but a load problem. Specifically, you have to think about it as a DDoS scenario. Multiple IPs hitting your server and consuming resources.

Account-level protections are not going to do anything, you need to handle the attack at the traffic level.

DDoS mitigation services are exactly what you need, but depending on the attack complexity, they might be too expensive. You could try working with your hosting company or ISP to see what they might be able to do.

Look into tools like fail2ban which allow you to limit the number of login attempts from a single IP address. Automatically banning an IP after 3 failed login attempts for 1 hour will effectively reduce the number of password guesses from 1000 IPs to less than 1 per second, without affecting your legitimate users too much.

Note that depending on where the firewall is, this might not lower the CPU load. If this is a hosted web server, then the firewall is also on the web server. fail2ban can consume resources, too.
– schroeder♦Mar 24 '17 at 8:03

@schroeder The OP says they blocked the initial IPs (presumably manually), and the attacker came back with new ones. I assumed manually banning these IPs did help, albeit temporarily.
– Dmitry GrigoryevMar 24 '17 at 8:27

4

Yes, but an automated process means that you end up with the economy of scale to your disadvantage. fail2ban running, plus constant updates to iptables, plus firewall processing all those increasing rules, now done automatically. Plus you still have all that incoming traffic. I have seen instances where the mitigation like this compounds the problem. It is far better if the mitigation is off the targeted server. So, your answer is fine, but a major caution should be made that if you try to do all this on the same server, 99% can become 100%.
– schroeder♦Mar 24 '17 at 9:23

What you need is to combine multiple solutions together to achieve the desired results. As pointed out by Dmitry and schroeder, you should deploy this server into a properly load-balanced environment in order to reduce the load of the one-server. From there, you also should use something such as Fail2Ban to prevent excessive abuse from a single IP. Fail2Ban would easily be able to check your Apache/Nginx access logs for auth-failures to block those IP's.

If the bandwidth is not as much of a concern as the overall load, simply isntalling Fail2Ban to block those incoming connections could be sufficient to reduce load enough on the server.

Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).