Hey Dan - comments inline below.
--
Ryan C. Barnett
ModSecurity Community Manager
Breach Security: Director of Application Security Training
Web Application Security Consortium (WASC) Member
Author: Preventing Web Attacks with Apache
--------------
Web Security Threat Report Webinar on May 9, 2007 (12 pm EST)
Learn More About the Breach Webinar Series:
http://www.breach.com/webinars.asp
--------------
> -----Original Message-----
> From: mod-security-users-bounces <at> lists.sourceforge.net
[mailto:mod-
> security-users-bounces <at> lists.sourceforge.net] On Behalf Of Dan
Wing
> Sent: Wednesday, April 11, 2007 8:17 PM
> To: mod-security-users <at> lists.sourceforge.net
> Subject: [mod-security-users] segmentation fault
>
> Hi. I'm a newbie and just installed mod_security2 2.1.0 last
Sunday. I
> played around with several rules, including this one which
successfully
> blocks over-zealous POSTs:
>
> SecAction initcol:ip=%{REMOTE_ADDR}
> SecAction deprecatevar:ip.post_count=1/10
> SecRule REQUEST_METHOD "^post$" \
> "chain,nolog,phase:2,setvar:ip.post_count=+1"
> SecRule REQUEST_URI "\.cgi|\.php"
> SecRule IP:POST_COUNT " <at> gt 9" \
> "chain,log,deny,phase:2,msg:'Brute
force POSTs,
> count=%{IP.POST_COUNT}',ctl:ruleEngine=on"
> SecRule REQUEST_METHOD "^post$"
>
[Ryan Barnett] I don’t think that
this ruleset works as you expect. Essentially, only the very first
SecAction directive is being executed. I have a few comments/questions
1) I would recommend that you specify phase:1
with these rules (at least the SecAction directives) so that they execute early
on the connection.
2) The SecAction directives that you
specified need to include the “pass” action if you don’t want
them to deny the connections. With the current config, your first
SecAction line will match every request, initiate initcol and deny the
connection.
3) If you fixed the SecAction directive
action to “pass” then your 3rd rule would match/deny on
all POSTS to either .cgi or .php scripts. This means that if someone
keeps POSTing to these scripts, they will keep getting blocked by this 3rd
rule and you will never get to your last chained rule that evaluates
IP:POST_COUNT. Therefore, you should move the last rule up before your
first SecRule.
4) I do like your use of the MSG expansion
of the POST_COUNT setvar data J
5) On that same rule, however, what/why are
you using ctl to turn on the ruleEngine? Do you have SecRuleEngine set to
DetectionOnly and you want to enable blocking only after a client triggers
these rules 9 or more times?
6) Use of deprecatevar can become a bit
tricky when you are battling automated programs/scanners/brute forcers. The
hard-to-determine aspect is how long will clients be denied access? When
using deprecatevar in this manner, a client could be denied access for an
exponentially longer time if the speed/number of their requests if really high.
Perhaps this is what you want – the harder a client scans you, then
the longer they have to sit in timeout… The alternative is to use
expirevar. This a better option when you have a certain timeout period
that you want to deny someone access. If you want to blackhole them for
say 1 hour, then use “expirevar:ip.post_count=3600”. This
means that once someone scans you and goes over your threshold and then stops,
they have to wait 1 hour before being let back in.
7) Also, I would recommend that you specify
deprecatevar/expirevar at the same time you use setvar. This keeps all of
the timings synced up.
Here is an updated ruleset that you can
test out -
SecAction
phase:1,initcol:ip=%{REMOTE_ADDR},nolog,pass
SecRule
IP:POST_COUNT " <at> gt 9" "chain,log,deny,phase:1,msg:'Brute force
POSTs, count=%{IP.POST_COUNT}',ctl:ruleEngine=on"
SecRule
REQUEST_METHOD "^post$"
SecRule
REQUEST_METHOD "^post$"
"chain,nolog,phase:1,setvar:ip.post_count=+1,deprecatevar:ip.post_count=1/10"
SecRule
REQUEST_URI "\.cgi|\.php"
> I had built this ruleset based on
> http://www.modsecurity.org/documentation/modsecurity-
> apache/2.1.0/modsecurity2-apache-reference.html#N11041
>
> SecAction initcol:ip=%{REMOTE_ADDR},nolog
> SecRule ARGS:login "!^$" \
> nolog,phase:1,setvar:ip.auth_attempt=+1,deprecatevar:ip.auth_attempt=20/12
> 0
> SecRule IP:AUTH_ATTEMPT " <at> gt 25" \
> log,drop,phase:1,msg:'Possible Brute
Force Attack"
>
[Ryan Barnett] Similar comments as above.
>
> However, I noticed that this rule causes Apache 2.0.59 to
occasionally
> segmentation fault on a live system with traffic.
httpd-error.log shows:
>
> [Wed Apr 11 13:22:49 2007] [notice] child pid
12137 exit
> signal Segmentation fault (11)
> [Wed Apr 11 13:22:50 2007] [notice] child pid
12140 exit
> signal Segmentation fault (11)
>
[Ryan Barnett] I seem to recall that there
were some bug issues with that version of Apache. Any chance of
upgrading?
RSS Feed