mod-security-developers — Development discussion about mod_security

[Mod-security-developers] [JIRA] Resolved: (MODSEC-245) Change apr_table_t to apr_hash_t into GSB implementation

[Breno S. P. (JIRA) <no...@mo...>]

     [ https://www.modsecurity.org/tracker/browse/MODSEC-245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Breno Silva Pinto resolved MODSEC-245.
--------------------------------------

    Resolution: Fixed

> Change apr_table_t to apr_hash_t into GSB implementation
> --------------------------------------------------------
>
>                 Key: MODSEC-245
>                 URL: https://www.modsecurity.org/tracker/browse/MODSEC-245
>             Project: ModSecurity
>          Issue Type: Improvement
>      Security Level: Normal
>          Components: Core
>    Affects Versions: 2.6.0
>            Reporter: Breno Silva Pinto
>            Assignee: Breno Silva Pinto
>             Fix For: 2.6.1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://www.modsecurity.org/tracker/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Re: [Mod-security-developers] building modsecurity 2.6.0 with apache httpd 2.2.19 on debian 6.0.1

[Oleg G. <ole...@ya...>]

just FYI: I didn't have a problem on Debian with RC2.
The error indicates that you don't have libexpat.
Try: aptitude install libexpat-dev (or libexpat1-dev - I'm not sure what version 
you need on your distro)


>
>From: Breno Silva <bre...@gm...>
>To: mod...@li...
>Sent: Tue, May 24, 2011 8:13:04 AM
>Subject: Re: [Mod-security-developers] building modsecurity 2.6.0 with apache 
>httpd 2.2.19 on debian 6.0.1
>
>Hi Todd,
>
>I'm download a Debian 6 vm image to test the build. Hope give you the directions 
>soon
>
>thanks
>
>Breno
>
>
>On Mon, May 23, 2011 at 2:15 PM, Breno Silva <bre...@gm...> wrote:
>
>The build system in 2.6.0 was totally rewritten ... i will need to setup a 
>debian 6 box to check it closer.
>>
>>Thanks
>>
>>Breno
>>
>>
>>On Mon, May 23, 2011 at 1:46 PM, Todd Woods <TW...@li...> wrote:
>>
>>There’s an issue building 2.6.0 on Debian 6.0.1 with apache httpd 2.2.19.
>>>2.5.13 compiles and runs tests with no errors. 
>>>Here’s the configure script 
>>> 
>>>./configure --prefix=/usr/local/modsecurity-2.6.0 
>>>--with-apxs=/usr/local/apache-2.2.19/bin/apxs --with-pcre=/usr/bin/pcre-config 
>>>--with-apr=/usr/local/apache-2.2.19/bin/apr-1-config 
>>>--with-apu=/usr/local/apache-2.2.19/bin/apu-1-config
>>> 
>>>Didn’t see any errors during configuration.
>>> 
>>>Running make produces this error 
>>> 
>>>/bin/bash ../libtool --tag=CC   --mode=link gcc 
>>>-I/usr/local/apache-2.2.19/include  -I/usr/local/apache-2.2.19/include   
>>>-I/usr/local/apache-2.2.19/include -I/usr/include/libxml2  -g -O2 -no-undefined 
>>>-module -avoid-version -lrt -lcrypt  -lpthread -ldl      -lexpat   -o 
>>>mod_security2.la -rpath /usr/local/modsecurity-2.6.0/lib 
>>>mod_security2_la-mod_security2.lo mod_security2_la-apache2_config.lo 
>>>mod_security2_la-apache2_io.lo mod_security2_la-apache2_util.lo 
>>>mod_security2_la-re.lo mod_security2_la-re_operators.lo 
>>>mod_security2_la-re_actions.lo mod_security2_la-re_tfns.lo 
>>>mod_security2_la-re_variables.lo mod_security2_la-msc_logging.lo 
>>>mod_security2_la-msc_xml.lo mod_security2_la-msc_multipart.lo 
>>>mod_security2_la-modsecurity.lo mod_security2_la-msc_parsers.lo 
>>>mod_security2_la-msc_util.lo mod_security2_la-msc_pcre.lo 
>>>mod_security2_la-persist_dbm.lo mod_security2_la-msc_reqbody.lo 
>>>mod_security2_la-msc_geo.lo mod_security2_la-msc_gsb.lo mod_security2_la-acmp.lo 
>>>mod_security2_la-msc_lua.lo mod_security2_la-msc_release.lo 
>>>/usr/local/apache-2.2.19/lib/libapr-1.la  
>>>/usr/local/apache-2.2.19/lib/libaprutil-1.la -lxml2
>>>libtool: link: gcc -shared  .libs/mod_security2_la-mod_security2.o 
>>>.libs/mod_security2_la-apache2_config.o .libs/mod_security2_la-apache2_io.o 
>>>.libs/mod_security2_la-apache2_util.o .libs/mod_security2_la-re.o 
>>>.libs/mod_security2_la-re_operators.o .libs/mod_security2_la-re_actions.o 
>>>.libs/mod_security2_la-re_tfns.o .libs/mod_security2_la-re_variables.o 
>>>.libs/mod_security2_la-msc_logging.o .libs/mod_security2_la-msc_xml.o 
>>>.libs/mod_security2_la-msc_multipart.o .libs/mod_security2_la-modsecurity.o 
>>>.libs/mod_security2_la-msc_parsers.o .libs/mod_security2_la-msc_util.o 
>>>.libs/mod_security2_la-msc_pcre.o .libs/mod_security2_la-persist_dbm.o 
>>>.libs/mod_security2_la-msc_reqbody.o .libs/mod_security2_la-msc_geo.o 
>>>.libs/mod_security2_la-msc_gsb.o .libs/mod_security2_la-acmp.o 
>>>.libs/mod_security2_la-msc_lua.o .libs/mod_security2_la-msc_release.o   
>>>-Wl,-rpath -Wl,/usr/local/apache-2.2.19/lib -Wl,-rpath 
>>>-Wl,/usr/local/apache-2.2.19/lib -lrt -lcrypt -lpthread -ldl -lexpat 
>>>/usr/local/apache-2.2.19/lib/libapr-1.so 
>>>/usr/local/apache-2.2.19/lib/libaprutil-1.so /usr/lib/libxml2.so    -Wl,-soname 
>>>-Wl,mod_security2.so -o .libs/mod_security2.so
>>>/usr/bin/ld: cannot find -lexpat
>>>collect2: ld returned 1 exit status
>>>make[2]: *** [mod_security2.la] Error 1
>>>make[2]: Leaving directory `/home/twoods/modsecurity-apache_2.6.0/apache2'
>>>make[1]: *** [all-recursive] Error 1
>>>make[1]: Leaving directory `/home/twoods/modsecurity-apache_2.6.0'
>>>make: *** [all] Error 2
>>> 
>>>---------------
>>>Todd Woods
>>>Web Developer
>>>LinguiSystems
>>>309-755-2300
>>> 
>>>------------------------------------------------------------------------------

>>>What Every C/C++ and Fortran developer Should Know!
>>>Read this article and learn how Intel has extended the reach of its
>>>next-generation tools to help Windows* and Linux* C/C++ and Fortran
>>>developers boost performance applications - including clusters.
>>>http://p.sf.net/sfu/intel-dev2devmay
>>>_______________________________________________
>>>mod-security-developers mailing list
>>>mod...@li...
>>>https://lists.sourceforge.net/lists/listinfo/mod-security-developers
>>>ModSecurity Services from Trustwave's SpiderLabs:
>>>https://www.trustwave.com/spiderLabs.php
>>>
>>
>

Re: [Mod-security-developers] building modsecurity 2.6.0 with apache httpd 2.2.19 on debian 6.0.1

[Breno S. <bre...@gm...>]

Hi Todd,

I'm download a Debian 6 vm image to test the build. Hope give you the
directions soon

thanks

Breno

On Mon, May 23, 2011 at 2:15 PM, Breno Silva <bre...@gm...> wrote:

> The build system in 2.6.0 was totally rewritten ... i will need to setup a
> debian 6 box to check it closer.
>
> Thanks
>
> Breno
>
> On Mon, May 23, 2011 at 1:46 PM, Todd Woods <TW...@li...>wrote:
>
>> There’s an issue building 2.6.0 on Debian 6.0.1 with apache httpd 2.2.19.
>>
>> 2.5.13 compiles and runs tests with no errors.
>>
>> Here’s the configure script
>>
>>
>>
>> ./configure --prefix=/usr/local/modsecurity-2.6.0
>> --with-apxs=/usr/local/apache-2.2.19/bin/apxs
>> --with-pcre=/usr/bin/pcre-config
>> --with-apr=/usr/local/apache-2.2.19/bin/apr-1-config
>> --with-apu=/usr/local/apache-2.2.19/bin/apu-1-config
>>
>>
>>
>> Didn’t see any errors during configuration.
>>
>>
>>
>> Running make produces this error
>>
>>
>>
>> /bin/bash ../libtool --tag=CC   --mode=link gcc
>> -I/usr/local/apache-2.2.19/include  -I/usr/local/apache-2.2.19/include
>> -I/usr/local/apache-2.2.19/include -I/usr/include/libxml2  -g -O2
>> -no-undefined -module -avoid-version -lrt -lcrypt  -lpthread -ldl
>>     -lexpat   -o mod_security2.la -rpath /usr/local/modsecurity-2.6.0/lib
>> mod_security2_la-mod_security2.lo mod_security2_la-apache2_config.lo
>> mod_security2_la-apache2_io.lo mod_security2_la-apache2_util.lo
>> mod_security2_la-re.lo mod_security2_la-re_operators.lo
>> mod_security2_la-re_actions.lo mod_security2_la-re_tfns.lo
>> mod_security2_la-re_variables.lo mod_security2_la-msc_logging.lo
>> mod_security2_la-msc_xml.lo mod_security2_la-msc_multipart.lo
>> mod_security2_la-modsecurity.lo mod_security2_la-msc_parsers.lo
>> mod_security2_la-msc_util.lo mod_security2_la-msc_pcre.lo
>> mod_security2_la-persist_dbm.lo mod_security2_la-msc_reqbody.lo
>> mod_security2_la-msc_geo.lo mod_security2_la-msc_gsb.lo
>> mod_security2_la-acmp.lo mod_security2_la-msc_lua.lo
>> mod_security2_la-msc_release.lo /usr/local/apache-2.2.19/lib/libapr-1.la
>> /usr/local/apache-2.2.19/lib/libaprutil-1.la -lxml2
>>
>> libtool: link: gcc -shared  .libs/mod_security2_la-mod_security2.o
>> .libs/mod_security2_la-apache2_config.o .libs/mod_security2_la-apache2_io.o
>> .libs/mod_security2_la-apache2_util.o .libs/mod_security2_la-re.o
>> .libs/mod_security2_la-re_operators.o .libs/mod_security2_la-re_actions.o
>> .libs/mod_security2_la-re_tfns.o .libs/mod_security2_la-re_variables.o
>> .libs/mod_security2_la-msc_logging.o .libs/mod_security2_la-msc_xml.o
>> .libs/mod_security2_la-msc_multipart.o .libs/mod_security2_la-modsecurity.o
>> .libs/mod_security2_la-msc_parsers.o .libs/mod_security2_la-msc_util.o
>> .libs/mod_security2_la-msc_pcre.o .libs/mod_security2_la-persist_dbm.o
>> .libs/mod_security2_la-msc_reqbody.o .libs/mod_security2_la-msc_geo.o
>> .libs/mod_security2_la-msc_gsb.o .libs/mod_security2_la-acmp.o
>> .libs/mod_security2_la-msc_lua.o .libs/mod_security2_la-msc_release.o
>> -Wl,-rpath -Wl,/usr/local/apache-2.2.19/lib -Wl,-rpath
>> -Wl,/usr/local/apache-2.2.19/lib -lrt -lcrypt -lpthread -ldl -lexpat
>> /usr/local/apache-2.2.19/lib/libapr-1.so
>> /usr/local/apache-2.2.19/lib/libaprutil-1.so /usr/lib/libxml2.so
>> -Wl,-soname -Wl,mod_security2.so -o .libs/mod_security2.so
>>
>> /usr/bin/ld: cannot find -lexpat
>>
>> collect2: ld returned 1 exit status
>>
>> make[2]: *** [mod_security2.la] Error 1
>>
>> make[2]: Leaving directory `/home/twoods/modsecurity-apache_2.6.0/apache2'
>>
>> make[1]: *** [all-recursive] Error 1
>>
>> make[1]: Leaving directory `/home/twoods/modsecurity-apache_2.6.0'
>>
>> make: *** [all] Error 2
>>
>>
>>
>> ---------------
>>
>> Todd Woods
>>
>> Web Developer
>>
>> LinguiSystems
>>
>> 309-755-2300
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> What Every C/C++ and Fortran developer Should Know!
>> Read this article and learn how Intel has extended the reach of its
>> next-generation tools to help Windows* and Linux* C/C++ and Fortran
>> developers boost performance applications - including clusters.
>> http://p.sf.net/sfu/intel-dev2devmay
>> _______________________________________________
>> mod-security-developers mailing list
>> mod...@li...
>> https://lists.sourceforge.net/lists/listinfo/mod-security-developers
>> ModSecurity Services from Trustwave's SpiderLabs:
>> https://www.trustwave.com/spiderLabs.php
>>
>
>

Re: [Mod-security-developers] building modsecurity 2.6.0 with apache httpd 2.2.19 on debian 6.0.1

[Breno S. <bre...@gm...>]

The build system in 2.6.0 was totally rewritten ... i will need to setup a
debian 6 box to check it closer.

Thanks

Breno

On Mon, May 23, 2011 at 1:46 PM, Todd Woods <TW...@li...>wrote:

> There’s an issue building 2.6.0 on Debian 6.0.1 with apache httpd 2.2.19.
>
> 2.5.13 compiles and runs tests with no errors.
>
> Here’s the configure script
>
>
>
> ./configure --prefix=/usr/local/modsecurity-2.6.0
> --with-apxs=/usr/local/apache-2.2.19/bin/apxs
> --with-pcre=/usr/bin/pcre-config
> --with-apr=/usr/local/apache-2.2.19/bin/apr-1-config
> --with-apu=/usr/local/apache-2.2.19/bin/apu-1-config
>
>
>
> Didn’t see any errors during configuration.
>
>
>
> Running make produces this error
>
>
>
> /bin/bash ../libtool --tag=CC   --mode=link gcc
> -I/usr/local/apache-2.2.19/include  -I/usr/local/apache-2.2.19/include
> -I/usr/local/apache-2.2.19/include -I/usr/include/libxml2  -g -O2
> -no-undefined -module -avoid-version -lrt -lcrypt  -lpthread -ldl
>     -lexpat   -o mod_security2.la -rpath /usr/local/modsecurity-2.6.0/lib
> mod_security2_la-mod_security2.lo mod_security2_la-apache2_config.lo
> mod_security2_la-apache2_io.lo mod_security2_la-apache2_util.lo
> mod_security2_la-re.lo mod_security2_la-re_operators.lo
> mod_security2_la-re_actions.lo mod_security2_la-re_tfns.lo
> mod_security2_la-re_variables.lo mod_security2_la-msc_logging.lo
> mod_security2_la-msc_xml.lo mod_security2_la-msc_multipart.lo
> mod_security2_la-modsecurity.lo mod_security2_la-msc_parsers.lo
> mod_security2_la-msc_util.lo mod_security2_la-msc_pcre.lo
> mod_security2_la-persist_dbm.lo mod_security2_la-msc_reqbody.lo
> mod_security2_la-msc_geo.lo mod_security2_la-msc_gsb.lo
> mod_security2_la-acmp.lo mod_security2_la-msc_lua.lo
> mod_security2_la-msc_release.lo /usr/local/apache-2.2.19/lib/libapr-1.la
> /usr/local/apache-2.2.19/lib/libaprutil-1.la -lxml2
>
> libtool: link: gcc -shared  .libs/mod_security2_la-mod_security2.o
> .libs/mod_security2_la-apache2_config.o .libs/mod_security2_la-apache2_io.o
> .libs/mod_security2_la-apache2_util.o .libs/mod_security2_la-re.o
> .libs/mod_security2_la-re_operators.o .libs/mod_security2_la-re_actions.o
> .libs/mod_security2_la-re_tfns.o .libs/mod_security2_la-re_variables.o
> .libs/mod_security2_la-msc_logging.o .libs/mod_security2_la-msc_xml.o
> .libs/mod_security2_la-msc_multipart.o .libs/mod_security2_la-modsecurity.o
> .libs/mod_security2_la-msc_parsers.o .libs/mod_security2_la-msc_util.o
> .libs/mod_security2_la-msc_pcre.o .libs/mod_security2_la-persist_dbm.o
> .libs/mod_security2_la-msc_reqbody.o .libs/mod_security2_la-msc_geo.o
> .libs/mod_security2_la-msc_gsb.o .libs/mod_security2_la-acmp.o
> .libs/mod_security2_la-msc_lua.o .libs/mod_security2_la-msc_release.o
> -Wl,-rpath -Wl,/usr/local/apache-2.2.19/lib -Wl,-rpath
> -Wl,/usr/local/apache-2.2.19/lib -lrt -lcrypt -lpthread -ldl -lexpat
> /usr/local/apache-2.2.19/lib/libapr-1.so
> /usr/local/apache-2.2.19/lib/libaprutil-1.so /usr/lib/libxml2.so
> -Wl,-soname -Wl,mod_security2.so -o .libs/mod_security2.so
>
> /usr/bin/ld: cannot find -lexpat
>
> collect2: ld returned 1 exit status
>
> make[2]: *** [mod_security2.la] Error 1
>
> make[2]: Leaving directory `/home/twoods/modsecurity-apache_2.6.0/apache2'
>
> make[1]: *** [all-recursive] Error 1
>
> make[1]: Leaving directory `/home/twoods/modsecurity-apache_2.6.0'
>
> make: *** [all] Error 2
>
>
>
> ---------------
>
> Todd Woods
>
> Web Developer
>
> LinguiSystems
>
> 309-755-2300
>
>
>
>
> ------------------------------------------------------------------------------
> What Every C/C++ and Fortran developer Should Know!
> Read this article and learn how Intel has extended the reach of its
> next-generation tools to help Windows* and Linux* C/C++ and Fortran
> developers boost performance applications - including clusters.
> http://p.sf.net/sfu/intel-dev2devmay
> _______________________________________________
> mod-security-developers mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-developers
> ModSecurity Services from Trustwave's SpiderLabs:
> https://www.trustwave.com/spiderLabs.php
>

[Mod-security-developers] building modsecurity 2.6.0 with apache httpd 2.2.19 on debian 6.0.1

[Todd W. <TW...@li...>]

There's an issue building 2.6.0 on Debian 6.0.1 with apache httpd 2.2.19.
2.5.13 compiles and runs tests with no errors.
Here's the configure script

./configure --prefix=/usr/local/modsecurity-2.6.0 --with-apxs=/usr/local/apache-2.2.19/bin/apxs --with-pcre=/usr/bin/pcre-config --with-apr=/usr/local/apache-2.2.19/bin/apr-1-config --with-apu=/usr/local/apache-2.2.19/bin/apu-1-config

Didn't see any errors during configuration.

Running make produces this error

/bin/bash ../libtool --tag=CC   --mode=link gcc -I/usr/local/apache-2.2.19/include  -I/usr/local/apache-2.2.19/include   -I/usr/local/apache-2.2.19/include -I/usr/include/libxml2  -g -O2 -no-undefined -module -avoid-version -lrt -lcrypt  -lpthread -ldl      -lexpat   -o mod_security2.la -rpath /usr/local/modsecurity-2.6.0/lib mod_security2_la-mod_security2.lo mod_security2_la-apache2_config.lo mod_security2_la-apache2_io.lo mod_security2_la-apache2_util.lo mod_security2_la-re.lo mod_security2_la-re_operators.lo mod_security2_la-re_actions.lo mod_security2_la-re_tfns.lo mod_security2_la-re_variables.lo mod_security2_la-msc_logging.lo mod_security2_la-msc_xml.lo mod_security2_la-msc_multipart.lo mod_security2_la-modsecurity.lo mod_security2_la-msc_parsers.lo mod_security2_la-msc_util.lo mod_security2_la-msc_pcre.lo mod_security2_la-persist_dbm.lo mod_security2_la-msc_reqbody.lo mod_security2_la-msc_geo.lo mod_security2_la-msc_gsb.lo mod_security2_la-acmp.lo mod_security2_la-msc_lua.lo mod_security2_la-msc_release.lo /usr/local/apache-2.2.19/lib/libapr-1.la  /usr/local/apache-2.2.19/lib/libaprutil-1.la -lxml2
libtool: link: gcc -shared  .libs/mod_security2_la-mod_security2.o .libs/mod_security2_la-apache2_config.o .libs/mod_security2_la-apache2_io.o .libs/mod_security2_la-apache2_util.o .libs/mod_security2_la-re.o .libs/mod_security2_la-re_operators.o .libs/mod_security2_la-re_actions.o .libs/mod_security2_la-re_tfns.o .libs/mod_security2_la-re_variables.o .libs/mod_security2_la-msc_logging.o .libs/mod_security2_la-msc_xml.o .libs/mod_security2_la-msc_multipart.o .libs/mod_security2_la-modsecurity.o .libs/mod_security2_la-msc_parsers.o .libs/mod_security2_la-msc_util.o .libs/mod_security2_la-msc_pcre.o .libs/mod_security2_la-persist_dbm.o .libs/mod_security2_la-msc_reqbody.o .libs/mod_security2_la-msc_geo.o .libs/mod_security2_la-msc_gsb.o .libs/mod_security2_la-acmp.o .libs/mod_security2_la-msc_lua.o .libs/mod_security2_la-msc_release.o   -Wl,-rpath -Wl,/usr/local/apache-2.2.19/lib -Wl,-rpath -Wl,/usr/local/apache-2.2.19/lib -lrt -lcrypt -lpthread -ldl -lexpat /usr/local/apache-2.2.19/lib/libapr-1.so /usr/local/apache-2.2.19/lib/libaprutil-1.so /usr/lib/libxml2.so    -Wl,-soname -Wl,mod_security2.so -o .libs/mod_security2.so
/usr/bin/ld: cannot find -lexpat
collect2: ld returned 1 exit status
make[2]: *** [mod_security2.la] Error 1
make[2]: Leaving directory `/home/twoods/modsecurity-apache_2.6.0/apache2'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/twoods/modsecurity-apache_2.6.0'
make: *** [all] Error 2

---------------
Todd Woods
Web Developer
LinguiSystems
309-755-2300

[Mod-security-developers] Announced ModSecurity 2.6.0

[Breno S. <bre...@gm...>]

The ModSecurity Development Team is pleased to announce the availability of
ModSecurity 2.6.0 Release.
This release includes some small bug fixes and a new feature to mitigate
slow DoS attacks, please see the release notes included into CHANGES  file.

The build system still need improvements, specially under some untested
operacional systems.

For known problems and more information about bug fixes, please see the
online ModSecurity Jira. Please report any bug to
mod...@li....

Thanks

Breno Silva

Re: [Mod-security-developers] CRS DoS protection & x-forwarded-for header

[Oleg G. <ole...@ya...>]

> By  the way - with regards to the pcre matching, switch your  single/double
> quotes around to test -

Here is the difference between greedy and non-greedy match:
ogryb@debian:~$ perl -e '"1.2.3.4" =~ /^(.*),?.*$/; print $1;'
1.2.3.4ogryb@debian:~$ perl -e '"1.2.3.4" =~ /^(.*?),?.*$/; print $1;'
ogryb@debian:~$ 

But your new rule should work because you've enforced the IP characters that 
exclude ',' and got rid of non-greedy match.The most importantly, you've 
achieved your goal of reducing the # of SecRulles :)

One tiny suggestion though:
^([0-9a-fA-F\.\:]+),?.*$

I think, we should treat empty values in the same way as cases when no 
x-forwarded-for header is present.



----- Original Message ----
> From: Ryan Barnett <RBa...@tr...>
> To: Oleg Gryb <ol...@gr...>; "mod...@li..." 
><mod...@li...>
> Cc: "owa...@li..." 
><owa...@li...>
> Sent: Fri, May 6, 2011 5:26:45 PM
> Subject: Re: [Mod-security-developers] CRS DoS protection & x-forwarded-for 
>header
> 
> This one seems to work in ModSecurity (verified with the debug log).   I
> matches a single IP, or the 1st one when there a multiple and it  handles
> IPv6 addresses as well -
> 
> SecRule   REQUEST_HEADERS:User-Agent  "^(.*)$" \
>          
>"phase:1,t:none,pass,nolog,t:sha1,t:hexEncode,setvar:tx.ua_hash=%{matched_
> var}"
> SecRule   REQUEST_HEADERS:x-forwarded-for "^([0-9a-fA-F\.\:]*),?.*$" \
>           "phase:1,t:none,pass,nolog,capture,setvar:tx.real_ip=%{tx.1}
> SecRule   &TX:REAL_IP "@eq  0" \
>          
>"phase:1,t:none,pass,nolog,initcol:global=global,initcol:ip=%{remote_addr}
> _%{tx.ua_hash},,setvar:tx.real_ip=%{remote_addr}"
> SecRule   &TX:REAL_IP "!@eq  0" \
>          
>"phase:1,t:none,pass,nolog,initcol:global=global,initcol:ip=%{tx.real_ip}_
> %{tx.ua_hash}"
> 
> 
> 
> By  the way - with regards to the pcre matching, switch your  single/double
> quotes around to test -
> 
> perl -e '"1.2.3.4" =~  m/^([0-9a-fA-F\.\:]*),?.*$/; print "$1\n";'
> 
> --
> Ryan Barnett
> Senior  Security Researcher
> Trustwave - SpiderLabs
> Email: rba...@tr...
> Phone: (703)  794-2248
> Cell: (571) 382-0476
> www.trustwave.com
> 
> 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. Thank you.
> 
> 
> 
> On 5/6/11 5:41 PM,  "Oleg Gryb" <ole...@ya...>  wrote:
> 
> >Ryan,
> >That might not work for a single IP in  x-forwarded-for header, becuase
> >non-greedy match for (.*?) will return  empty string.
> >
> >Try:
> >
> >perl -e "'1.2.3.4' =~  /^(.*?),?.*$/; print $1;"
> >
> >and you'll see what I mean. I'm  assuming here that modsecurity uses  PCRE.
> >
> >Thanks,
> >Oleg.
> >
> >
> >
> >
> >
> >
> >-----  Original Message ----
> >> From: Ryan Barnett <RBa...@tr...>
> >>  To: "ol...@gr..." <ol...@gr...>;
> >>"mod...@li..."
> >><mod...@li...>
> >>  Cc: "owa...@li..."
> >><owa...@li...>
> >>  Sent: Fri, May 6, 2011 10:29:57 AM
> >> Subject: Re:  [Mod-security-developers] CRS DoS protection  &
> >>x-forwarded-for
> >>header
> >>
> >> Good  point about IPv6.  Looks like we could still do this using  the
> >>same  #
> >> of SecRules and just not using an IP  regex like this -
> >>
> >> SecRule   REQUEST_HEADERS:User-Agent   "^(.*)$"
> >>
> >>"phase:1,t:none,pass,nolog,t:sha1,t:hexEncode,setvar:tx.ua_hash=%{matched
> >>_v
> >>  ar}"
> >> SecRule  REQUEST_HEADERS:x-forwarded-for   "^(.*?),?.*$"
> >>  "phase:1,t:none,pass,nolog,setvar:tx.real_ip=%{matched_var}"
> >>
> >>  SecRule  &TX:REAL_IP "@eq   0"
> >>
> >>"phase:1,t:none,pass,nolog,initcol:global=global,initcol:ip=%{remote_addr
> >>}_
> >>  %{tx.ua_hash},,setvar:tx.real_ip=%{remote_addr}"
> >> SecRule   &TX:REAL_IP "!@eq   0"
> >>
> >>"phase:1,t:none,pass,nolog,initcol:global=global,initcol:ip=%{tx.real_ip}
> >>_%
> >>  {tx.ua_hash}"
> >>
> >>
> >>
> >> --
> >>  Ryan
> >>
> >>
> >>
> >> On  5/6/11 1:16 PM,  "Oleg Gryb" <ole...@ya...>   wrote:
> >>
> >> >Ryan,
> >> >
> >> >Thanks  for the update. It might have  problems with IPv6 though.  Here
> >>are
> >> >my rules: they search for ',' and   disregard the IP structure:
> >> >
> >> >
> >>  >SecRule  REQUEST_HEADERS:User-Agent   "^(.*)$"
> >>
> >>>"phase:1,t:none,pass,nolog,t:sha1,t:hexEncode,setvar:tx.ua_hash=%{matche
> >>>d_
> >>  >var}"
> >> >SecRule  REQUEST_HEADERS:x-forwarded-for   "^(.*)$"
> >>  >"phase:1,t:none,pass,nolog,setvar:tx.real_ip=%{matched_var}"
> >>  >SecRule  TX:REAL_IP  "^(.*?),.*$"
> >>  >"phase:1,t:none,pass,nolog,capture,setvar:tx.real_ip=%{TX.1}"
> >>  >
> >> >SecRule  &TX:REAL_IP "@eq   0"
> >>
> >>>"phase:1,t:none,pass,nolog,initcol:global=global,initcol:ip=%{remote_add
> >>>r}
> >>  >_%{tx.ua_hash},,setvar:tx.real_ip=%{remote_addr}"
> >>  >SecRule  &TX:REAL_IP "!@eq   0"
> >>
> >>>"phase:1,t:none,pass,nolog,initcol:global=global,initcol:ip=%{tx.real_ip
> >>>}_
> >>  >%{tx.ua_hash}"
> >> >
> >> >Thanks,
> >>  >Oleg.
> >> >
> >> >---  On Thu, 5/5/11, Ryan  Barnett <RBa...@tr...>   wrote:
> >> >
> >> >> From: Ryan Barnett <RBa...@tr...>
> >>  >>  Subject: Re: [Mod-security-developers] CRS DoS protection   &
> >> >>x-forwarded-for header
> >> >> To: "Oleg  Gryb" <ol...@gr...>,
> >> >>"mod...@li..."
> >>  >><mod...@li...>
> >>  >>  Cc: "owa...@li..."
> >>  >><owa...@li...>
> >>  >>  Date: Thursday, May 5, 2011, 10:46 AM
> >> >> FYI -  updated the CRS 10  config file
> >> >> to add in this logic  and uploaded it to SVN  -
> >>  >>
> >>
> >>>>http://mod-security.svn.sourceforge.net/viewvc/mod-security/crs/trunk/m
> >>>>od
> >>  >>security_crs_10_config.conf.example?revision=1772
> >>  >>
> >> >>  #
> >> >> # -=[ 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_
> >>>>ha
> >>  >>sh=%{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
> >>>>=%
> >>  >>{tx.real_ip}_%{tx.ua_hash}"
> >> >>  SecRule  &TX:REAL_IP "@eq  0"
> >>  >>
> >>
> >>>>"phase:1,id:'981218',t:none,pass,nolog,initcol:global=global,initcol:ip
> >>>>=%
> >>  >>{remote_addr}_%{tx.ua_hash}"
> >> >>
> >>  >>  The new rules will grab the first IP address listed in  an
> >> >>  X-Forwared-For header and use that for the IP  collection
> >> >> key.   If X-Forwarded-For is not present,  then it will
> >> >> use  REMOTE_ADDR.
> >>  >>
> >> >> Thanks for the  suggestion!
> >>  >>
> >> >> -Ryan
> >> >>
> >>  >>
> >> >> On  4/28/11 8:19 PM, "Oleg Gryb"
> >>  >><ole...@ya...<mailto:ole...@ya...>>
> >>  >>  wrote:
> >> >>
> >> >> I've just  realized that there might be a problem  with
> >> >> relying  on that header: if
> >> >> an attacker  intentionally sends  different random IPs in
> >> >> there, DoS   protection
> >> >> can be efficiently by-passed. In my case it  should  not
> >> >> happen, because an LB is
> >>  >> the one who adds the  header, but in general we should  warn
> >> >> engineers about  the
> >> >>  possible exploit.
> >> >>
> >> >>
> >> >>  Actually,  even in LB case: if a request has already had the
> >>  >> header, LB  will
> >> >> create a new one with the  existing value appended to  the
> >> >> client IP:
> >>  >>
> >> >> x-forwarded-for:  real-client-ip,
> >>  >> whatever-client-sent-to-LB
> >> >>
> >>  >>  It means that we would need to rely on the the first IP  in
> >> >> the list,  everything
> >> >> else  should be considered as  untrusted.
> >> >>
> >>  >> Thanks,
> >> >>  Oleg.
> >>  >>
> >> >>
> >> >> ----- Original Message   ----
> >> >> From: Ryan Barnett
> >> >><RBa...@tr...<mailto:RBa...@tr...>>
> >>  >>  To: Oleg Gryb <ol...@gr...<mailto:ol...@gr...>>;
> >>  >>
> >>
> >>>>"mod...@li...<mailto:mod-security-deve
> >>>>lo
> >>  >>pe...@li...>"
> >>  >>
> >>
> >>>><mod...@li...<mailto:mod-security-deve
> >>>>lo
> >>  >>pe...@li...>>
> >>  >>  Cc:
> >>
> >>>>"owa...@li...<mailto:owasp-modsecuri
> >>>>ty
> >>  >>-co...@li...>"
> >>  >>
> >>
> >>>><owa...@li...<mailto:owasp-modsecuri
> >>>>ty
> >>  >>-co...@li...>>
> >>  >>  Sent: Thu, April 28, 2011 4:41:14 PM
> >> >>  Subject: Re:  [Mod-security-developers] CRS DoS protection
> >>  >> &  x-forwarded-for
> >> >> header
> >>  >> Thanks for the updates  Oleg!  This will certainly be  a
> >> >> useful update   to
> >> >> not only the  DoS rules buy any rules that will be based  on
> >> >> the  client  IP.
> >> >> I will actually go back to check   other uses of REMOTE_ADDR
> >> >> and see if  we
> >>  >> can swap  it for tx.real_ip instead.
> >> >> I will  add this to the CRS  v2.2.0  that I am working
> >> >>  on.
> >> >> For future reference - here is the  OWASP  CRS
> >> >> mail-list -
> >> >>
> >>https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
> >>  >>  --
> >> >> Ryan  Barnett
> >> >>  Senior Security  Researcher
> >> >> Trustwave -   SpiderLabs
> >> >> On 4/28/11 7:32  PM, "Oleg  Gryb"
> >> >><ole...@ya...<mailto:ole...@ya...>>
> >>  >>  wrote:
> >> >> >I'm not sure if I can discuss CRS  rules here. If  not,
> >> >> please  let me  know
> >> >> >what
> >> >>  >the right  place is. I want to suggest an
> >> >> improvement to DoS   protection in
> >> >> >CRS
> >> >> >2.1.2. The  problem is  that  enterprise
> >> >> applications usually  run behind
> >> >>  >load
> >> >>  >balancers, so  relying on remote_addr doesn't  make
> >>  >> too much sense, because
> >> >> >you'll
> >>  >>  >always have an LB's IP in there.
> >> >>  >
> >> >>  >
> >> >> >My improved   rules (attached)  check  for
> >> >> x-forwarded-for  header and if
> >> >> >it's
> >> >>   >present, this IP will be used to initialize IP
> >> >>  collection. If  it's  not
> >> >> >then  the
> >> >> >old logic will be  used.
> >> >>  >
> >> >> >It would be  great if we can include   this
> >> >> improvement to the next  CRS
> >>  >>  >release.
> >> >> >
> >> >>  >Thanks,
> >> >>  >Oleg.
> >>  >>
> >>
> >>>>-----------------------------------------------------------------------
> >>>>--
> >>  >>-----
> >> >>  WhatsUp  Gold - Download Free  Network Management
> >> >>  Software
> >> >> The  most intuitive,  comprehensive, and  cost-effective
> >>  >> network
> >> >> management toolset  available   today.  Delivers
> >> >> lowest initial
> >>  >>  acquisition cost and overall TCO of any
> >> >>  competing   solution.
> >> >>  http://p.sf.net/sfu/whatsupgold-sd
> >> >>   _______________________________________________
> >> >>   mod-security-developers  mailing list
> >>  >>
> >>
> >>>>mod...@li...<mailto:mod-security-devel
> >>>>op
> >>  >>er...@li...>
> >>  >> https://lists.sourceforge.net/lists/listinfo/mod-security-developers
> >>  >>  ModSecurity  Services from Trustwave's  SpiderLabs:
> >> >> https://www.trustwave.com/spiderLabs.php
> >> >>
> >>  >>
> >>
> >>>>-----------------------------------------------------------------------
> >>>>--
> >>  >>-----
> >> >>  WhatsUp Gold - Download Free Network  Management Software
> >> >> The most  intuitive,  comprehensive, and cost-effective
> >> >> network
> >>  >>  management toolset available today.  Delivers  lowest
> >> >>  initial
> >> >> acquisition cost  and overall TCO of any  competing
> >> >>  solution.
> >> >> http://p.sf.net/sfu/whatsupgold-sd
> >> >>   _______________________________________________
> >> >>   mod-security-developers mailing list
> >>  >>
> >>
> >>>>mod...@li...<mailto:mod-security-devel
> >>>>op
> >>  >>er...@li...>
> >>  >> https://lists.sourceforge.net/lists/listinfo/mod-security-developers
> >>  >>  ModSecurity Services from Trustwave's SpiderLabs:
> >>  >> https://www.trustwave.com/spiderLabs.php
> >> >>
> >>  >>
> >> >>
> >> >>   ________________________________
> >> >> 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.
> >> >>
> >> >>
> >>  >
> >>
> >>
> >> 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.
> >>
> >>
> >
> 
> 
> 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.
> 
> 
> ------------------------------------------------------------------------------
> WhatsUp  Gold - Download Free Network Management Software
> The most intuitive,  comprehensive, and cost-effective network 
> management toolset available  today.  Delivers lowest initial 
> acquisition cost and overall TCO of any  competing solution.
> http://p.sf.net/sfu/whatsupgold-sd
> _______________________________________________
> mod-security-developers  mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-developers
> ModSecurity  Services from Trustwave's SpiderLabs:
> https://www.trustwave.com/spiderLabs.php
> 

Re: [Mod-security-developers] CRS DoS protection & x-forwarded-for header

[Ryan B. <RBa...@tr...>]

This one seems to work in ModSecurity (verified with the debug log).  I
matches a single IP, or the 1st one when there a multiple and it handles
IPv6 addresses as well -

SecRule  REQUEST_HEADERS:User-Agent  "^(.*)$" \
        "phase:1,t:none,pass,nolog,t:sha1,t:hexEncode,setvar:tx.ua_hash=%{matched_
var}"
SecRule  REQUEST_HEADERS:x-forwarded-for "^([0-9a-fA-F\.\:]*),?.*$" \
        "phase:1,t:none,pass,nolog,capture,setvar:tx.real_ip=%{tx.1}
SecRule  &TX:REAL_IP "@eq  0" \
        "phase:1,t:none,pass,nolog,initcol:global=global,initcol:ip=%{remote_addr}
_%{tx.ua_hash},,setvar:tx.real_ip=%{remote_addr}"
SecRule  &TX:REAL_IP "!@eq  0" \
        "phase:1,t:none,pass,nolog,initcol:global=global,initcol:ip=%{tx.real_ip}_
%{tx.ua_hash}"



By the way - with regards to the pcre matching, switch your single/double
quotes around to test -

perl -e '"1.2.3.4" =~ m/^([0-9a-fA-F\.\:]*),?.*$/; print "$1\n";'

--
Ryan Barnett
Senior Security Researcher
Trustwave - SpiderLabs
Email: rba...@tr...
Phone: (703) 794-2248
Cell: (571) 382-0476
www.trustwave.com

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



On 5/6/11 5:41 PM, "Oleg Gryb" <ole...@ya...> wrote:

>Ryan,
>That might not work for a single IP in x-forwarded-for header, becuase
>non-greedy match for (.*?) will return empty string.
>
>Try:
>
>perl -e "'1.2.3.4' =~ /^(.*?),?.*$/; print $1;"
>
>and you'll see what I mean. I'm assuming here that modsecurity uses PCRE.
>
>Thanks,
>Oleg.
>
>
>
>
>
>
>----- Original Message ----
>> From: Ryan Barnett <RBa...@tr...>
>> To: "ol...@gr..." <ol...@gr...>;
>>"mod...@li..."
>><mod...@li...>
>> Cc: "owa...@li..."
>><owa...@li...>
>> Sent: Fri, May 6, 2011 10:29:57 AM
>> Subject: Re: [Mod-security-developers] CRS DoS protection &
>>x-forwarded-for
>>header
>>
>> Good point about IPv6.  Looks like we could still do this using the
>>same  #
>> of SecRules and just not using an IP regex like this -
>>
>> SecRule  REQUEST_HEADERS:User-Agent  "^(.*)$"
>>
>>"phase:1,t:none,pass,nolog,t:sha1,t:hexEncode,setvar:tx.ua_hash=%{matched
>>_v
>> ar}"
>> SecRule  REQUEST_HEADERS:x-forwarded-for  "^(.*?),?.*$"
>> "phase:1,t:none,pass,nolog,setvar:tx.real_ip=%{matched_var}"
>>
>> SecRule  &TX:REAL_IP "@eq  0"
>>
>>"phase:1,t:none,pass,nolog,initcol:global=global,initcol:ip=%{remote_addr
>>}_
>> %{tx.ua_hash},,setvar:tx.real_ip=%{remote_addr}"
>> SecRule  &TX:REAL_IP "!@eq  0"
>>
>>"phase:1,t:none,pass,nolog,initcol:global=global,initcol:ip=%{tx.real_ip}
>>_%
>> {tx.ua_hash}"
>>
>>
>>
>> --
>> Ryan
>>
>>
>>
>> On  5/6/11 1:16 PM, "Oleg Gryb" <ole...@ya...>  wrote:
>>
>> >Ryan,
>> >
>> >Thanks for the update. It might have  problems with IPv6 though. Here
>>are
>> >my rules: they search for ',' and  disregard the IP structure:
>> >
>> >
>> >SecRule  REQUEST_HEADERS:User-Agent  "^(.*)$"
>>
>>>"phase:1,t:none,pass,nolog,t:sha1,t:hexEncode,setvar:tx.ua_hash=%{matche
>>>d_
>> >var}"
>> >SecRule  REQUEST_HEADERS:x-forwarded-for  "^(.*)$"
>> >"phase:1,t:none,pass,nolog,setvar:tx.real_ip=%{matched_var}"
>> >SecRule  TX:REAL_IP  "^(.*?),.*$"
>> >"phase:1,t:none,pass,nolog,capture,setvar:tx.real_ip=%{TX.1}"
>> >
>> >SecRule  &TX:REAL_IP "@eq  0"
>>
>>>"phase:1,t:none,pass,nolog,initcol:global=global,initcol:ip=%{remote_add
>>>r}
>> >_%{tx.ua_hash},,setvar:tx.real_ip=%{remote_addr}"
>> >SecRule  &TX:REAL_IP "!@eq  0"
>>
>>>"phase:1,t:none,pass,nolog,initcol:global=global,initcol:ip=%{tx.real_ip
>>>}_
>> >%{tx.ua_hash}"
>> >
>> >Thanks,
>> >Oleg.
>> >
>> >---  On Thu, 5/5/11, Ryan Barnett <RBa...@tr...>  wrote:
>> >
>> >> From: Ryan Barnett <RBa...@tr...>
>> >>  Subject: Re: [Mod-security-developers] CRS DoS protection  &
>> >>x-forwarded-for header
>> >> To: "Oleg Gryb" <ol...@gr...>,
>> >>"mod...@li..."
>> >><mod...@li...>
>> >>  Cc: "owa...@li..."
>> >><owa...@li...>
>> >>  Date: Thursday, May 5, 2011, 10:46 AM
>> >> FYI - updated the CRS 10  config file
>> >> to add in this logic and uploaded it to SVN  -
>> >>
>>
>>>>http://mod-security.svn.sourceforge.net/viewvc/mod-security/crs/trunk/m
>>>>od
>> >>security_crs_10_config.conf.example?revision=1772
>> >>
>> >>  #
>> >> # -=[ 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_
>>>>ha
>> >>sh=%{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
>>>>=%
>> >>{tx.real_ip}_%{tx.ua_hash}"
>> >>  SecRule &TX:REAL_IP "@eq  0"
>> >>
>>
>>>>"phase:1,id:'981218',t:none,pass,nolog,initcol:global=global,initcol:ip
>>>>=%
>> >>{remote_addr}_%{tx.ua_hash}"
>> >>
>> >>  The new rules will grab the first IP address listed in an
>> >>  X-Forwared-For header and use that for the IP collection
>> >> key.   If X-Forwarded-For is not present, then it will
>> >> use  REMOTE_ADDR.
>> >>
>> >> Thanks for the  suggestion!
>> >>
>> >> -Ryan
>> >>
>> >>
>> >> On  4/28/11 8:19 PM, "Oleg Gryb"
>> >><ole...@ya...<mailto:ole...@ya...>>
>> >>  wrote:
>> >>
>> >> I've just realized that there might be a problem  with
>> >> relying on that header: if
>> >> an attacker  intentionally sends different random IPs in
>> >> there, DoS  protection
>> >> can be efficiently by-passed. In my case it should  not
>> >> happen, because an LB is
>> >> the one who adds the  header, but in general we should warn
>> >> engineers about  the
>> >> possible exploit.
>> >>
>> >>
>> >> Actually,  even in LB case: if a request has already had the
>> >> header, LB  will
>> >> create a new one with the existing value appended to  the
>> >> client IP:
>> >>
>> >> x-forwarded-for:  real-client-ip,
>> >> whatever-client-sent-to-LB
>> >>
>> >>  It means that we would need to rely on the the first IP in
>> >> the list,  everything
>> >> else should be considered as  untrusted.
>> >>
>> >> Thanks,
>> >>  Oleg.
>> >>
>> >>
>> >> ----- Original Message  ----
>> >> From: Ryan Barnett
>> >><RBa...@tr...<mailto:RBa...@tr...>>
>> >>  To: Oleg Gryb <ol...@gr...<mailto:ol...@gr...>>;
>> >>
>>
>>>>"mod...@li...<mailto:mod-security-deve
>>>>lo
>> >>pe...@li...>"
>> >>
>>
>>>><mod...@li...<mailto:mod-security-deve
>>>>lo
>> >>pe...@li...>>
>> >>  Cc:
>>
>>>>"owa...@li...<mailto:owasp-modsecuri
>>>>ty
>> >>-co...@li...>"
>> >>
>>
>>>><owa...@li...<mailto:owasp-modsecuri
>>>>ty
>> >>-co...@li...>>
>> >>  Sent: Thu, April 28, 2011 4:41:14 PM
>> >> Subject: Re:  [Mod-security-developers] CRS DoS protection
>> >> &  x-forwarded-for
>> >> header
>> >> Thanks for the updates  Oleg!  This will certainly be a
>> >> useful update   to
>> >> not only the DoS rules buy any rules that will be based  on
>> >> the client  IP.
>> >> I will actually go back to check  other uses of REMOTE_ADDR
>> >> and see if  we
>> >> can swap  it for tx.real_ip instead.
>> >> I will add this to the CRS  v2.2.0  that I am working
>> >> on.
>> >> For future reference - here is the  OWASP CRS
>> >> mail-list -
>> >>
>>https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
>> >>  --
>> >> Ryan  Barnett
>> >> Senior Security  Researcher
>> >> Trustwave -  SpiderLabs
>> >> On 4/28/11 7:32  PM, "Oleg Gryb"
>> >><ole...@ya...<mailto:ole...@ya...>>
>> >>  wrote:
>> >> >I'm not sure if I can discuss CRS rules here. If  not,
>> >> please  let me know
>> >> >what
>> >>  >the right place is. I want to suggest an
>> >> improvement to DoS  protection in
>> >> >CRS
>> >> >2.1.2. The problem is  that  enterprise
>> >> applications usually run behind
>> >>  >load
>> >> >balancers, so  relying on remote_addr doesn't  make
>> >> too much sense, because
>> >> >you'll
>> >>  >always have an LB's IP in there.
>> >> >
>> >>  >
>> >> >My improved  rules (attached)  check  for
>> >> x-forwarded-for header and if
>> >> >it's
>> >>  >present, this IP will be used to initialize IP
>> >> collection. If  it's  not
>> >> >then the
>> >> >old logic will be  used.
>> >> >
>> >> >It would be  great if we can include  this
>> >> improvement to the next  CRS
>> >>  >release.
>> >> >
>> >> >Thanks,
>> >>  >Oleg.
>> >>
>>
>>>>-----------------------------------------------------------------------
>>>>--
>> >>-----
>> >>  WhatsUp  Gold - Download Free Network Management
>> >>  Software
>> >> The most intuitive,  comprehensive, and  cost-effective
>> >> network
>> >> management toolset  available  today.  Delivers
>> >> lowest initial
>> >>  acquisition cost and overall TCO of any
>> >> competing   solution.
>> >> http://p.sf.net/sfu/whatsupgold-sd
>> >>  _______________________________________________
>> >>  mod-security-developers  mailing list
>> >>
>>
>>>>mod...@li...<mailto:mod-security-devel
>>>>op
>> >>er...@li...>
>> >> https://lists.sourceforge.net/lists/listinfo/mod-security-developers
>> >>  ModSecurity  Services from Trustwave's SpiderLabs:
>> >> https://www.trustwave.com/spiderLabs.php
>> >>
>> >>
>>
>>>>-----------------------------------------------------------------------
>>>>--
>> >>-----
>> >>  WhatsUp Gold - Download Free Network Management Software
>> >> The most  intuitive, comprehensive, and cost-effective
>> >> network
>> >>  management toolset available today.  Delivers lowest
>> >>  initial
>> >> acquisition cost and overall TCO of any  competing
>> >> solution.
>> >> http://p.sf.net/sfu/whatsupgold-sd
>> >>  _______________________________________________
>> >>  mod-security-developers mailing list
>> >>
>>
>>>>mod...@li...<mailto:mod-security-devel
>>>>op
>> >>er...@li...>
>> >> https://lists.sourceforge.net/lists/listinfo/mod-security-developers
>> >>  ModSecurity Services from Trustwave's SpiderLabs:
>> >> https://www.trustwave.com/spiderLabs.php
>> >>
>> >>
>> >>
>> >>  ________________________________
>> >> 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.
>> >>
>> >>
>> >
>>
>>
>> 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.
>>
>>
>


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.

[Mod-security-developers] Themeforest Theme Updates

[Weeklyy <we...@we...>]

Your email client cannot read this email.
To view it online, please go here:
http://iintense.com/email/display.php?M=10355&C=e4cf5d0b3f95ff730d29addcde97f37a&S=3&L=1&N=1


To stop receiving these
emails:http://iintense.com/email/unsubscribe.php?M=10355&C=e4cf5d0b3f95ff730d29addcde97f37a&L=1&N=3

Re: [Mod-security-developers] CRS DoS protection & x-forwarded-for header

[Oleg G. <ole...@ya...>]

Ryan,
That might not work for a single IP in x-forwarded-for header, becuase 
non-greedy match for (.*?) will return empty string.

Try:

perl -e "'1.2.3.4' =~ /^(.*?),?.*$/; print $1;"

and you'll see what I mean. I'm assuming here that modsecurity uses PCRE.

Thanks,
Oleg.






----- Original Message ----
> From: Ryan Barnett <RBa...@tr...>
> To: "ol...@gr..." <ol...@gr...>; 
>"mod...@li..." 
><mod...@li...>
> Cc: "owa...@li..." 
><owa...@li...>
> Sent: Fri, May 6, 2011 10:29:57 AM
> Subject: Re: [Mod-security-developers] CRS DoS protection & x-forwarded-for 
>header
> 
> Good point about IPv6.  Looks like we could still do this using the same  #
> of SecRules and just not using an IP regex like this -
> 
> SecRule  REQUEST_HEADERS:User-Agent  "^(.*)$"
> "phase:1,t:none,pass,nolog,t:sha1,t:hexEncode,setvar:tx.ua_hash=%{matched_v
> ar}"
> SecRule  REQUEST_HEADERS:x-forwarded-for  "^(.*?),?.*$"
> "phase:1,t:none,pass,nolog,setvar:tx.real_ip=%{matched_var}"
> 
> SecRule  &TX:REAL_IP "@eq  0"
> "phase:1,t:none,pass,nolog,initcol:global=global,initcol:ip=%{remote_addr}_
> %{tx.ua_hash},,setvar:tx.real_ip=%{remote_addr}"
> SecRule  &TX:REAL_IP "!@eq  0"
> "phase:1,t:none,pass,nolog,initcol:global=global,initcol:ip=%{tx.real_ip}_%
> {tx.ua_hash}"
> 
> 
> 
> --
> Ryan
> 
> 
> 
> On  5/6/11 1:16 PM, "Oleg Gryb" <ole...@ya...>  wrote:
> 
> >Ryan,
> >
> >Thanks for the update. It might have  problems with IPv6 though. Here are
> >my rules: they search for ',' and  disregard the IP structure:
> >
> >
> >SecRule  REQUEST_HEADERS:User-Agent  "^(.*)$"
> >"phase:1,t:none,pass,nolog,t:sha1,t:hexEncode,setvar:tx.ua_hash=%{matched_
> >var}"
> >SecRule  REQUEST_HEADERS:x-forwarded-for  "^(.*)$"
> >"phase:1,t:none,pass,nolog,setvar:tx.real_ip=%{matched_var}"
> >SecRule  TX:REAL_IP  "^(.*?),.*$"
> >"phase:1,t:none,pass,nolog,capture,setvar:tx.real_ip=%{TX.1}"
> >
> >SecRule  &TX:REAL_IP "@eq  0"
> >"phase:1,t:none,pass,nolog,initcol:global=global,initcol:ip=%{remote_addr}
> >_%{tx.ua_hash},,setvar:tx.real_ip=%{remote_addr}"
> >SecRule  &TX:REAL_IP "!@eq  0"
> >"phase:1,t:none,pass,nolog,initcol:global=global,initcol:ip=%{tx.real_ip}_
> >%{tx.ua_hash}"
> >
> >Thanks,
> >Oleg.
> >
> >---  On Thu, 5/5/11, Ryan Barnett <RBa...@tr...>  wrote:
> >
> >> From: Ryan Barnett <RBa...@tr...>
> >>  Subject: Re: [Mod-security-developers] CRS DoS protection  &
> >>x-forwarded-for header
> >> To: "Oleg Gryb" <ol...@gr...>,
> >>"mod...@li..."
> >><mod...@li...>
> >>  Cc: "owa...@li..."
> >><owa...@li...>
> >>  Date: Thursday, May 5, 2011, 10:46 AM
> >> FYI - updated the CRS 10  config file
> >> to add in this logic and uploaded it to SVN  -
> >>
> >>http://mod-security.svn.sourceforge.net/viewvc/mod-security/crs/trunk/mod
> >>security_crs_10_config.conf.example?revision=1772
> >>
> >>  #
> >> # -=[ 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_ha
> >>sh=%{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=%
> >>{tx.real_ip}_%{tx.ua_hash}"
> >>  SecRule &TX:REAL_IP "@eq  0"
> >>
> >>"phase:1,id:'981218',t:none,pass,nolog,initcol:global=global,initcol:ip=%
> >>{remote_addr}_%{tx.ua_hash}"
> >>
> >>  The new rules will grab the first IP address listed in an
> >>  X-Forwared-For header and use that for the IP collection
> >> key.   If X-Forwarded-For is not present, then it will
> >> use  REMOTE_ADDR.
> >>
> >> Thanks for the  suggestion!
> >>
> >> -Ryan
> >>
> >>
> >> On  4/28/11 8:19 PM, "Oleg Gryb"
> >><ole...@ya...<mailto:ole...@ya...>>
> >>  wrote:
> >>
> >> I've just realized that there might be a problem  with
> >> relying on that header: if
> >> an attacker  intentionally sends different random IPs in
> >> there, DoS  protection
> >> can be efficiently by-passed. In my case it should  not
> >> happen, because an LB is
> >> the one who adds the  header, but in general we should warn
> >> engineers about  the
> >> possible exploit.
> >>
> >>
> >> Actually,  even in LB case: if a request has already had the
> >> header, LB  will
> >> create a new one with the existing value appended to  the
> >> client IP:
> >>
> >> x-forwarded-for:  real-client-ip,
> >> whatever-client-sent-to-LB
> >>
> >>  It means that we would need to rely on the the first IP in
> >> the list,  everything
> >> else should be considered as  untrusted.
> >>
> >> Thanks,
> >>  Oleg.
> >>
> >>
> >> ----- Original Message  ----
> >> From: Ryan Barnett
> >><RBa...@tr...<mailto:RBa...@tr...>>
> >>  To: Oleg Gryb <ol...@gr...<mailto:ol...@gr...>>;
> >>
> >>"mod...@li...<mailto:mod-security-develo
> >>pe...@li...>"
> >>
> >><mod...@li...<mailto:mod-security-develo
> >>pe...@li...>>
> >>  Cc:
> >>"owa...@li...<mailto:owasp-modsecurity
> >>-co...@li...>"
> >>
> >><owa...@li...<mailto:owasp-modsecurity
> >>-co...@li...>>
> >>  Sent: Thu, April 28, 2011 4:41:14 PM
> >> Subject: Re:  [Mod-security-developers] CRS DoS protection
> >> &  x-forwarded-for
> >> header
> >> Thanks for the updates  Oleg!  This will certainly be a
> >> useful update   to
> >> not only the DoS rules buy any rules that will be based  on
> >> the client  IP.
> >> I will actually go back to check  other uses of REMOTE_ADDR
> >> and see if  we
> >> can swap  it for tx.real_ip instead.
> >> I will add this to the CRS  v2.2.0  that I am working
> >> on.
> >> For future reference - here is the  OWASP CRS
> >> mail-list -
> >> https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
> >>  --
> >> Ryan  Barnett
> >> Senior Security  Researcher
> >> Trustwave -  SpiderLabs
> >> On 4/28/11 7:32  PM, "Oleg Gryb"
> >><ole...@ya...<mailto:ole...@ya...>>
> >>  wrote:
> >> >I'm not sure if I can discuss CRS rules here. If  not,
> >> please  let me know
> >> >what
> >>  >the right place is. I want to suggest an
> >> improvement to DoS  protection in
> >> >CRS
> >> >2.1.2. The problem is  that  enterprise
> >> applications usually run behind
> >>  >load
> >> >balancers, so  relying on remote_addr doesn't  make
> >> too much sense, because
> >> >you'll
> >>  >always have an LB's IP in there.
> >> >
> >>  >
> >> >My improved  rules (attached)  check  for
> >> x-forwarded-for header and if
> >> >it's
> >>  >present, this IP will be used to initialize IP
> >> collection. If  it's  not
> >> >then the
> >> >old logic will be  used.
> >> >
> >> >It would be  great if we can include  this
> >> improvement to the next  CRS
> >>  >release.
> >> >
> >> >Thanks,
> >>  >Oleg.
> >>
> >>-------------------------------------------------------------------------
> >>-----
> >>  WhatsUp  Gold - Download Free Network Management
> >>  Software
> >> The most intuitive,  comprehensive, and  cost-effective
> >> network
> >> management toolset  available  today.  Delivers
> >> lowest initial
> >>  acquisition cost and overall TCO of any
> >> competing   solution.
> >> http://p.sf.net/sfu/whatsupgold-sd
> >>  _______________________________________________
> >>  mod-security-developers  mailing list
> >>
> >>mod...@li...<mailto:mod-security-develop
> >>er...@li...>
> >> https://lists.sourceforge.net/lists/listinfo/mod-security-developers
> >>  ModSecurity  Services from Trustwave's SpiderLabs:
> >> https://www.trustwave.com/spiderLabs.php
> >>
> >>
> >>-------------------------------------------------------------------------
> >>-----
> >>  WhatsUp Gold - Download Free Network Management Software
> >> The most  intuitive, comprehensive, and cost-effective
> >> network
> >>  management toolset available today.  Delivers lowest
> >>  initial
> >> acquisition cost and overall TCO of any  competing
> >> solution.
> >> http://p.sf.net/sfu/whatsupgold-sd
> >>  _______________________________________________
> >>  mod-security-developers mailing list
> >>
> >>mod...@li...<mailto:mod-security-develop
> >>er...@li...>
> >> https://lists.sourceforge.net/lists/listinfo/mod-security-developers
> >>  ModSecurity Services from Trustwave's SpiderLabs:
> >> https://www.trustwave.com/spiderLabs.php
> >>
> >>
> >>
> >>  ________________________________
> >> 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.
> >>
> >>
> >
> 
> 
> 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.
> 
> 

Re: [Mod-security-developers] CRS DoS protection & x-forwarded-for header

[Ryan B. <RBa...@tr...>]

Good point about IPv6.  Looks like we could still do this using the same #
of SecRules and just not using an IP regex like this -

SecRule REQUEST_HEADERS:User-Agent "^(.*)$"
"phase:1,t:none,pass,nolog,t:sha1,t:hexEncode,setvar:tx.ua_hash=%{matched_v
ar}"
SecRule REQUEST_HEADERS:x-forwarded-for "^(.*?),?.*$"
"phase:1,t:none,pass,nolog,setvar:tx.real_ip=%{matched_var}"

SecRule &TX:REAL_IP "@eq 0"
"phase:1,t:none,pass,nolog,initcol:global=global,initcol:ip=%{remote_addr}_
%{tx.ua_hash},,setvar:tx.real_ip=%{remote_addr}"
SecRule &TX:REAL_IP "!@eq 0"
"phase:1,t:none,pass,nolog,initcol:global=global,initcol:ip=%{tx.real_ip}_%
{tx.ua_hash}"



--
Ryan



On 5/6/11 1:16 PM, "Oleg Gryb" <ole...@ya...> wrote:

>Ryan,
>
>Thanks for the update. It might have problems with IPv6 though. Here are
>my rules: they search for ',' and disregard the IP structure:
>
>
>SecRule REQUEST_HEADERS:User-Agent "^(.*)$"
>"phase:1,t:none,pass,nolog,t:sha1,t:hexEncode,setvar:tx.ua_hash=%{matched_
>var}"
>SecRule REQUEST_HEADERS:x-forwarded-for "^(.*)$"
>"phase:1,t:none,pass,nolog,setvar:tx.real_ip=%{matched_var}"
>SecRule TX:REAL_IP "^(.*?),.*$"
>"phase:1,t:none,pass,nolog,capture,setvar:tx.real_ip=%{TX.1}"
>
>SecRule &TX:REAL_IP "@eq 0"
>"phase:1,t:none,pass,nolog,initcol:global=global,initcol:ip=%{remote_addr}
>_%{tx.ua_hash},,setvar:tx.real_ip=%{remote_addr}"
>SecRule &TX:REAL_IP "!@eq 0"
>"phase:1,t:none,pass,nolog,initcol:global=global,initcol:ip=%{tx.real_ip}_
>%{tx.ua_hash}"
>
>Thanks,
>Oleg.
>
>--- On Thu, 5/5/11, Ryan Barnett <RBa...@tr...> wrote:
>
>> From: Ryan Barnett <RBa...@tr...>
>> Subject: Re: [Mod-security-developers] CRS DoS protection &
>>x-forwarded-for header
>> To: "Oleg Gryb" <ol...@gr...>,
>>"mod...@li..."
>><mod...@li...>
>> Cc: "owa...@li..."
>><owa...@li...>
>> Date: Thursday, May 5, 2011, 10:46 AM
>> FYI - updated the CRS 10 config file
>> to add in this logic and uploaded it to SVN -
>>
>>http://mod-security.svn.sourceforge.net/viewvc/mod-security/crs/trunk/mod
>>security_crs_10_config.conf.example?revision=1772
>>
>> #
>> # -=[ 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_ha
>>sh=%{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=%
>>{tx.real_ip}_%{tx.ua_hash}"
>> SecRule &TX:REAL_IP "@eq 0"
>>
>>"phase:1,id:'981218',t:none,pass,nolog,initcol:global=global,initcol:ip=%
>>{remote_addr}_%{tx.ua_hash}"
>>
>> The new rules will grab the first IP address listed in an
>> X-Forwared-For header and use that for the IP collection
>> key.  If X-Forwarded-For is not present, then it will
>> use REMOTE_ADDR.
>>
>> Thanks for the suggestion!
>>
>> -Ryan
>>
>>
>> On 4/28/11 8:19 PM, "Oleg Gryb"
>><ole...@ya...<mailto:ole...@ya...>>
>> wrote:
>>
>> I've just realized that there might be a problem with
>> relying on that header: if
>> an attacker intentionally sends different random IPs in
>> there, DoS protection
>> can be efficiently by-passed. In my case it should not
>> happen, because an LB is
>> the one who adds the header, but in general we should warn
>> engineers about the
>> possible exploit.
>>
>>
>> Actually, even in LB case: if a request has already had the
>> header, LB will
>> create a new one with the existing value appended to the
>> client IP:
>>
>> x-forwarded-for: real-client-ip,
>> whatever-client-sent-to-LB
>>
>> It means that we would need to rely on the the first IP in
>> the list, everything
>> else should be considered as untrusted.
>>
>> Thanks,
>> Oleg.
>>
>>
>> ----- Original Message ----
>> From: Ryan Barnett
>><RBa...@tr...<mailto:RBa...@tr...>>
>> To: Oleg Gryb <ol...@gr...<mailto:ol...@gr...>>;
>>
>>"mod...@li...<mailto:mod-security-develo
>>pe...@li...>"
>>
>><mod...@li...<mailto:mod-security-develo
>>pe...@li...>>
>> Cc:
>>"owa...@li...<mailto:owasp-modsecurity
>>-co...@li...>"
>>
>><owa...@li...<mailto:owasp-modsecurity
>>-co...@li...>>
>> Sent: Thu, April 28, 2011 4:41:14 PM
>> Subject: Re: [Mod-security-developers] CRS DoS protection
>> & x-forwarded-for
>> header
>> Thanks for the updates Oleg!  This will certainly be a
>> useful update  to
>> not only the DoS rules buy any rules that will be based on
>> the client  IP.
>> I will actually go back to check other uses of REMOTE_ADDR
>> and see if  we
>> can swap it for tx.real_ip instead.
>> I will add this to the CRS  v2.2.0 that I am working
>> on.
>> For future reference - here is the OWASP CRS
>> mail-list -
>> https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
>> --
>> Ryan  Barnett
>> Senior Security Researcher
>> Trustwave -  SpiderLabs
>> On 4/28/11 7:32 PM, "Oleg Gryb"
>><ole...@ya...<mailto:ole...@ya...>>
>> wrote:
>> >I'm not sure if I can discuss CRS rules here. If not,
>> please  let me know
>> >what
>> >the right place is. I want to suggest an
>> improvement to DoS protection in
>> >CRS
>> >2.1.2. The problem is that  enterprise
>> applications usually run behind
>> >load
>> >balancers, so  relying on remote_addr doesn't make
>> too much sense, because
>> >you'll
>> >always have an LB's IP in there.
>> >
>> >
>> >My improved  rules (attached)  check for
>> x-forwarded-for header and if
>> >it's
>> >present, this IP will be used to initialize IP
>> collection. If it's  not
>> >then the
>> >old logic will be used.
>> >
>> >It would be  great if we can include this
>> improvement to the next  CRS
>> >release.
>> >
>> >Thanks,
>> >Oleg.
>>
>>-------------------------------------------------------------------------
>>-----
>> WhatsUp  Gold - Download Free Network Management
>> Software
>> The most intuitive,  comprehensive, and cost-effective
>> network
>> management toolset available  today.  Delivers
>> lowest initial
>> acquisition cost and overall TCO of any
>> competing  solution.
>> http://p.sf.net/sfu/whatsupgold-sd
>> _______________________________________________
>> mod-security-developers  mailing list
>>
>>mod...@li...<mailto:mod-security-develop
>>er...@li...>
>> https://lists.sourceforge.net/lists/listinfo/mod-security-developers
>> ModSecurity  Services from Trustwave's SpiderLabs:
>> https://www.trustwave.com/spiderLabs.php
>>
>>
>>-------------------------------------------------------------------------
>>-----
>> WhatsUp Gold - Download Free Network Management Software
>> The most intuitive, comprehensive, and cost-effective
>> network
>> management toolset available today.  Delivers lowest
>> initial
>> acquisition cost and overall TCO of any competing
>> solution.
>> http://p.sf.net/sfu/whatsupgold-sd
>> _______________________________________________
>> mod-security-developers mailing list
>>
>>mod...@li...<mailto:mod-security-develop
>>er...@li...>
>> https://lists.sourceforge.net/lists/listinfo/mod-security-developers
>> ModSecurity Services from Trustwave's SpiderLabs:
>> https://www.trustwave.com/spiderLabs.php
>>
>>
>>
>> ________________________________
>> 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.
>>
>>
>


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.

Re: [Mod-security-developers] CRS DoS protection & x-forwarded-for header

[Oleg G. <ole...@ya...>]

Ryan,

Thanks for the update. It might have problems with IPv6 though. Here are my rules: they search for ',' and disregard the IP structure:


SecRule REQUEST_HEADERS:User-Agent "^(.*)$" "phase:1,t:none,pass,nolog,t:sha1,t:hexEncode,setvar:tx.ua_hash=%{matched_var}"
SecRule REQUEST_HEADERS:x-forwarded-for "^(.*)$" "phase:1,t:none,pass,nolog,setvar:tx.real_ip=%{matched_var}"
SecRule TX:REAL_IP "^(.*?),.*$" "phase:1,t:none,pass,nolog,capture,setvar:tx.real_ip=%{TX.1}"

SecRule &TX:REAL_IP "@eq 0"  "phase:1,t:none,pass,nolog,initcol:global=global,initcol:ip=%{remote_addr}_%{tx.ua_hash},,setvar:tx.real_ip=%{remote_addr}"
SecRule &TX:REAL_IP "!@eq 0" "phase:1,t:none,pass,nolog,initcol:global=global,initcol:ip=%{tx.real_ip}_%{tx.ua_hash}"

Thanks,
Oleg.

--- On Thu, 5/5/11, Ryan Barnett <RBa...@tr...> wrote:

> From: Ryan Barnett <RBa...@tr...>
> Subject: Re: [Mod-security-developers] CRS DoS protection & x-forwarded-for header
> To: "Oleg Gryb" <ol...@gr...>, "mod...@li..." <mod...@li...>
> Cc: "owa...@li..." <owa...@li...>
> Date: Thursday, May 5, 2011, 10:46 AM
> FYI - updated the CRS 10 config file
> to add in this logic and uploaded it to SVN -
> http://mod-security.svn.sourceforge.net/viewvc/mod-security/crs/trunk/modsecurity_crs_10_config.conf.example?revision=1772
> 
> #
> # -=[ 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=%{tx.real_ip}_%{tx.ua_hash}"
> SecRule &TX:REAL_IP "@eq 0" 
> "phase:1,id:'981218',t:none,pass,nolog,initcol:global=global,initcol:ip=%{remote_addr}_%{tx.ua_hash}"
> 
> The new rules will grab the first IP address listed in an
> X-Forwared-For header and use that for the IP collection
> key.  If X-Forwarded-For is not present, then it will
> use REMOTE_ADDR.
> 
> Thanks for the suggestion!
> 
> -Ryan
> 
> 
> On 4/28/11 8:19 PM, "Oleg Gryb" <ole...@ya...<mailto:ole...@ya...>>
> wrote:
> 
> I've just realized that there might be a problem with
> relying on that header: if
> an attacker intentionally sends different random IPs in
> there, DoS protection
> can be efficiently by-passed. In my case it should not
> happen, because an LB is
> the one who adds the header, but in general we should warn
> engineers about the
> possible exploit.
> 
> 
> Actually, even in LB case: if a request has already had the
> header, LB will
> create a new one with the existing value appended to the
> client IP:
> 
> x-forwarded-for: real-client-ip,
> whatever-client-sent-to-LB
> 
> It means that we would need to rely on the the first IP in
> the list, everything
> else should be considered as untrusted.
> 
> Thanks,
> Oleg.
> 
> 
> ----- Original Message ----
> From: Ryan Barnett <RBa...@tr...<mailto:RBa...@tr...>>
> To: Oleg Gryb <ol...@gr...<mailto:ol...@gr...>>;
> "mod...@li...<mailto:mod...@li...>"
> <mod...@li...<mailto:mod...@li...>>
> Cc: "owa...@li...<mailto:owa...@li...>"
> <owa...@li...<mailto:owa...@li...>>
> Sent: Thu, April 28, 2011 4:41:14 PM
> Subject: Re: [Mod-security-developers] CRS DoS protection
> & x-forwarded-for
> header
> Thanks for the updates Oleg!  This will certainly be a
> useful update  to
> not only the DoS rules buy any rules that will be based on
> the client  IP.
> I will actually go back to check other uses of REMOTE_ADDR
> and see if  we
> can swap it for tx.real_ip instead.
> I will add this to the CRS  v2.2.0 that I am working
> on.
> For future reference - here is the OWASP CRS 
> mail-list -
> https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
> --
> Ryan  Barnett
> Senior Security Researcher
> Trustwave -  SpiderLabs
> On 4/28/11 7:32 PM, "Oleg Gryb" <ole...@ya...<mailto:ole...@ya...>> 
> wrote:
> >I'm not sure if I can discuss CRS rules here. If not,
> please  let me know
> >what
> >the right place is. I want to suggest an 
> improvement to DoS protection in
> >CRS
> >2.1.2. The problem is that  enterprise
> applications usually run behind
> >load
> >balancers, so  relying on remote_addr doesn't make
> too much sense, because
> >you'll
> >always have an LB's IP in there.
> >
> >
> >My improved  rules (attached)  check for
> x-forwarded-for header and if
> >it's
> >present, this IP will be used to initialize IP
> collection. If it's  not
> >then the
> >old logic will be used.
> >
> >It would be  great if we can include this
> improvement to the next  CRS
> >release.
> >
> >Thanks,
> >Oleg.
> ------------------------------------------------------------------------------
> WhatsUp  Gold - Download Free Network Management
> Software
> The most intuitive,  comprehensive, and cost-effective
> network
> management toolset available  today.  Delivers
> lowest initial
> acquisition cost and overall TCO of any 
> competing  solution.
> http://p.sf.net/sfu/whatsupgold-sd
> _______________________________________________
> mod-security-developers  mailing list
> mod...@li...<mailto:mod...@li...>
> https://lists.sourceforge.net/lists/listinfo/mod-security-developers
> ModSecurity  Services from Trustwave's SpiderLabs:
> https://www.trustwave.com/spiderLabs.php
> 
> ------------------------------------------------------------------------------
> WhatsUp Gold - Download Free Network Management Software
> The most intuitive, comprehensive, and cost-effective
> network
> management toolset available today.  Delivers lowest
> initial
> acquisition cost and overall TCO of any competing
> solution.
> http://p.sf.net/sfu/whatsupgold-sd
> _______________________________________________
> mod-security-developers mailing list
> mod...@li...<mailto:mod...@li...>
> https://lists.sourceforge.net/lists/listinfo/mod-security-developers
> ModSecurity Services from Trustwave's SpiderLabs:
> https://www.trustwave.com/spiderLabs.php
> 
> 
> 
> ________________________________
> 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.
> 
> 

Re: [Mod-security-developers] CRS DoS protection & x-forwarded-for header

[Ryan B. <RBa...@tr...>]

FYI - updated the CRS 10 config file to add in this logic and uploaded it to SVN -
http://mod-security.svn.sourceforge.net/viewvc/mod-security/crs/trunk/modsecurity_crs_10_config.conf.example?revision=1772

#
# -=[ 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=%{tx.real_ip}_%{tx.ua_hash}"
SecRule &TX:REAL_IP "@eq 0"  "phase:1,id:'981218',t:none,pass,nolog,initcol:global=global,initcol:ip=%{remote_addr}_%{tx.ua_hash}"

The new rules will grab the first IP address listed in an X-Forwared-For header and use that for the IP collection key.  If X-Forwarded-For is not present, then it will use REMOTE_ADDR.

Thanks for the suggestion!

-Ryan


On 4/28/11 8:19 PM, "Oleg Gryb" <ole...@ya...<mailto:ole...@ya...>> wrote:

I've just realized that there might be a problem with relying on that header: if
an attacker intentionally sends different random IPs in there, DoS protection
can be efficiently by-passed. In my case it should not happen, because an LB is
the one who adds the header, but in general we should warn engineers about the
possible exploit.


Actually, even in LB case: if a request has already had the header, LB will
create a new one with the existing value appended to the client IP:

x-forwarded-for: real-client-ip, whatever-client-sent-to-LB

It means that we would need to rely on the the first IP in the list, everything
else should be considered as untrusted.

Thanks,
Oleg.


----- Original Message ----
From: Ryan Barnett <RBa...@tr...<mailto:RBa...@tr...>>
To: Oleg Gryb <ol...@gr...<mailto:ol...@gr...>>; "mod...@li...<mailto:mod...@li...>"
<mod...@li...<mailto:mod...@li...>>
Cc: "owa...@li...<mailto:owa...@li...>"
<owa...@li...<mailto:owa...@li...>>
Sent: Thu, April 28, 2011 4:41:14 PM
Subject: Re: [Mod-security-developers] CRS DoS protection & x-forwarded-for
header
Thanks for the updates Oleg!  This will certainly be a useful update  to
not only the DoS rules buy any rules that will be based on the client  IP.
I will actually go back to check other uses of REMOTE_ADDR and see if  we
can swap it for tx.real_ip instead.
I will add this to the CRS  v2.2.0 that I am working on.
For future reference - here is the OWASP CRS  mail-list -
https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
--
Ryan  Barnett
Senior Security Researcher
Trustwave -  SpiderLabs
On 4/28/11 7:32 PM, "Oleg Gryb" <ole...@ya...<mailto:ole...@ya...>>  wrote:
>I'm not sure if I can discuss CRS rules here. If not, please  let me know
>what
>the right place is. I want to suggest an  improvement to DoS protection in
>CRS
>2.1.2. The problem is that  enterprise applications usually run behind
>load
>balancers, so  relying on remote_addr doesn't make too much sense, because
>you'll
>always have an LB's IP in there.
>
>
>My improved  rules (attached)  check for x-forwarded-for header and if
>it's
>present, this IP will be used to initialize IP collection. If it's  not
>then the
>old logic will be used.
>
>It would be  great if we can include this improvement to the next  CRS
>release.
>
>Thanks,
>Oleg.
------------------------------------------------------------------------------
WhatsUp  Gold - Download Free Network Management Software
The most intuitive,  comprehensive, and cost-effective network
management toolset available  today.  Delivers lowest initial
acquisition cost and overall TCO of any  competing  solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
mod-security-developers  mailing list
mod...@li...<mailto:mod...@li...>
https://lists.sourceforge.net/lists/listinfo/mod-security-developers
ModSecurity  Services from Trustwave's SpiderLabs:
https://www.trustwave.com/spiderLabs.php

------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today.  Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
mod-security-developers mailing list
mod...@li...<mailto:mod...@li...>
https://lists.sourceforge.net/lists/listinfo/mod-security-developers
ModSecurity Services from Trustwave's SpiderLabs:
https://www.trustwave.com/spiderLabs.php



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

[Mod-security-developers] [JIRA] Resolved: (MODSEC-241) Build issues with 2.6.x branch

[Breno S. P. (JIRA) <no...@mo...>]

     [ https://www.modsecurity.org/tracker/browse/MODSEC-241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Breno Silva Pinto resolved MODSEC-241.
--------------------------------------

    Resolution: Fixed

> Build issues with 2.6.x branch
> ------------------------------
>
>                 Key: MODSEC-241
>                 URL: https://www.modsecurity.org/tracker/browse/MODSEC-241
>             Project: ModSecurity
>          Issue Type: Bug
>      Security Level: Normal
>          Components: Build System
>    Affects Versions: 2.6.0
>         Environment: Ubuntu 10.10 x86_64
>            Reporter: Brian Rectanus
>            Assignee: Breno Silva Pinto
>             Fix For: 2.6.0
>
>
> 1) "make clean" does not clean up properly
>   - *.slo files are still there
>   - make test/test-regression files are not cleaned
> 2) Warnings:
> mod_security2.c: In function 'hook_request_late':
> mod_security2.c:862: warning: format '%d' expects type 'int', but argument 3 has type 'apr_size_t'
> libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -I/usr/include/apache2 -I/usr/include/apr-1.0 -I/usr/include/apr-1.0 -I/usr/include/libxml2 -g -O2 -MT mod_security2_la-mod_security2.lo -MD -MP -MF .deps/mod_security2_la-mod_security2.Tpo -c mod_security2.c -o mod_security2_la-mod_security2.o >/dev/null 2>&1
> --
> apache2_io.c: In function 'inject_content_to_of_brigade':
> apache2_io.c:508: warning: format '%d' expects type 'int', but argument 4 has type 'apr_size_t'
> libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -I/usr/include/apache2 -I/usr/include/apr-1.0 -I/usr/include/apr-1.0 -I/usr/include/libxml2 -g -O2 -MT mod_security2_la-apache2_io.lo -MD -MP -MF .deps/mod_security2_la-apache2_io.Tpo -c apache2_io.c -o mod_security2_la-apache2_io.o >/dev/null 2>&1
> --
> msc_reqbody.c: In function 'modsecurity_request_body_to_stream':
> msc_reqbody.c:415: warning: format '%u' expects type 'unsigned int', but argument 3 has type 'apr_size_t'
> libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -I/usr/include/apache2 -I/usr/include/apr-1.0 -I/usr/include/apr-1.0 -I/usr/include/libxml2 -g -O2 -MT mod_security2_la-msc_reqbody.lo -MD -MP -MF .deps/mod_security2_la-msc_reqbody.Tpo -c msc_reqbody.c -o mod_security2_la-msc_reqbody.o >/dev/null 2>&1
> 3) "make test" fails to build:
> msc_test-re_operators.o: In function `msre_op_rsub_execute':
> /work/modsecurity/tests/../apache2/re_operators.c:407: undefined reference to `ap_regexec'
> /work/modsecurity/tests/../apache2/re_operators.c:421: undefined reference to `ap_regexec'
> /work/modsecurity/tests/../apache2/re_operators.c:375: undefined reference to `ap_pregcomp'
> /work/modsecurity/tests/../apache2/re_operators.c:373: undefined reference to `ap_pregcomp'
> msc_test-re_operators.o: In function `msre_op_rsub_param_init':
> /work/modsecurity/tests/../apache2/re_operators.c:315: undefined reference to `ap_pregcomp'
> 4) "make test-regression" fails (may send a patch later if time).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://www.modsecurity.org/tracker/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Mod-security-developers] [PATCH 5/5] build-sys: avoid sub-shell for recursion.

