Thread: [mod-security-users] Problem trying to catch malformed requests
Brought to you by:
victorhora,
zimmerletw
From: Leandro M. <lme...@cy...> - 2005-08-12 21:02:40
|
According to Apache documentation: "Although most error messages can be overriden, there are certain circumstances where the internal messages are used regardless of the setting of ErrorDocument. In particular, if a malformed request is detected, normal request processing will be immediately halted and the internal error message returned. This is necessary to guard against security problems caused by bad requests." I've tried to catch malformed requests using mod_security but it seems that they don't even reach mod_security. Does anyone know how to overcome this limitation? Regards, ------------------------------------------------ Leandro Federico Meiners CYBSEC S.A. Security Systems E-mail: lme...@cy... Tel/Fax: [54-11] 4382-1600 Web: http://www.cybsec.com |
From: Tom A. <tan...@oa...> - 2005-08-12 21:22:50
|
I had the same problem... no solution other than putting a proxy in front of your server. Tom ----- Original Message ----- From: "Leandro Meiners" <lme...@cy...> To: <mod...@li...> Sent: Friday, August 12, 2005 5:02 PM Subject: [mod-security-users] Problem trying to catch malformed requests > According to Apache documentation: > "Although most error messages can be overriden, there are certain > circumstances where the internal messages are used regardless of the > setting > of ErrorDocument. In particular, if a malformed request is detected, > normal > request processing will be immediately halted and the internal error > message > returned. This is necessary to guard against security problems caused by > bad > requests." > > I've tried to catch malformed requests using mod_security but it seems > that > they don't even reach mod_security. > > Does anyone know how to overcome this limitation? > > Regards, > > ------------------------------------------------ > Leandro Federico Meiners > CYBSEC S.A. Security Systems > E-mail: lme...@cy... > Tel/Fax: [54-11] 4382-1600 > Web: http://www.cybsec.com > > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle > Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > 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 > > > |
From: Ryan B. <rcb...@gm...> - 2005-08-13 00:03:35
|
Ivan can speak better on this, however I believe that the problem is that Apache does some processing early in the request loop cycle before mod_security has a hook to inspect it. Take a look here at the Apache request loop - http://modperlbook.org/html/ch01_04.html. Then compare this will the hooks that mod_security has into Apache. - module MODULE_VAR_EXPORT security_module =3D { STANDARD_MODULE_STUFF, sec_init, /* module initializer */ sec_create_dir_config, /* create per-dir config structures */ sec_merge_dir_config, /* merge per-dir config structures */ sec_create_srv_config, /* create per-server config structures */ sec_merge_srv_config, /* merge per-server config structures */ sec_cmds, /* table of config file commands */ NULL, /* [#8] MIME-typed-dispatched handlers */ NULL, /* [#1] URI to filename translation */ NULL, /* [#4] validate user id from request */ NULL, /* [#5] check if the user is ok _here_ */ NULL, /* [#3] check access by host address */ NULL, /* [#6] determine MIME type */ sec_check_access, /* [#7] pre-run fixups */ sec_logger, /* [#9] log a transaction */ NULL, /* [#2] header parser */ sec_child_init, /* child_init */ NULL, /* child_exit */ NULL /* [#0] post read-request */ Apache runs through steps 0 - 6 before mod_security has a hook to perform any actions. Ivan - please correct me if I am wrong here. Are there any plans to implement hooks earlier into the request loop? --=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/12/05, Leandro Meiners <lme...@cy...> wrote: > According to Apache documentation: > "Although most error messages can be overriden, there are certain > circumstances where the internal messages are used regardless of the sett= ing > of ErrorDocument. In particular, if a malformed request is detected, norm= al > request processing will be immediately halted and the internal error mess= age > returned. This is necessary to guard against security problems caused by = bad > requests." >=20 > I've tried to catch malformed requests using mod_security but it seems th= at > they don't even reach mod_security. >=20 > Does anyone know how to overcome this limitation? >=20 > Regards, >=20 > ------------------------------------------------ > Leandro Federico Meiners > CYBSEC S.A. Security Systems > E-mail: lme...@cy... > Tel/Fax: [54-11] 4382-1600 > Web: http://www.cybsec.com >=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 > |
From: Ivan R. <iv...@we...> - 2005-08-15 12:18:50
|
Ryan Barnett wrote: > Ivan can speak better on this, however I believe that the problem is > that Apache does some processing early in the request loop cycle > before mod_security has a hook to inspect it. > > Take a look here at the Apache request loop - > http://modperlbook.org/html/ch01_04.html. Then compare this will the > hooks that mod_security has into Apache. - > > ... > NULL, /* [#8] MIME-typed-dispatched handlers */ > NULL, /* [#1] URI to filename translation */ > NULL, /* [#4] validate user id from request */ > NULL, /* [#5] check if the user is ok _here_ */ > NULL, /* [#3] check access by host address */ > NULL, /* [#6] determine MIME type */ > sec_check_access, /* [#7] pre-run fixups */ > sec_logger, /* [#9] log a transaction */ > NULL, /* [#2] header parser */ > sec_child_init, /* child_init */ > NULL, /* child_exit */ > NULL /* [#0] post read-request */ > > Apache runs through steps 0 - 6 before mod_security has a hook to > perform any actions. That's correct. For me it was always a matter of choice whether I want to protect applications, or Apache itself. At the moment mod_security is configured to protect applications. A further problem is that, as Apache processes phases 0-6, it creates a lot of information (which mod_security uses) which would otherwise be unavailable in hook #0 (for example). My idea is to split rule processing into two phases. One would happen in hook #0, and the other #6. However, as I was making improvements to 1.9 I solved one of the major obstacles to move mod_security from hook #7 into earlier phase. I won't bother you with programming details but now it may be possible to run from hook #0. I don't have time to test it thoroughly but since there is demand for it, 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. -- Ivan Ristic Apache Security (O'Reilly) - http://www.apachesecurity.net Open source web application firewall - http://www.modsecurity.org |
From: Ivan R. <iv...@we...> - 2005-08-19 08:52:08
|
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. FYI, I've released 1.9dev3 with a compile-time option to make mod_security run in hook #0 (post_read_request). Here's a fragment from the manual: --- 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: * It should now be possible to detect invalid requests before Apache handles them. * It should be possible to assess requests that would otherwise handled by Apache (e.g TRACE) * Only server-wide rules will run. This is because at this point Apache hasn't mapped the request to the path yet. 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. --- -- Ivan Ristic Apache Security (O'Reilly) - http://www.apachesecurity.net Open source web application firewall - http://www.modsecurity.org |
From: Ryan B. <rcb...@gm...> - 2005-08-19 12:08:56
|
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 > |
From: Leandro M. <lme...@cy...> - 2005-08-19 17:50:36
|
Exactly why I asked about the problem of not been able to catch malformed requests... I was investigating how httprint identifies de remote host, and trying to filter this. regards, Leandro On Fri, 2005-08-19 at 08:08 -0400, Ryan Barnett wrote: > 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 :) > ---------------------------- Leandro Meiners CYBSEC S.A. Security Systems E-mail: lme...@cy... Tel/Fax: [54-11] 4382-1600 Web: http://www.cybsec.com |