mod-security-users — General discussion about mod_security

Re: [mod-security-users] Allow and Pass with logging issues

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

Julian Frumar wrote:
> I am trying to implement mod security initially to audit all POSTED
> variables.
> 
> 
> In order to do this, all I really need is a filter rule that matches the
> POST request type, and logs, but allows the request.
> 
> 
> I am having touble getting this simple setup running in Mod_security 1.7.1.
> 
> It seems that the auditing and logging works when I deny the requests, but I
> cannot get anything to log with the 'pass', and 'allow' actions.
> 
> I am using apache 1.3.28, mod_security 1.7.1.
> 
> I have copied the rule off page 16 of the PDF manual:
> 
> ----------------------------------------------------
> pass
> Allow request to continue on filter match. This action is useful when you
> want to log a filter match
> but otherwise do not want to take action.
> 
> SecFilter KEYWORD "pass,log"
> ----------------------------------------------------
> 
> However, I receive no logging at all!
> 
> When I turn on debug logging, it says it is passing the match off to the
> audit engine, but I see nothing in the error_log of apache, or the audit_log
> of mod security.
> 
> Can anyone else replicate this behaviour?

   I can. It is a bug. Since I am releasing 1.7.2 tonight the bug
   fix will be included with the new version.

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]

[mod-security-users] Allow and Pass with logging issues

[Julian F. <jf...@id...>]

I am trying to implement mod security initially to audit all POSTED
variables.


In order to do this, all I really need is a filter rule that matches the
POST request type, and logs, but allows the request.


I am having touble getting this simple setup running in Mod_security 1.7.1.

It seems that the auditing and logging works when I deny the requests, but I
cannot get anything to log with the 'pass', and 'allow' actions.

I am using apache 1.3.28, mod_security 1.7.1.

I have copied the rule off page 16 of the PDF manual:

----------------------------------------------------
pass
Allow request to continue on filter match. This action is useful when you
want to log a filter match
but otherwise do not want to take action.

SecFilter KEYWORD "pass,log"
----------------------------------------------------

However, I receive no logging at all!

When I turn on debug logging, it says it is passing the match off to the
audit engine, but I see nothing in the error_log of apache, or the audit_log
of mod security.

Can anyone else replicate this behaviour?


Many Thanks!

Re: [mod-security-users] Questions about SecFilterCheckURLEncoding

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

> if noticed that some of my sites uses special chars like ä,ö,ü.
> and i heard that this will be soon allowed in domainnames too.
> is it possible to add some special chars to SecFilterCheckURLEncoding?
> would be great.

   SecFilterCheckURLEncoding will never create you problems with
   special characters. It only verifies that all URL encoded characters
   are valid (they must contain two HEX digits after the % character).

   SecFilterForceByteRange START END

   can create problem in these cases. One possible enhancement is
   to allow byte ranges, such as:

   SecFilterForceByteRange "32-126,138,140,200-215"

   Is this what you had in mind?

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]

[mod-security-users] Questions about SecFilterCheckURLEncoding

[mutombo <mut...@gm...>]

hi .

if noticed that some of my sites uses special chars like =E4,=F6,=FC.
and i heard that this will be soon allowed in domainnames too.
is it possible to add some special chars to SecFilterCheckURLEncoding?
would be great.

greetings

christian

[mod-security-users] downloadlinks for 1.7.1 seems down.

[mutombo <mut...@gm...>]

hi .

i checked out all mirrors of sf.net but the files seems not to be there.
cvs is working, but the release tgz is only until 1.5.


greetings

christian

Re: [mod-security-users] Re: Failing tests in 1.7.1

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

> Can I please ask you to announce new releases in this mailing list or,
> if possible, send me a notice so I can update Debian package when new
> versions if available. 

   Of course. I will crate another list, purely for announcements, and
   add your email address to it.


> I've had to skip version 1.6 because you had 1.5 on
> your old domain and I haven't looked at new modsecurity.org
> 
> New Debian package are available at http://www.litux.org/debian/unstable
> and will be uploaded to Debian's main repository in a while...

   Great, thanks a lot!

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]

[mod-security-users] Re: Failing tests in 1.7.1

[<bru...@li...>]