[Diego E. P. <fla...@gm...>]

---
 Makefile.am |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

[Mod-security-developers] [PATCH 3/5] build-sys: avoid using different LDFLAGS for different OSes.

[Diego E. P. <fla...@gm...>]

This also allows dropping a number of boring tests from the configure
script.
---
 apache2/Makefile.am |   44 -----------------------------------
 configure.ac        |   63 ---------------------------------------------------
 2 files changed, 0 insertions(+), 107 deletions(-)

[Mod-security-developers] [PATCH 4/5] build-sys: handle SUBDIRS in a more automake-conformant way

[Diego E. P. <fla...@gm...>]

Instead of doing the conditionals within the ./configure script, do them on
Makefile.am, this way make dist will always recurse into the directories
even if they are disabled.

Drop the docs options since the docs/ directory does not even exists.
---
 Makefile.am  |   21 ++++++++++++++++++++-
 configure.ac |   47 ++---------------------------------------------
 2 files changed, 22 insertions(+), 46 deletions(-)

[Mod-security-developers] [PATCH 2/5] build-sys: avoid using hooks to handle Apache modules.

[Diego E. P. <fla...@gm...>]

Set the installation directory as library class instead of moving it, and
use -shared to ensure that the static library is never built.
---
 apache2/Makefile.am |   28 ++++++++++------------------
 ext/Makefile.am     |   14 +++-----------
 2 files changed, 13 insertions(+), 29 deletions(-)

