mod-security-users — General discussion about mod_security

[mod-security-users] Chroot + Frontpage

[Domenico \DoM\ De M. <do...@mi...>]

Hi,
Before all greets for your mod really helpful :)
Great job!

And now my question :P
I have apache 1.3.33 + frontpage extension.
Chroot works great for all but not for frontpage.
On error_log i receive this at apache start:

Apache/1.3.33 (Unix) mod_throttle/3.1.2 PHP/4.3.10 FrontPage/5.0.2.2635 
configured -- resuming normal operations

And when i try to login with frontpage, prompt login doesnt appear and 
fp_client just tell me that no windows sharepoints are presente on that 
server.
No error anymore not in error_log neither in audit_log or modsec_debug.

If i stop Chroot enviroment everything works fine but i wanna chroot :!

THx & Byez DoM

Re: [mod-security-users] Apache Regular Expressions

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

----- Original Message ----- 
From: "Ivan Ristic" <iv...@we...>
>> In Perl, you
>> would do this: "(?<!login)$"
>
>   The above works in Apache 2.0.52 (which has a different regex engine
>   from Apache 1.x BTW). I used it with <FilesMatch>:
>
>   <FilesMatch "(?<!login)$">
>       Order Allow,Deny
>       Deny from all
>   </FilesMatch>
>
>   The second suggestion does not work for me.

Indeed, it probably shouldn't with the end terminator included, since the 
period would have to be the last character.  Trying <FilesMatch 
"\.(?!login)"> would probably do it though, as it would match any file that 
has a period not followed by "login".  I have to imagine that if Apache 
recognizes a negative lookbehind, it would recognize a negative lookahead, 
since the latter is older and more established.  In any event, if the first 
suggestion worked, then that should be sufficient for finding all files that 
do not end with "login".  I'm glad to hear that Apache's regex engine is so 
advanced.

Tom 

Re: [mod-security-users] Apache Regular Expressions

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

> In Perl, you
> would do this: "(?<!login)$"

   The above works in Apache 2.0.52 (which has a different regex engine
   from Apache 1.x BTW). I used it with <FilesMatch>:

   <FilesMatch "(?<!login)$">
       Order Allow,Deny
       Deny from all
   </FilesMatch>

   The second suggestion does not work for me.

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

Re: [mod-security-users] Apache Regular Expressions

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

On Tue, 2005-02-08 at 19:21, Rudi Starcevic wrote:
> My URLs look like
> 
> http://www.myserver.com/members.main
> http://www.myserver.com/members.login
> 
> I would like to match every request *not* containing the word login on 
> the end:
> 
> This is what I have and it is not working how I would like.
> 
> <Files ~ "/[^(login)]$/">
> or even
> <Files ~ "/[^(login)]/">

That says to accept all characters except: l o g i n ( )

In rewrite rules and mod_sec, you negate a regex like this:
"!(login)$".  See the exclamation point in the front?  In Perl, you
would do this: "(?<!login)$" or "\.(?!login)$", which in the first case
is a negative lookbehind on the end terminator, while the latter is a
negative lookahead on the period.  Try them... I don't know which if any
of them work.

Tom

Re: [mod-security-users] Apache Regular Expressions

[Fred S. <fr...@me...>]

Hi,

As far as I know, you can't do this in apache.  The way the Files or 
FilesMatch directive works, its logic won't support a logical not (its 
matching mechanism only gets triggered by a match).

Modsecurity does support the "!" as the inversion operator, so it would be 
fairly easy to construct

<Location /foo>
SecFilterSelective REQUEST_URI !members
</Location>

I've only been using modsec for a few days now, so if there's a way to do 
it more elegantly, feel free to correct me.



On Tue, 8 Feb 2005, Rudi Starcevic wrote:

> Hello,
>
> I"m trying to write a Regular expression without any joy, so I thought I'd 
> ask for some help.
>
> At this stage the first thing I want to do is match a request using the 
> <Files> Directive.
>
> My URLs look like
>
> http://www.myserver.com/members.main
> http://www.myserver.com/members.login
>
> I would like to match every request *not* containing the word login on the 
> end:
>
> This is what I have and it is not working how I would like.
>
> <Files ~ "/[^(login)]$/">
> or even
> <Files ~ "/[^(login)]/">
>
> I'm want to do this so I can sort my Folders for a client with some weird 
> setup.
>
> Can you see where I am going wrong ?
> Many thanks
> Best Regards
> Rudi
>
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
>

-- 
Fred Stutzman
Desk: 962-5646
Cell: 260-8508
www.ibiblio.org

[mod-security-users] Advanced filtering

[Katsuharu W. <ml...@pa...>]

Hi all,

I have some trouble.

 (1) I want to block some meta-characters on request paramaters except that named test1, but I can't filter "&" and "=" well.

 --- My configuration ---
 SecFilterSelective "ARGS_NAMES|ARGS_VALUES|!ARG_test1" "[&]" deny,log
 SecFilterSelective "ARGS_NAMES|ARGS_VALUES|!ARG_test1" "[=]" deny,log

 In detail, when the request have a paramater only test1, it's work fine. But the paramaters are more, any requests are blocked. For example, I access bellow URL.

  http://www.example.com/index.html?test1=111&test2=222&test3=333

 This case is checking against "test2=222&test3=333". (found this from debug-log.)
 I want to evaluate "222" and "333", but I have no idea.


 (2) How do SecFilterSelective's location match the whole request including headers?

 That's maybe,

  SecFilterSelective "THE_REQUEST|POST_PAYLOAD|HTTP_Host|HTTP_User-Agent|(...more and more headers context)" foo deny,log

 But this is very hard... I want more easy and simple configuration like Output filter,

   SecFilterSelective INPUT foo deny,log

 What do you think?

--
Katsuharu Watanabe
Key fingerprint = 121E AC94 AD99 C468 9E02  C868 827B D767 058A E62E

[mod-security-users] Apache Regular Expressions

[Rudi S. <te...@wi...>]

Hello,

I"m trying to write a Regular expression without any joy, so I thought 
I'd ask for some help.

At this stage the first thing I want to do is match a request using the 
<Files> Directive.

My URLs look like

http://www.myserver.com/members.main
http://www.myserver.com/members.login

I would like to match every request *not* containing the word login on 
the end:

This is what I have and it is not working how I would like.

<Files ~ "/[^(login)]$/">
or even
<Files ~ "/[^(login)]/">

I'm want to do this so I can sort my Folders for a client with some 
weird setup.

Can you see where I am going wrong ?
Many thanks
Best Regards
Rudi

RE: [mod-security-users] [Fwd: Re: Mod_Security]

[Eli <eli...@ex...>]

Tommy Burchfield wrote:

> This rule kills phpMyAdmin
>
> # Very crude filters to prevent SQL injection attacks
> SecFilter "delete[[:space:]]+from"
> SecFilter "insert[[:space:]]+into"
> SecFilter "select.+from"

>From the headers you showed, it was a GET request which was used - where did
you get this in phpMyAdmin?  I didn't check extensively, however all I saw
were POST uses in the latest 2.6.1.  Maybe all that's required is an
upgrade?

Besides, it's always been my thought that SQL injection is best left to be
prevented code side, not webserver side.  As you can see, you'll run in to
some headaches, not to mention it's a VERY crude hack as you mention.

Oh, and "select.+from" is about the worst SQL regex you could imagine :)

"I wish to select some fields where I show a drop down list menu thingy from
my website" - just matched "select.+from" :P  If you search GET only, then
not so bad... But if you're filtering POST too, good luck :P

Eli.

Re: [mod-security-users] [Fwd: Re: Mod_Security]

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