Ivan Ristic <iv...@we...> wrote:
> [-- text/plain, encoding 7bit, charset: us-ascii, 22 lines --]
> 
> Bruno Rodrigues wrote:
> 
>> During debianization of mod-security 1.7.1 I saw that the following
>> tests are failing:
> 
>    That's my fault, I forgot to update the configuration file to
>    the last version. Try with the attachment, and I'll add the
>    configuration to the CVS to avoid this in the future.

;) It works perfectly


>    PS. Test #36 should fail because you are not on Windows.

Already disabled


Can I please ask you to announce new releases in this mailing list or,
if possible, send me a notice so I can update Debian package when new
versions if available. 
I've had to skip version 1.6 because you had 1.5 on
your old domain and I haven't looked at new modsecurity.org

New Debian package are available at http://www.litux.org/debian/unstable
and will be uploaded to Debian's main repository in a while...

Thanks Ivan.

Re: [mod-security-users] Failing tests in 1.7.1

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

Bruno Rodrigues wrote:

> During debianization of mod-security 1.7.1 I saw that the following
> tests are failing:

    That's my fault, I forgot to update the configuration file to
    the last version. Try with the attachment, and I'll add the
    configuration to the CVS to avoid this in the future.

    I need to reorganize my regression tests anyway. In the beginning
    I just made them up as I went along but now there are over 50
    tests and they need to be documented, arranged in an order
    that makes sense, etc.

    PS. Test #36 should fail because you are not on Windows.

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]

[mod-security-users] Failing tests in 1.7.1

[<bru...@li...>]

During debianization of mod-security 1.7.1 I saw that the following
tests are failing:

44-normalisation-bug.test
47-action-allow.test
48-chained-rules-1.test
53-cookie-1.test
55-cookie-3.test
56-cookie-4.test

Any reason for this or am I doing something wrong ?

For example, test 47:
# 47 test action "allow" (requires 200)
#
#
GET /cgi-bin/modsec-test.pl/keyword?p=secret HTTP/1.0

but in http-full, this url is configured to always failed due to:
    SecFilter "/cgi-bin/modsec-test.pl/keyword"


Thanks

[mod-security-users] Re: Re2: SecChrootDir and httpd.conf

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

>> [notice] SIGHUP received.  Attempting to restart
>> [notice] mod_security: sec_init called, getppid()=1
>> [notice] mod_security: performed chroot, path=/disk2
>> [error] (2)No such file or directory: could not create /tmp/httpd.pid
>> [error] httpd: could not log pid to file /tmp/httpd.pid
> 
> getppid() returns 1 => chroot gets called => apache dies :(

   I don't have root access to a Solaris box but I think
   I figured out what happens because it is the same on my
   Linux development server.

   There are two things you need to do:

   1) The path in jail must be the same as the path outside
      the jail. Let's assume you keep Apache at

      /usr/local/apache

      then the chroot must be

      /chroot/usr/local/apache

   2) Inside the jail, the logs folder must exist, so you
      need to have

      /chroot/usr/local/apache/logs

   I didn't notice this because I already had my jail
   configured as above. Does this work for you? If it does I will
   address this issue in the documentation for the upcoming v1.7
   release (scheduled for a week from now).

   BTW, standard apachectl stop and restart won't work on a
   chrooted server as the script can't find the pid file. Stopping
   the server is easy, I'll probably write a script for that in
   the future. Restart could be easy, too, but only provided you
   keep the configuration files in jail, as the chrooted copy of
   the server must re-read them.

   The requirement above (the same folder structure and a place
   to create the pid file) does not exist in Apache1 as there
   the apachectl script creates the pidfile.

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]

[mod-security-users] Re2: SecChrootDir and httpd.conf

[Markus J. <ml...@ze...>]

Hi

Thanks for the fast reply.

At 18:06 +0100 20.9.2003, Ivan Ristic wrote:
>   How did you change it? That check is what makes it work; Apache
>   initialises all modules twice, and getppid returns 1 on the
>   second pass (and the chroot call must be made in the second
>   pass).

I just commented it out, since I noticed that neither of the 
ap_log_error()s appeared in the logs.


After receiving your message I removed the comment (reactivating the 
call to getppid()) and added a call to ap_log_error() to the top of 
sec_init(). These are the results:


First test, no SecChrootDir in conf

