Re: Mitigation of Apache Range Header DoS Attack

nice - but are you guys really sure that REQUEST_HEADERS:Range " <at> beginsWith bytes=0-"
is a protocol conform rule with do not block legal requests?

http://labs.apache.org/webarch/http/draft-fielding-http/p5-range.html#byte.ranges

    The first 500 bytes (byte offsets 0-499, inclusive): bytes=0-499
    The second 500 bytes (byte offsets 500-999, inclusive): bytes=500-999
    The final 500 bytes (byte offsets 9500-9999, inclusive): bytes=-500
    Or bytes=9500-
    The first and last bytes only (bytes 0 and 9999): bytes=0-0,-1
    Several legal but not canonical specifications of the second 500 bytes (byte offsets 500-999, inclusive):
    bytes=500-600,601-999
    bytes=500-700,601-999

Am 24.08.2011 16:54, schrieb Ryan Barnett:
> FYI - http://blog.spiderlabs.com/2011/08/mitigation-of-apache-range-header-dos-attack.html
> 
> If you are concerned about this attack, I suggest that you download the latest
modsecurity_crs_20_protocol_violations.conf file from SVN as it has the new rules -
> http://mod-security.svn.sourceforge.net/viewvc/mod-security/crs/trunk/base_rules/modsecurity_crs_20_protocol_violations.conf
> 
> --
> Ryan Barnett
> Senior Security Researcher
> Trustwave - SpiderLabs
> 
> 
> ________________________________
> 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

Re: Mitigation of Apache Range Header DoS Attack

On 8/24/11 3:29 PM, "Reindl Harald" <h.reindl <at> thelounge.net> wrote:

>nice - but are you guys really sure that REQUEST_HEADERS:Range
>" <at> beginsWith bytes=0-"
>is a protocol conform rule with do not block legal requests?

This rule was included based upon data from Bad Behavior site -
http://bad-behavior.ioerror.us/documentation/how-it-works/.

In the Bad Behavior rules there is a file called "common_tests.inc.php"
which has the following info -

// Range: field exists and begins with 0
        // Real user-agents do not start ranges at 0
        // NOTE: this blocks the whois.sc bot. No big loss.
        // Exceptions: MT (not fixable); LJ (refuses to fix; may be
        // blocked again in the future); Facebook
        if ($settings['strict'] && array_key_exists('Range',
$package['headers_mixed']) && strpos($package['headers_mixed']['Range'],
"=0-") !== FALSE) {
                if (strncmp($ua, "MovableType", 11) && strncmp($ua, "URI::Fetch", 10) &&
strncmp($ua, "php-openid/", 11) && strncmp($ua, "facebookexternalhit",
19)) {
                        return "7ad04a8a";
                }
        }

So it seems that although this is legal per the RFC, it seems as though no
legitimate clients do this.

Re: Mitigation of Apache Range Header DoS Attack

Am 24.08.2011 21:41, schrieb Ryan Barnett:
> 
> On 8/24/11 3:29 PM, "Reindl Harald" <h.reindl <at> thelounge.net> wrote:
> 
>> nice - but are you guys really sure that REQUEST_HEADERS:Range
>> " <at> beginsWith bytes=0-"
>> is a protocol conform rule with do not block legal requests?
> 
> This rule was included based upon data from Bad Behavior site -
> http://bad-behavior.ioerror.us/documentation/how-it-works/.
> 
> In the Bad Behavior rules there is a file called "common_tests.inc.php"
> which has the following info -
> 
> // Range: field exists and begins with 0
>         // Real user-agents do not start ranges at 0
>         // NOTE: this blocks the whois.sc bot. No big loss.
>         // Exceptions: MT (not fixable); LJ (refuses to fix; may be
>         // blocked again in the future); Facebook
>         if ($settings['strict'] && array_key_exists('Range',
> $package['headers_mixed']) && strpos($package['headers_mixed']['Range'],
> "=0-") !== FALSE) {
>                 if (strncmp($ua, "MovableType", 11) && strncmp($ua, "URI::Fetch", 10) &&
> strncmp($ua, "php-openid/", 11) && strncmp($ua, "facebookexternalhit",
> 19)) {
>                         return "7ad04a8a";
>                 }
>         }
> 

Re: [Owasp-modsecurity-core-rule-set] ModSecurity Advanced Topic of the Week: (Updated) Exception Handling

Hi Ryan

I've tried using the SecRuleUpdateTargetById directive as you describe 
in your blog. However I've got problems getting it working when I want 
to exclude a specific file that is being caught:

--dfd6c026-A--
[24/Aug/2011:22:10:37 +0200] TlVavH8AAQEAAEaWBogAAAAA 10.30.255.126 
54271 2.2.2.2 80
--dfd6c026-B--
GET /lib/images/license/button/cc-by-sa.png HTTP/1.1
Host: wiki.example.org
Connection: keep-alive
Cache-Control: max-age=0
User-Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/535.1 (KHTML, like 
Gecko) Chrome/13.0.782.215 Safari/535.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

--dfd6c026-F--
HTTP/1.1 403 Forbidden
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 201
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1

Re: [Owasp-modsecurity-core-rule-set] ModSecurity Advanced Topic of the Week: (Updated) Exception Handling

On 8/24/11 4:45 PM, "Thomas D. Dahlmann" <domingo <at> domingo.dk> wrote:

>Hi Ryan
>
>I've tried using the SecRuleUpdateTargetById directive as you describe
>in your blog. However I've got problems getting it working when I want
>to exclude a specific file that is being caught:
>
>--dfd6c026-A--
>[24/Aug/2011:22:10:37 +0200] TlVavH8AAQEAAEaWBogAAAAA 10.30.255.126
>54271 2.2.2.2 80
>--dfd6c026-B--
>GET /lib/images/license/button/cc-by-sa.png HTTP/1.1
>Host: wiki.example.org
>Connection: keep-alive
>Cache-Control: max-age=0
>User-Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/535.1 (KHTML, like
>Gecko) Chrome/13.0.782.215 Safari/535.1
>Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
>Accept-Encoding: gzip,deflate,sdch
>Accept-Language: en-US,en;q=0.8
>Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
>
>--dfd6c026-F--
>HTTP/1.1 403 Forbidden
>Vary: Accept-Encoding
>Content-Encoding: gzip
>Content-Length: 201
>Keep-Alive: timeout=15, max=100

Re: [Owasp-modsecurity-core-rule-set] ModSecurity Advanced Topic of the Week: (Updated) Exception Handling

On 2011-08-24 23:12, Ryan Barnett wrote:
> SecRuleUpdateTargetById 950907 !REQUEST_FILENAME
If I go with the above will it then bypass any file request unconditionally?

/T

------------------------------------------------------------------------------
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management 
Up to 160% more powerful than alternatives and 25% more efficient. 
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
_______________________________________________
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

Re: Rule causing Modsecurity to Segfault

------------------------------------------------------------------------------
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management 
Up to 160% more powerful than alternatives and 25% more efficient. 
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev

_______________________________________________
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

Re: [Owasp-modsecurity-core-rule-set] ModSecurity Advanced Topic of the Week: (Updated) Exception Handling

On 8/24/11 5:47 PM, "Thomas D. Dahlmann" <domingo <at> domingo.dk> wrote:

>On 2011-08-24 23:12, Ryan Barnett wrote:
>> SecRuleUpdateTargetById 950907 !REQUEST_FILENAME
>If I go with the above will it then bypass any file request
>unconditionally?

Correct, if you use this directive, it will modify the TARGET list for
rule ID 950907 and will not inspect the REQUEST_FILENAME variable at all.

-Ryan

>
>/T
>

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.

------------------------------------------------------------------------------
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management 
Up to 160% more powerful than alternatives and 25% more efficient. 
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
_______________________________________________
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

Re: [Owasp-modsecurity-core-rule-set] ModSecurity Advanced Topic of the Week: (Updated) Exception Handling

Ok thanks.

Both solutions work but I think I stick with the custom 15 solution to 
be as specific as possible.

/T

>>> SecRuleUpdateTargetById 950907 !REQUEST_FILENAME
>> If I go with the above will it then bypass any file request
>> unconditionally?
> Correct, if you use this directive, it will modify the TARGET list for
> rule ID 950907 and will not inspect the REQUEST_FILENAME variable at all.
>
> -Ryan
>
>

------------------------------------------------------------------------------
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management 
Up to 160% more powerful than alternatives and 25% more efficient. 
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
_______________________________________________
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

Cookie tripping modsec

Hello, we are having a problem where a cookie being set is tripping rule 981173 due to the number of special
characters. I have created a modsecurity_crs_15_customrules.conf file with the following content:

# Ignore tracker cookie
SecRule REQUEST_HEADERS \
   "phase:1,t:none,nolog,pass,ctl:ruleUpdateTargetById=981173:!REQUEST_COOKIES:tracker"

Yet when I reload HTTPD and test the cookie is still being reported as a warning. How would one override it
please ? Do I have it set to early in the processing ?
--

-- 
Thank you, OS

------------------------------------------------------------------------------
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management 
Up to 160% more powerful than alternatives and 25% more efficient. 
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev

_______________________________________________
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