mod-security-developers — Development discussion about mod_security

Re: [Mod-security-developers] Presentation and Mod Security for Java Advance

[Juan c. <jua...@ow...>]

Hello All

Just keeping you updated, I didn't make it to release WAF this week as
planned, yet this is how I am doing so far.

The Following variables are now available:
ARGS, ARGS_NAMES, QUERY_STRING, REMOTE_ADDR, REQUEST_BASENAME,
REQUEST_COOKIES, REQUEST_COOKIES_NAMES, REQUEST_FILENAME,
REQUEST_HEADERS_NAMES, REQUEST_HEADERS, REQUEST_METHOD, REQUEST_PROTOCOL,
REQUEST_URI, REQUEST_URI_RAW, RESPONSE_CONTENT_TYPE.

Operators

   - rx
   - eq
   - ge
   - gt
   - le
   - lt

Actions

   - msg
   - id
   - rev
   - severity
   - log
   - block
   - status
   - phase
   - t

Transformation Functions

   - lowercase
   - urlDecode
   - compressWhitespace
   - removeWhitespace
   - replaceNulls
   - removeNulls

Phases
    phase:1 - Request headers stage
    phase:2 - Request body stage
    phase:4 - Response body stage

Phase 3 is not available in Java, thus, Java 4 will be used as a fall back
to phase 3 actions.

Also support for individual Mode Security rules and external rule files is
implemented so you can embed Mod_Security rules in current XML configuration
file or "include" a whole rules file ot the WAF rule-set.

Missing parts are:
1. Response variables are still not available
2. Some actions are missing like "skip" and "chain"
3. Mod_Security format logging is still not implemented.

So as you can see we are almost there, yet, some work is still missing. Now
since I am in charge of OWASP Day Mexico 2011, I do not expect to have any
advance for the next 30 days until the event finishes on Nov 11. so my new
target date is Dec 25 I think it will be a good christmas gift.

Regards,
Juan Carlos

On Thu, Apr 21, 2011 at 10:24 PM, Juan calderon <jua...@ow...>wrote:

> Hello Guys
>
> My name is Juan Carlos Calderon I live in Mexico and I am creating the
> ModSecurity Java Port by including Level 1 Port Specification functionality
> to OWASP Java WAF. I want to give you a small update on my advance.
>
> The Following variables are now available:
> ARGS, ARGS_NAMES, QUERY_STRING, REMOTE_ADDR, REQUEST_BASENAME,
> REQUEST_COOKIES, REQUEST_COOKIES_NAMES, REQUEST_FILENAME,
> REQUEST_HEADERS_NAMES, REQUEST_HEADERS, REQUEST_METHOD, REQUEST_PROTOCOL,
> REQUEST_URI, REQUEST_URI_RAW, RESPONSE_CONTENT_TYPE.
>
> Phases
>     phase:1 - Request headers stage
>     phase:2 - Request body stage
>     phase:4 - Response body stage
>
> Phase 3 is not available in Java, thus, Java 4 will be used as a fall back
> to phase 3 actions.
>
> Little by little the port is taking shape.
>
> Regards,
> Juan Carlos Calderon
>

[Mod-security-developers] Availability of ModSecurity 2.6.2

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

The ModSecurity Development Team is pleased to announce the availability of
ModSecurity 2.6.2 Release.
The stability of this release is good and it includes some new features and
bug fixes, specially came from lessons learned in SQL Injection Challenge.
Please see the release notes included into CHANGES file. The download can be
done from ModSecurity website http://www.modsecurity.org/

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

Thanks

Breno

Re: [Mod-security-developers] How to filter non-english string

[Josh Amishav-Z. <ja...@gm...>]

On Thu, Sep 22, 2011 at 11:06 AM, kong lw <leg...@gm...> wrote:
> Hi,
>
> How can Modsecurity filter non-english string, for example: Japanese,
> Chinese?

Hi Kong,

Yes, Modsecurity can filter non-English character strings.

> How to write the filter rule, for example:
>
> SecRule RESPONSE_BODY "non-english string" "phase:4,t:none,deny"

For example, I created the following rule using Hebrew characters in UTF-8:

SecRule REQUEST_URI "גגג" phase:2,block,log,auditlog

Then sent the following request:
echo -e "GET /?גגג HTTP/1.0\n\n"|nc localhost 80

which resulted in:

[Thu Sep 22 11:14:19 2011] [error] [client 127.0.0.1] ModSecurity:
Access denied with code 500 (phase 2). Pattern match
"\\xd7\\x92\\xd7\\x92\\xd7\\x92" at REQUEST_URI. [file
"/opt/modsecurity/etc/rules.conf"] [line "5"] [hostname
"lab.localdomain"] [uri "/"] [unique_id "TnruW38AAQEAAFhZBC8AAAAF"]

--
 - Josh

[Mod-security-developers] How to filter non-english string

[kong lw <leg...@gm...>]

Hi,

How can Modsecurity filter non-english string, for example: Japanese,
Chinese?
How to write the filter rule, for example:

SecRule RESPONSE_BODY "non-english string" "phase:4,t:none,deny"

Thanks,
Lulu

[Mod-security-developers] Availability of ModSecurity 2.6.2-rc1

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

The ModSecurity Development Team is pleased to announce the availability of
ModSecurity 2.6.2-rc1 Release.
The stability of this release should be good and it includes some new
features and bug fixes, specially came from lessons learned in SQL Injection
Challenge.
Please see the release notes included into CHANGES file. The download can be
done from ModSecurity website http://www.modsecurity.org/

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

Thanks

Breno

[Mod-security-developers] mod-security 2.6.1 make test errors

[James B. M. <Jam...@hi...>]

Hello All,

I am building mod_security 2.6.1 on Solaris 10 and am receiving errors during "make test". As requested in the mod_security documentation I am posting the following snippet that shows the error:

----------------------------------------------------------------------------

