3

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.

schroeder
  • 123,438
  • 55
  • 284
  • 319
whoami
  • 131
  • 3
  • 2
    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 - Vignesh4303 Mar 24 '17 at 06:57
  • Consider reading [this](https://security.stackexchange.com/questions/108116/are-recaptcha-enough-to-prevent-brute-force-password-guesses) and [this](https://security.stackexchange.com/questions/13555/appropriate-strategy-for-preventing-brute-forcing-of-logins). – MiaoHatola Mar 24 '17 at 06:58
  • 1
    There is nothing that can be done on the client side – schroeder Mar 24 '17 at 07:33
  • 1
    @BlueBerry-Vignesh4303 using a honeypot only increases the CPU load. The OP also says that there is a large number of usernames used. – schroeder Mar 24 '17 at 07:35
  • You can scan one of the zombies. nmap -sS/-sU -p 1-65535 . Open ports can tell you more information sometimes. – user3606329 Mar 24 '17 at 07:45
  • 1
    @user3606329 what could be done with any information gained by a scan? – schroeder Mar 24 '17 at 08:02
  • @schroeder: There are lots of cases where ports could help to identify the attack.For example luminati.io sells peer's bandwith from Hola VPN. The open ports lead to their service - and the attack could be stopped. – user3606329 Mar 24 '17 at 14:27

3 Answers3

11

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.

schroeder
  • 123,438
  • 55
  • 284
  • 319
5

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.

Dmitry Grigoryev
  • 10,072
  • 1
  • 26
  • 56
  • 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 08: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 Grigoryev Mar 24 '17 at 08: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 09:23
2

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.

Andrew
  • 371
  • 1
  • 6