Thomas Anderson | 16 Sep 23:19 2011

SecRequestBodyLimit inside Location

I want to permit larger file transfers only for SVN access, so what I 
wanted to do was this:

<IfDefine SVN>
  <Location /svn/repos>
   # mod_security rules for SVN
   <IfModule security2_module>
	SecRequestBodyLimit 1073741824
   </IfModule>
  </Location>
</IfDefine>

# mod_security rules for everything else
<IfModule security2_module>
	SecRequestBodyLimit 6291456
</IfModule>

This does not work though... the Location-bounded SecRequestBodyLimit 
does not seem to get interpreted although SecRules in the same scope do. 
  Am I doing something wrong, is this a bug, or is it just not possible?

Tom

------------------------------------------------------------------------------
BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
http://p.sf.net/sfu/rim-devcon-copy2
_______________________________________________
mod-security-users mailing list
mod-security-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-security-users
(Continue reading)

Ryan Barnett | 17 Sep 00:06 2011

Re: SecRequestBodyLimit inside Location

Try using the ctl:requestBodyLimit action -
http://sourceforge.net/apps/mediawiki/mod-security/index.php?title=Reference_Manual#ctl

SecRule REQUEST_URI " <at> streq /svn/repos" "phase:1,t:none,nolog,pass,ctl:requestBodyLimit=1073741824"

Ryan

On Sep 16, 2011, at 5:55 PM, "Thomas Anderson" <tanderso <at> oac-design.com> wrote:

> I want to permit larger file transfers only for SVN access, so what I
> wanted to do was this:
>
> <IfDefine SVN>
>  <Location /svn/repos>
>   # mod_security rules for SVN
>   <IfModule security2_module>
>    SecRequestBodyLimit 1073741824
>   </IfModule>
>  </Location>
> </IfDefine>
>
> # mod_security rules for everything else
> <IfModule security2_module>
>    SecRequestBodyLimit 6291456
> </IfModule>
>
> This does not work though... the Location-bounded SecRequestBodyLimit
> does not seem to get interpreted although SecRules in the same scope do.
>  Am I doing something wrong, is this a bug, or is it just not possible?
>
(Continue reading)

Delta Yeh | 17 Sep 06:18 2011
Picon

svn r1838 duble free by typo?

Hi,
  I didn't subscribe modsec dev list , so I post is here.
I upate latest SVN today , and find, maybe ,there is typo in r1838

line 221 and line 243:
  if(target != NULL)
                free(replace);

should be

 if(target != NULL)
                free(target);

?

------------------------------------------------------------------------------
BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
http://p.sf.net/sfu/rim-devcon-copy2
_______________________________________________
mod-security-users mailing list
mod-security-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-security-users
ModSecurity Services from Trustwave's SpiderLabs:
https://www.trustwave.com/application-security.php

Breno Silva | 17 Sep 15:35 2011
Picon

Re: svn r1838 duble free by typo?

Yes.. thanks.

On Fri, Sep 16, 2011 at 11:18 PM, Delta Yeh <delta.yeh <at> gmail.com> wrote:
Hi,
 I didn't subscribe modsec dev list , so I post is here.
I upate latest SVN today , and find, maybe ,there is typo in r1838

line 221 and line 243:
 if(target != NULL)
               free(replace);

should be

 if(target != NULL)
               free(target);

?

------------------------------------------------------------------------------
BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
http://p.sf.net/sfu/rim-devcon-copy2
_______________________________________________
mod-security-users mailing list
mod-security-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-security-users
ModSecurity Services from Trustwave's SpiderLabs:
https://www.trustwave.com/application-security.php

------------------------------------------------------------------------------
BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
http://p.sf.net/sfu/rim-devcon-copy2
_______________________________________________
mod-security-users mailing list
mod-security-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-security-users
ModSecurity Services from Trustwave's SpiderLabs:
https://www.trustwave.com/application-security.php
Breno Silva | 18 Sep 01:01 2011
Picon

Re: svn r1838 duble free by typo?

Hello,

I decided to upload a new tarball for 2.6.2-rc1 (not only provide the fix already in svn) fixing this typo and do not wait until the stable version.
Please, for those that downloaded the old tarball (2.6.2-rc1) for testing, please get it again.

Thanks for your comprehension.

Breno


On Sat, Sep 17, 2011 at 8:35 AM, Breno Silva <breno.silva <at> gmail.com> wrote:
Yes.. thanks.


On Fri, Sep 16, 2011 at 11:18 PM, Delta Yeh <delta.yeh <at> gmail.com> wrote:
Hi,
 I didn't subscribe modsec dev list , so I post is here.
I upate latest SVN today , and find, maybe ,there is typo in r1838

line 221 and line 243:
 if(target != NULL)
               free(replace);

should be

 if(target != NULL)
               free(target);

?

------------------------------------------------------------------------------
BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
http://p.sf.net/sfu/rim-devcon-copy2
_______________________________________________
mod-security-users mailing list
mod-security-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-security-users
ModSecurity Services from Trustwave's SpiderLabs:
https://www.trustwave.com/application-security.php


