mod-security-users

[mod-security-users] http-version

[Tom A. <tan...@oa...>]

I'm trying to determine how to match the HTTP protocol version passed in
from the client in order to help prevent fingerprinting.  For example,
if the request is "GET / HTTP/3.0", Apache generally returns "400 Bad
Request" while IIS returns "200 OK", and Netscape returns "505 HTTP
Version Not Supported".  I'd like to be able to match the HTTP version
string in order to change the response to 505 or 406 or something else. 
However, none of the "locations" for SecFilterSelective seem to work. 
HTTP_VERSION at least doesn't return an error, but it doesn't match the
http version string either.  Please let me know if what I want to do is
possible, and if so, how to do it.  Thanks.

Tom

Re: [mod-security-users] http-version

[Ivan R. <iv...@we...>]

Tom Anderson wrote:
> I'm trying to determine how to match the HTTP protocol version passed in
> from the client in order to help prevent fingerprinting.  For example,
> if the request is "GET / HTTP/3.0", Apache generally returns "400 Bad
> Request" while IIS returns "200 OK", and Netscape returns "505 HTTP
> Version Not Supported".  I'd like to be able to match the HTTP version
> string in order to change the response to 505 or 406 or something else. 
> However, none of the "locations" for SecFilterSelective seem to work. 

   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.

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

Re: [mod-security-users] http-version

[Tom A. <tan...@oa...>]

----- Original Message ----- 
From: "Ivan Ristic" <iv...@we...>
>   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

Re: [mod-security-users] http-version

[Ivan R. <iv...@we...>]

Tom Anderson wrote:
> ----- Original Message ----- From: "Ivan Ristic" <iv...@we...>
> 
>>   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)

Re: [mod-security-users] http-version

[Tom A. <tan...@oa...>]

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

Re: [mod-security-users] http-version

[Ivan R. <iv...@we...>]

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)

Re: [mod-security-users] http-version

[Tom A. <tan...@oa...>]

----- 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
 -D AP_HAVE_RELIABLE_PIPED_LOGS
 -D HTTPD_ROOT="/usr"
 -D SUEXEC_BIN="/usr/sbin/suexec2"
 -D DEFAULT_PIDLOG="/var/run/httpd.pid"
 -D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
 -D DEFAULT_LOCKFILE="/var/run/accept.lock"
 -D DEFAULT_ERRORLOG="logs/error_log"
 -D AP_TYPES_CONFIG_FILE="/etc/apache2/conf/mime.types"
 -D SERVER_CONFIG_FILE="/etc/apache2/conf/apache2.conf"

Compiled in modules:
    core.c
    prefork.c
    http_core.c
    mod_so.c

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

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

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

At least "deny" should take precedence over "status:200".  If I've denied 
the request but tried to pass a 200 status code, then the status code is 
what should not get passed if these are mutually exclusive.

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

It's definitely not working in this version...  I just changed my filter as 
follows:

SecFilterSelective "HTTP_USER_AGENT|HTTP_HOST" "^$" "nolog,deny,status:407"

And my request in the audit log looks like this:

========================================
Request: 65.126.137.220 - - [[02/Feb/2005:11:53:47 --0500]] "GET / JUNK/3.0" 
407 509
Handler: httpd/unix-directory
----------------------------------------
GET / JUNK/3.0
mod_security-message: Access denied with code 407. Pattern match "^$" at 
HEADER.
mod_security-action: 407

JUNK/3.0 407 Proxy Authentication Required
Vary: Accept-Encoding
Content-Length: 509
Connection: close
Content-Type: text/html; charset=iso-8859-1

But this may again be related to the "Handler: httpd/unix-directory", as the 
same request with "/index.html" instead of "/" does not get logged.

Tom

P.S. Please don't copy both me and the list.  I'm subscribed, so I'm getting 
it twice.  Thanks.

Re: [mod-security-users] http-version

[Ivan R. <iv...@we...>]

> 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
>>   it's a bug.
> 
> 
> It's definitely not working in this version...  I just changed my filter 
> as follows:

   I don't recall when I made that change. It could have been
   after 1.7.6. (But I see the code for that in the source now.)

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

Re: [mod-security-users] http-version

[Tom A. <tan...@oa...>]

----- Original Message ----- 
From: "Ivan Ristic" <iv...@we...>

>   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

Re: [mod-security-users] http-version

[Tom A. <tan...@oa...>]

----- Original Message ----- 
From: "Ivan Ristic" <iv...@we...>
>   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.

