Hi. Sorry for reply so later, but I was on holidays :).

Try to use fail2ban app if you are using linux box and/or two factor authentication in application web and honeypot form fields in order to blacklist those robots.

Kind regards,


2013/8/14 Jeremy Brock <jbrock@xtremeservices.net>
Hi Ryan,

     Thank you for the input, I did read your blog post which is
actually where I got the idea to begin with : ) so thx.

     I am going to revisit the Brute Force method I now see more clearly
in the blog. I think that is a great idea since I can limit it to a
specific login page vs iptables is more global.

     I also read a similar approach in your book Web Application
Defenders Cookbook, which is fantastic! However I was not able to get
them to work, so I produced something that I was able to get working.  I
am sure it is just my novice modsecurity abilities and not your examples.

     Thank you for the JS idea, I will look into that and see if I can
apply it to some of our internal WP sites.

     Hope you have an excellent week as well and thank you for an
amazing product.

~Jeremy

--

Jeremy Brock

XtremeServices.Net
Xtreme Services, LLC

On 8/14/2013 3:07 PM, Ryan Barnett wrote:
> On 8/14/13 12:48 PM, "Jeremy Brock" <jbrock@xtremeservices.net> wrote:
>
>> Hi All,
>>
>>      Been trying to limit the exposure of my clients to the massive
>> Brute Force bot nets out there and came up with the following :
>>
>> ##Collect Data
>> SecAction
>> phase:1,nolog,pass,initcol:ip=%{REMOTE_ADDR},initcol:user=%{REMOTE_ADDR},i
>> d:5000134
>>
>> ## Honor blocked IPs
>> SecRule user:bfwp_block "@gt 0" "drop,log,id:5000135,msg:'ip address
>> blocked for 5 minutes due to WordPress login attempts in 3 minutes.'"
>>
>> ## Block more than 2 attempts against WordPress authentication (invalid
>> username)
>> SecRule REQUEST_FILENAME "@streq /wp-login.php"
>> "chain,phase:4,id:5000136,t:none,nolog,pass"
>> SecRule REQUEST_METHOD "@streq POST" "chain"
>> SecRule ARGS:log ".*" "chain"
>> SecRule RESPONSE_STATUS "200" "chain"
>> SecRule RESPONSE_BODY "@contains <strong>ERROR</strong>: Invalid
>> username"
>> "chain,t:none,setvar:ip.bf_wp_user_counter=+1,deprecatevar:ip.bf_wp_user_c
>> ounter=1/180"
>> SecRule ip:bf_wp_user_counter "@gt 2"
>> "t:none,setvar:user.bfwp_block=1,expirevar:user.bfwp_block=300,setvar:ip.b
>> f_wp_user_counter=0"
>>
>> ## Block more than 5 attempts against WordPress password authentication
>> SecRule REQUEST_FILENAME "@streq /wp-login.php"
>> "chain,phase:4,id:5000137,t:none,nolog,pass"
>> SecRule REQUEST_METHOD "@streq POST" "chain"
>> SecRule ARGS:pwd ".*" "chain"
>> SecRule RESPONSE_STATUS "200" "chain"
>> SecRule RESPONSE_BODY "@contains <strong>ERROR</strong>: The password
>> you entered"
>> "chain,t:none,setvar:ip.bf_wp_pass_counter=+1,deprecatevar:ip.bf_wp_pass_c
>> ounter=1/180"
>> SecRule ip:bf_wp_pass_counter "@gt 5"
>> "t:none,setvar:user.bfwp_block=1,expirevar:user.bfwp_block=300,setvar:ip.b
>> f_wp_pass_counter=0"
>>
>> ###################### End WordPress Brute Force #########################
>>
>>
>>      However, I do not believe this is very efficient since it is
>> waiting till Phase 4 after the login attempt has failed.
>>
>>      Can anyone recommend a better approach?
>>
>>      The Bot Nets are rolling IPs constantly which is why this is so
>> intensive causing mlogc to lock up bringing down the entire web server.
>>
>>      Thx in advance,
>>
>> ~Jeremy
>>
> Jeremy,
> Did you see my past blog post on this topic for more options?
> http://blog.spiderlabs.com/2013/04/defending-wordpress-logins-from-brute-fo
> rce-attacks.html
>
>
> You have two main options here:
> 1) Rate limit requests (per IP) to the authentication page
> In this scenario, you don't care what the username/password credentials
> are.  You are simply denying clients who hit that page too often.
>
> 2) Rate limit clients (per IP) based on failed auth attempts
> This is what you are doing already and you must wait intil after the auth
> attempt to know if the credentials are valid or not.
>
> Besides rate limiting, another technique I would suggest is some type of
> client/user validation check prior to allowing authentication.  For
> example, you could simply inject some JS code into the WordPress auth page
> html that will add a new Cookie value.  Then, when someone authenticates
> to the WordPress, you simply check for the existence of the JS cookie.  If
> it is missing, then you know that the client was most likely not a real
> person using a web browser.  This works surprisingly well against botnet
> clients as they are using Perl scripts to send attacks and they therefor
> won't execute JS code like browsers.
>
> As a side note - I outline this technique in Recipe 15-1: JavsScript
> Cookie Testing of my book -
> http://www.wiley.com/WileyCDA/WileyTitle/productCd-1118362187,descCd-tableO
> fContents.html
>
> -Ryan
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite!
> It's a free troubleshooting tool designed for production.
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> _______________________________________________
> mod-security-users mailing list
> mod-security-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> http://www.modsecurity.org/projects/commercial/rules/
> http://www.modsecurity.org/projects/commercial/support/
>


------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
_______________________________________________
mod-security-users mailing list
mod-security-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-security-users
Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
http://www.modsecurity.org/projects/commercial/rules/
http://www.modsecurity.org/projects/commercial/support/