[Mod-security-developers] [PATCH 1/5] build-sys: declare the name of the project to follow the tarball released.

[Diego E. P. <fla...@gm...>]

This allows using make dist and generate similarly named tarballs.

Change version to 2.6.0-rc3 since rc2 was released already.
---
 configure.ac |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

[Mod-security-developers] Two more files shouldn't be in svn

[Diego E. P. <fla...@gm...>]

build/install-sh
modsecurity_config_auto.h.in

The former is installed by automake, the latter generated by autoheader.

-- 
Diego Elio Pettenò — Flameeyes
http://blog.flameeyes.eu/

[Mod-security-developers] Making tarballs

[Diego E. P. <fla...@gm...>]

Hi all,

I've noticed that the tarballs for ModSecurity are currently prepared
manually, since they tend to vary a lot one between the other.

For common autotools project, the proper way to build the package is
using "make dist"; this does not currently work on ModSecurity because a
number of files are missing.

I suggest, if you want to proceed on that note, that you start by
listing the header files together with the source files in the _SOURCES
variables (even though _HEADERS exists, that's supposed to be used only
for installed ones, all the others are fine with _SOURCES), and the
documentation files into the doc_DATA variable (which also installs
them, which is good).

The idea is for each file that needs to be shipped to be listed
somewhere in the Makefile.am files.