0) Starting apache:
>[notice] mod_security: sec_init called, getppid()=2712
>[notice] mod_security: sec_init called, getppid()=1
>[notice] Apache/2.0.47 (Unix) PHP/4.3.3 configured -- resuming 
>normal operations

1) Restarting apache:
>[notice] SIGHUP received.  Attempting to restart
>[notice] mod_security: sec_init called, getppid()=1
>[notice] Apache/2.0.47 (Unix) PHP/4.3.3 configured -- resuming 
>normal operations

which looks ok


Second test, added "SecChrootDir /disk2" to conf

0) Starting apache:
>[notice] mod_security: sec_init called, getppid()=2756
>[notice] mod_security: sec_init called, getppid()=2757
>[notice] Apache/2.0.47 (Unix) PHP/4.3.3 configured -- resuming 
>normal operations

getppid() doesn' return 1 => chroot doesn't get called.

1) Restarting apache:
>[notice] SIGHUP received.  Attempting to restart
>[notice] mod_security: sec_init called, getppid()=1
>[notice] mod_security: performed chroot, path=/disk2
>[error] (2)No such file or directory: could not create /tmp/httpd.pid
>[error] httpd: could not log pid to file /tmp/httpd.pid

getppid() returns 1 => chroot gets called => apache dies :(


Thanks
--markus

Re: [mod-security-users] SecChrootDir and httpd.conf

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

> I'm running into problems using SecChrootDir on one of my machines 
> (Sol8, apache 2.0.47, mod_security as DSO).
> 
> 0) I changed the check for getppid and compiled.

   How did you change it? That check is what makes it work; Apache
   initialises all modules twice, and getppid returns 1 on the
   second pass (and the chroot call must be made in the second
   pass).

   The other warnings are probably a result of that change.

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]

[mod-security-users] SecChrootDir and httpd.conf

[Markus J. <ml...@ze...>]

Hi

I'm running into problems using SecChrootDir on one of my machines 
(Sol8, apache 2.0.47, mod_security as DSO).

0) I changed the check for getppid and compiled.

1) apache complained:
>[crit] (2)No such file or directory: mod_security: Could not create 
>modsec_debuglog_lock

2) I moved the chroot block to the bottom of sec_init() and recompiled.

3) apache gets chrooted:
>[notice] mod_security: performed chroot, path=/disk2

4) but then complains:
>httpd: could not open document config file /disk1/conf/httpd.conf


It seems to try rereading the config - lying otside the jail

Any ideas?

Thanks
--markus

Re: [mod-security-users] Finding out a password from basic auth?

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

> So does anyone know of some obscure configuration directive to tell Apache
> to set ta REMOTE_PASSWORD environment variable? Or would I need to hack
> the source code? If the latter, has anyone already done it and can send me
> a patch?

   The password is available to the script encoded in a HTTP header.
   A quick Google search gave this link, among others:

   http://frontier.userland.com/stories/storyReader$2159

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]

[mod-security-users] Finding out a password from basic auth?

[Toby A I. <to...@go...>]

This is one of those questions that is either laughably easy or impossibly
difficult. Unfortunately I am as yet unable to decide which it is.

I have a directory on my server that is protected using basic
HTTP authentication (it's over SSL so don't worry about that!). Everything
is working fine and dandy there.

Now, CGI scripts within this directory can obtain the user name of someone
visiting through the REMOTE_USER environment variable. However, I also
need to access the remote password (so that I can pass it on log in to a
mail server), which doesn't seem possible.

Numerous resources on the web seem to mention REMOTE_PASSWORD, but their
authors seem to be living in a dream world. :-)

I am well aware that there are potential security issues with allowing any
script on the server to access this piece of information, but I don't
think any apply in this particular case.

So does anyone know of some obscure configuration directive to tell Apache
to set ta REMOTE_PASSWORD environment variable? Or would I need to hack
the source code? If the latter, has anyone already done it and can send me
a patch?

Using:  mod_auth_pam 1.1.1 (authenticating via samba)
	Apache 1.3.27
	Mandrake Linux 9.1

Thanks in advance,

-- 
Toby A Inkster BSc (Hons) ARCS
Contact Me - http://www.goddamn.co.uk/tobyink/?id=132

Re: [mod-security-users] Nulls in post cause false negative (Bug?)

[<sre...@g8...>]