Making all in tests
Making check in tools
Making check in apache2
Making check in tests
make  msc_test run-unit-tests.pl
/bin/bash ../libtool --tag=CC    --mode=link gcc -I/usr/local/httpd-2.2.20/include  -I/usr/local/src/httpd-2.2.20/srclib/apr/include   -I/usr/local/src/httpd-2.2.20/srclib/apr-util/include   -I/usr/local/include -I/usr/include/libxml2 -g -O2  -luuid -lsendfile -lrt -lsocket -lnsl  -lpthread      -lexpat  -o msc_test msc_test-msc_test.o  msc_test-re.o msc_test-re_operators.o  msc_test-re_actions.o msc_test-re_tfns.o  msc_test-re_variables.o msc_test-msc_logging.o  msc_test-msc_xml.o msc_test-msc_multipart.o  msc_test-modsecurity.o msc_test-msc_parsers.o  msc_test-msc_util.o msc_test-msc_pcre.o  msc_test-msc_unicode.o msc_test-persist_dbm.o  msc_test-msc_reqbody.o msc_test-msc_geo.o  msc_test-msc_gsb.o msc_test-acmp.o  msc_test-msc_lua.o msc_test-msc_release.o /usr/local/src/httpd-2.2.20/srclib/apr/libapr-1.la  /usr/local/src/httpd-2.2.20/srclib/apr-util/libaprutil-1.la  -L/usr/local/lib -R/usr/local/lib -lpcre -L/usr/lib -R/usr/lib -lxml2 -lz -lpthread -lm -lsocket -lnsl
libtool: link: gcc -I/usr/local/httpd-2.2.20/include -I/usr/local/src/httpd-2.2.20/srclib/apr/include -I/usr/local/src/httpd-2.2.20/srclib/apr-util/include -I/usr/local/include -I/usr/include/libxml2 -g -O2 -o .libs/msc_test msc_test-msc_test.o msc_test-re.o msc_test-re_operators.o msc_test-re_actions.o msc_test-re_tfns.o msc_test-re_variables.o msc_test-msc_logging.o msc_test-msc_xml.o msc_test-msc_multipart.o msc_test-modsecurity.o msc_test-msc_parsers.o msc_test-msc_util.o msc_test-msc_pcre.o msc_test-msc_unicode.o msc_test-persist_dbm.o msc_test-msc_reqbody.o msc_test-msc_geo.o msc_test-msc_gsb.o msc_test-acmp.o msc_test-msc_lua.o msc_test-msc_release.o  /usr/local/src/httpd-2.2.20/srclib/apr-util/.libs/libaprutil-1.so -lexpat /usr/local/src/httpd-2.2.20/srclib/apr/.libs/libapr-1.so -luuid -lsendfile -lrt -L/usr/local/lib /usr/local/lib/libpcre.so -L/usr/lib -lxml2 -lz -lpthread -lm -lsocket -lnsl -R/usr/local/httpd-2.2.20/lib -R/usr/local/lib -R/usr/lib
Undefined                       first referenced
symbol                             in file
ap_regexec                          msc_test-re_operators.o
ap_pregcomp                         msc_test-re_operators.o
ld: fatal: Symbol referencing errors. No output written to .libs/msc_test
collect2: ld returned 1 exit status
*** Error code 1
make: Fatal error: Command failed for target `msc_test'
Current working directory /opt/sfw/src/modsecurity-apache_2.6.1/tests
*** Error code 1
make: Fatal error: Command failed for target `check-am'
Current working directory /opt/sfw/src/modsecurity-apache_2.6.1/tests
*** Error code 1
The following command caused the error:
fail= failcom='exit 1'; \
for f in x $MAKEFLAGS; do \
  case $f in \
    *=* | --[!k]*);; \
    *k*) failcom='fail=yes';; \
  esac; \
done; \
dot_seen=no; \
target=`echo check-recursive | sed s/-recursive//`; \
list='tools apache2 tests'; for subdir in $list; do \
  echo "Making $target in $subdir"; \
  if test "$subdir" = "."; then \
    dot_seen=yes; \
    local_target="$target-am"; \
  else \
    local_target="$target"; \
  fi; \
  (CDPATH="${ZSH_VERSION+.}:" && cd $subdir && make  $local_target) \
  || eval $failcom; \
done; \
if test "$dot_seen" = "no"; then \
  make  "$target-am" || exit 1; \