-- 
Diego Elio Pettenò — Flameeyes
http://blog.flameeyes.eu/

[Mod-security-developers] ModSecurity 2.6.0-rc2 is available

[Breno S. <bre...@gm...>]

The ModSecurity Development Team is pleased to announce the availability of
ModSecurity 2.6.0-rc2 Release.
This release includes some small improvements and bug fixes, please see the
release notes included into
CHANGES<http://mod-security.svn.sourceforge.net/viewvc/mod-security/m2/tags/2.6.0-rc2/CHANGES>file.

We are specially looking for users to test ModSecurity under AIX and HPUX
systems.
For known problems and more information about bug fixes, please see the
online ModSecurity Jira.
This is a release candidate version so the stability should be good. Please
report any bug to
mod...@li...<http://lists.sourceforge.net/lists/listinfo/mod-security-developers>
.

Thanks

Breno Silva

Re: [Mod-security-developers] CRS DoS protection & x-forwarded-for header

[Oleg G. <ole...@ya...>]

I've just realized that there might be a problem with relying on that header: if 
an attacker intentionally sends different random IPs in there, DoS protection 
can be efficiently by-passed. In my case it should not happen, because an LB is 
the one who adds the header, but in general we should warn engineers about the 
possible exploit.


Actually, even in LB case: if a request has already had the header, LB will 
create a new one with the existing value appended to the client IP:

x-forwarded-for: real-client-ip, whatever-client-sent-to-LB

It means that we would need to rely on the the first IP in the list, everything 
else should be considered as untrusted.

Thanks,
Oleg.


----- Original Message ----
> From: Ryan Barnett <RBa...@tr...>
> To: Oleg Gryb <ol...@gr...>; "mod...@li..." 
><mod...@li...>
> Cc: "owa...@li..." 
><owa...@li...>
> Sent: Thu, April 28, 2011 4:41:14 PM
> Subject: Re: [Mod-security-developers] CRS DoS protection & x-forwarded-for 
>header
> 
> Thanks for the updates Oleg!  This will certainly be a useful update  to
> not only the DoS rules buy any rules that will be based on the client  IP.
> I will actually go back to check other uses of REMOTE_ADDR and see if  we
> can swap it for tx.real_ip instead.
> 
> I will add this to the CRS  v2.2.0 that I am working on.
> 
> For future reference - here is the OWASP CRS  mail-list -
> 
> https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
> 
> --
> Ryan  Barnett
> Senior Security Researcher
> Trustwave -  SpiderLabs
> 
> 
> 
> 
> On 4/28/11 7:32 PM, "Oleg Gryb" <ole...@ya...>  wrote:
> 
> >I'm not sure if I can discuss CRS rules here. If not, please  let me know
> >what 
> >the right place is. I want to suggest an  improvement to DoS protection in
> >CRS 
> >2.1.2. The problem is that  enterprise applications usually run behind
> >load 
> >balancers, so  relying on remote_addr doesn't make too much sense, because
> >you'll 
> >always have an LB's IP in there.
> >
> >
> >My improved  rules (attached)  check for x-forwarded-for header and if
> >it's 
> >present, this IP will be used to initialize IP collection. If it's  not
> >then the 
> >old logic will be used.
> >
> >It would be  great if we can include this improvement to the next  CRS
> >release.
> >
> >Thanks,
> >Oleg.
> 
> 
> 
> ------------------------------------------------------------------------------
> WhatsUp  Gold - Download Free Network Management Software
> The most intuitive,  comprehensive, and cost-effective network 
> management toolset available  today.  Delivers lowest initial 
> acquisition cost and overall TCO of any  competing  solution.
> http://p.sf.net/sfu/whatsupgold-sd
> _______________________________________________
> mod-security-developers  mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-developers
> ModSecurity  Services from Trustwave's SpiderLabs:
> https://www.trustwave.com/spiderLabs.php
> 