> It works, but not completely. For example, it would not catch
> this:
>
>  GET /cgi-bin/modsec-test.pl?p=dummy%00chicken
>
> with a filter
>
>  SecFilterSelective ARG_p chicken
>  (assuming the range allowed is 0-255)

I profess, I only tried the patch with filters that worked on
POST_PAYLOAD.


> To fight this, I will add a piece of code to the URL decoding
> function to automatically convert null bytes %00 to a space. That
> will work in all cases.

That sounds good.  If you'd like me to test the new version out, I'd
be happy to do so.

Thanks.

-- 
sre...@in...

Re: [mod-security-users] Nulls in post cause false negative (Bug?)

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

sre...@g8... wrote:
> I spent a little time stepping through with a debugger, and made a
> small modification based on what I noticed (diffs at end of message).
> With this patch, "chicken" after the \0 triggered a filter match:
> 
>   mod_security: Access denied with code 501. Pattern match "chicken" at POST_PAYLOAD.
> 
> If the patch seems okay, please feel free to use it.

   It works, but not completely. For example, it would not catch
   this:

    GET /cgi-bin/modsec-test.pl?p=dummy%00chicken

   with a filter

    SecFilterSelective ARG_p chicken
    (assuming the range allowed is 0-255)

   To fight this, I will add a piece of code to the URL decoding
   function to automatically convert null bytes %00 to a space. That
   will work in all cases.


>>>This is more of an RFE, but it would also be nice to allow arbitrary
>>>binary data in keyword patterns.  (Like "\177ELF" :).
>>
>>   Did you try it? I've had no problem running regular expressions
>>   against binary files (with null characters removed). Maybe it
>>   already works.
> 
> 
> I tried
> 
>   SecFilterSelective "POST_PAYLOAD" "\177ELF" "deny,log,status:502"
>   SecFilterSelective "POST_PAYLOAD" "^?ELF" "deny,log,status:502"
>   # "^?" is a literal 0x7f
> 
> but no dice :(

   OK, I've added it to my TODO list.

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]

Re: [mod-security-users] Nulls in post cause false negative (Bug?)

[<sre...@g8...>]

>    I fixed it tonight. I checked, it is visible now via the
>    anonymous CVS (sometimes it is up to a day late).

Ivan,

I downloaded version 1.25 of apache1/mod_security.c and tried it out,
using sample request that I'd used earlier:

  my $request =
    POST($ARGV[0],
	[ a => "so much depends",
	  b => "upon a red wheelbarrow",
	  c => "glazed with rainwater",
	  d => "beside the white ^@ chickens"]);

Here's what I found.

  SecFilterForceByteRange 32 126

Nailed the null byte in the POST data.

  mod_security: Invalid character detected [0]

But

  SecFilterForceByteRange 0 255
  SecFilterSelective "POST_PAYLOAD" "chicken" "deny,log,status:501"

Did not match the "chicken" that followed the null.

I spent a little time stepping through with a debugger, and made a
small modification based on what I noticed (diffs at end of message).
With this patch, "chicken" after the \0 triggered a filter match:

  mod_security: Access denied with code 501. Pattern match "chicken" at POST_PAYLOAD.

If the patch seems okay, please feel free to use it.


>> This is more of an RFE, but it would also be nice to allow arbitrary
>> binary data in keyword patterns.  (Like "\177ELF" :).
>
>    Did you try it? I've had no problem running regular expressions
>    against binary files (with null characters removed). Maybe it
>    already works.

I tried

  SecFilterSelective "POST_PAYLOAD" "\177ELF" "deny,log,status:502"
  SecFilterSelective "POST_PAYLOAD" "^?ELF" "deny,log,status:502"
  # "^?" is a literal 0x7f

but no dice :(

Anyway, here's the patch to
 * $Id: mod_security.c,v 1.25 2003/08/28 20:48:32 ivanr Exp $

------------------------------------------------------------------
*** mod_security.c.ORIG	Fri Aug 29 12:58:38 2003
--- mod_security.c	Fri Aug 29 12:59:31 2003
***************
*** 1052,1062 ****
                  // sec_debug_log(r, 3, "Before: %s", _post_payload);
                  _post_payload = normalise_uri(r, _post_payload, dcfg->range_start, dcfg->range_end, dcfg->check_encoding, dcfg->check_unicode_encoding);
                  // sec_debug_log(r, 3, "After: %s", _post_payload);
!             } else {
!                 // remove binary content from the payload
!                 sec_debug_log(r, 3, "Removing null bytes from POST payload");
!                 _post_payload = remove_binary_content(r, _post_payload);
!             }

              if (_post_payload == NULL) {
                  return dcfg->action.status;
--- 1052,1062 ----
                  // sec_debug_log(r, 3, "Before: %s", _post_payload);
                  _post_payload = normalise_uri(r, _post_payload, dcfg->range_start, dcfg->range_end, dcfg->check_encoding, dcfg->check_unicode_encoding);
                  // sec_debug_log(r, 3, "After: %s", _post_payload);
!             }
!
!             // remove binary content from the payload
!             sec_debug_log(r, 3, "Removing null bytes from POST payload");
!             _post_payload = remove_binary_content(r, _post_payload);

              if (_post_payload == NULL) {
                  return dcfg->action.status;
------------------------------------------------------------------

Hth.

-- 
Steve

Re: [mod-security-users] Nulls in post cause false negative (Bug?)

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

re...@g8... wrote:
>>   No, it is definitely a bug - I'll upload a fix to the CVS
>>   tonight.
> 
> Wow, that's quick :)

   I fixed it tonight. I checked, it is visible now via the
   anonymous CVS (sometimes it is up to a day late).


> I spent a little bit of time looking through mod_security.c.  It seems
> as if you'd still want this case to be caught when
> "SecFilterForceByteRange 0 255" was given as a setting.  The program
> on the receiving end (a cgi in this case) still sees 0x0 coming
> though, and everything afterwards.  In some languages, ^@ is a
> perfectly valid character.
> 
> This is a tricky one, since regexec() is expecting a null terminated
> string.  Perhaps remove_binary_content() after normalise_uri() would
> be the ticket.

   I agree. I don't think many people will expect (or even think
   about) null characters. I'll add one more remove_binary_content
   call there.

   While we are at the subject, please note that parameters are
   not parsed when multipart/form-data content type is used. I have
   the code to parse that and I'll integrate it some time soon.


> This is more of an RFE, but it would also be nice to allow arbitrary
> binary data in keyword patterns.  (Like "\177ELF" :).

   Did you try it? I've had no problem running regular expressions
   against binary files (with null characters removed). Maybe it
   already works.

   Would you settle for an external hook allowing you to run
   arbitrary scripts against the uploaded file?


> Thanks for the quick response.

   You are welcome :)

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]

Re: [mod-security-users] Nulls in post cause false negative (Bug?)

[<sre...@g8...>]

>    No, it is definitely a bug - I'll upload a fix to the CVS
>    tonight.

Wow, that's quick :)

>    The bug was that there was no range checking for POST
>    payloads (range 0-255 was hardcoded). Normally something like
>    this would have been caught by the SecFilterForceByteRange
>    check.
>
>    I am not really sure whether to implement an additional
>    check for the null byte. It is aleady being done for
>    all content types other than "application/x-www-form-urlencoded"
>    (to allow for scanning of uploaded files, even if they are in
>    a binary format).
>
>    I feel that it would be better to let SecFilterForceByteRange
>    catch the null byte attack. What do you think?

I spent a little bit of time looking through mod_security.c.  It seems
as if you'd still want this case to be caught when
"SecFilterForceByteRange 0 255" was given as a setting.  The program
on the receiving end (a cgi in this case) still sees 0x0 coming
though, and everything afterwards.  In some languages, ^@ is a
perfectly valid character.

This is a tricky one, since regexec() is expecting a null terminated
string.  Perhaps remove_binary_content() after normalise_uri() would
be the ticket.

This is more of an RFE, but it would also be nice to allow arbitrary
binary data in keyword patterns.  (Like "\177ELF" :).

Thanks for the quick response.

-- 
Steve

Re: [mod-security-users] Nulls in post cause false negative (Bug?)

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

> Second, I'd like to report what seems to be a bug in POST_PAYLOAD
> scanning.
 >
 > ...
