2

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.

  • What anti-flood system you are using? Could you link to it? It's pretty hard to guess. Flood control? And what exactly you want from us? If any of us knows how to make bot authors blacklist sites, I doubt he will admit it ;) – Mołot Dec 3 '13 at 15:07
  • I'm using the built in flood system that D7 has in it (drupal.org/node/164983#comment-589458). I'm looking for a way to stop suspicious login attempts before they hit the validator. IE, if hidden captcha worked the way I had hoped it would, when it signaled it was a bot it would kill the login process right then and there instead of letting the validation process go thorough. That's what I'm looking for, a way to intercept potential bot logins before they hit the validator. – Jance Dec 3 '13 at 15:16
  • So the way hidden captcha works is it has a hidden field that it expects not to be filled in, if it is, it suspects a bot. At that point I would like it to simply kill all log in processes, but it dosn't do that. I'm looking for something that does. – Jance Dec 3 '13 at 15:17
  • 1
    It will be hard to go around something that's meant as first line of defence. And if you want captcha, it will meant that form actually will be processed. So it will hurt your server way more than a built-in flood control. Maybe it's time to install mod_security ? – Mołot Dec 3 '13 at 15:20
5

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.

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.

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.