------------------------------------------------------------------------------
BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
http://p.sf.net/sfu/rim-devcon-copy2
_______________________________________________
mod-security-users mailing list
mod-security-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-security-users
ModSecurity Services from Trustwave's SpiderLabs:
https://www.trustwave.com/application-security.php
Frantisek Hanzlik | 18 Sep 22:23 2011
Picon

Re: selectively disable logging or auditing

Ryan Barnett wrote:
> Check out the FAQ -
> http://sourceforge.net/apps/mediawiki/mod-security/index.php?title=FAQ#How_do_I_whitelist_an_IP_address_so_it_can_pass_through_ModSecurity.3F
> 
> Look at the last example where it uses the ctl:auditEngine=Off action.
> Just update the rule to check the URL you want instead of an IP address.
> 
> Ryan
> 
> On Sep 15, 2011, at 7:20 PM, "Frantisek Hanzlik" <franta <at> hanzlici.cz> wrote:
> 
>> First, please excuse for probably beginners question.
>> Recently I start using mod_security on small server, where Apache
>> on gateway is used mainly for webmail a some internal demands
>> (eg. downloading files).
>>
>> What I now see, modsec_audit.log files are quite big (several hunderts
>> megabytes per month), and 95% of their size are about logging requests
>> to access Web Proxy autoconfiguration file ("GET /wpad.dat"). Because
>> I probably not need log this access, i would like implement something
>> to suppress mod_security auditing or logging this. When more concretize
>> problem:
>> Is somehow possible disable auditing and/or logging "GET /wpad.dat"
>> and "GET /wpad.da" requests comming from 192.168.0.0/22 network?
>>
>> I was trying some attempts to solve this, but, due to complexity
>> mod_security rules, still without success.
>> My system is Fedora 12 i686 Linux with mod_security-2.5.12
>>
>> Thanks in advance, Franta Hanzlik
>>
>> ------------------------------------------------------------------------------
>> BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
>> http://p.sf.net/sfu/rim-devcon-copy2
>> _______________________________________________
>> mod-security-users mailing list
>> mod-security-users <at> lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mod-security-users
>> ModSecurity Services from Trustwave's SpiderLabs:
>> https://www.trustwave.com/application-security.php

Ryan, thank You. It seems as things are OK now - other requests
are audited and these two no.

Franta Hanzlik

------------------------------------------------------------------------------
BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
http://p.sf.net/sfu/rim-devcon-copy2
_______________________________________________
mod-security-users mailing list
mod-security-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-security-users
ModSecurity Services from Trustwave's SpiderLabs:
https://www.trustwave.com/application-security.php

Michael Haas | 19 Sep 15:05 2011
Picon

experimental_rules/modsecurity_crs_41_advanced_filters.conf umlauts

Hello,

is it intentional that in Rule 9000039 are not only Null bytes
detected but also "umlaut's".
If "umlaut's" are considered as bad characters wouldn't it be better
to make an extra rule for Umlauts? in order to make it easy to exclude
only that rule.

