Re: [mod-security-users] Wordpress Brute Force

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

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 <jb...@xt...>

> 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" <jb...@xt...> 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...@li...
> > 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...@li...
> 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/
>