> 
> Is this the desired behavior?

   No, it is definitely a bug - I'll upload a fix to the CVS
   tonight.

   The bug was that there was no range checking for POST
   payloads (range 0-255 was hardcoded). Normally something like
   this would have been caught by the SecFilterForceByteRange
   check.

   I am not really sure whether to implement an additional
   check for the null byte. It is aleady being done for
   all content types other than "application/x-www-form-urlencoded"
   (to allow for scanning of uploaded files, even if they are in
   a binary format).

   I feel that it would be better to let SecFilterForceByteRange
   catch the null byte attack. What do you think?

Bye,
Ivan

[mod-security-users] Nulls in post cause false negative (Bug?)

[<sre...@g8...>]

I recently build mod_security and incorporated it into an apache
1.3.28 installation.

First, I'd like to say that this looks like a very useful package.
Nice job!

Second, I'd like to report what seems to be a bug in POST_PAYLOAD
scanning.

I have the following directives

  SecFilterEngine On
  SecFilterDefaultAction "deny,log,status:400"
  SecFilterCheckURLEncoding On
  SecFilterForceByteRange 32 128
  SecAuditEngine On
  SecFilterScanPOST On
  SecAuditLog logs/localhost/mod_security_audit.log
  SecFilterSelective "POST_PAYLOAD" "chicken" "deny,log,status:501"

The following code (perl) creates a post that successfully generates a
filter hit.

use HTTP::Request::Common;
my $request =
  POST($ARGV[0],
       [ a => "so much depends",
	 b => "upon a red wheelbarrow",
	 c => "glazed with rainwater",
	 d => "beside the white chickens"]);

  mod_security: Access denied with code 501. Pattern match "chicken"
  at POST_PAYLOAD.

That's great.  However, the following is allowed to pass (HTTP 200)

my $request =
  POST($ARGV[0],
       [ a => "so much depends",
	 b => "upon a red wheelbarrow",
	 c => "glazed with rainwater",
	 d => "beside the white ^@ chickens"]);

Where "^@" is an ASCII null, which gets encoded and sent as "%00".

Is this the desired behavior?

Thanks.

-- 
Steve

Re: [mod-security-users] SecFilter rule processing questions

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

Brett Dicker wrote:
> Hi,
> 
> I've just subscribed so I'm not sure if this has been previously
> discussed.
> 
> I've created a set of rules to explicitly allow certain files, e.g.
> 
>     SecFilter "\.jsp|\.html|\.css|\.js|\.gif|\.jpg" "allow"
>     SecFilter  "^/$" "allow"     # (Still working on this one)
> 
> ...
> 
> My question is,  is the 'allow' action the wrong action for the job and
> I should be using a different action? 

   The idea you have is a right one but there is a problem
   because mod_security has no "allow" action :) There is
   "pass" but its effect is not to stop execution on a filter
   match (it proceeds with other filters).

   I will be dealing with filters and actions extensively in the
   forthcoming 1.7 release, and "allow" certainly seems like something
   we should have.

   But not everything is lost. One way to do what you want
   is with this filter:

   SecFilterSelective REQUEST_URI "!(\.jsp)|(\.gif)"

   * I've used SecFilterSelective to only look at the REQUEST_URI
     because that is where the filename is at. This way the filter
     is more efficient.

   * Note the exclamation mark at the beginning of the
     regular expression. It reverses its effect so the filter
     will match on those requests that do not satisfy the
     expression.

Bye,
Ivan

[mod-security-users] SecFilter rule processing questions

[Brett D. <bd...@b-...>]

Hi,

I've just subscribed so I'm not sure if this has been previously
discussed.

I've created a set of rules to explicitly allow certain files, e.g.

    SecFilter "\.jsp|\.html|\.css|\.js|\.gif|\.jpg" "allow"
    SecFilter  "^/$" "allow"     # (Still working on this one)

And I want to drop everything else.

    SecFilter ".+" "log,status:406"

But from looking at the debug,  when a match is made against the "allow"
rules, mod_security doesn't stop processing and continue on until it
either gets to the end of the filter rules, or hits a deny filter (e.g.
my deny everything else rule).  

Debug from request http://192.168.0.50/apache_pb.gif

