Dan Wing | 12 Apr 02:17 2007

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$"

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/120
   SecRule IP:AUTH_ATTEMPT " <at> gt 25" \
     log,drop,phase:1,msg:'Possible Brute Force Attack"

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)
(Continue reading)

Ryan Barnett | 12 Apr 06:54 2007

Re: segmentation fault

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?

 

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
mod-security-users mailing list
mod-security-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-security-users
Brian Rectanus | 12 Apr 07:34 2007

Re: segmentation fault

>> 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?

This may be a bug in macro expansion.  You can upgrade to 2.1.1 which
fixes this macro expansion issue.

-B

--

-- 
Brian Rectanus
Breach Security

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Dan Wing | 12 Apr 07:56 2007

Re: segmentation fault

Thanks for your reply, Ryan.

>>     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.

My interpretation of the documentation is that SecAction doesn't
do anything to deny/pass a connection.  The documentation for 'drop'
shows a similar use of SecAction, which is what I patterned most of
this ruleset after.

http://www.modsecurity.org/documentation/modsecurity-apache/2.1.0/modsecurity2-apache-reference.html#N11041

> 3)    If you fixed the SecAction directive action to “pass” then your 
> 3^rd 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 3^rd 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.

Ok.

> 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

Right, I'm still testing other rules and don't want them turned on yet.
The dcoumentation isn't clear if I can do "SecRuleEngine On" and then
have a bunch of SecAction's and SecRule's and then set it back off
again afterwards; I expect I can?  That'd be a little cleaner than
having to do the per-rule ctl:ruleEngine=on.

 > and you
> want to enable blocking only after a client triggers these rules 9 or 
> more times?

Right.

> 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… 

I would have preferred the ability to make it exponential, but I didn't
see that a multiplier was available, only an additive function.

 > 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.

Ok.

> 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.

Well, I want to only increment the variable for POSTs to CGI or PHP, and
I want to decrement the variable every 10 seconds -- no matter if the
user did a GET or some other non-POST method, or the user did nothing.

It wasn't clear to me that would occur if I put the deprecatevar into
a rule that only 'fired' when the rule was true.

> Here is an updated ruleset that you can test out -

Thanks.

> 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"
> 
>  
> 
...

>>  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?

Sure, we can probably do that.

Thanks!
-d

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Dan Wing | 12 Apr 08:01 2007

Re: segmentation fault

Brian Rectanus wrote:
>>> 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?
> 
> This may be a bug in macro expansion.  You can upgrade to 2.1.1 which
> fixes this macro expansion issue.

Ok, thanks.
-d

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Christian Folini | 12 Apr 08:15 2007
Picon

ModSecurity on lighttpd (?)

Hi there,

I am wondering if porting ModSecurity to lighttpd is an issue or not.
Lighttpd is getting hotter as time moves on and its speed makes it
a good alternative to apache as reverse proxy; obviously a position
where ModSecurity is welcome.

