Login Security Brute Force Attack

Home Forums BulletProof Security Pro Login Security Brute Force Attack

This topic contains 13 replies, has 4 voices, and was last updated by  AITpro Admin 9 months, 3 weeks ago.

Viewing 14 posts - 1 through 14 (of 14 total)
  • Author
    Posts
  • #5714 Facebook Google Twitter Email Stumbleupon Digg reddit pinterest Myspace Delicious LinkedIn tumblr

    Krzysztof
    Participant

    I’m also using Wordfence and have decided to turn off login security there and check how BPS works in this matter. Puting various names and passwords didn’t lock me out as in wordfence so I tried to put a valid nam and wrong password and even after typing the password wrong for severall times (more than 3) I was not locked out. Is this normal?

    #5716 Facebook Google Twitter Email Stumbleupon Digg reddit pinterest Myspace Delicious LinkedIn tumblr

    AITpro Admin
    Keymaster

    BPS Pro only locks out valid user accounts.

    Nope that is not normal.  Have you saved your Login Security options?  If you set the max attempts to 3 then you will be locked out after 3 failed login attempts.  For testing set the Automatic Lockout time to 1 minute or just use another login account so you don’t actually lock yourself out for the default 60 minutes.

    If BPS Pro Login Security is not working then another plugin is overriding it.  You can only use 1 login security feature/plugin at a time otherwise they will conflict with each other.

    #5719 Facebook Google Twitter Email Stumbleupon Digg reddit pinterest Myspace Delicious LinkedIn tumblr

    Krzysztof
    Participant

    I had to refresh several times to see the locked out user.

    So does this mean that someone can try to do a bruteforce and attack the login page with various invalid user names and passwords?  Like use admin as name and try hundreds of paswords for it? Will this be too uch for the server? Wouldnt it be better to lock out invalid user names right away as Wordfence is doeing? And if the name is valid lock out the user after 3 failed attempts?

    #5720 Facebook Google Twitter Email Stumbleupon Digg reddit pinterest Myspace Delicious LinkedIn tumblr

    AITpro Admin
    Keymaster

    I’m not sure what is wrong on your website.  3 failed login attempts with a setting of max 3 attempts locks a valid user account after 3 failed login attempts.  If this is not working on your website then something is wrong with your website.  ie another plugin is causing this problem or something else about your website or DB is fubar.

    How do you lock out a username that does not exist?  The normal/standard way that WordPress Authentication processing code works is this.

    If a username/user account does not exist then return an error and kill the script and do not proceed any further.  BPS Pro Login Security hooks into the WordPress Authentication process and also kills the script.

    When a script is killed it does not consume any significant resources so let’s say someone was trying to run an automated login script on your site at a rate of 1,000 times per second.

    Attempt 1 = script killed in less than 1 millisecond
    Attempt 2 = script killed in less than 1 millisecond



    Attempt 1,000 = script killed in less than 1 millisecond

    I looked at adding a threshold, but I found this to be really stupid and a waste of time.  Most other Login security plugins are using a threshold – dumb.  ;)

    #5721 Facebook Google Twitter Email Stumbleupon Digg reddit pinterest Myspace Delicious LinkedIn tumblr

    AITpro Admin
    Keymaster

    You can test BPS Pro Login Security on any of the AITpro websites by performing 3 bad login attempts to see how it is supposed to work.  If it is working differently on your website then something is not right and you will have to look at any other plugins that could be conflicting or interfering with BPS Pro Login Security.

    #5722 Facebook Google Twitter Email Stumbleupon Digg reddit pinterest Myspace Delicious LinkedIn tumblr

    AITpro Admin
    Keymaster

    Someone asked some similar questions and I answered them in the WordPress.org forum.

    Source:  http://wordpress.org/support/topic/login-security-question?replies=5#post-4191648

    100 to 1,000 times per second is the thing that is important to note. You would never want to log or process this type of malicious activity for 2 reasons. The goal of a DoS/DDoS attack is to overload your Server and crash your website.

    1. If the hacker is NOT using a valid username then they will never be able to successfully log into the site.

    2. WordPress handles this type of malicious authentication activity by returning an error instead of consuming unnecessary resources by continuing the authentication processing any further.

    BPS Login Security is hooking into the WordPress authentication process and is also returning an error on this type of malicious activity.

    Every time someone attempts to login to your website they are attempting to connect to your WordPress Database. This costs website resources so if someone is overloading your website resources by trying to login repetively then this will cause your website to run slower or probably just crash the site. So by ending the script with an error instead of continuing with script processing the resource cost is almost nil. If on the other hand you allowed the processing of this type of malicious activity to continue on in the script and be processed then this is unnecessary use of your Server resources and would have a negative impact on website performance. If handled completely wrong it could cause your Host to suspend your Hosting account. Therefore not allowing this type of malicious activity in the first place is the smart way to handle this.

    Honestly why would you want to see or log login attempts for invalid usernames? I do not see any valid reason to do something like that. It is an unnecessary waste of your Server’s resources/website resources.

    #5724 Facebook Google Twitter Email Stumbleupon Digg reddit pinterest Myspace Delicious LinkedIn tumblr

    Krzysztof
    Participant

    Now this is interesting. Never thought that this works like this. Thank you for claryfying it. This means that Wordfence way is not so good. I will stick to BPS PRO ;)

    #5725 Facebook Google Twitter Email Stumbleupon Digg reddit pinterest Myspace Delicious LinkedIn tumblr

    AITpro Admin
    Keymaster

    The highest priority is security.  The next highest priority is website performance.  What good would security be if your site ran slow as molasses.  I hate having to log HTTP and Security Log errors, but that is a necessary evil.  With Login Security this is much simpler because you only need to keep track of/log valid login attempts and just ignore all the other attacks since they cannot hurt your website performance.  So yeah the last thing I would want to do would be to process/log/keep track of login attempts that do not matter anyway – waste of resources, DB space and time.

    #5823 Facebook Google Twitter Email Stumbleupon Digg reddit pinterest Myspace Delicious LinkedIn tumblr

    Steve Lubetkin
    Participant

    Is there a way to permanently block specific IP addresses from logging in? I’m getting hack attempts from one specific IP on several sites, all trying valid usernames but obviously not getting the password right. I want to block those IPs without blocking the usernames. Is that possible?

    #5825 Facebook Google Twitter Email Stumbleupon Digg reddit pinterest Myspace Delicious LinkedIn tumblr

    AITpro Admin
    Keymaster

    You can try, but IP addresses can be faked and changed very easily.  Most automated hacking and spamming scripts will automatically switch to a different IP address if you block the current IP address that they are using.

    Here is IP address blocking .htaccess code if you want to give it a try.

    http://forum.ait-pro.com/forums/topic/htaccess-block-ip-address-block-access-to-files-by-ip-address/

    Or you could try something like this that is ONLY blocking IP addresses on your login page itself.

    <FilesMatch "^(wp-login\.php)$">
    Order Allow,Deny
    Deny from 46.119.35.
    Deny from 46.119.45.
    Deny from 91.236.74.
    Deny from 93.182.147.
    Deny from 93.182.187.
    Deny from 94.27.72.
    Deny from 94.27.75.
    Deny from 94.27.76.
    Deny from 193.105.210.
    Deny from 195.43.128.
    Deny from 198.144.105.
    Deny from 199.15.234.
    Allow from all
    </FilesMatch>
    #12239 Facebook Google Twitter Email Stumbleupon Digg reddit pinterest Myspace Delicious LinkedIn tumblr

    Daniella Norwood
    Participant

    What about only allowing from certain IPs?

    #12240 Facebook Google Twitter Email Stumbleupon Digg reddit pinterest Myspace Delicious LinkedIn tumblr

    AITpro Admin
    Keymaster

    Yes, that is always the much better aproach to use since you have full control over allowing IP addresses vs denying IP addresses.  Allowing IP addresses is a finite number.  Denying IP addresses is in infinite number (millions of possible IP addresses to block).  See this Topic link below that has Bonus Code that you can add to BPS Custom Code that uses an Allow vs Deny protection method/approach.

    http://forum.ait-pro.com/forums/topic/protect-login-page-from-brute-force-login-attacks/

    #12241 Facebook Google Twitter Email Stumbleupon Digg reddit pinterest Myspace Delicious LinkedIn tumblr

    Daniella Norwood
    Participant

    So this is what I placed in the Custom Code Brute Force Login….

    # Protect wp-login.php from Brute Force Login Attacks based on IP Address
    <FilesMatch "^(wp-login\.php)">
    Order Allow,Deny
    # Add your website/Server IP Address
    Allow from xxx.xxx
    Allow from xxx.xxx
    Allow from xxx
    </FilesMatch>

    Do I need Deny from all at the end and do I need periods after the IPs?

    #12243 Facebook Google Twitter Email Stumbleupon Digg reddit pinterest Myspace Delicious LinkedIn tumblr

    AITpro Admin
    Keymaster

    No, you do not need to add a deny condition/rule it is implied.  Yes, you would need dots after each octet of the IP address.
    3 octets:  Allow from 100.99.88.
    2 octets:  Allow from 100.99.

    # Allow,Deny
    # First, all Allow directives are evaluated. At least one must match, or the request is rejected.
    # Next, all Deny directives are evaluated. If any matches, the request is rejected.
    # Last, any requests which do not match an Allow or a Deny directive are denied by default.
    #
    # Deny,Allow
    # First, all Deny directives are evaluated. If any match, the request is denied unless
    # it also matches an Allow directive. Any requests which do not match any Allow or Deny directives are permitted.
    #
    # *Match* -------------------- *Allow,Deny result* -------------------- *Deny,Allow result*
    # Match Allow only ----------- Request allowed ------------------------ Request allowed
    # Match Deny only ------------ Request denied ------------------------- Request denied
    # No match ------------------- Default to second directive: Denied ---- Default to second directive: Allowed
    # Match both Allow & Deny ---- Final match controls: Denied ----------- Final match controls: Allowed
Viewing 14 posts - 1 through 14 (of 14 total)

You must be logged in to reply to this topic.