fi; test -z "$fail"
make: Fatal error: Command failed for target `check-recursive'

----------------------------------------------------------------------------

my build script is as follows:

----------------------------------------------------------------------------

#!/usr/bin/bash
# hdrs_build_mod_security.sh - build the mod_security2.so module.

# Make sure we can get to gcc, but not cc. Set the path
# to find the gcc compiler in /usr/local/bin.

# Set the path to find the Solaris make in /usr/ccs/bin.

PATH=/usr/local/bin:/usr/sbin:/usr/bin:/usr/ccs/bin
export PATH

# Build mod_security outside the apache source tree as a DSO with Apache 2.
# You need to supply the path to the APR and APU config scripts inside Apache2.
# You also need to disable the mlogc option that we are not using.
cd /usr/local/src/modsecurity-apache_2.6.1
./configure --disable-mlogc \
            --with-apxs=/usr/local/httpd-2.2.20/bin/apxs \
            --with-apr=/usr/local/src/httpd-2.2.20/srclib/apr \
            --with-apu=/usr/local/src/httpd-2.2.20/srclib/apr-util
make &&
make test &&
make install

----------------------------------------------------------------------------

-James



IMPORTANT NOTICE REGARDING THIS ELECTRONIC MESSAGE:

This message is intended for the use of the person to whom it is addressed and may contain information that is privileged, confidential, and protected from disclosure under applicable law. If you are not the intended recipient, your use of this message for any purpose is strictly prohibited. If you have received this communication in error, please delete the message and notify the sender so that we may correct our records.

Re: [Mod-security-developers] How does it works (e.g. SecServerSignature)?

[Leon F. <leo...@go...>]

Hi Breno,

Am 11.08.2011 um 15:33 schrieb Breno Silva:
> 
> 
> We found the server signature using apache_get_server_version, pointing
> a pointer to this memory location and then change it.
> 
> Take a look in the change_server_signature() function.

okay. thanks for this hint. 

LF

Re: [Mod-security-developers] How does it works (e.g. SecServerSignature)?

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

Hi Leon,

We found the server signature using apache_get_server_version, pointing a
pointer to this memory location and then change it.

Take a look in the change_server_signature() function.

thanks

Breno

On Thu, Aug 11, 2011 at 5:37 AM, Leon Fauster <leo...@go...>wrote:

> Dear List,
>
> to understand the general handling of requests i want
> to ask how the following works.
>
> Lets say i have just this configuration
>
> <IfModule mod_security2.c>
>        SecServerSignature "httpd"
> </IfModule>
>
> The docs stated that using SecServerSignature means substitution in memory.
>
> How to interpret this:
>
>  Does this mapping happens only one time for each process fork?
>
>  Or does this happens for every client request?
>
> Thanks for clarification
>
> LF
>
>
>
>
> ------------------------------------------------------------------------------
> Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
> user administration capabilities and model configuration. Take
> the hassle out of deploying and managing Subversion and the
> tools developers use with it.
> http://p.sf.net/sfu/wandisco-dev2dev
> _______________________________________________
> 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] How does it works (e.g. SecServerSignature)?

[Leon F. <leo...@go...>]

Dear List,

to understand the general handling of requests i want 
to ask how the following works.

Lets say i have just this configuration 

<IfModule mod_security2.c>
	SecServerSignature "httpd"
</IfModule>

The docs stated that using SecServerSignature means substitution in memory. 

How to interpret this: 

 Does this mapping happens only one time for each process fork?  

 Or does this happens for every client request?

Thanks for clarification 

LF

[Mod-security-developers] can i ask a technological problem?thank you very much!

[ci ci <new...@gm...>]

I have a problem that the storage of rules in mod_security.
I debug the mod_security in linux with gdb.when i run the code to the
point(mod_security2.c:330),
i found that "msr->dcfg1 = (directory_config
*)ap_get_module_config(r->per_dir_config, &security2_module);"

(gdb)p *msr->dcfg1->ruleset->phase_request_headers

the result tell me there are 48 rules(may be more,because someone added the
rules) in the struct member of phase_request_headers.
my problem is that: how to do this?when did you divide the rules?in which
function?

My english is not well,and thank you for your help. i wish you can help me!

[Mod-security-developers] Warning in error.log about PCRE

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

I've got the following warnings in Apache's error file about PCRE mismatch. Should I be concerned? If I need to upgrade PCRE, lib, what is the correct *rpm for RedHat should be?


[Fri Jul 22 10:46:26 2011] [notice] ModSecurity for Apache/2.6.0 (http://www.mod
security.org/) configured.
[Fri Jul 22 10:46:26 2011] [notice] ModSecurity: APR compiled version="1.4.5"; l
oaded version="1.4.5"
[Fri Jul 22 10:46:26 2011] [notice] ModSecurity: PCRE compiled version="6.6"; lo
aded version="5.0 13-Sep-2004"
[Fri Jul 22 10:46:26 2011] [warn] ModSecurity: Loaded PCRE do not match with com
piled!
[Fri Jul 22 10:46:26 2011] [notice] ModSecurity: LIBXML compiled version="2.6.26

Re: [Mod-security-developers] [mod-security-users] Availability of ModSecurity 2.6.1 Release

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

Thanka Rainer,

I will take a look

Breno

On Tue, Jul 19, 2011 at 7:06 PM, Rainer Jung <rai...@ki...>wrote:

> Hi devs,
>
> 2.6.1 has small build problems. The module build Makefile in apache2
> does not use any of the PCRE_* vars when actually building the modules.
> So it will only work when PCRE is in the default system pathzs and will
> then use that PCRE.
>
> Possible patch:
>
> --- Makefile.in.kpdt_orig       2011-07-19 12:40:41.000000000 +0200
> +++ Makefile.in 2011-07-20 01:31:31.823349000 +0200
> @@ -306,41 +306,41 @@
>                            msc_geo.c msc_gsb.c msc_unicode.c acmp.c
> msc_lua.c msc_release.c
>
>  mod_security2_la_CFLAGS = @APXS_CFLAGS@ @APR_CFLAGS@ @APU_CFLAGS@ \
> -                          @LIBXML2_CFLAGS@ @LUA_CFLAGS@
> @MODSEC_EXTRA_CFLAGS@
> +                          @PCRE_CFLAGS@ @LIBXML2_CFLAGS@ @LUA_CFLAGS@
> @MODSEC_EXTRA_CFLAGS@
>
> -mod_security2_la_CPPFLAGS = @APR_CPPFLAGS@ @LIBXML2_CPPFLAGS@
> -mod_security2_la_LIBADD = @APR_LDADD@ @APU_LDADD@ @LIBXML2_LDADD@
> @LUA_LDADD@
> +mod_security2_la_CPPFLAGS = @APR_CPPFLAGS@ @PCRE_CPPFLAGS@
> @LIBXML2_CPPFLAGS@
> +mod_security2_la_LIBADD = @APR_LDADD@ @APU_LDADD@ @PCRE_LDADD@
> @LIBXML2_LDADD@ @LUA_LDADD@
>  @AIX_TRUE@mod_security2_la_LDFLAGS = -module -avoid-version \
>  @AIX_TRUE@                           @APR_LDFLAGS@ @APU_LDFLAGS@
> @APXS_LDFLAGS@ \
> -@AIX_TRUE@                           @LIBXML2_LDFLAGS@ @LUA_LDFLAGS@
> +@AIX_TRUE@                           @PCRE_LDFLAGS@ @LIBXML2_LDFLAGS@
> @LUA_LDFLAGS@
>
>  @FREEBSD_TRUE@mod_security2_la_LDFLAGS = -no-undefined -module
> -avoid-version \
>  @FREEBSD_TRUE@                           @APR_LDFLAGS@ @APU_LDFLAGS@
> @APXS_LDFLAGS@ \
> -@FREEBSD_TRUE@                           @LIBXML2_LDFLAGS@ @LUA_LDFLAGS@
> +@FREEBSD_TRUE@                           @PCRE_LDFLAGS@
> @LIBXML2_LDFLAGS@ @LUA_LDFLAGS@
>
>  @HPUX_TRUE@mod_security2_la_LDFLAGS = -module -avoid-version \
>  @HPUX_TRUE@                           @APR_LDFLAGS@ @APU_LDFLAGS@
> @APXS_LDFLAGS@ \
> -@HPUX_TRUE@                           @LIBXML2_LDFLAGS@ @LUA_LDFLAGS@
> +@HPUX_TRUE@                           @PCRE_LDFLAGS@ @LIBXML2_LDFLAGS@
> @LUA_LDFLAGS@
>
>  @LINUX_TRUE@mod_security2_la_LDFLAGS = -no-undefined -module
> -avoid-version \
>  @LINUX_TRUE@                           @APR_LDFLAGS@ @APU_LDFLAGS@
> @APXS_LDFLAGS@ \
> -@LINUX_TRUE@                           @LIBXML2_LDFLAGS@ @LUA_LDFLAGS@
> +@LINUX_TRUE@                           @PCRE_LDFLAGS@ @LIBXML2_LDFLAGS@
> @LUA_LDFLAGS@
>
>  @MACOSX_TRUE@mod_security2_la_LDFLAGS = -module -avoid-version \
>  @MACOSX_TRUE@                           @APR_LDFLAGS@ @APU_LDFLAGS@
> @APXS_LDFLAGS@ \
> -@MACOSX_TRUE@                           @LIBXML2_LDFLAGS@ @LUA_LDFLAGS@
> +@MACOSX_TRUE@                           @PCRE_LDFLAGS@
> @LIBXML2_LDFLAGS@ @LUA_LDFLAGS@
>
>  @NETBSD_TRUE@mod_security2_la_LDFLAGS = -no-undefined -module
> -avoid-version \
>  @NETBSD_TRUE@                           @APR_LDFLAGS@ @APU_LDFLAGS@
> @APXS_LDFLAGS@ \
> -@NETBSD_TRUE@                           @LIBXML2_LDFLAGS@ @LUA_LDFLAGS@
> +@NETBSD_TRUE@                           @PCRE_LDFLAGS@
> @LIBXML2_LDFLAGS@ @LUA_LDFLAGS@
>
>  @OPENBSD_TRUE@mod_security2_la_LDFLAGS = -no-undefined -module
> -avoid-version \
>  @OPENBSD_TRUE@                           @APR_LDFLAGS@ @APU_LDFLAGS@
> @APXS_LDFLAGS@ \
> -@OPENBSD_TRUE@                           @LIBXML2_LDFLAGS@ @LUA_LDFLAGS@
> +@OPENBSD_TRUE@                           @PCRE_LDFLAGS@
> @LIBXML2_LDFLAGS@ @LUA_LDFLAGS@
>
>  @SOLARIS_TRUE@mod_security2_la_LDFLAGS = -module -avoid-version \
>  @SOLARIS_TRUE@                           @APR_LDFLAGS@ @APU_LDFLAGS@
> @APXS_LDFLAGS@ \
> -@SOLARIS_TRUE@                           @LIBXML2_LDFLAGS@ @LUA_LDFLAGS@
> +@SOLARIS_TRUE@                           @PCRE_LDFLAGS@
> @LIBXML2_LDFLAGS@ @LUA_LDFLAGS@
>
>  all: modsecurity_config_auto.h
>        $(MAKE) $(AM_MAKEFLAGS) all-am
>
>
> Ânother thing: the -DMSC_TEST hint is a bit hidden. It would be nice, if
> "make test" would apply this automatically. I first ran into link
> failures for msc_test, and when checking the code that used the missing
> symbols, I saw the test against the MSC_TEST define, which I then also
> found in the doc file.
>
> Thanks for the good work!
>
> Rainer
>
>
> ------------------------------------------------------------------------------
> 10 Tips for Better Web Security
> Learn 10 ways to better secure your business today. Topics covered include:
> Web security, SSL, hacker attacks & Denial of Service (DoS), private keys,
> security Microsoft Exchange, secure Instant Messaging, and much more.
> http://www.accelacomm.com/jaw/sfnl/114/51426210/
> _______________________________________________
> 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] [mod-security-users] Availability of ModSecurity 2.6.1 Release

[Rainer J. <rai...@ki...>]

Hi devs,

2.6.1 has small build problems. The module build Makefile in apache2
does not use any of the PCRE_* vars when actually building the modules.
So it will only work when PCRE is in the default system pathzs and will
then use that PCRE.

Possible patch:

--- Makefile.in.kpdt_orig       2011-07-19 12:40:41.000000000 +0200
+++ Makefile.in 2011-07-20 01:31:31.823349000 +0200
@@ -306,41 +306,41 @@
                            msc_geo.c msc_gsb.c msc_unicode.c acmp.c
msc_lua.c msc_release.c

 mod_security2_la_CFLAGS = @APXS_CFLAGS@ @APR_CFLAGS@ @APU_CFLAGS@ \
-                          @LIBXML2_CFLAGS@ @LUA_CFLAGS@
@MODSEC_EXTRA_CFLAGS@
+                          @PCRE_CFLAGS@ @LIBXML2_CFLAGS@ @LUA_CFLAGS@
@MODSEC_EXTRA_CFLAGS@

-mod_security2_la_CPPFLAGS = @APR_CPPFLAGS@ @LIBXML2_CPPFLAGS@
-mod_security2_la_LIBADD = @APR_LDADD@ @APU_LDADD@ @LIBXML2_LDADD@
@LUA_LDADD@
+mod_security2_la_CPPFLAGS = @APR_CPPFLAGS@ @PCRE_CPPFLAGS@
@LIBXML2_CPPFLAGS@
+mod_security2_la_LIBADD = @APR_LDADD@ @APU_LDADD@ @PCRE_LDADD@
@LIBXML2_LDADD@ @LUA_LDADD@
 @AIX_TRUE@mod_security2_la_LDFLAGS = -module -avoid-version \
 @AIX_TRUE@                           @APR_LDFLAGS@ @APU_LDFLAGS@
@APXS_LDFLAGS@ \
-@AIX_TRUE@                           @LIBXML2_LDFLAGS@ @LUA_LDFLAGS@
+@AIX_TRUE@                           @PCRE_LDFLAGS@ @LIBXML2_LDFLAGS@
@LUA_LDFLAGS@

 @FREEBSD_TRUE@mod_security2_la_LDFLAGS = -no-undefined -module
-avoid-version \
 @FREEBSD_TRUE@                           @APR_LDFLAGS@ @APU_LDFLAGS@
@APXS_LDFLAGS@ \
-@FREEBSD_TRUE@                           @LIBXML2_LDFLAGS@ @LUA_LDFLAGS@
+@FREEBSD_TRUE@                           @PCRE_LDFLAGS@
@LIBXML2_LDFLAGS@ @LUA_LDFLAGS@

 @HPUX_TRUE@mod_security2_la_LDFLAGS = -module -avoid-version \
 @HPUX_TRUE@                           @APR_LDFLAGS@ @APU_LDFLAGS@
@APXS_LDFLAGS@ \
-@HPUX_TRUE@                           @LIBXML2_LDFLAGS@ @LUA_LDFLAGS@
+@HPUX_TRUE@                           @PCRE_LDFLAGS@ @LIBXML2_LDFLAGS@
@LUA_LDFLAGS@

 @LINUX_TRUE@mod_security2_la_LDFLAGS = -no-undefined -module
-avoid-version \
 @LINUX_TRUE@                           @APR_LDFLAGS@ @APU_LDFLAGS@
@APXS_LDFLAGS@ \
-@LINUX_TRUE@                           @LIBXML2_LDFLAGS@ @LUA_LDFLAGS@
+@LINUX_TRUE@                           @PCRE_LDFLAGS@ @LIBXML2_LDFLAGS@
@LUA_LDFLAGS@

 @MACOSX_TRUE@mod_security2_la_LDFLAGS = -module -avoid-version \
 @MACOSX_TRUE@                           @APR_LDFLAGS@ @APU_LDFLAGS@
@APXS_LDFLAGS@ \
-@MACOSX_TRUE@                           @LIBXML2_LDFLAGS@ @LUA_LDFLAGS@
+@MACOSX_TRUE@                           @PCRE_LDFLAGS@
@LIBXML2_LDFLAGS@ @LUA_LDFLAGS@

 @NETBSD_TRUE@mod_security2_la_LDFLAGS = -no-undefined -module
-avoid-version \
 @NETBSD_TRUE@                           @APR_LDFLAGS@ @APU_LDFLAGS@
@APXS_LDFLAGS@ \
-@NETBSD_TRUE@                           @LIBXML2_LDFLAGS@ @LUA_LDFLAGS@
+@NETBSD_TRUE@                           @PCRE_LDFLAGS@
@LIBXML2_LDFLAGS@ @LUA_LDFLAGS@

 @OPENBSD_TRUE@mod_security2_la_LDFLAGS = -no-undefined -module
-avoid-version \
 @OPENBSD_TRUE@                           @APR_LDFLAGS@ @APU_LDFLAGS@
@APXS_LDFLAGS@ \
-@OPENBSD_TRUE@                           @LIBXML2_LDFLAGS@ @LUA_LDFLAGS@
+@OPENBSD_TRUE@                           @PCRE_LDFLAGS@
@LIBXML2_LDFLAGS@ @LUA_LDFLAGS@

 @SOLARIS_TRUE@mod_security2_la_LDFLAGS = -module -avoid-version \
 @SOLARIS_TRUE@                           @APR_LDFLAGS@ @APU_LDFLAGS@
@APXS_LDFLAGS@ \
-@SOLARIS_TRUE@                           @LIBXML2_LDFLAGS@ @LUA_LDFLAGS@
+@SOLARIS_TRUE@                           @PCRE_LDFLAGS@
@LIBXML2_LDFLAGS@ @LUA_LDFLAGS@

 all: modsecurity_config_auto.h
        $(MAKE) $(AM_MAKEFLAGS) all-am


Ânother thing: the -DMSC_TEST hint is a bit hidden. It would be nice, if
"make test" would apply this automatically. I first ran into link
failures for msc_test, and when checking the code that used the missing
symbols, I saw the test against the MSC_TEST define, which I then also
found in the doc file.

Thanks for the good work!

Rainer

[Mod-security-developers] Availability of ModSecurity 2.6.1 Release

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

The ModSecurity Development Team is pleased to announce the availability of
ModSecurity 2.6.1 Release.
This release includes some new features and bug fixes from the first release
candidate and an update of reference manual, please see the release notes
included into CHANGES file.
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] sanitizeMatchedBytes question

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

Hey Jeff,

You can only sanitize headers and args. If you want to do this improvements
for modsecurity will be great! We can apply your patch! If you want to do
that please go to the modsecurity devel list and we can share information
about the source code.

thanks

Breno

On Mon, Jul 11, 2011 at 4:10 PM, Jeff Sundquist <jef...@gm...>wrote:

> Breno,
>
> Thanks for looking at this so fast.  Agree that RESPONSE_BODY isn't for everyone but in my case I do want to record and sanitize it.
>
> >From the doc I thought this would do the trick.  I'll look at changing the code ( or my requirements! ).
>
> Also, I want to do the REQUEST_BODY and from my read of the code I will hit the same issue.  Do you believe that it should work?  I see code in msc_logging.c for it but I'm not the offsets will ever get recorded.
>
> Thanks,
>
> Jeff
>
>
>
> > Hey Jeff,
> >
> > Looking at the code, since we are using part of the same code of
> > sanitzematched and it doesn't support RESPONSE_BODY variable you are seeing
> > that msg. The reason for that is it's not common people enable RESPONSE_BODY
> > to be logged in production env, because the log dir/file will increase a
> > lot.
> >
> > I will discuss internally if we will move to the direction to support
> > RESPONSE_BODY in sanitizematched action.
> >
> > Thanks
> >
> > Breno
>
>
>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> 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] sanitizeMatchedBytes question

[Jeff S. <jef...@gm...>]

Breno,

Thanks for looking at this so fast.  Agree that RESPONSE_BODY isn't
for everyone but in my case I do want to record and sanitize it.

>From the doc I thought this would do the trick.  I'll look at changing
the code ( or my requirements! ).

Also, I want to do the REQUEST_BODY and from my read of the code I
will hit the same issue.  Do you believe that it should work?  I see
code in msc_logging.c for it but I'm not the offsets will ever get
recorded.

Thanks,

Jeff



> Hey Jeff,
>
> Looking at the code, since we are using part of the same code of
> sanitzematched and it doesn't support RESPONSE_BODY variable you are seeing
> that msg. The reason for that is it's not common people enable RESPONSE_BODY
> to be logged in production env, because the log dir/file will increase a
> lot.
>
> I will discuss internally if we will move to the direction to support
> RESPONSE_BODY in sanitizematched action.
>
> Thanks
>
> Breno

Re: [Mod-security-developers] sanitizeMatchedBytes question

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

Hey Jeff,

Looking at the code, since we are using part of the same code of
sanitzematched and it doesn't support RESPONSE_BODY variable you are seeing
that msg. The reason for that is it's not common people enable RESPONSE_BODY
to be logged in production env, because the log dir/file will increase a
lot.

I will discuss internally if we will move to the direction to support
RESPONSE_BODY in sanitizematched action.

Thanks

Breno

On Mon, Jul 11, 2011 at 3:44 PM, Breno Silva <bre...@gm...> wrote:

> Hi Jeff,
>
> This seems to be a bug. I will take a look
>
> thanks
>
> Breno
>
> On Mon, Jul 11, 2011 at 3:34 PM, Jeff Sundquist <jef...@gm...>wrote:
>
>> I'm not able to get sanitizeMatchedBytes to work for RESPONSE_BODY and
>> want to confirm that this should actually work.
>>
>> I'm using the rule from the documentation:
>>
>> SecRule RESPONSE_BODY "@verifyCC \d{13,16}"
>> "phase:4,t:none,log,capture,block,msg:'Potential credit card number is
>> response body',sanitiseMatchedBytes:0/4"
>>
>> and I see the rule "fire" but it has all the credit card info intact.
>>
>> When I turn on debug I see this:
>>
>> sanitizeMatched: Don't know how to handle variable: RESPONSE_BODY
>>
>> and when I look at the code it doesn't look like there is any logic to
>> sanitize the response body in msc_logging.c.
>>
>> Before I go forward with trying to add this functionality I wanted to make
>> sure that I wasn't missing something obvious....
>>
>> Thanks,
>> Jeff
>>
>>
>>
>> ------------------------------------------------------------------------------
>> All of the data generated in your IT infrastructure is seriously valuable.
>> Why? It contains a definitive record of application performance, security
>> threats, fraudulent activity, and more. Splunk takes this data and makes
>> sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-d2d-c2
>> _______________________________________________
>> 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] sanitizeMatchedBytes question

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

Hi Jeff,

This seems to be a bug. I will take a look

thanks

Breno

On Mon, Jul 11, 2011 at 3:34 PM, Jeff Sundquist <jef...@gm...>wrote:

> I'm not able to get sanitizeMatchedBytes to work for RESPONSE_BODY and want
> to confirm that this should actually work.
>
> I'm using the rule from the documentation:
>
> SecRule RESPONSE_BODY "@verifyCC \d{13,16}"
> "phase:4,t:none,log,capture,block,msg:'Potential credit card number is
> response body',sanitiseMatchedBytes:0/4"
>
> and I see the rule "fire" but it has all the credit card info intact.
>
> When I turn on debug I see this:
>
> sanitizeMatched: Don't know how to handle variable: RESPONSE_BODY
>
> and when I look at the code it doesn't look like there is any logic to
> sanitize the response body in msc_logging.c.
>
> Before I go forward with trying to add this functionality I wanted to make
> sure that I wasn't missing something obvious....
>
> Thanks,
> Jeff
>
>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> 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] sanitizeMatchedBytes question

[Jeff S. <jef...@gm...>]

I'm not able to get sanitizeMatchedBytes to work for RESPONSE_BODY and want
to confirm that this should actually work.

I'm using the rule from the documentation:

SecRule RESPONSE_BODY "@verifyCC \d{13,16}"
"phase:4,t:none,log,capture,block,msg:'Potential credit card number is
response body',sanitiseMatchedBytes:0/4"

and I see the rule "fire" but it has all the credit card info intact.

When I turn on debug I see this:

sanitizeMatched: Don't know how to handle variable: RESPONSE_BODY

and when I look at the code it doesn't look like there is any logic to
sanitize the response body in msc_logging.c.

Before I go forward with trying to add this functionality I wanted to make
sure that I wasn't missing something obvious....

Thanks,
Jeff

Re: [Mod-security-developers] Limits of SecWriteStateLimit (was: Re: Advanced Slow DoS Mitigation)

[Christian F. <chr...@ti...>]

Hi Breno,

SecWriteStateLimit was like one week to late for real world use
when we came under attack by anonymous. It would have helped a big
deal and I think it is a very good defense mechanism against generic
DoS attack scripts. If I am able to set the limit as high as
150-250 then I am sure I will be free of collateral damage (at least
in our case).
The DDoS case asks for different tool though. Especially on servers
which accept big file uploads.

On Thu, Jul 07, 2011 at 09:31:46AM -0500, Breno Silva wrote:
> When you say "active connections"  if i understand well the term you are
> using ... it is a established  connections right ? But it is not necessary a
> simultaneous SERVER_BUSY threads.

Yes, I meant "established" on the tcp level. Some of them can be in 
SERVER_BUSY in Apache. (Sorry for being inexact in the previous message).

And from the other message:
> FYI.  I'm adding a small check in SecWriteStateLimit to only check for POST
> connections (2.6.1-stable)

How about the other methods? Don't a few of the less frequently used
methods like PUT enter the SERVER_BUSY state?

Best,

Christian

-- 
Everyone is a prisoner of his own experiences. 
No one can eliminate prejudices - just recognize them.
--- Edward R. Murrow

Re: [Mod-security-developers] Limits of SecWriteStateLimit (was: Re: Advanced Slow DoS Mitigation)

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

FYI.  I'm adding a small check in SecWriteStateLimit to only check for POST
connections (2.6.1-stable)

thanks

Breno

On Thu, Jul 7, 2011 at 9:31 AM, Breno Silva <bre...@gm...> wrote:

> Hi Christian,
>
> Did you try to SecWriteStateLimit ? I think we can use a value like 150-250
> and detect the attacks and maybe you will not see FPs.
>
> When you say "active connections"  if i understand well the term you are
> using ... it is a established  connections right ? But it is not necessary a
> simultaneous SERVER_BUSY threads.
>
> So don't think in SecWriteStateLimit as a counter for connections... but
> for simultaneous threads in that state. Also you can have active 200 threads
> .. but a few in SERVER_BUSY state.
>
> I recommend you test (if you didn't ) it with the range of value i said
> here.
>
> Thanks
>
> Breno
>
>
> On Thu, Jul 7, 2011 at 12:24 AM, Christian Folini <
> chr...@ti...> wrote:
>
>> Hi Ryan,
>>
>> Thank you for your extensive comments. I agree with almost all.
>> Let me just quickly say a few words about SecWriteStateLimit.
>>
>> On Wed, Jul 06, 2011 at 07:42:50AM -0500, Ryan Barnett wrote:
>> > Did you see that Breno recently added SecWriteStateLimit as well to help
>> > mitigate Slow POST Attacks?
>> >
>> http://sourceforge.net/apps/mediawiki/mod-security/index.php?title=Referenc
>> > e_Manual#SecWriteStateLimit
>>
>> I have seen it immediately when it came out and it is a must-have
>> feature. But it is limited to single IP attackers and I am
>> not really afraid of those.
>>
>> Otherwise SecWriteStateLimit interferes with HTTP Proxies. My
>> real world experience tells me that a legitimate Proxy can easily
>> have 50 active connections to my server. Not all of those
>> will be in SERVER_BUSY_WRITE but somehow SecWriteStateLimit
>> treats all connections equally and I would need some way to
>> tweak with that. Mod_qos has a notion of VIP connections
>> (via a list of predefined IP ranges). I do not really
>> think that this mechanism is very elegant, but whatever
>> you do with DDoS defense, it gets hairy very fast.
>> SecWriteStateLimit is elegant, but very limited.
>>
>> Best,
>>
>> Christian
>>
>>
>> --
>> It is not power that corrupts but fear. Fear of losing power corrupts
>> those who wield it and fear of the scourge of power corrupts those who
>> are subject to it.
>> -- Aung San Suu Kyi
>>
>>
>> ------------------------------------------------------------------------------
>> All of the data generated in your IT infrastructure is seriously valuable.
>> Why? It contains a definitive record of application performance, security
>> threats, fraudulent activity, and more. Splunk takes this data and makes
>> sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-d2d-c2
>> _______________________________________________
>> 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] Limits of SecWriteStateLimit (was: Re: Advanced Slow DoS Mitigation)

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

Hi Christian,

Did you try to SecWriteStateLimit ? I think we can use a value like 150-250
and detect the attacks and maybe you will not see FPs.

When you say "active connections"  if i understand well the term you are
using ... it is a established  connections right ? But it is not necessary a
simultaneous SERVER_BUSY threads.

So don't think in SecWriteStateLimit as a counter for connections... but for
simultaneous threads in that state. Also you can have active 200 threads ..
but a few in SERVER_BUSY state.

I recommend you test (if you didn't ) it with the range of value i said
here.

Thanks

Breno

On Thu, Jul 7, 2011 at 12:24 AM, Christian Folini <
chr...@ti...> wrote:

> Hi Ryan,
>
> Thank you for your extensive comments. I agree with almost all.
> Let me just quickly say a few words about SecWriteStateLimit.
>
> On Wed, Jul 06, 2011 at 07:42:50AM -0500, Ryan Barnett wrote:
> > Did you see that Breno recently added SecWriteStateLimit as well to help
> > mitigate Slow POST Attacks?
> >
> http://sourceforge.net/apps/mediawiki/mod-security/index.php?title=Referenc
> > e_Manual#SecWriteStateLimit
>
> I have seen it immediately when it came out and it is a must-have
> feature. But it is limited to single IP attackers and I am
> not really afraid of those.
>
> Otherwise SecWriteStateLimit interferes with HTTP Proxies. My
> real world experience tells me that a legitimate Proxy can easily
> have 50 active connections to my server. Not all of those
> will be in SERVER_BUSY_WRITE but somehow SecWriteStateLimit
> treats all connections equally and I would need some way to
> tweak with that. Mod_qos has a notion of VIP connections
> (via a list of predefined IP ranges). I do not really
> think that this mechanism is very elegant, but whatever
> you do with DDoS defense, it gets hairy very fast.
> SecWriteStateLimit is elegant, but very limited.
>
> Best,
>
> Christian
>
>
> --
> It is not power that corrupts but fear. Fear of losing power corrupts
> those who wield it and fear of the scourge of power corrupts those who
> are subject to it.
> -- Aung San Suu Kyi
>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> 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] Advanced Slow DoS Mitigation

[Christian F. <chr...@ti...>]

Hi there,

On Wed, Jul 06, 2011 at 07:42:50AM -0500, Ryan Barnett wrote:
> Great preso and really highlights the threat.  I was wondering what
> percentage of WikiLeaks DoS attacks were utilizing Slowloris-type
> techniques.

Me2. ;)

To be honest there was too much noise to do any sort of measurements.
We have seen a lot of things, also a lot of vanilla slowloris,
but we also must have missed a lot of other interesting attacks.

> Specifically, phase:1 was moved by Ivan awhile ago to be the same as
> phase:2 (instead of Apache post-read-request) due to many users wanting to
> use phase:1 rules inside Apache scope directives like <Location>.  I
> personally do not agree with this change and we are reviewing a potential
> change back.

I bumped into the old phase:1 / Location issue before so I understand
the motivation. But I thought it would have been the better
countermeasure to have apache refuse to start with a phase:1 rule
inside a location.

> Regardless - I believe that we should consider a "phase:0" option that
> would essentially work at the Apache Filter level hook.  So, this would
> not be parsed like the other variables but could give basic access to src
> IP data and the entire request payload as perhaps a new variable -
> THE_REQUEST.

That sounds nice.

> The main issue that I see with a Filter level hook is that mod_uniqueid is
> not yet available and that is used by ModSecurity for proper logging.

That does not sound very nice, though.

Was not there a discussion on the Apache ML to hand over mod_uniqueid
(functionality) to ModSecurity? I think that would be wrong, but maybe
it is possible to introduce a patch to have mod_uniqueid run at this
early hook too (and before phase:0).

Cheers,

Christian


-- 
If we could read the secret history of our enemies, we should find in
each man's life sorrow and suffering enough to disarm all hostility.
-- Henry Wadsworth Longfellow

[Mod-security-developers] Limits of SecWriteStateLimit (was: Re: Advanced Slow DoS Mitigation)

[Christian F. <chr...@ti...>]

Hi Ryan,

Thank you for your extensive comments. I agree with almost all.
Let me just quickly say a few words about SecWriteStateLimit.

On Wed, Jul 06, 2011 at 07:42:50AM -0500, Ryan Barnett wrote:
> Did you see that Breno recently added SecWriteStateLimit as well to help
> mitigate Slow POST Attacks?
> http://sourceforge.net/apps/mediawiki/mod-security/index.php?title=Referenc
> e_Manual#SecWriteStateLimit

I have seen it immediately when it came out and it is a must-have
feature. But it is limited to single IP attackers and I am
not really afraid of those.

Otherwise SecWriteStateLimit interferes with HTTP Proxies. My
real world experience tells me that a legitimate Proxy can easily
have 50 active connections to my server. Not all of those 
will be in SERVER_BUSY_WRITE but somehow SecWriteStateLimit 
treats all connections equally and I would need some way to 
tweak with that. Mod_qos has a notion of VIP connections
(via a list of predefined IP ranges). I do not really
think that this mechanism is very elegant, but whatever
you do with DDoS defense, it gets hairy very fast.
SecWriteStateLimit is elegant, but very limited.

Best,

Christian


-- 
It is not power that corrupts but fear. Fear of losing power corrupts
those who wield it and fear of the scourge of power corrupts those who
are subject to it.
-- Aung San Suu Kyi

Re: [Mod-security-developers] Advanced Slow DoS Mitigation

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

On 7/5/11 2:42 PM, "Christian Folini" <chr...@ti...>
wrote:

>Hi there,

Hey Christian!  Application (D)DoS detection and mitigation is a very
challenging and important topic and merits more discussion so thank you
for the email.


>
>ModSecurity always had a few nice options to help with request delaying
>mitigation. The combination with mod_reqtimeout is a good strategy as
>explained by Ryan at
>http://blog.spiderlabs.com/2010/11/advanced-topic-of-the-week-mitigating-s
>low-http-dos-attacks.html

Did you see that Breno recently added SecWriteStateLimit as well to help
mitigate Slow POST Attacks?
http://sourceforge.net/apps/mediawiki/mod-security/index.php?title=Referenc
e_Manual#SecWriteStateLimit



>
>In May, I did a presentation on the defense against Request Delaying DDoS
>aka as Slow DoS or Slowloris type attacks. That Swiss Cyberstorm talk is
>now online at http://www.youtube.com/watch?v=svN49PIbcks

Great preso and really highlights the threat.  I was wondering what
percentage of WikiLeaks DoS attacks were utilizing Slowloris-type
techniques.

>
>Around 32:30, I mention some advanced ideas on how to identify attackers
>very easily.
>
>As you know, a POST request to /index.html is perfectly okay with
>Apache. You can prevent it with ModSecurity, but not immediately
>when the server receives the requestline.
>
>Ideally, you should be able to drop a request trying this immediately.
>I would like to write rules that trigger as soon as the request line
>has been received. A phase 0 somehow.

We are currently having a discussion about ModSecurity's phases in this
Jira ticket - https://www.modsecurity.org/tracker/browse/MODSEC-98

Specifically, phase:1 was moved by Ivan awhile ago to be the same as
phase:2 (instead of Apache post-read-request) due to many users wanting to
use phase:1 rules inside Apache scope directives like <Location>.  I
personally do not agree with this change and we are reviewing a potential
change back.

Regardless - I believe that we should consider a "phase:0" option that
would essentially work at the Apache Filter level hook.  So, this would
not be parsed like the other variables but could give basic access to src
IP data and the entire request payload as perhaps a new variable -
THE_REQUEST.

>
>This would also be handy to drop requests that try to upload files
>before the user has been authenticated. Apache does not mind large
>uploads from unauthenticated users until it has received the whole
>blob. Not even mod_reqtimeout is of big help if you need to allow
>big file uploads.
>
>Now I doubt that Apache allows for a phase 0 (I am not an apache
>developer and
>as you know not even a ModSecurity developer) as there seems to be no
>hook at that moment and if I get it right, the whole request record
>is not being prepared until post-read-request. But maybe I am wrong.

The main issue that I see with a Filter level hook is that mod_uniqueid is
not yet available and that is used by ModSecurity for proper logging.

I will let Breno comment on some ideas.

Cheers,
Ryan


>
>So what do you guys think?
>
>Cheers,
>
>Christian
>
>
>--
>I think IT projects are about supporting social systems - about
>communications between people and machines. They tend to fail due to
>cultural issues.
>-- Tim Berners-Lee
>
>
>--------------------------------------------------------------------------
>----
>All of the data generated in your IT infrastructure is seriously valuable.
>Why? It contains a definitive record of application performance, security
>threats, fraudulent activity, and more. Splunk takes this data and makes
>sense of it. IT sense. And common sense.
>http://p.sf.net/sfu/splunk-d2d-c2
>_______________________________________________
>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
>


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.