I found http://trac.lighttpd.net/trac/ticket/403 stating, that lighttpd
users should use mod_magnet, but mod_magnet does not sound like
supporting the interesting features in ModSecurity out of the box
(http://trac.lighttpd.net/trac/wiki/Docs%3AModMagnet). Despite looking
like a very nice module by itself.

Lighttpd has a share of 0.3% according to netcraft
(http://news.netcraft.com/archives/2007/04/02/april_2007_web_server_survey.html)
but considering sourceforge and reddit as being lighttpd users, there
might be some interest...

regs,

Christian

--

-- 
Given the choice between two theories, take the one which is funnier.
--- Blore's Razor, Author unknown

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Ivan Ristic | 12 Apr 10:21 2007
Picon

Re: ModSecurity on lighttpd (?)

I'd love to see ModSecurity running on other web servers, including
lighttpd. But I am pretty sure we (as in the ModSecurity developers)
are not going to attempt to port it. We'd be happy to assist someone
else do the job.

However, there is no point in trying to port ModSecurity 2.x. Although
significant changes were made in the 2.x branch to separate it from
Apache the ties are still strong. The good news is the main goal of
ModSecurity 3.x, due later this year, is portability. It should be
pretty straightforward to port ModSecurity 3.x to a web server of your
choice.

On 4/12/07, Christian Folini <christian.folini <at> time-machine.ch> wrote:
> Hi there,
>
> I am wondering if porting ModSecurity to lighttpd is an issue or not.
> Lighttpd is getting hotter as time moves on and its speed makes it
> a good alternative to apache as reverse proxy; obviously a position
> where ModSecurity is welcome.
>
> I found http://trac.lighttpd.net/trac/ticket/403 stating, that lighttpd
> users should use mod_magnet, but mod_magnet does not sound like
> supporting the interesting features in ModSecurity out of the box
> (http://trac.lighttpd.net/trac/wiki/Docs%3AModMagnet). Despite looking
> like a very nice module by itself.
>
> Lighttpd has a share of 0.3% according to netcraft
> (http://news.netcraft.com/archives/2007/04/02/april_2007_web_server_survey.html)
> but considering sourceforge and reddit as being lighttpd users, there
> might be some interest...
>
> regs,
>
> Christian
>
> --
> Given the choice between two theories, take the one which is funnier.
> --- Blore's Razor, Author unknown
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> mod-security-users mailing list
> mod-security-users <at> lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
>

--

-- 
Ivan Ristic

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Ivan Ristic | 12 Apr 10:56 2007
Picon

Re: Big number of Web server

Hi Marc,

On 4/6/07, Marc Stern <marc.stern <at> approach.be> wrote:
> Hello,
>
> If you want to use ModSecurity in an environment where you have a big
> number of very different applications, what would be the best approach ?
>
> Would one reverse proxy (even on a good machine) be powerful enough to
> not slow down the system ?

How many web servers are we talking about? If there are many than
having ModSecurity installed on a single reverse proxy box would
probably be much easier to maintain. But you'll need at least two
boxes at this layer to avoid a central point of failure.

As for performance - that depends entirely on the rate of requests.
Properly sized I don't expect you'd have any problems.

> Wouldn't it be better to have, for instance, one reverse proxy for the
> general things (maybe core rules), then another one (or the module on
> the Web server) for dedicated rules ?
> Or another architecture ?
>
> Does somebody have any metrics ?
>
> Thanks
>
> Marc
>
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> mod-security-users mailing list
> mod-security-users <at> lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
>

--

-- 
Ivan Ristic

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Filip Hajny | 12 Apr 11:05 2007

Re: ModSecurity on lighttpd (?)

Slightly offtopic: LiteSpeed 3.0 does include a simplified,  
mod_security 1.9 inspired markup for request filtering. I think  
SecFilter and SecFilterSelective are implemented.

Filip

On 12.4.2007, at 10:21, Ivan Ristic wrote:

> I'd love to see ModSecurity running on other web servers, including
> lighttpd. But I am pretty sure we (as in the ModSecurity developers)
> are not going to attempt to port it. We'd be happy to assist someone
> else do the job.
>
> However, there is no point in trying to port ModSecurity 2.x. Although
> significant changes were made in the 2.x branch to separate it from
> Apache the ties are still strong. The good news is the main goal of
> ModSecurity 3.x, due later this year, is portability. It should be
> pretty straightforward to port ModSecurity 3.x to a web server of your
> choice.
>
>
> On 4/12/07, Christian Folini <christian.folini <at> time-machine.ch> wrote:
>> Hi there,
>>
>> I am wondering if porting ModSecurity to lighttpd is an issue or not.
>> Lighttpd is getting hotter as time moves on and its speed makes it
>> a good alternative to apache as reverse proxy; obviously a position
>> where ModSecurity is welcome.
>>
>> I found http://trac.lighttpd.net/trac/ticket/403 stating, that  
>> lighttpd
>> users should use mod_magnet, but mod_magnet does not sound like
>> supporting the interesting features in ModSecurity out of the box
>> (http://trac.lighttpd.net/trac/wiki/Docs%3AModMagnet). Despite  
>> looking
>> like a very nice module by itself.
>>
>> Lighttpd has a share of 0.3% according to netcraft
>> (http://news.netcraft.com/archives/2007/04/02/ 
>> april_2007_web_server_survey.html)
>> but considering sourceforge and reddit as being lighttpd users, there
>> might be some interest...
>>
>> regs,
>>
>> Christian
>>
>> --
>> Given the choice between two theories, take the one which is funnier.
>> --- Blore's Razor, Author unknown
>>
>> --------------------------------------------------------------------- 
>> ----
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to  
>> share your
>> opinions on IT & business topics through brief surveys-and earn cash
>> http://www.techsay.com/default.php? 
>> page=join.php&p=sourceforge&CID=DEVDEV
>> _______________________________________________
>> mod-security-users mailing list
>> mod-security-users <at> lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mod-security-users
>>
>
>
> -- 
> Ivan Ristic
>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> mod-security-users mailing list
> mod-security-users <at> lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mod-security-users

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Gmane