> Got that issue fixed but now noone can get to phpmyadim-
> well they can get to to, but can not select any tables
> 
> ...
 >
> This rule kills phpMyAdmin
> 
> # Very crude filters to prevent SQL injection attacks
> SecFilter "delete[[:space:]]+from"
> SecFilter "insert[[:space:]]+into"
> SecFilter "select.+from"


   It does, because of this:

 > sql_query=SELECT+%2A+FROM+%60columns_priv%60

   That's what the rule was designed to prevent.


> Is there are way to still stop injection attacks and keep phpmyadmin 
> running ??

   I have a limited understanding of how PHPMyAdmin works but my
   impression is that you log into it (PHPMyAdmin) with your
   database username and password. Because of this it makes no sense
   to try and use SQL injection against PHPMyAdmin because it already
   allows you to do anything you want with the database. (Some other
   types of attack, e.g. file disclosure, are more appropriate.)

   Therefore you should look at telling mod_security not to bother
   with SQL injection filters with PHPMyAdmin:

   <Location /MyAdmin/>
       SecFilterInheritance Off

       # now you have the same configuration as
       # in the parent context but no rules

       # Add the rules you want below, but not the ones
       # that deal with SQL injection
       # ...

   </Location>

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

Re: [mod-security-users] apache in chroot dies and doesn't restart

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

Rudy Gevaert wrote:
> Hello,
> 
> I'm running debian stable and using the latest mod_security.
> My chroot is in /sd/webchroot/
> 
> I can set up the chroot fine, and apache works perfectally.  But the
> morning after I set it up apache didn't run:
> 
 > ...
> 
> So it seems that it tries to restart but  looks in the chroot for the
> correct files.

   It is not possible to restart Apache in a jail that is not
   self-contained. The best you can do is stop it first, then start
   it again.

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

[mod-security-users] [Fwd: Re: Mod_Security]

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

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

[mod-security-users] apache in chroot dies and doesn't restart

[Rudy G. <ru...@sc...>]

Hello,

I'm running debian stable and using the latest mod_security.

My chroot is in /sd/webchroot/

I can set up the chroot fine, and apache works perfectally.  But the
morning after I set it up apache didn't run:

[Sat Feb  5 07:25:02 2005] [notice] SIGUSR1 received.  Doing graceful restart fopen: No such file or directory apache: could not open document config file /etc/apache/httpd.conf

So I copied my /etc/apache directory in my chroot... and started it
again.  However this morning it had the following in my logs:

[Sun Feb  6 07:25:04 2005] [notice] SIGUSR1 received.  Doing graceful restart Syntax error on line 204 of /etc/apache/httpd.conf: Cannot load /usr/lib/apache/1.3/mod_security.so into server: /usr/lib/apache/1.3/mod_security.so: cannot open shared object file: No such file or directory


So it seems that it tries to restart but  looks in the chroot for the
correct files.

Any ideas?

Thanks

Rudy

Re: [mod-security-users] "invalid unicode"?

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

Mark wrote:
>>>What is with the "invalid unicode"? That was a perfectly legit
>>>request, as far as I can tell. If not a bug, then why does
>>>this occur?
>>
>> > User-Agent: ... Fran=E7ais 2.2;
>>
>>   It's this character ^ here that causes problems. You need to
>>   turn Unicode validation off. Characters over 0x7f have a special
>>   meaning in Unicode...
>=20
>=20
> Is there not a way I can disable unicode checking just for User-Agent?

   No, not yet. But as a rule of thumb Unicode checking should always
   be disabled by default and only enabled for applications that
   use Unicode. If you don't do this you are bound to get false
   positives from time to time.

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

RE: [mod-security-users] "invalid unicode"?

[Mark <ad...@as...>]

