• gotmike

    (@gotmike)


    I have Brute Force Protection enabled.

    I have “Lock out after how many login failures” set to 5.

    I have 3 specific usernames listed in “Immediately block the IP of users who try to sign in as these usernames”.

    “Count failures over what time period” is set to 10 minutes.

    “Amount of time a user is locked out” is set to 12 hours.

    Even though all this seems to be setup, I still regularly see 8-10 attempted failed logins all within a few minutes of each other from the same IP address, and they remain unblocked.

    I have seen one IP address blocked by Wordfence, but that was just one time and it has just now apparently been unblocked automatically (I assume expired).

    I’m not even sure how they are getting to 8-9 attempts. I would expect it would block them at attempt #6.

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

    (@wfdave)

    Hi @gotmike,

    Can you take a screenshot of the live traffic when an attacker is attempting to login 8-10 times in a row?

    I can recommend setting Count failures over what time period higher, such as 30 minutes to an hour.

    Note that if the login attempts are ~3 minutes within each other, it will still work because when the attacker does his 6th attempt, it would have been 12 minutes since his 1st attempt.

    Dave

    Thread Starter gotmike

    (@gotmike)

    Image Link

    the above link shows the log. as you can see, there are 9 attempts within a minute all from the same IP address.

    3 of the 9 logins are usernames that i have specifically added to the “immediately block the ip of users who try to sign in as these usernames” list.

    the only “current blocks” i have are those that i added myself. the “amount of time a user is locked out” is set to 12 hours, and these attempts were just under 6 hours ago, so they should certainly still be blocked.

    @gotmike Did you find a solution? I have the same issue.

    — Chaitanya

    @gotmike @cmangla I’m seeing this too – usernames on the “Immediately block the IP of users who try to sign in as these usernames” list are never IP blocked. Are any of you using directory authentication plugins? I’m using wpDirAuth and suspect that it might be interfering.

    wpDirAuth either hooks to the authenticate filter, or overrides wp_authenticate() depending on the version of WordPress being used. If the method is handed a WP_User object and that user isn’t marked as being an AD-authed user, it will return the WP_User object. If the method is handed a WP_Error object, it immediately returns the WP_Error object. After that, if the user name isn’t an AD-authed user, it returns the login name it was given. After all that, it attempts to auth against LDAP/AD and returns a WP_User on success or WP_Error object on failure.

    In looking at WordFence’s code, they’re hooked to authenticate after wpDirAuth (wpDirAuth hooks with priority 10, WordFence hooks with priority 25 for authenticate and 99 for authenticateFilter()). One thing I’m noticing is that their method Controller_WordfenceLS::_authenticate() never checks $user to see if what it was handed is an instance of WP_Error. It’s possible that if wpDirAuth has already failed the auth and passed on a WP_Error object, WordFence gets confused and doesn’t see it should record the failure.

    Wait, I think I found it. Line 3002 of wordfenceClass.php is looking for specific error codes if the the user passed to the method is an WP_Error object, and I’m betting there are a couple of situations where error codes from wpDirAuth aren’t going to match up with what they’re looking for, in which case, they aren’t going to record the failed attempt.

    • This reply was modified 5 years, 8 months ago by Paul Gilzow.

    It would be really good to have this issue resolved. “admin” login attempts are a large part of the hits I get.

Viewing 6 replies - 1 through 6 (of 6 total)
  • The topic ‘Brute Force Protection – Not Blocking Failed Logins’ is closed to new replies.