headers
Tom Anderson | 1 Feb 20:16
Favicon

Re: http-version

----- Original Message ----- 
From: "Ivan Ristic" <ivanr <at> webkreator.com>
>   The variable that works is SERVER_PROTOCOL. There's one problem,
>   though. Apache handles requests with invalid protocol versions long
>   before the request is passed on to mod_security for analysis. That's
>   why it always responds with 400.

Is there a way to redirect the 400 response?  I tried it with ErrorDocument, 
but it didn't seem to work.  I guess it doesn't pass the error document 
request back through mod_security.  In fact, it didn't even fetch the error 
document for 400 at all, but just returned its generic 400 error message.

Tom

-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
Permalink | Reply |
headers
Ivan Ristic | 2 Feb 10:43
Gravatar

Re: http-version

Tom Anderson wrote:
> ----- Original Message ----- From: "Ivan Ristic" <ivanr <at> webkreator.com>
> 
>>   The variable that works is SERVER_PROTOCOL. There's one problem,
>>   though. Apache handles requests with invalid protocol versions long
>>   before the request is passed on to mod_security for analysis. That's
>>   why it always responds with 400.
> 
> Is there a way to redirect the 400 response?  I tried it with 
> ErrorDocument, but it didn't seem to work.  I guess it doesn't pass the 
> error document request back through mod_security.  In fact, it didn't 
> even fetch the error document for 400 at all, but just returned its 
> generic 400 error message.

   That's what I get too. And, no, I don't know a way to get round it.

--

-- 
Ivan Ristic (http://www.modsecurity.org)

-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
Permalink | Reply |
headers
Tom Anderson | 2 Feb 16:33
Favicon

Re: http-version

I have SecAuditEngine set to "RelevantOnly", but the log is getting filled 
up with "HTTP/1.0 200 OK" entries every three minutes from my web host 
checking the connection with "check_http/1.24.2.4 (nagios-plugins )".  I 
don't have any rules that return 200... they all return 406.  Why is it 
logging these?  There are no mod_security headers attached.

I tried to work around the problem by matching "check_http" in the user 
agent and giving it a "nolog,deny,status:200", but apparently the 
"status:200" overrules the deny directive as the page is still output, and 
apparently the "nolog" command doesn't apply to the audit log.

Desired/expected behavior:

1) it shouldn't add any unmatched requests to the audit log when set to 
RelevantOnly
2) "deny" command with "status:200" should just return the 200 header 
without any data
3) "nolog" should apply to the audit log too

Tom

-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
Permalink | Reply |
headers
Ivan Ristic | 2 Feb 16:53
Gravatar

Re: http-version

Tom Anderson wrote:
> I have SecAuditEngine set to "RelevantOnly", but the log is getting 
> filled up with "HTTP/1.0 200 OK" entries every three minutes from my web 
> host checking the connection with "check_http/1.24.2.4 (nagios-plugins 
> )".  I don't have any rules that return 200... they all return 406.  Why 
> is it logging these?  There are no mod_security headers attached.

   Are you using 1.9dev1? If you are it's a bug (fixed in the CVS). If
   not... post your mod_security configuration and the audit log entry
   for that request.

> 1) it shouldn't add any unmatched requests to the audit log when set to 
> RelevantOnly

   That depends. For example, I consider 414 responses to be relevant,
   match or no match. 1.9 will have a conf. option to deal with that.

> 2) "deny" command with "status:200" should just return the 200 header 
> without any data

   I'm not sure Apache will allow that but I'll try.

> 3) "nolog" should apply to the audit log too

   I programmed it to apply to the audit log too. If it doesn't then
   it's a bug.

--

-- 
Ivan Ristic (http://www.modsecurity.org)
(Continue reading)

Permalink | Reply |
headers
Tom Anderson | 2 Feb 17:58
Favicon

Re: http-version

----- Original Message ----- 
>   Are you using 1.9dev1? If you are it's a bug (fixed in the CVS). If
>   not... post your mod_security configuration and the audit log entry
>   for that request.

These are my system specs:

Linux 2.6.9-gentoo-r4 i686 Intel Pentium 4 CPU 1.80GHz
Portage 2.0.51-r15
gcc-3.3.5
glibc-2.3.4.20040808-r1
autoconf-2.59-r6
automake-1.8.5-r1
binutils-2.15.92.0.2-r1
libtool-1.5.2-r7
CFLAGS="-02 -march=i686 -fomit-frame-pointer"

Server version:  Apache/2.0.52
Server built:    Nov 21 2004 17:37:14
Server's Module Magic Number: 20020903:9
Architecture:    32-bit
Server compiled with....
 -D APACHE_MPM_DIR="server/mpm/prefork"
 -D APR_HAS_SENDFILE
 -D APR_HAS_MMAP
 -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
 -D APR_USE_SYSVSEM_SERIALIZE
 -D APR_USE_PTHREAD_SERIALIZE
 -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
 -D APR_HAS_OTHER_CHILD
(Continue reading)

Permalink | Reply |
headers
Ivan Ristic | 2 Feb 18:15
Gravatar

Re: http-version


> mod_security-1.7.6 (net-www/mod_security)
> 
> This is the latest stable version in portage when using "emerge -s 
> mod_security" or "emerge -uDp mod_security".

   That's way too old, having been released in March 2004. The 1.8 is
   better in many, many ways. I can see here
   http://www.gentoo-portage.com/net-www/mod_security

   they have the 1.8.6 version (I don't know what "hard masked" means,
   though). Chances are your problems will go away when you upgrade. Or,
   if they don't go away - I'll fix them.

>>> 1) it shouldn't add any unmatched requests to the audit log when set 
>>> to RelevantOnly
>>
>>   That depends. For example, I consider 414 responses to be relevant,
>>   match or no match. 1.9 will have a conf. option to deal with that.
> 
> The manual says that "Relevant requests are those requests that caused a 
> filter match".  I would agree with that description.  A 414 should be 
> logged to the Apache error log, but not the mod_security audit log.

   That's why you'll get a conf. option to turn it off ;)

>>> 3) "nolog" should apply to the audit log too
>>
>>
>>   I programmed it to apply to the audit log too. If it doesn't then
(Continue reading)

Permalink | Reply |
headers
Tom Anderson | 2 Feb 18:53
Favicon

Re: http-version

----- Original Message ----- 
From: "Ivan Ristic" <ivanr <at> webkreator.com>

>   they have the 1.8.6 version (I don't know what "hard masked" means,
>   though). Chances are your problems will go away when you upgrade. Or,
>   if they don't go away - I'll fix them.

I checked bugzilla which led me to 
http://dev.gentoo.org/~vericgar/doc/apache-package-refresh.html. 
Apparently, there was a feature-freeze on Apache in portage until a new 
scheme could be developed which changed lots and lots of stuff.  I'll have 
to investigate upgrading. Thanks.

Tom

-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
Permalink | Reply |

Gmane