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?

Improve this question
10
  • 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, 2015 at 2:54
  • 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, 2015 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, 2015 at 14:08
  • 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, 2015 at 12:00
  • 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 5, 2016 at 0:59

1 Answer 1

Reset to default
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.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .