So I've implemented an IP Blacklist 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 blacklisted 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:

  • Blackhat wants to DOS LegitUser's website
  • LegitUser has a server with the IP
  • LegitUser's server needs to communicate with my system in order to remain online.
  • Blackhat finds out what LegitUser's server IP is
  • Blackhat 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 blacklisted.
  • Blackhat doesn't care if he receives 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 has exceeded its allotted login failures for any given timeframe.
  • The result is that the IP is blacklisted by my system. But, this IP does not belong to Blackhat, it belongs to LegitUser, who has played no role in this attack at all.
  • The result of the blacklisting of the IP 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?

  • 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 1: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 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 '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
  • 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 '16 at 0:59

According to several of these answers:


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.