e.g.: Null Bytes
(?:\\\\\\\\x[01][\db-ce-f])|(?:%[01][\db-ce-f])|(?:&#[01][\db-ce-f])|(?:\\\\\\\\[01][\db-ce-f])|(?:&#x[01][\db-ce-f])
        Chars whits umlauts
(?:\\\\\\\\x[ef][\db-ce-f])|(?:%[ef][\db-ce-f])|(?:&#[ef][\db-ce-f])|(?:\\\\\\\\[ef][\db-ce-f])|(?:&#x[ef][\db-ce-f])

Thanks
Michael

------------------------------------------------------------------------------
BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
Learn about the latest advances in developing for the 
BlackBerry&reg; mobile platform with sessions, labs & more.
See new tools and technologies. Register for BlackBerry&reg; DevCon today!
http://p.sf.net/sfu/rim-devcon-copy1 
_______________________________________________
mod-security-users mailing list
mod-security-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-security-users
ModSecurity Services from Trustwave's SpiderLabs:
https://www.trustwave.com/application-security.php

Todd Michael Bushnell | 21 Sep 01:19 2011

Secure way to deal with ModSecurity SQLI False Positives on AJAX pages

Running into an issue where AJAX pages are taking 7-10 seconds to load.  Dug in deeper and noticed that it's indeed due to 30+ false positives detected during request body processing (phase 2).  I'm trying to determine the most secure way to deal with this.  I run in anomaly based mode.  I thought about just increasing the threshold, but I don't think this will address the performance issue because all the rules will still still be triggered.  The only thing I'll save on is the generation of the alert which my data tell me is not the delay.  I see my remaining options as:

 - disable the rules that are firing (about 10 or so sql injection pattern matching rules) globally.  SQL Injection rules are generating 95% of my false positives on the site.
 - disable all modsecurity processing of anything with Body that starts with ^AJAXREQUEST
 - disable all or partial rules on page by page basis, feeding that data in using something like <at> pfFromFile.  

Would appreciate advice from folks who've dealt with this before.  Much obliged.

todd










------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
mod-security-users mailing list
mod-security-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-security-users
ModSecurity Services from Trustwave's SpiderLabs:
https://www.trustwave.com/application-security.php
Ryan Barnett | 21 Sep 01:36 2011

Re: Secure way to deal with ModSecurity SQLI False Positives on AJAX pages

Can you provide an example audit log or two of some false positives?  This will help in recommending some
exception options.

You might be able to use the ctl:ruleUpdateTargetById action to exclude certain AJAX params from
inspection for specific pages.  See this blog post -
http://blog.spiderlabs.com/2011/08/modsecurity-advanced-topic-of-the-week-exception-handling.html

-Ryan

From: Todd Michael Bushnell <todd <at> toorsecurity.com<mailto:todd <at> toorsecurity.com>>
Date: Tue, 20 Sep 2011 18:19:26 -0500
To:
"mod-security-users <at> lists.sourceforge.net<mailto:mod-security-users <at> lists.sourceforge.net>" <mod-security-users <at> lists.sourceforge.net<mailto:mod-security-users <at> lists.sourceforge.net>>
Subject: [mod-security-users] Secure way to deal with ModSecurity SQLI False Positives on AJAX pages

Running into an issue where AJAX pages are taking 7-10 seconds to load.  Dug in deeper and noticed that it's
indeed due to 30+ false positives detected during request body processing (phase 2).  I'm trying to
determine the most secure way to deal with this.  I run in anomaly based mode.  I thought about just
increasing the threshold, but I don't think this will address the performance issue because all the rules
will still still be triggered.  The only thing I'll save on is the generation of the alert which my data tell
me is not the delay.  I see my remaining options as:

 - disable the rules that are firing (about 10 or so sql injection pattern matching rules) globally.  SQL
Injection rules are generating 95% of my false positives on the site.
 - disable all modsecurity processing of anything with Body that starts with ^AJAXREQUEST
 - disable all or partial rules on page by page basis, feeding that data in using something like  <at> pfFromFile.

Would appreciate advice from folks who've dealt with this before.  Much obliged.

todd

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

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
mod-security-users mailing list
mod-security-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-security-users
ModSecurity Services from Trustwave's SpiderLabs:
https://www.trustwave.com/application-security.php

Todd Michael Bushnell | 21 Sep 06:44 2011

Re: Secure way to deal with ModSecurity SQLI False Positives on AJAX pages

Ryan (et al.),

Appreciate the help.  Attached is a sample event log entry in gzip format.  Not sure if this will even take, but worth a shot.  It's been scrubbed and the majority of the request data truncated, but you'll get the picture.  As you can see from this, there are a lot of strings that trip the SQL injection rules.  Even pipe delimiters in the cookie header are contributing to this, but the vast majority in this case comes from the 3k AJAX request body.  I'm trying to find that balance between reasonably protective and unnecessarily noisy and most of my difficulties are with the SQL injection rules given the sheer number of "interesting" characters and strings that will trip it.  Appreciate the assist.

todd

On Sep 20, 2011, at 4:36 PM, Ryan Barnett wrote:

Can you provide an example audit log or two of some false positives?  This will help in recommending some exception options.

You might be able to use the ctl:ruleUpdateTargetById action to exclude certain AJAX params from inspection for specific pages.  See this blog post -
http://blog.spiderlabs.com/2011/08/modsecurity-advanced-topic-of-the-week-exception-handling.html

-Ryan

From: Todd Michael Bushnell <todd <at> toorsecurity.com<mailto:todd <at> toorsecurity.com>>
Date: Tue, 20 Sep 2011 18:19:26 -0500
To: "mod-security-users <at> lists.sourceforge.net<mailto:mod-security-users <at> lists.sourceforge.net>" <mod-security-users <at> lists.sourceforge.net<mailto:mod-security-users <at> lists.sourceforge.net>>
Subject: [mod-security-users] Secure way to deal with ModSecurity SQLI False Positives on AJAX pages

Running into an issue where AJAX pages are taking 7-10 seconds to load.  Dug in deeper and noticed that it's indeed due to 30+ false positives detected during request body processing (phase 2).  I'm trying to determine the most secure way to deal with this.  I run in anomaly based mode.  I thought about just increasing the threshold, but I don't think this will address the performance issue because all the rules will still still be triggered.  The only thing I'll save on is the generation of the alert which my data tell me is not the delay.  I see my remaining options as:

- disable the rules that are firing (about 10 or so sql injection pattern matching rules) globally.  SQL Injection rules are generating 95% of my false positives on the site.
- disable all modsecurity processing of anything with Body that starts with ^AJAXREQUEST
- disable all or partial rules on page by page basis, feeding that data in using something like <at> pfFromFile.

Would appreciate advice from folks who've dealt with this before.  Much obliged.

todd











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

Attachment (modsec_fp_ajax_2011-09-21.txt.gz): application/x-gzip, 6323 bytes

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
mod-security-users mailing list
mod-security-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-security-users
ModSecurity Services from Trustwave's SpiderLabs:
https://www.trustwave.com/application-security.php

Gmane