> -----Original Message-----
> From: mod...@li...=20
> [mailto:mod...@li...] On=20
> Behalf Of Ivan Ristic
> Sent: donderdag 3 februari 2005 17:19
> To: Mark
> Cc: mod...@li...
> Subject: Re: [mod-security-users] "invalid unicode"?
>=20
>=20
> > What is with the "invalid unicode"? That was a perfectly legit
> > request, as far as I can tell. If not a bug, then why does
> > this occur?
>=20
>  > User-Agent: ... Fran=E7ais 2.2;
>=20
>    It's this character ^ here that causes problems. You need to
>    turn Unicode validation off. Characters over 0x7f have a special
>    meaning in Unicode...

Is there not a way I can disable unicode checking just for User-Agent?
I doubt I am the only server who receives requests from France or
other countries with such characters in it.

Thanks.

- Mark

Re: [mod-security-users] apache-monitor error

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

Rudi Starcevic wrote:
> Hi,
> 
>  >> Some things seem to be missing from the output. Do you have
>  >> ExtendedStatus set to On (in the Apache configuration)?
> 
> Doh .. no I didn't.
> This scirpt works fine now, sorry for my stoopid mistake.
> 
> The apache-monitor-graph is not so happy for me though.
> Graphs are generated from the dat and rrd files OK but there are no graphs.
> The blue bar charts are totally absent.
> 
> Hmm.
> I'd like to generate stats for the last hour so I'm using something like:
> 
> ./apache-monitor-graph /root/scripts/httpd/server-status/server1 
> /home/www/httpd/server-status 3600
> 
> This does not show any error and does produce 4 gifs with 1 hour 
> timeline but no bar charts ...

   The format of the RRD file has changed. You may need to erase the
   RRD files to allow the script to re-create them.

   Looking at the source code, it checks for error after every RRD
   operation - it's strange that it does not output anything. Are
   you starting them from the command line?

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

Re: [mod-security-users] "invalid unicode"?

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

> What is with the "invalid unicode"? That was a perfectly legit
> request, as far as I can tell. If not a bug, then why does
> this occur?

 > User-Agent: ... Fran=E7ais 2.2;

   It's this character ^ here that causes problems. You need to
   turn Unicode validation off. Characters over 0x7f have a special
   meaning in Unicode...

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

[mod-security-users] "invalid unicode"?

[Mark <ad...@as...>]

Hmm, just found this in my mod_security log:

--------------------------------------------
GET /spf/sendmail-milter-spf.pl HTTP/1.0
Accept: */*
Accept-Language: fr-ch
Cache-Control: max-age=3D259200
Connection: keep-alive
Host: srs-socketmap.info
Referer: http://spf.pobox.com/downloads.html
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; =
Fran=E7ais 2.2;
..NET CLR 1.1.4322)
Via: 1.0 zante.efg.ch:3128 (squid/2.5.STABLE5-20040628)
X-Forwarded-For: 10.60.11.239, 127.0.0.1
mod_security-message: Access denied with code 406. Error validating =
header
value (User-Agent): Invalid Unicode encoding: invalid byte value
--------------------------------------------

What is with the "invalid unicode"? That was a perfectly legit
request, as far as I can tell. If not a bug, then why does
this occur?

Thanks,

- Mark

Re: [mod-security-users] apache-monitor error

[Rudi S. <te...@wi...>]

Hi,

 >> Some things seem to be missing from the output. Do you have
 >> ExtendedStatus set to On (in the Apache configuration)?

Doh .. no I didn't.
This scirpt works fine now, sorry for my stoopid mistake.

The apache-monitor-graph is not so happy for me though.
Graphs are generated from the dat and rrd files OK but there are no graphs.
The blue bar charts are totally absent.

Hmm.
I'd like to generate stats for the last hour so I'm using something like:

./apache-monitor-graph /root/scripts/httpd/server-status/server1 
/home/www/httpd/server-status 3600

This does not show any error and does produce 4 gifs with 1 hour 
timeline but no bar charts ...

Any ideas?
Thanks
Rudi

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

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

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

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