Re: [mod-security-users] Problem trying to catch malformed requests

[Ryan B. <rcb...@gm...>]

Another small benefit of plugging mod_security into hook-0 would be
its ability to alter the sematic characteristics of Apache that web
server fingerprinting apps often rely on for accuracy.

HTTPrint -
http://net-square.com/httprint/index.html

Identification of web servers despite the banner string and any other
obfuscation. httprint can successfully identify the underlying web
servers when their headers are mangled by either patching the binary,
by modules such as mod_security.c or by commercial products such as
ServerMask.

HTTPrint sends malformed requests that Apache will respond to is a
distinct way.  Allowing Mod_Security to get the first crack at
inspecting these requests will help to alter the default Apache
responses.

Looks like it is time to have some fun with Mod_Security's "status"
flag and see how these fingerprinters react :)

--=20
Ryan C. Barnett
Web Application Security Consortium (WASC) Member
CIS Apache Benchmark Project Lead
SANS Instructor: Securing Apache
GCIA, GCFA, GCIH, GSNA, GCUX, GSEC


On 8/19/05, Ivan Ristic <iv...@we...> wrote:
> Ivan Ristic wrote:
> >
> > I'll do a couple of test to see if it works,
> > and if does I will release 1.9dev3 (by the end of week) with a
> > configuration option to choose the hook to run at.
>=20
>   FYI, I've released 1.9dev3 with a compile-time option to make
>   mod_security run in hook #0 (post_read_request).
>=20
>   Here's a fragment from the manual:
>=20
> ---
> By default mod_security will try to run at the last possible moment in
> Apache request pre-processing, but just before the request is actually
> run (for example, processed by mod_php). I have chosen this approach
> because the most important function of mod_security is to protect the
> application. On the other hand by doing this we are leaving certain
> parts of Apache unprotected although there are things we could do about
> it. For those who wish to experiment, as of 1.9dev3 mod_security can be
> compiled to run at the earliest possible moment. Just compile it with
> -DENABLE_EARLY_HOOK. Bear in mind that this is an experimental feature.
> Some of the differences you will discover are:
>=20
>  * It should now be possible to detect invalid requests before Apache
>    handles them.
>=20
>  * It should be possible to assess requests that would otherwise
>    handled by Apache (e.g TRACE)
>=20
>  * Only server-wide rules will run. This is because at this point
>    Apache hasn't mapped the request to the path yet.
>=20
> Subsequent releases of ModSecurity are likely to allow rule processing
> to be split into two phases. One to run as early as possible, and
> another, to run as late as possible.
> ---
>=20
> --
> Ivan Ristic
> Apache Security (O'Reilly) - http://www.apachesecurity.net
> Open source web application firewall - http://www.modsecurity.org
>=20
>=20
>=20
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practic=
es
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & Q=
A
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
>