CODEWITHSUNDEEP
phpsecuritybrute-forceddos
user1751672
user1751672

Reputation:

10 request/minute for brute force attack and ddos?

If I save the time of first logging attempt and if the 10th attempt is made in less than 1 minute and I ban the IP address would that be enough to stop brute force attack and ddos? In real life example will it be possible for a user to enter the wrong address more than 10 times in a minute?

EDIT: maybe I didn't put the question in right way, would blocking the user/ip after 10 req/m make the system much more secure, than standard block after 10 wrong attempts?

Upvotes: 1

Views: 761

Answers (2)

ejfrancis
ejfrancis

Reputation: 3035

I made a class that takes care of brute force attack protection in PHP.

https://github.com/ejfrancis/BruteForceBlocker

it logs all failed logins site-wide in a db table, and if the number of failed logins in the last 10 minutes (or whatever time frame you choose) is over a set limit (also chosen by you), it enforces a time delay and/or a captcha requirement before logging in again.

example:

//build throttle settings array. (# recent failed logins => response).

$throttle_settings = [

    50 => 2,            //delay in seconds
    150 => 4,           //delay in seconds
    300 => 'captcha'    //captcha

];

$BFBresponse = BruteForceBlocker::getLoginStatus($throttle_settings);

//$throttle_settings is an optional parameter. if it's not included,the default settings array in BruteForceBlocker.php will be used

switch ($BFBresponse['status']){

case 'safe':
    //safe to login
    break;
case 'error':
    //error occured. get message
    $error_message = $BFBresponse['message'];
    break;
case 'delay':
    //time delay required before next login
    $remaining_delay_in_seconds = $BFBresponse['message'];
    break;
case 'captcha':
    //captcha required
    break;

}

Upvotes: 0

Voitcus
Voitcus

Reputation: 4446

I think that the detecting method is quite correct. If a user tries to log in 10 times a minute this is something wrong here.

But you need to check if:

  • the user is impatient so clicks ten times just to "make the loading faster". It's ok if you disable login button with JavaScript but the user can have JS disabled.
  • the user clicks "refresh" on the perform-login page, so that the browser resends the post data. This is possible even if redirecting him, because he's got low connection speed. So this could be treated by you as an attack.
  • the user has auto-completed form with wrong password stored. He clicks, so there is error, so he does it again, and again, and again.

In my opinion this is no counter-measure if he's trying to make a DoS attack, because it doesn't matter what query he makes, because he just wants to halt your server. And, moreover, he will try to do this from many computers with different IPs so you can't easily block them.

I think blocking an IP is no protection and makes the user sure that you have something to hide. You are able to block him this way, so he'll start another way, the one you had not even thought of. I think -- as the other comments say -- you should temporarily block the user (you can log the IP, why not?), but showing him something like "Internal server/database error, please wait".

All the major sites of largest worldwide companies do not block anybody.

And finally answering to your question: yes, this method will make your system more secure in short term, but user should never know he's been blocked.

Upvotes: 0

Related Questions