Slowing down requests raises the risk of exhausting Apache' s request limit

  • Hi,

    (I know that the topic of whether it is a good practice to slow down requests that come from brute force attempts or not, has been discussed many times before. However, I believe have something to add to it.)

    First of all, I find it quite logical that one chooses to slow down these requests. The problem with this is that, by slowing them down, the requests are kept alive much longer than usual and it is very easy to reach the maximum number of requests allowed by your Apache configuration! And this will be perceived by your users as if the server is actully not responsive!

    Maybe it would be better to just stop these requests immediately when they are detected. Of course, then you risk your server actually receiving a proper DDoS attack. Well, we have actually tried that ourselves in many installations (more than a 100 really) of our clients lately, by tinkering with the plugin’s code. And we have stopped a lot of attacks successfully (even as we speak), without suffering the results of a DDoS attack. Maybe the attacks were too distributed!

    I would like to repeat it once more: slowing down the requests and reaching your sever’s request limit is actually equivalent of a DDoS attack from the users’ point of view.

    So, why argue? Maybe we could add an option to the plugin so that the administrator chooses which mode they wish to enforce: a) slow down brute force requests or b) immediately stop them.

    (Of course we already do have our own version of the plugin, but it would be nicer to have only one!)

    https://www.ads-software.com/extend/plugins/login-security-solution/

Viewing 6 replies - 1 through 6 (of 6 total)

  • Can you share this edit? I have simply commented out the php sleep command.

    I agree with the delay time being a user setting with an option for no delay. What I need from this solution is the tracking of the username and the IP of the failed attempts. When an IP/user has reached the threshold to be blocked, I would prefer no delay and a generic 500/400 error response.

    A good addition to the plugin would be a smart list of usernames to ignore. We do not have an “admin” user so it seems fruitless to ask the database if the password matches and to waste a php process delaying the automated attacks on the “admin” account.

    I understand the wish to slow the attack down, but it is better for server resources to send error pages quickly than to slow each login down.

    Thread Starter Takis Bouyouris

    (@nevma)

    Well what we did was not too smart, but it was quick and effective. We replaced the call to the sleep function with this:

    if ( $fails_total>$this->options["login_fail_tier_3"] ) {
    die("You are a very naughty boy...");
}

    We do not care at all if the attacker gets a proper message or error code at all, as you see.

    Thread Starter Takis Bouyouris

    (@nevma)

    I would like to add one extra thought tomy first post.

    If the attackers wished to hit us with a DDoS attack, then they could do it just as easily without hitting the login script. What they want with these attacks is to access our passwords and, in order to dot that, it is important for them that the server is actually reposding to requests. So they have no reason to crash it with a DDoS attack. And this is exactly what practise has shown to us during the last months of everyday attacks! The attacks were not massive and dense, they were distributed and came in small waves.

    (Of course, this is not the case for proper DDoS attacks. Neither this plugin nor this conversation is relevant to them.)

    Plugin Author Daniel Convissor

    (@convissor)

    A simple way to keep sites from getting totally bogged down is adjusting the LSS’ “Delay Tier 2” and “Delay Tier 3” settings to large numbers.

    Thread Starter Takis Bouyouris

    (@nevma)

    Hi, Daniel,

    So, what you are suggesting is that we raise these limits high enough, so that that the plugin will never go into the mode of slowing down brute force requests. This could actually be a workaround to what we need.

    (Well, it’s not very straightforward and one might have to experiment a bit in order to get it right, but it will do the trick.)

    Thanks for the tip!

    Plugin Author Daniel Convissor

    (@convissor)

    Exactly. You’re welcome.

Viewing 6 replies - 1 through 6 (of 6 total)
  • The topic ‘Slowing down requests raises the risk of exhausting Apache' s request limit’ is closed to new replies.