Re: [Mod-security-developers] CRS DoS protection & x-forwarded-for header

[Ryan B. <RBa...@tr...>]

Thanks for the updates Oleg!  This will certainly be a useful update to
not only the DoS rules buy any rules that will be based on the client IP.
I will actually go back to check other uses of REMOTE_ADDR and see if we
can swap it for tx.real_ip instead.

I will add this to the CRS v2.2.0 that I am working on.

For future reference - here is the OWASP CRS mail-list -

https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set

--
Ryan Barnett
Senior Security Researcher
Trustwave - SpiderLabs




On 4/28/11 7:32 PM, "Oleg Gryb" <ole...@ya...> wrote:

>I'm not sure if I can discuss CRS rules here. If not, please let me know
>what 
>the right place is. I want to suggest an improvement to DoS protection in
>CRS 
>2.1.2. The problem is that enterprise applications usually run behind
>load 
>balancers, so relying on remote_addr doesn't make too much sense, because
>you'll 
>always have an LB's IP in there.
>
>
>My improved rules (attached)  check for x-forwarded-for header and if
>it's 
>present, this IP will be used to initialize IP collection. If it's not
>then the 
>old logic will be used.
>
>It would be great if we can include this improvement to the next CRS
>release.
>
>Thanks,
>Oleg.

[Mod-security-developers] CRS DoS protection & x-forwarded-for header

[Oleg G. <ole...@ya...>]

I'm not sure if I can discuss CRS rules here. If not, please let me know what 
the right place is. I want to suggest an improvement to DoS protection in CRS 
2.1.2. The problem is that enterprise applications usually run behind load 
balancers, so relying on remote_addr doesn't make too much sense, because you'll 
always have an LB's IP in there. 


My improved rules (attached)  check for x-forwarded-for header and if it's 
present, this IP will be used to initialize IP collection. If it's not then the 
old logic will be used.

It would be great if we can include this improvement to the next CRS release.

Thanks,
Oleg.