Protect site from flooding when user login is attacked by brute force

Question

I've been experiencing issues with bots trying to force their way into the website I manage. It seems to be a daily occurrence the the flood system is being triggered (I'm on D7).

I'm happy the the flood system is doing it's job and stopping the attacks, but the problem is the bots are using private IPs, so when the flood is triggered it just locks everyone out.

I would like to find out if there is a way to limit the amount of bots that are getting through to the actual login verification. I tried throwing hidden captcha on to the login form, which does an ok job of it, but even when it suspects a bot, it doesn't't stop the login verification, so the flood system still gets triggered. Does anyone know of anything I can put in front of that process to limit the amount of bots getting though? The less intrusive, obviously the better.

Answer 1

The type malicious bots you describe can connect through open proxies all over the world (typically without permission), each having different IP addresses. They can also use trojans and viruses on hijacked client computers/servers to do their work. In other words, Drupal's built-in flood control system, that uses IP-addresses for blocking, is no good for dealing with this type of attack. If the flood system causes problems for you ("locks everyone out"), you need to reconfigure it or turn it off.

You can do this by adding one or both of the following pair of configuration settings to your site's settings.php file:

// Set per-IP failed login attempt limit to max and window to 5 seconds
$conf['user_failed_login_ip_limit'] = PHP_INT_MAX;
$conf['user_failed_login_ip_window'] = 5;

// Set per-user failed login attempt limit to max and window to 5 seconds
$conf['user_failed_login_user_limit'] = PHP_INT_MAX;
$conf['user_failed_login_user_window'] = 5;

In that way, no-one will be locked out.

Instead of using the built-in flood control in Drupal, try using Apache ModSecurity to limit bots access to your server, filtering on content (POST requests), instead of IP-address.

From its documentation on HTTP Traffic Logging:

Web servers are typically well-equipped to log traffic in a form useful for marketing analyses, but fall short logging traffic to web applications. In particular, most are not capable of logging the request bodies. Your adversaries know this, and that is why most attacks are now carried out via POST requests, rendering your systems blind. ModSecurity makes full HTTP transaction logging possible, allowing complete requests and responses to be logged. Its logging facilities also allow fine-grained decisions to be made about exactly what is logged and when, ensuring only the relevant data is recorded.

First discover the pattern in the POST requests the bots make, and use Apache to block them.

Answer 2

In case anyone else comes across a similar issue, I didn't realize that the two IP addresses were coming from my varnish servers. I was able to use secure login to redirect user login attempts to https (which I should have been doing anyway) and that ended up bypassing vanish, thus allowing me to capture the actual IPs. That allowed to flood table to function as it was intended.