4

So I've implemented an IP Blocklist for the /login endpoint on my server.

If any IP fails to login more than x number of attempts in x number of minutes the requesting IP is blocklisted for x number of minutes.

That goes a long way in mitigating any brute-force attacks attempting to determine a users password by adding large delays to the mix when too many failed /login requests are received by any given IP.

But there's a scenario where this could be problematic, and actually be an instrument for an attacker to launch a DOS attack agains my legitimate user, like so:

  • BadHacker wants to DOS LegitUser's website
  • LegitUser has a server with the IP 11.22.33.44
  • LegitUser's server needs to communicate with my system in order to remain online.
  • BadHacker finds out what LegitUser's server IP is
  • BadHacker uses a proxy server as an IP-Spoofing machine to send a large number of purposely unsuccessful /login attempts to my system, knowing that these failed attempts will get the requesting IP (which has been spoofed to be 11.22.33.44) blocklisted.
  • BadHacker doesn't care if they receive a response from my system for the purposely unsuccessful /login requests because the point of this attack is not to brute-force any credentials, it's to trick my system into believing that the IP 11.22.33.44 has exceeded its allotted login failures for any given timeframe.
  • The result is that the IP 11.22.33.44 is blocklisted by my system. But, this IP does not belong to BadHacker, it belongs to LegitUser, who has played no role in this attack at all.
  • The result of the blocklisting of the IP 11.22.33.44 is that the website served from that host is now offline, because it depends on my system to remain online.

How could I go about protecting against this?

AJB
  • 316
  • 2
  • 12
  • Thats impossible. There is no way to authenticate that the actual user is entering incorrect passwords. If s.o. tries to hack your facebook account they will block the entire account and send you an email. As for your services: dont blacklist. – marstato Dec 25 '15 at 01:35
  • 1
    Hi @marstato, I'm not sure I understand your comment, or that you fully understand the scenario I'm describing. I've edited it now to make things clearer. – AJB Dec 25 '15 at 02:54
  • This is one of the reasons why IP Blacklisting does not work very effectively. another scenario is when two legitimate users share the same Public IP address. say, one user has many failed login attempts which leads to their IP getting blacklisted. then the other legitimate user under that public IP address is affected. – JOW Dec 25 '15 at 04:24
  • Ah, right. Like a corporate proxy, perhaps. Hmmm. Okay, I think I understand marsato's comment a bit better. So is it safe to assume the general idea among the Infosec pros is that Blacklisting is to be avoided for the reasons you listed? What is used in it's place? Rate limiting? Would that not suffer the same flaws since both use the IP as the ID for tracking? – AJB Dec 25 '15 at 04:28
  • 1
    @AJB as far as i can see, IP blacklisting works as it shoulld. however, it must be used wisely as it also has some limitations too(just like everything else). I think you should wait for someone here to provide an alternative(answer). – JOW Dec 25 '15 at 12:58
  • 1
    to clear it up a bit: i think it is okey for a website to blacklist accounts/ips for human interaction with the system (e.g. admin login). Not even big companies as google and facebook have a solution to this; so i think there is no solution. But for your services (API, etc), just dont blacklist (for the reasons/complications mentioned). – marstato Dec 25 '15 at 14:08
  • Got it. That's what I've done now. Any APIs that can provide a true/false answer to a password guess are now 'blacklist-able', other APIs are not. Thanks for your advice folks! – AJB Dec 28 '15 at 01:26
  • 1
    How can the attacker sends requests to the /login page with spoofed IPs? Before he can initiate an HTTP request, he needs to complete the 3-way TCP handshake and that is very very difficult to pulled off with spoof IPs (theoretically possible but practically almost impossible). – void_in Dec 31 '15 at 12:00
  • @void_in, I'm trying to find some time to learn and understand the TCP handshake better. I may be protecting against something impossible, not sure yet. – AJB Jan 05 '16 at 00:59
  • 1
    On a side note, I dropped blacklisting altogether in favour of Recaptcha (or Recaptcha triggered by failed logins) by accountID. This actually prevents this problem altogether, if it even was a problem to begin with. – AJB Jan 05 '16 at 00:59

1 Answers1

4

According to several of these answers:

https://serverfault.com/questions/381393/can-the-ip-address-for-an-http-request-be-spoofed

It is really unlikely that you could indeed spoof the IP address and send a full HTTP request to a server. TCP requires a three-way handshake, which means sending one packet back to the sender and expecting a very specific answer back (with a number that is expected to be random, 10+ years ago, that number would just be incremented so it was possible to more or less guess the next number and thus send a "reply"--second request really--with the data and thus the HTTP request itself).

With that in mind, blocking an IP address is a good way to prevent wasting bandwidth to satisfy a robot thirst in an attempt to log in an account. Many systems offer this capability and most, like yours, do it temporarily. Actually, I generally set mine up to block that account for 1 whole day because I've seen many attacks lasting at least that long. That being said, my websites are not like Facebook or Twitter where people come back several times a day pretty much every day... So it will depend on your business model, who uses your systems, how much, how often they need to log in or log back in, etc.

Community
  • 1
Alexis Wilke
  • 862
  • 5
  • 19