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}"
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)" <[email protected]<mailto:[email protected]>>
Date: Monday, January 14, 2013 8:54 AM
To:
"[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>
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:[email protected]]
Sent: Monday, January 14, 2013 1:34 PM
To: Paul Beckett (ITCS);
[email protected]<mailto:[email protected]>
Subject: Re: [Owasp-modsecurity-core-rule-set] experimental brute_force
protection rule
From: "Paul Beckett (ITCS)" <[email protected]<mailto:[email protected]>>
Date: Monday, January 14, 2013 8:22 AM
To:
"[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>
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
[email protected]<mailto:[email protected]>
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
[email protected]
https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