[06/Aug/2003:11:01:33 +1000]
[192.168.0.50/sid#80ef438][rid#8185fd8][/apache_pb.gif] Checking
signature "\.jsp|\.html|\.css|\.js|\.gif|\.jpg" at THE_REQUEST
[06/Aug/2003:11:01:33 +1000]
[192.168.0.50/sid#80ef438][rid#8185fd8][/apache_pb.gif]
check_sig_against_string: string: /apache_pb.gif regex_result: 0
is_allow: 0


I'm assuming (Assumptions being the mother of all #$%^ ups) that the
"regex_result: 0 is_allow: 0" in the second line means it matched OK.
But it continues matching the request against the rest of the rules.

My question is,  is the 'allow' action the wrong action for the job and
I should be using a different action? 
 
Or is my rule set just destined to not work?
Is there a different approach I should be using to achieve the same
results?

Thanks

Brett

MBL: 0414 680 664
Direct Office: (03)96824977
*************************************
b-sec  http://www.b-sec.com.au

Melbourne: 03 9682 5700
Brisbane:  07 3374 3011
Sydney:    02 9908 5100
National Fax + 61 7 3374 3022

Email Disclaimer: www.b-sec.com.au/disclaimer.txt
*************************************

Re: [mod-security-users] UTC Logging in Apache

[Tyler <ty...@ty...>]

Ahh..  I think i found the problem, and the solution.  The main reason I
wanted to use mod_security was for its easy chroot feature, and that seems
to be the feature that's doing it.

Mod_security was enabled, but without the secChroot feature enabled.

I've pasted the error_log below.  Basically I restarted Apache, then I Added
the SecChroot line, and restarted again.  You can see the time difference in
the log.

Currently its 2:20 PM Mountain time, 8:20 PM UTC.

(~)# tail /var/log/apache/error_log
[Fri Jul 18 14:17:44 2003] [warn] child process 14990 still did not exit,
sending a SIGTERM
[Fri Jul 18 14:17:48 2003] [notice] caught SIGTERM, shutting down
[Fri Jul 18 14:18:12 2003] [notice] Apache/1.3.27 (Unix)  (Gentoo/Linux)
mod_ssl/2.8.14 OpenSSL/0.9.6i mod_perl/1.27 PHP/4.3.2 configured -- resuming
normal operations
[Fri Jul 18 14:18:12 2003] [notice] suEXEC mechanism enabled (wrapper:
/usr/sbin/suexec)
[Fri Jul 18 14:18:12 2003] [notice] Accept mutex: sysvsem (Default: sysvsem)
[Fri Jul 18 14:19:09 2003] [notice] caught SIGTERM, shutting down
[Fri Jul 18 20:19:17 2003] [notice] mod_security: performed chroot,
path=/www
[Fri Jul 18 20:19:17 2003] [notice] Apache/1.3.27 (Unix)  (Gentoo/Linux)
mod_ssl/2.8.14 OpenSSL/0.9.6i mod_perl/1.27 PHP/4.3.2 configured -- resuming
normal operations
[Fri Jul 18 20:19:17 2003] [notice] suEXEC mechanism enabled (wrapper:
/usr/sbin/suexec)
[Fri Jul 18 20:19:17 2003] [notice] Accept mutex: sysvsem (Default: sysvsem)


So I figured it was because Apache can't see the /etc/localtime file to know
what timezone I was in.  My chroot directory was set to /www  so I created
/www/etc/localtime and it logs in MDT now.

Don't know why I just figured this out now, but it makes sense.

Thank you for all your help.

Tyler

----- Original Message ----- 
From: "Ivan Ristic" <iv...@we...>
To: "Tyler" <ty...@ty...>
Cc: <mod...@li...>
Sent: Friday, July 18, 2003 2:14 PM
Subject: Re: [mod-security-users] UTC Logging in Apache


> Tyler wrote:
> > Yeah, all my Apache logs, access/error and per vhost logs are logging
UTC
> > time.  And yes, it does go away when I comment out the mod_security
module.
>
>    I've just examined the whole module and I don't have a clue. Send
>    me examples of how times are logged with and without mod_security
>    so that I can see the difference and I'll keep looking (obviosly,
>    this is not happening on any of my installations otherwise it
>    would be much easier to track it down).
>
> -- 
> ModSecurity (http://www.modsecurity.org)
> [ Open source IDS for Web applications ]
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: VM Ware
> With VMware you can run multiple operating systems on a single machine.
> WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
> same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
>