• Resolved saintandrews

    (@saintandrews)


    Here’s what I’m trying to assess for my site. I’ve been under recent repeated dictionary assault from the botnet, and while I don’t worry about them breaking into the site, the repeated waves of several thousand login attempts periodically slow the site to a crawl.

    Naturally I use a standard login limiter set to a very low threshold and a long lockout period. Nonetheless, the botnet will typically make only one or two login attempts with an IP before cycling to another, thus evading my login lockout plugin, and this behavior will go on for hours.

    You mentioned on another thread that BP acts after X (which I won’t repeat for security reasons) number of login attempts. Is that

    – X number of attempts over BP’s history of any particular offending IP, whereafter the offending IP is blacklisted from all future attempts against any BP subscriber? For only a limited period? Permanently?

    – X number of attempts against my particular site in any given attack session, thus making it, effectively, a redundant login lockout plugin set to a threshold higher than the one I’m already employing?

    – X number of attempts across any number of BP subscriber sites in a particular session, after which the offending IP is a)locked out temporarily, allowing it to rinse and repeat? b)blacklisted permanently? c)?

    The reason I ask is this. Overnight, my BP widget tally of attacks thwarted by BP jumped from single digits into high 3 digits. Great! But my activity logs also registered several thousand failed login attempts along with close to a hundred login lockouts.

    Is what I am seeing BP acting before the fact of an even larger number of attacks against my particular site – because BP has to register the higher value X number of attacks across all subscriber sites during the attack period, after which these many hundred offending IPs BP just thwarted will never plague me again?

    Or am I merely seeing BP registering attacks thwarted after the fact of my own, lower threshold defenses already having blocked them first while consuming memory/CPU on my site in the process?

    I’m not trying to get you to give up your secrets publicly. I’m just not clear on exactly how effective BP is at exactly what on my site compared to my existing alternatives.

    Thanks.

    http://wordpress.org/plugins/bruteprotect/

Viewing 5 replies - 1 through 5 (of 5 total)
  • @saintandrews – good questions, I would also like to see a well documented answer, as since today my hosting company blocked the login script because of the brute force attacks I received lately.

    I only have 2 IPs whitelisted for now and I have installed this plugin, but I would like to run a more flexible solution as I use multiple connections and dynamic IPs. Is there some other good solution (renaming /wp-admin, etc.?)

    Thread Starter saintandrews

    (@saintandrews)

    Let me try to be a little more succinct by stating what I hope is happening.

    Adding a 90,000 member botnet to an individual site plugin or .htaccess file is clearly a fool’s errand.

    However, even if there is some redundancy on the front end of BP identifying offending IPs and adding them to its database and/or even if there is a high initial threshold of offense – as long as it is quantified over the entire BP subscriber base – if BP ends up permanently blacklisting these offenders rather than just cyclically catching and releasing them, then what would have been a fool’s errand for one person becomes intelligent long term insurance for the group when that errand is assumed by BP’s cloud.

    The more the botnet attacks BP-protected sites, the fewer its effective numbers become and eventually all 90,000 are in the BP blacklist. I’m patient enough to wait for that outcome.

    Personally, I really don’t care if someone whose computer has been incorporated into the botnet can no longer access my site, although, like any standing permanent blacklist some criteria from being removed from it, for example, once one’s computer has been cleaned, would obviously be advisable from a PR standpoint.

    Plugin Contributor Sam Hotchkiss

    (@samhotchkiss)

    Hey Guys– we just rolled out new changes to our blocking algorithm this morning. Here’s how it works:

    8 failed attempts in 8 hours = 8 hour block
    15 failed attempts in 24 hours = 48 hour block
    25 failed attempts in 7 days = 14 day block
    40 failed attempts in 1 month = 2 month block
    65 failed attempts in 1 year = 2 year block

    Since the blocking is all handled by our servers, this algorithm is now in effect for ALL BP USERS, regardless of version. Until this morning, only the first rule was in effect, so the blocks were expiring every 8 hours. Now repeat offenders get blocked for longer and longer.

    There IS a new version of BP, out today, that cleans up transients, so it’ll clean out your DB.

    Thanks, guys, for your input and support, every piece of feedback helps us make BP better, and helps us work toward the utopian dream of a world without brute force attacks!

    Best,
    Sam

    Thread Starter saintandrews

    (@saintandrews)

    Thanks, Sam, an excellent improvement.

    So all offenders are logged in the options tables of the individual sites rather than the cloud, their entries expiring according to the schedule above, with their expired transient entries of whatever duration cleaned out by BP as they respectively expire, after 8 hours, 48 hours, 14 days, etc. Is that correct?

    Plugin Contributor Sam Hotchkiss

    (@samhotchkiss)

    BP caches blocks locally– all blocks are determined by our server, then our server feeds the expiration time to your site, where it is stored as a transient. If there is no block, then that is cached on your site for 1 hour (however, that cache is cleared whenever a login attempt fails)

Viewing 5 replies - 1 through 5 (of 5 total)
  • The topic ‘Are offending IPs actually blacklisted in BP to prevent future attacks?’ is closed to new replies.