Dynamic IP-based blacklisting

Question

Folks, we all know that IP blacklisting doesn't work - spammers can come in through a proxy, plus, legitimate users might get affected... That said, blacklisting seems to me to be an efficient mechanism to stop a persistent attacker, given that the actual list of IP's is determined dynamically, based on application's feedback and user behavior.

For example: - someone trying to brute-force your login screen - a poorly written bot issues very strange HTTP requests to your site - a script-kiddie uses a scanner to look for vulnerabilities in your app

I'm wondering if the following mechanism would work, and if so, do you know if there are any tools that do it:

• In a web application, developer has a hook to report an "offense". An offense can be minor (invalid password) and it would take dozens of such offenses to get blacklisted; or it can be major, and a couple of such offenses in a 24-hour period kicks you out.
• Some form of a web-server-level block kicks in on before every page is loaded, and determines if the user comes from a "bad" IP.
• There's a "forgiveness" mechanism built-in: offenses no longer count against an IP after a while.

Thanks!

Extra note: it'd be awesome if the solution worked in PHP, but I'd love to hear your thoughts about the approach in general, for any language/platform

Answer 1

Take a look at fail2ban. A python framework that allows you to raise IP tables blocks from tailing log files for patterns of errant behaviour.

Answer 2

are you on a *nix machine? this sort of thing is probably better left to the OS level, using something like iptables

edit:

in response to the comment, yes (sort of). however, the idea is that iptables can work independently. you can set a certain threshold to throttle (for example, block requests on port 80 TCP that exceed x requests/minute), and that is all handled transparently (ie, your application really doesn't need to know anything about it, to have dynamic blocking take place).

i would suggest the iptables method if you have full control of the box, and would prefer to let your firewall handle throttling (advantages are, you don't need to build this logic into your web app, and it can save resources as requests are dropped before they hit your webserver)

otherwise, if you expect blocking won't be a huge component, (or your app is portable and can't guarantee access to iptables), then it would make more sense to build that logic into your app.