Here's an interesting problem.... I have the rule 'SecFilterSelective 
SERVER_PROTOCOL "!HTTP"' in order to return an error when someone tries 
something like "GET / JUNK/1.0".  However, not only does that not match and 
reject the intended string, it instead matches any "httpd/unix-directory" 
handler requests.  In other words, all "/" or "/directory/" requests.  But 
it doesn't reject pages that have a filename.  The audit log shows the same 
HTTP protocol in both cases.  It seems that SERVER_PROTOCOL isn't matching 
the right thing.

Tom

Re: [mod-security-users] http-version

[Ivan R. <iv...@we...>]

Tom Anderson wrote:
> Here's an interesting problem.... I have the rule 'SecFilterSelective 
> SERVER_PROTOCOL "!HTTP"' in order to return an error when someone tries 
> something like "GET / JUNK/1.0".  However, not only does that not match 
> and reject the intended string, it instead matches any 
> "httpd/unix-directory" handler requests.  In other words, all "/" or 
> "/directory/" requests.  But it doesn't reject pages that have a 
> filename.  The audit log shows the same HTTP protocol in both cases.  It 
> seems that SERVER_PROTOCOL isn't matching the right thing.

   Works for me here. From the debug log (at level 9):

   Checking signature "!HTTP" at SERVER_PROTOCOL
   Checking against "JUNK/1.0"
   Signature check returned 403

   Which error message are you getting? Look into the debug log at
   level 9 for more information.

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

Re: [mod-security-users] http-version

[Tom A. <tan...@oa...>]

----- Original Message ----- 
From: "Ivan Ristic" <iv...@we...>
>   Works for me here. From the debug log (at level 9):
>
>   Checking signature "!HTTP" at SERVER_PROTOCOL
>   Checking against "JUNK/1.0"
>   Signature check returned 403
>
>   Which error message are you getting? Look into the debug log at
>   level 9 for more information.

root@www tanderso # tail -n 500 /var/log/apache2/modsec_debug
[02/Feb/2005:12:26:40 --0500] [www.tr-teach.org/sid#8280ba8][rid#837d470][/] 
Filtering off for non-dynamic resources [content-type=httpd/unix-directory]
[02/Feb/2005:12:26:40 --0500] 
[www.tr-teach.org/sid#8280ba8][rid#8385490][/index.html] Looking into 
subrequest because initial request skipped because of DynamicOnly
[02/Feb/2005:12:26:40 --0500] 
[www.tr-teach.org/sid#8280ba8][rid#8385490][/index.html] Checking with 
per-dir-config [:null][/index.html]
[02/Feb/2005:12:26:40 --0500] 
[www.tr-teach.org/sid#8280ba8][rid#8385490][/index.html] sec_pre: Filtering 
off for a subrequest.
...
[02/Feb/2005:12:26:40 --0500] 
[www.tr-teach.org/sid#8280ba8][rid#8385490][/index.html] Checking signature 
"!^$" at HEADER(Transfer-Encoding)
[02/Feb/2005:12:26:40 --0500] 
[www.tr-teach.org/sid#8280ba8][rid#8385490][/index.html] Variable value: []
[02/Feb/2005:12:26:40 --0500] 
[www.tr-teach.org/sid#8280ba8][rid#8385490][/index.html] 
check_sig_against_string: string:  regex_result: 0 is_allow: 1
[02/Feb/2005:12:26:40 --0500] 
[www.tr-teach.org/sid#8280ba8][rid#8385490][/index.html] Signature check 
returned 0
[02/Feb/2005:12:26:40 --0500] 
[www.tr-teach.org/sid#8280ba8][rid#8385490][/index.html] Checking signature 
"!HTTP" at SERVER_PROTOCOL(SERVER_PROTOCOL)
[02/Feb/2005:12:26:40 --0500] 
[www.tr-teach.org/sid#8280ba8][rid#8385490][/index.html] Variable value: 
[INCLUDED]
[02/Feb/2005:12:26:40 --0500] 
[www.tr-teach.org/sid#8280ba8][rid#8385490][/index.html] 
check_sig_against_string: string: INCLUDED regex_result: 17 is_allow: 1
[02/Feb/2005:12:26:40 --0500] 
[www.tr-teach.org/sid#8280ba8][rid#8385490][/index.html] Pausing 
[/index.html] for 1000 ms
[02/Feb/2005:12:26:41 --0500] 
[www.tr-teach.org/sid#8280ba8][rid#8385490][/index.html] Signature check 
returned 406
[02/Feb/2005:12:26:41 --0500] 
[www.tr-teach.org/sid#8280ba8][rid#8385490][/index.html] Access denied with 
code 406. Pattern match "!HTTP" at SERVER_PROTOCOL.
[02/Feb/2005:12:26:41 --0500] [www.tr-teach.org/sid#8280ba8][rid#837d470][/] 
sec_logger: start

Apparently, SERVER_PROTOCOL==INCLUDED for directory listings, and that's 
causing the problem.

Tom