On 12/15/11 1:52 PM, "[email protected]" <[email protected]> wrote:
>
>My test team is reporting unfortunate results with the brute force rules.
>
>CentOS release 5.7 (Final)
>
>Server version: Apache/2.2.21 (Unix)
>Server built: Sep 22 2011 17:34:16
>
>ModSecurity 2.5.9
>SecComponentSignature "core ruleset/2.2.2"
>
>The symptom that we are seeing is that 981042 doesn't seem to be picking
>up
>the
>value of tx.brute_force_counter_threshold. If I enable logging on that
>rule,
>the entry in the mod security log reads
>
>Message: Warning. Operator GT matched 0 at IP:brute_force_counter. [file
>"/etc/httpd/conf.d/modsecurity_crs/experimental_rules/modsecurity_crs_11_b
>ru
>te_f
>orce.conf"] [line "53"] [id "981042"]
>
>Our configuration of rule 981214 is almost right out of the box
>
>SecAction "phase:1,id:'981214',t:none,nolog,pass, \
>setvar:'tx.brute_force_protected_urls=/protectThisUrl', \
>setvar:'tx.brute_force_burst_time_slice=60', \
>setvar:'tx.brute_force_counter_threshold=10', \
>setvar:'tx.brute_force_block_timeout=60'"
>
>My development sandbox behaves as I would expect:
>
>Message: Warning. Operator GT matched 10 at IP:brute_force_counter. [file
>"C:/Program Files (x86)/Apache Software
>Foundation/Apache2.2/conf/modsecurity_crs/experimental_rules/modsecurity_c
>rs
>_11_
>brute_force.conf"] [line "53"] [id "981042"]
>
>However, the development sandbox is running windows, and is using the
>binaries I
>downloaded for ModSecurity 2.6.2
>
>Have I simply loaded the experimental rules into a version of modsecurity
>that
>doesn't support them, or is something more sinister going on? I'm running
>out
>of ideas on how to trouble shoot this.
>
>Thanks,
>Danil
Those rules are tracking and inspecting data in the IP persistent
collection data. Do you have the IP collection initiation rules activated
at the end of the modsecurity_crs_10_config.conf file?
#
# -=[ Global and IP Collections ]=-
#
# Create both Global and IP collections for rules to use
# There are some CRS rules that assume that these two collections
# have already been initiated.
#
SecRule REQUEST_HEADERS:User-Agent "^(.*)$"
"phase:1,id:'981217',t:none,pass,nolog,t:sha1,t:hexEncode,setvar:tx.ua_hash
=%{matched_var}"
SecRule REQUEST_HEADERS:x-forwarded-for
"^\b(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})\b"
"phase:1,id:'981225',t:none,pass,nolog,capture,setvar:tx.real_ip=%{tx.1}"
SecRule &TX:REAL_IP "!@eq 0"
"phase:1,id:'981226',t:none,pass,nolog,initcol:global=global,initcol:ip=%{t
x.real_ip}_%{tx.ua_hash}"
SecRule &TX:REAL_IP "@eq 0"
"phase:1,id:'981218',t:none,pass,nolog,initcol:global=global,initcol:ip=%{r
emote_addr}_%{tx.ua_hash}"
-Ryan
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
