I believe this issue solved by Ryan's suggestion (below), is still present in 2.2.7-4. Currently I'm patching the CRS before deployment on my servers with this modification, but was wondering if it, or an equivalent improvement could be applied in the CRS source? Thanks, Paul
From: Paul Beckett (ITCS) Sent: Monday, January 14, 2013 4:24 PM To: owasp-modsecurity-core-rule-set@lists.owasp.org Subject: RE: [Owasp-modsecurity-core-rule-set] experimental brute_force protection rule Ryan, That's fantastic. It works perfectly for me. Do you know if this (or a similar change) will make it into the CRS? Thanks, Paul From: Ryan Barnett [mailto:rbarn...@trustwave.com] Sent: Monday, January 14, 2013 2:27 PM To: Paul Beckett (ITCS); owasp-modsecurity-core-rule-set@lists.owasp.org<mailto:owasp-modsecurity-core-rule-set@lists.owasp.org> Subject: Re: [Owasp-modsecurity-core-rule-set] experimental brute_force protection rule Right.... The issue here seems to be that, only for "/", we have a sub-string match. Here is a quick fix. Essentially you need to make that rule into a chained rule. The first like is used to simply create a new custom variable that uses # chars to surround the request filename data. The 2nd rule in the chain then runs the same - SecRule REQUEST_FILENAME ".*" "chain,phase:5,id:'981039',t:none,nolog,pass,setvar:'tx.filename=#%{request_filename}#',skipAfter:END_BRUTE_FORCE_PROTECTION_CHECKS" SecRule TX:FILENAME "!@within %{tx.brute_force_protected_urls}<mailto:!@within%20%25%7btx.brute_force_protected_urls%7d>" For this to work, you would then need to modify your URL list in the 10 file like this - SecAction \ "id:'900014', \ phase:1, \ t:none, \ setvar:'tx.brute_force_protected_urls=#/login.jsp# #/partner_login.php#', \ setvar:'tx.brute_force_burst_time_slice=60', \ setvar:'tx.brute_force_counter_threshold=10', \ setvar:'tx.brute_force_block_timeout=300', \ nolog, \ pass" This should work. -Ryan From: "Paul Beckett (ITCS)" <p.beck...@uea.ac.uk<mailto:p.beck...@uea.ac.uk>> Date: Monday, January 14, 2013 8:54 AM To: "owasp-modsecurity-core-rule-set@lists.owasp.org<mailto:owasp-modsecurity-core-rule-set@lists.owasp.org>" <owasp-modsecurity-core-rule-set@lists.owasp.org<mailto:owasp-modsecurity-core-rule-set@lists.owasp.org>> Subject: Re: [Owasp-modsecurity-core-rule-set] experimental brute_force protection rule Ryan, Thanks for the very quick response. The proposed modification, doesn't work for me. The original rule negated the @within match. I'm still figuring out the modsecurity rule language so I'm not at all sure about this...... but I guess it's not as simple as negating @pm if you have multiple values in brute_force_protected_urls. Cheers, Paul From: Ryan Barnett [mailto:rbarn...@trustwave.com] Sent: Monday, January 14, 2013 1:34 PM To: Paul Beckett (ITCS); owasp-modsecurity-core-rule-set@lists.owasp.org<mailto:owasp-modsecurity-core-rule-set@lists.owasp.org> Subject: Re: [Owasp-modsecurity-core-rule-set] experimental brute_force protection rule From: "Paul Beckett (ITCS)" <p.beck...@uea.ac.uk<mailto:p.beck...@uea.ac.uk>> Date: Monday, January 14, 2013 8:22 AM To: "owasp-modsecurity-core-rule-set@lists.owasp.org<mailto:owasp-modsecurity-core-rule-set@lists.owasp.org>" <owasp-modsecurity-core-rule-set@lists.owasp.org<mailto:owasp-modsecurity-core-rule-set@lists.owasp.org>> Subject: [Owasp-modsecurity-core-rule-set] experimental brute_force protection rule I'm pretty new to this list, so apologies if this is the wrong place for this. I've just been looking at the experimental brute force protection rules in OWASP CRS v2.2.7. Currently I still have the default brute_force_protected_urls value of "/login.jsp /partner_login.php", and was initially surprised to see that the home-page of my site triggered these rules. I think this is because the homepage "/" is always going to be within "/login.jsp" and will therefore never bypass rule 981039. Hmm, yes, good catch. For me, matching the home-page of my site, wasn't my expected behaviour for this rule. To avoid matching the site home-page I guess I could either remove the leading slash in the brute_force_protected_urls , or for sites that only require protecting a single URL I could change the @within operator to be @streq. Any other thoughts / ideas would be welcome. I think that you should change 981039 below to look like this instead - SecRule REQUEST_FILENAME "@pm %{tx.brute_force_protected_urls}" "phase:5,id:'981039',t:none,nolog,pass,skipAfter:END_BRUTE_FORCE_PROTECTION_CHECKS" Hopefully this works for you, Ryan Cheers, Paul modsecurity_crs_10_setup.conf: SecAction \ "id:'900014', \ phase:1, \ t:none, \ setvar:'tx.brute_force_protected_urls=/login.jsp /partner_login.php', \ setvar:'tx.brute_force_burst_time_slice=60', \ setvar:'tx.brute_force_counter_threshold=10', \ setvar:'tx.brute_force_block_timeout=300', \ nolog, \ pass" modsecurity_crs_11_brute_force.conf SecRule IP:BRUTE_FORCE_BLOCK "@eq 1" "chain,phase:1,id:'981036',block,msg:'Brute Force Attack Identified from %{remote_addr} (%{tx.brute_force_block_counter} hits since last alert)',setvar:ip.brute_force_block_counter=+1" SecRule &IP:BRUTE_FORCE_BLOCK_FLAG "@eq 0" "setvar:ip.brute_force_block_flag=1,expirevar:ip.brute_force_block_flag=60,setvar:tx.brute_force_block_counter=%{ip.brute_force_block_counter},setvar:ip.brute_force_block_counter=0" # # Block and track # of requests but don't log SecRule IP:BRUTE_FORCE_BLOCK "@eq 1" "phase:1,id:'981037',block,nolog,setvar:ip.brute_force_block_counter=+1" # # skipAfter Checks # There are different scenarios where we don't want to do checks - # 1. If the user has not defined any URLs for Brute Force Protection in the 10 config file # 2. If the current URL is not listed as a protected URL # 3. If the current IP address has already been blocked due to high requests # In these cases, we skip doing the request counts. # SecRule &TX:BRUTE_FORCE_PROTECTED_URLS "@eq 0" "phase:5,id:'981038',t:none,nolog,pass,skipAfter:END_BRUTE_FORCE_PROTECTION_CHECKS" SecRule REQUEST_FILENAME "!@within %{tx.brute_force_protected_urls}<mailto:!@within%20%25%7btx.brute_force_protected_urls%7d>" "phase:5,id:'981039',t:none,nolog,pass,skipAfter:END_BRUTE_FORCE_PROTECTION_CHECKS" SecRule IP:BRUTE_FORCE_BLOCK "@eq 1" "phase:5,id:'981040',t:none,nolog,pass,skipAfter:END_BRUTE_FORCE_PROTECTION_CHECKS" # # Brute Force Counter # Count the number of requests to these resoures # SecAction "phase:5,id:'981041',t:none,nolog,pass,setvar:ip.brute_force_counter=+1" # # Check Brute Force Counter # If the request count is greater than or equal to 50 within 5 mins, # we then set the burst counter # SecRule IP:BRUTE_FORCE_COUNTER "@gt %{tx.brute_force_counter_threshold}" "phase:5,id:'981042',t:none,nolog,pass,t:none,setvar:ip.brute_force_burst_counter=+1,expirevar:ip.brute_force_burst_counter=%{tx.brute_force_burst_time_slice},setvar:!ip.brute_force_counter" # # Check Brute Force Burst Counter and set Block # Check the burst counter - if greater than or equal to 2, then we set the IP # block variable for 5 mins and issue an alert. # SecRule IP:BRUTE_FORCE_BURST_COUNTER "@ge 2" "phase:5,id:'981043',t:none,log,pass,msg:'Potential Brute Force Attack from %{remote_addr} - # of Request Bursts: %{ip.brute_force_burst_counter}',setvar:ip.brute_force_block=1,expirevar:ip.brute_force_block=%{tx.brute_force_block_timeout}" SecMarker END_BRUTE_FORCE_PROTECTION_CHECKS ________________________________ This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. _______________________________________________ Owasp-modsecurity-core-rule-set mailing list Owasp-modsecurity-core-rule-set@lists.owasp.org<mailto:Owasp-modsecurity-core-rule-set@lists.owasp.org> https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set ________________________________ This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.
_______________________________________________ Owasp-modsecurity-core-rule-set mailing list Owasp-modsecurity-core-rule-set@lists.owasp.org https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
