mod-security-users — General discussion about mod_security

[mod-security-users] Validation type of upload files

[Jochen K. <deb...@fr...>]

I have a PHP-form running at

 http://127.0.0.1/xxx.xxx/upload/upload.php

with a file-selection field.

All the date ist transmitted to

http://127.0.0.1/noeinfo.noe.de/upload/do_upload.php

Now I wan't to allow only image-files to be uploaded.
But the following does not work:

    <Location /var/www/noeinfo.noe.de/upload/upload.php>
            SecFilterInheritance Off
            SecFilterSelective POST_PAYLOAD "!image/(jpeg|bmp|gif)"
    </Location>

What's wrong here?

Thanx


-- 
Jochen Kaechelin

RE: [mod-security-users] REQUEST_URI decodes URI before running checks

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

I myself wrote:
> Here's the patch - tested and it works.  Reliable?  No idea yet :)
> About to put it in to production on 4 webservers.

Here's a URL to it as well:
http://www.hoktar.com/downloads/other/mod_security-1.9dev1-no_decoding.pa=
tch

Eli.

RE: [mod-security-users] REQUEST_URI decodes URI before running checks

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

Ivan wrote:
> Eli wrote:
>> Hm, apparently my stuff does zilch!  It compiles, no segfaults, no
apparent
>> memory leaks so far (didn't really test much in this area though), =
but
>> changing the "SecFilterDoURLDecoding" (which I noticed I reversed =
it's
>> meaning!  Heheh) to On/Off doesn't seem to make a difference at all.  =
I
have
>> a feeling I'm missing something big here!

>   Maybe there's code calling normalise_inplace() directly? I don't
>   have the time to check right now.
>
>   Anyway, poke around and I'm sure you'll figure it out. That's how
>   I do it anyway :)

Figured it out - I was dumb :)  Since I was just copying your code and
tweaking it - I copied one line where you get the CGI variables and you =
are
forcing decoding to be done.  I didn't know it was a forcing thing, I
thought it was initializing the value to a default so I had copied my =
thing
like yours...  Of course, this was always forcing it off so that's why =
it
wasn't working!

Here's the patch - tested and it works.  Reliable?  No idea yet :)  =
About to
put it in to production on 4 webservers.


*******NOTE*******  This is not to be used by clueless users!!!  Don't =
ask
me how to use it or what it does.  It's just something to fix *MY* =
problems.


--- mod_security.c.old  Fri Feb 18 12:34:53 2005
+++ mod_security.c      Fri Feb 18 14:10:54 2005
@@ -310,6 +310,7 @@
     int filters_clear;
     int range_start;
     int range_end;
+    int check_decoding;
     int check_encoding;
     int check_unicode_encoding;
     char *upload_dir;
@@ -1372,6 +1373,7 @@

     if (dcfg->range_start =3D=3D NOT_SET) dcfg->range_start =3D 0;
     if (dcfg->range_end =3D=3D NOT_SET) dcfg->range_end =3D 255;
+    if (dcfg->check_decoding =3D=3D NOT_SET) dcfg->check_decoding =3D =
0;
     if (dcfg->check_encoding =3D=3D NOT_SET) dcfg->check_encoding =3D =
0;
     if (dcfg->check_unicode_encoding =3D=3D NOT_SET)
dcfg->check_unicode_encoding =3D 0;
     if (dcfg->upload_dir =3D=3D NOT_SET_P) dcfg->upload_dir =3D NULL;
@@ -1418,6 +1420,7 @@

     dcfg->range_start =3D NOT_SET;
     dcfg->range_end =3D NOT_SET;
+    dcfg->check_decoding =3D NOT_SET;
     dcfg->check_encoding =3D NOT_SET;
     dcfg->check_unicode_encoding =3D NOT_SET;

@@ -1489,6 +1492,7 @@

     new->range_start =3D (child->range_start =3D=3D NOT_SET) ?
parent->range_start : child->range_start;
     new->range_end =3D (child->range_end =3D=3D NOT_SET) ? =
parent->range_end :
child->range_end;
+    new->check_decoding =3D (child->check_decoding =3D=3D NOT_SET) ?
parent->check_decoding : child->check_decoding;
     new->check_encoding =3D (child->check_encoding =3D=3D NOT_SET) ?
parent->check_encoding : child->check_encoding;
     new->check_unicode_encoding =3D (child->check_unicode_encoding =
=3D=3D
NOT_SET) ? parent->check_unicode_encoding : =
child->check_unicode_encoding;
     new->upload_dir =3D (child->upload_dir =3D=3D NOT_SET_P) ? =
parent->upload_dir
: child->upload_dir;
@@ -1856,6 +1860,8 @@
 char *normalise(request_rec *r, sec_dir_config *dcfg, char *_uri, char
**error_msg) {
     char *uri;

+    if (dcfg->check_decoding) return _uri;
+
     if (_uri =3D=3D NULL) return NULL;
     uri =3D ap_pstrdup(r->pool, _uri);
     if (uri =3D=3D NULL) return NULL;
@@ -3044,6 +3050,11 @@
     return NULL;
 }

+static const char *cmd_filter_no_url_decoding(cmd_parms * cmd,
sec_dir_config *dcfg, int flag) {
+    dcfg->check_decoding =3D flag;
+    return NULL;
+}
+
 static const char *cmd_filter_check_url_encoding(cmd_parms * cmd,
sec_dir_config *dcfg, int flag) {
     dcfg->check_encoding =3D flag;
     return NULL;
@@ -3489,6 +3500,15 @@
      },

      {
+         "SecFilterNoURLDecoding",
+         cmd_filter_no_url_decoding,
+         NULL,
+         CMD_SCOPE_ANY,
+         FLAG,
+         "On or Off to set whether URL decoding will be performed"
+     },
+
+     {
          "SecFilterCheckURLEncoding",
          cmd_filter_check_url_encoding,
          NULL,

---end of patch---


Eli.

Re: [mod-security-users] REQUEST_URI decodes URI before running checks

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

Eli wrote:
> Hm, apparently my stuff does zilch!  It compiles, no segfaults, no apparent
> memory leaks so far (didn't really test much in this area though), but
> changing the "SecFilterDoURLDecoding" (which I noticed I reversed it's
> meaning!  Heheh) to On/Off doesn't seem to make a difference at all.  I have
> a feeling I'm missing something big here!

   Maybe there's code calling normalise_inplace() directly? I don't
   have the time to check right now.

   Anyway, poke around and I'm sure you'll figure it out. That's how
   I do it anyway :)

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

RE: [mod-security-users] REQUEST_URI decodes URI before running checks

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

Hm, apparently my stuff does zilch!  It compiles, no segfaults, no =
apparent
memory leaks so far (didn't really test much in this area though), but
changing the "SecFilterDoURLDecoding" (which I noticed I reversed it's
meaning!  Heheh) to On/Off doesn't seem to make a difference at all.  I =
have
a feeling I'm missing something big here!

Eli.

------

I hacked in a flag called "SecFilterDoURLDecoding" (I think - haven't =
test
compiled yet) and hopefully added all the required entries for the
"dcfg->check_decoding" config paramater.  My only question is:


char *normalise(request_rec *r, sec_dir_config *dcfg, char *_uri, char
**error_msg) {
    char *uri;

    if (_uri =3D=3D NULL) return NULL;
    uri =3D ap_pstrdup(r->pool, _uri);
    if (uri =3D=3D NULL) return NULL;

    if (dcfg->check_decoding) return uri;         // is this correct?

    return normalise_inplace(r, dcfg, uri, error_msg);
}

I don't know if the "return uri" is the right way to do it or not.  Will
this cause a memory leak at all, or return something the user wouldn't
expect?

If that looks OK to you, I'm gonna test this out and see if it segs or =
not
:)  If not, I'll send you the patch - it's for the apache 1.x module =
only
though since I don't have Apache 2 to test with.  You don't have to =
include
it obviously - I'm sure it's a horrible hack, and it took me like 2 =
minutes
to hack this up so I'm sure you've got something much better planned.

Re: [mod-security-users] REQUEST_URI decodes URI before running checks

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

> Ok, the reason for not having this yet and not having it until v2.x - is it
> because of time required to work on development?  I don't mind helping...

   Two reasons: 1) it will break backward compatibility and 2) a lot of
   work is needed to do it right. No 2 is not a problem by itself but
   v2 is going to be a complete rewrite: I would much rather put that
   effort into v2 in the first place.



> I hacked in a flag called "SecFilterDoURLDecoding" (I think - haven't test
> compiled yet) and hopefully added all the required entries for the
> "dcfg->check_decoding" config paramater.  My only question is:
> 
> 
> char *normalise(request_rec *r, sec_dir_config *dcfg, char *_uri, char
> **error_msg) {
>     char *uri;
> 
>     if (_uri == NULL) return NULL;
>     uri = ap_pstrdup(r->pool, _uri);
>     if (uri == NULL) return NULL;
> 
>     if (dcfg->check_decoding) return uri;         // is this correct?
> 
>     return normalise_inplace(r, dcfg, uri, error_msg);
> }
> 
> I don't know if the "return uri" is the right way to do it or not.  Will
> this cause a memory leak at all, or return something the user wouldn't
> expect?

   It's fine. You can also move the line to the beginning of the
   function.


> to hack this up so I'm sure you've got something much better planned.

   I'd like to be able to configure individual anti-evasion methods on
   the per-rule basis. Some methods are appropriate for some things and
   not for others.

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

RE: [mod-security-users] REQUEST_URI decodes URI before running checks

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

Ivan wrote:
> Eli wrote:
> Now, I couldn't find out if there's a way to disable this URI decoding so
it

>    Correct, because there isn't one.

Gah!

Ok, the reason for not having this yet and not having it until v2.x - is it
because of time required to work on development?  I don't mind helping...

I hacked in a flag called "SecFilterDoURLDecoding" (I think - haven't test
compiled yet) and hopefully added all the required entries for the
"dcfg->check_decoding" config paramater.  My only question is:


char *normalise(request_rec *r, sec_dir_config *dcfg, char *_uri, char
**error_msg) {
    char *uri;

    if (_uri == NULL) return NULL;
    uri = ap_pstrdup(r->pool, _uri);
    if (uri == NULL) return NULL;

    if (dcfg->check_decoding) return uri;         // is this correct?

    return normalise_inplace(r, dcfg, uri, error_msg);
}

I don't know if the "return uri" is the right way to do it or not.  Will
this cause a memory leak at all, or return something the user wouldn't
expect?

If that looks OK to you, I'm gonna test this out and see if it segs or not
:)  If not, I'll send you the patch - it's for the apache 1.x module only
though since I don't have Apache 2 to test with.  You don't have to include
it obviously - I'm sure it's a horrible hack, and it took me like 2 minutes
to hack this up so I'm sure you've got something much better planned.

Eli.

Re: [mod-security-users] REQUEST_URI decodes URI before running checks

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

Eli wrote:
> Now, I couldn't find out if there's a way to disable this URI decoding so it

   Correct, because there isn't one.

   (ducks)

   It's a curse and a blessing. In the current version it is not possible
   to disable anti-evasion techniques (URL decoding is one of them). It
   will be possible to fine-tune this behaviour in one of the future
   versions (not 1.9, most likely the one after that).

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

[mod-security-users] REQUEST_URI decodes URI before running checks

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

I didn't notice this in the documentation at first, but just ran in to =
the
outcome of not knowing about it...

I have this in my config:

        SecFilterEngine On
        SecFilterScanPOST Off
        SecFilterCheckURLEncoding Off
        SecFilterCheckUnicodeEncoding Off
        SecFilterNormalizeCookies Off
        SecFilterCheckCookieFormat Off
        SecFilterDefaultAction "log,deny,status:403"
        SecFilterSelective "REQUEST_URI" "!^[\x20-\x7E]+$"
"log,deny,status:403"

The REQUEST_URI check was my attempt to limit the characters in the URI =
(GET
requests) only, and at first it seemed just fine (restricts you to using
ASCII 32 to ASCII 126), however I just found out that mod_security =
decodes
the URI before checking it:

[Fri Feb 18 11:19:26 2005] [error] [client 216.209.84.151] mod_security:
Access denied with code 403. Pattern match "!^[\x20-\x7E]+$" at =
REQUEST_URI
[hostname "xxx"] [uri "/search.php?q=3D%A9"]

I tested and it is being caused by the "%A9" in the URI.

Now, I couldn't find out if there's a way to disable this URI decoding =
so it
instead will check exactly what the client types in as is, nor could I
figure out if there's another CGI paramater that has the same info as
REQUEST_URI but would not have it decoded before checking.

Any pointers to what I'd need?  I'm sure it's in the manual somewhere =
but I
haven't found it yet...

Oh, I'm using the dev version, so I can use all the new features in the
reference manual.

Eli.

Re: [mod-security-users] Help! Can't even get a basic configuration working! :(

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

Boocock, John (CSS) wrote:
> I am having frustrating problems in that I can=92t get even the most ba=
sic=20
> configuration to work with mod_security, I was trying to set it up so=20
> that initially I can stop our Apache 1.3 (+Tomcat 3) web server=20
> servicing requests which feature =93..=94, and if this worked removing=20
> multiple forward slashes in requests as we get odd results from=20
> accessing apps if you enter multiple slashes such as=20
> http://domain.com//app1//
 >
 > ...
 > SecFilter "\.\./"
 >
> However if I go to http://domain.com/somepath/../ I can still get the=20
> front page on the web server and nothing appears in the audit log.

   That's because Apache normalizes the URI before it reaches
   mod_security. If you send a request like this one:

   http://domain.com/somepath/?x=3D../tra/la/la

   ..it would get caught by mod_security.

   You may be able to use mod_rewrite though. It may be that it gets
   to run before Apache performs normalisation.


> I know mod_security is doing something as if I turn the debug log on, o=
r=20
> change SecAuditEngine to On I see inbound connections being logged, the=
=20
> problem is I still can use ../ in URLS and nothing is logged.

   If you crank up the debug log level you should see mod_security
   accessing a normalized URI.


> I hope someone can help as I=92m very disappointed with myself especial=
ly=20
> that I can=92t even get this working!

   Don't worry, it's not your fault :) It's Apache and its peculiarities.


> Also, does mod_security work with piped logs like apache? Just wonderin=
g=20
> as some extra modules such as mod_jk (or at least the version of mod_jk=
=20
> I have) won=92t work with them and I=92d like to rotate them with crono=
log=20
> if possible.

   It doesn't. It's possible to add piped logging for the debug log but
   since one should always use a debug level of zero in production this
   is not a very useful feature. It is not possible to support piped
   logging for the audit log because it (piped logging) does not support
   locking and audit log spans multiple lines.

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

[mod-security-users] Help! Can't even get a basic configuration working! :(

[Boocock, J. (CSS) <Joh...@ca...>]

All, I'm wondering if you can help me please,

 

I am having frustrating problems in that I can't get even the most basic
configuration to work with mod_security, I was trying to set it up so that
initially I can stop our Apache 1.3 (+Tomcat 3) web server servicing
requests which feature "..", and if this worked removing multiple forward
slashes in requests as we get odd results from accessing apps if you enter
multiple slashes such as http://domain.com//app1//

 

I have the following defined at the start of my httpd.conf:

 

<IfModule mod_security.c>

  # The name of the audit log file

  SecAuditLog /www/apache/common/logs/audit_log

  SecAuditEngine RelevantOnly

  SecFilterDebugLog /www/apache/common/logs/modsec_debug_log

  SecFilterDebugLevel 0

  # Turn the filtering engine On or Off

  SecFilterEngine On

  # Action to take by default

  SecFilterDefaultAction "deny,log,status:403"

  # Prevent path traversal (..) attacks

  SecFilter "\.\./"

</IfModule>

 

However if I go to http://domain.com/somepath/../ I can still get the front
page on the web server and nothing appears in the audit log.

 

I know mod_security is doing something as if I turn the debug log on, or
change SecAuditEngine to On I see inbound connections being logged, the
problem is I still can use ../ in URLS and nothing is logged.

 

The platform is Sun Solaris 9, using apache 1.3.33, mod_ssl-2.8.22 and
mod_security-1.8.6 compiled in statically, with mod_jk loaded as a DSO,
"httpd -l" shows the following:

 

Compiled-in modules:

  http_core.c

  mod_env.c

  mod_log_config.c

  mod_mime.c

  mod_negotiation.c

  mod_status.c

  mod_info.c

  mod_include.c

  mod_autoindex.c

  mod_dir.c

  mod_cgi.c

  mod_asis.c

  mod_imap.c

  mod_actions.c

  mod_userdir.c

  mod_alias.c

  mod_access.c

  mod_auth.c

  mod_auth_dbm.c

  mod_proxy.c

  mod_so.c

  mod_setenvif.c

  mod_ssl.c

  mod_security.c

 

It was build using nothing fancy:

 

./configure --prefix=/www/apache/apache_1.3.33+mod_ssl-2.8.22 \

--enable-module=ssl \

--disable-rule=SSL_COMPAT \

--enable-rule=SSL_SDBM \

--enable-module=rewrite \

--enable-shared=rewrite \

--enable-module=proxy \

--enable-module=auth_dbm \

--enable-module=info \

--add-module=../mod_security-1.8.6/apache1/mod_security.c

 

Tomcat's configured to run through Apache only for servlets and .jsp files,
so that Apache's security features are still applicable up front.

 

I hope someone can help as I'm very disappointed with myself especially that
I can't even get this working!

 

Also, does mod_security work with piped logs like apache? Just wondering as
some extra modules such as mod_jk (or at least the version of mod_jk I have)
won't work with them and I'd like to rotate them with cronolog if possible.

 

Many thanks in advance.

 

JB



**********************************************************************************
This email and any files transmitted with it are confidential, and may be subject to legal privilege, and are intended solely for the use of the individual or entity to whom they are addressed.  
If you have received this email in error or think you may have done so, you may not peruse, use, disseminate, distribute or copy this message. Please notify the sender immediately and delete the original e-mail from your system.

Computer viruses can be transmitted by e-mail. Recipients should check this e-mail for the presence of viruses. The Capita Group and its subsidiaries accept no liability for any damage caused by any virus transmitted by this e-mail.
***********************************************************************************

Re: [mod-security-users] moinmoin with mod_security

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

kr...@fr... wrote:
> hello! 
> i've a problem with moinmoin and mod_security.
> this is the error:
> [Sun Feb 13 05:14:02 2005] [error] [client 80.18X.XX.XX]
 > Premature end of script headers: /usr/share/moin/mywiki/cgi-bin/moin.cgi

   On every request or on some requests? Which version of mod_security?

   You need to give us more information about your system. See here:
   http://www.modsecurity.org/documentation/support-request-checklist.html

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

[mod-security-users] moinmoin with mod_security

[<kr...@fr...>]

hello! 



i've a problem with moinmoin and mod_security.



this is the error:



[Sun Feb 13 05:14:02 2005] [error] [client 80.18X.XX.XX] Premature end of script headers: /usr/share/moin/mywiki/cgi-bin/moin.cgi



this is my mod_security configuration:



<IfModule mod_security.c>

        # Turn the filtering engine On or Off

        # (or DynamicOnly - but it'll require a bit further configuration)

        SecFilterEngine On



        # This will fool a lot of script kiddies to waste their time attacking $        # with IIS4 exploits - enjoy it by viewing their futile attempts in Apa$        SecServerSignature "Microsoft-IIS/5.0"



        # Some sane defaults

        SecFilterScanPOST On

        SecFilterCheckURLEncoding On

        SecFilterCheckCookieFormat On

        SecFilterCheckUnicodeEncoding Off



        # Only allow bytes from this range

        SecFilterForceByteRange 0 255



        # Only log suspicious requests

        SecAuditEngine RelevantOnly

        SecAuditLog /var/log/apache/modsec_audit_log



        # Debug level set to a minimum

        SecFilterDebugLevel 0

        SecFilterDebugLog /var/log/apache/modsec_debug_log



        # By default log and deny suspicious requests

        # with HTTP status 403

        SecFilterDefaultAction "deny,log,status:403"



        # Basic protection against SQL attacks

        SecFilter "delete[[:space:]]+from"

        SecFilter "insert[[:space:]]+into"

        SecFilter "select.+from"



        #Protect against attacks on critical directories

        SecFilter /boot

        SecFilter /bin

        SecFilter /sbin

        SecFilter /etc

        SecFilter /lib

        SecFilter /root

        SecFilter /home

        SecFilter /tmp

        SecFilter /usr

        Secfilter /var



        # Basic protection against XSS attacks :

        # filter out any <script> tag on URL

        SecFilter "<[[:space:]]*script"

        # filter out any HTML tag on URL

        SecFilter "<.+>"

        # Basic protection against Directory traversal attacks

        SecFilter "\.\./"



        # Basic protection agains Command execution attacks

        SecFilter /bin/sh

        SecFilter /bin/bash

        SecFilter /bin/ls

        SecFilter /etc/passwd

        SecFilter /etc/shadow



        # Should mod_security inspect POST payloads

        SecFilterScanPOST On

        # Only accept request encodings we know how to handle

        # we exclude GET requests from this because some (automated)

        # clients supply "text/html" as Content-Type

        SecFilterSelective REQUEST_METHOD "!^(GET|HEAD)$" chain

        SecFilterSelective HTTP_Content-Type "!(^application/x-www-form-urlencoded$|^multipart/form-data;)"



        # Require Content-Length to be provided with every POST request

        SecFilterSelective REQUEST_METHOD "^POST$" chain

        SecFilterSelective HTTP_Content-Length "^$"



        # Protect against Chunked transfer requests

        SecFilterSelective HTTP_Transfer-Encoding "!^$"



        # The following will only allow "admin" user to logon

        # if they're connecting via the specified IP address

        #SecFilterSelective ARG_username admin chain

        #SecFilterSelective REMOTE_ADDR "!^ADMIN_IP_ADDRESS_HERE$"



</IfModule>





without loading mod_security all works ok.



ciao

---------------------------------------------------------------
Scegli il tuo dominio preferito e attiva la tua email! Da oggi
l'eMail di superEva e' ancora piu' veloce e ricca di funzioni!
http://webmail.supereva.it/new/
---------------------------------------------------------------

Re: [mod-security-users] Advanced filtering

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

At Tue, 08 Feb 2005 19:03:51 +0000,
Ivan Ristic wrote:
> 
>     That's not possible at the moment. However, it makes sense and I'll
>     make it possible in 1.9. (The "!ARG_xyz" syntax only works with
>     "ARGS" at the moment.)
> 
> 
snip...
> 
>     In 1.9 it's:
> 
>     SecFilterSelective THE_REQUEST|POST_PAYLOAD|HEADERS foo deny,log
> 
>     I can add EVERYWHERE to make it even simpler :)
> 
>     Although do note OUTPUT only covers the response body at this time.
>     It doesn't include the response headers.
> 

It sounds good.
Thank you for your great work.

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

Re: [mod-security-users] exempting certain virtual hosts from filters? (mt-comments.cgi filter)

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

Fred Stutzman wrote:
> A ruleset like this is well-suited for blocking movable type:
> 
> # Block Movable Type Comments
> SecFilterSelective REQUEST_URI "mt-comments.cgi" chain

   While there the chances of suffering a false positive in
   this case are small, you might want to look at using a
   tighter filter for other filters.

   SecFilterSelective SCRIPT_FILENAME "mt-comments.cgi$" chain

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

RE: [mod-security-users] mod_security throttling?

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

>> I'm trying to find a way to block the bulk of Movable Type  comment 
>> spam at the apache level, rather than at the weblog level. Is 
>> mod_security capable of any kind of throttling, i.e. more than a given 
>> number of requests on a single script per  time interval get dropped? 
>> Or is this a job for mod_dosevasive?

>   mod_dosevasive can do it but it works on per-process level. There's
>   no security-aware throttling module available for Apache that I'm
>   aware. ModSecurity 2.x will be.

>   What rate of comment spam are you getting? There's a script called
>   apache-protect (http://www.apachesecurity.net), which monitors
>   mod_status output to detect too many requests for the same URL. It
>   then uses iptables to ban the offending IP address.


This is only for Apache 1.3.x but does what you want:

http://www.snert.com/Software/mod_throttle/

However, no compatibility for Apache 2.x.  Also be cautious as there is an
apparent root exploit possible for the current version - version 4 which is
not yet released is supposed to fix this bug.

I found this for Apache 2.x:

http://www.topology.org/src/bwshare/README.html

Let me know if you test bwshare in Apache 2.x - I'd be interested to know if
it works well or not.

Eli.

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

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

Rudi wrote: 

> So instead of using a *not* reg ex I'll go the other way:
>
> Use this to find matches:
> <Files ~
"(main|movie|dvd4abuck|latest|popular|cat|stream|vote|movie|upcoming|wildpas
s|allcontent2)$">
>
> Instead of finding *not* matches
> <FilesMatch "(?<!login)$">

Untested, but if Apache allows this trick (which is POSIX regex compatible
even), it should technically do the trick:

<Files ~ "(login){0}$">

The {0} specifies that it should *NOT* find "login" at the end of the line.

Eli.

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

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

Hi,

Thanks for the replies.

Unfortunately none of them would work for me on my machine.

Sample URLs:
http://www.myserver.com/members.login
http://www.myserver.com/members.main
http://www.myserver.com/members.stream
http://www.myserver.com/members.cat

So instead of using a *not* reg ex I'll go the other way:

Use this to find matches:
<Files ~ 
"(main|movie|dvd4abuck|latest|popular|cat|stream|vote|movie|upcoming|wildpass|allcontent2)$">

Instead of finding *not* matches
<FilesMatch "(?<!login)$">

Not what I was exactly after but it does exactly what I need

Cheers
Rudi

Ivan Ristic wrote:

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

Re: [mod-security-users] exempting certain virtual hosts from filters? (mt-comments.cgi filter)

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

A ruleset like this is well-suited for blocking movable type:

# Block Movable Type Comments
SecFilterSelective REQUEST_URI "mt-comments.cgi" chain
SecFilterSelective REQUEST_METHOD "POST" chain
SecFilterSelective SERVER_NAME "foo.org" allow,nolog

This rule blocks all posts to mt-comments.cgi (still allowing your users to 
see their exsiting comments) and allows posts from only foo.org.

You can add an instance of this rule for all domains that patch their 
movable types.  FWIW, you might want to implement this for mt-tb.cgi as 
well, trackback spam is becoming quite prevalent.




On Tue, 8 Feb 2005, Hugh Beaumont wrote:

> Hi,
>
> I have server configured as follows :
>
> server wide mod_security rules set up in httpd.conf
>
> and then virtual hosts added at the end of httpd.conf
>
> Right now, the mod_security rules affect all virtual hosts.
>
> I would like to have the option to turn off certain rules for some hosts.
> Is there a way to do this? A way to unset a rule?
>
> The only way I've thought of is to define the rules inside of the virtual hosts
> instead of server wide. I would prefer not to do this since in the majority of
> cases the rules should be enforced - it is only a select few that need them
> waived.
>
> Are there resource/performance issues I would need to worry about if I resort defining the rules
> inside each virtual host?
>
> Thanks for any advice.
>
> By the way, what I'm trying to resolve are the recent issues with Moveable Type blogs where
> spammers are calling mt-comments.cgi repeatly and causing a DOS.
>
> For now I'm planning to just reject all requests for mt-comments.cgi and then only turn it on for
> users who complain. I believe we have a lot of users who have the script installed but no longer
> use it.
>
> Please let me know if anyone has a better solution to the recent Moveable Type issues (other than
> upgrades which are too hard to get all users to do right now - I'm looking for a quick fix to stop
> the problem ASAP).
>
> Thanks!
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail - now with 250MB free storage. Learn more.
> http://info.mail.yahoo.com/mail_250
>
>
> -------------------------------------------------------
> 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

Re: [mod-security-users] exempting certain virtual hosts from filters? (mt-comments.cgi filter)

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

Hugh Beaumont wrote:
> Hi,
> 
> I have server configured as follows :
> 
> server wide mod_security rules set up in httpd.conf
> 
> and then virtual hosts added at the end of httpd.conf
> 
> Right now, the mod_security rules affect all virtual hosts.
> 
> I would like to have the option to turn off certain rules for some hosts.
> Is there a way to do this? A way to unset a rule?

   <VirtualHost ...>
   SecFilterEngine Off
   </VirtualHost>

   or

   <VirtualHost ...>
   SecFilterInheritance off
   # same configuration as the parent but no rules
   # ...
   # new rules here ...
   </VirtualHost>


> Are there resource/performance issues I would need to worry about if I resort defining the rules
> inside each virtual host?

   No, I don't think there's any difference.

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

Re: [mod-security-users] mod_security throttling?

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

> I'm trying to find a way to block the bulk of Movable Type  comment spam at
> the apache level, rather than at the weblog level. Is mod_security capable
> of any kind of throttling, i.e. more than a given number of requests on a
> single script per  time interval get dropped? Or is this a job for
> mod_dosevasive?

   mod_dosevasive can do it but it works on per-process level. There's
   no security-aware throttling module available for Apache that I'm
   aware. ModSecurity 2.x will be.

   What rate of comment spam are you getting? There's a script called
   apache-protect (http://www.apachesecurity.net), which monitors
   mod_status output to detect too many requests for the same URL. It
   then uses iptables to ban the offending IP address.

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

[mod-security-users] exempting certain virtual hosts from filters? (mt-comments.cgi filter)

[Hugh B. <hbe...@ya...>]

Hi,

I have server configured as follows :

server wide mod_security rules set up in httpd.conf

and then virtual hosts added at the end of httpd.conf

Right now, the mod_security rules affect all virtual hosts.

I would like to have the option to turn off certain rules for some hosts.
Is there a way to do this? A way to unset a rule?

The only way I've thought of is to define the rules inside of the virtual hosts
instead of server wide. I would prefer not to do this since in the majority of
cases the rules should be enforced - it is only a select few that need them
waived.

Are there resource/performance issues I would need to worry about if I resort defining the rules
inside each virtual host?

Thanks for any advice.

By the way, what I'm trying to resolve are the recent issues with Moveable Type blogs where
spammers are calling mt-comments.cgi repeatly and causing a DOS. 

For now I'm planning to just reject all requests for mt-comments.cgi and then only turn it on for
users who complain. I believe we have a lot of users who have the script installed but no longer
use it. 

Please let me know if anyone has a better solution to the recent Moveable Type issues (other than
upgrades which are too hard to get all users to do right now - I'm looking for a quick fix to stop
the problem ASAP).

Thanks!



		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - now with 250MB free storage. Learn more.
http://info.mail.yahoo.com/mail_250

[mod-security-users] mod_security throttling?

[Scot H. <sh...@bi...>]

Hi -

I'm trying to find a way to block the bulk of Movable Type  comment spam at
the apache level, rather than at the weblog level. Is mod_security capable
of any kind of throttling, i.e. more than a given number of requests on a
single script per  time interval get dropped? Or is this a job for
mod_dosevasive?

I know that mod_security can be made to integrate with MT Blacklist, but
that approach will not catch the bulk of requests that can  cripple a server
with a lot  of MT blogs, since most server-crippling comment spam sessions
include strings that are not yet  blacklisted;  hence I'd like to try
another approach --  blocking any too-frequent CGI requests.

Thanks,
Scot

Re: [mod-security-users] Chroot + Frontpage

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

Domenico "DoM" De Monte wrote:
> 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 :!

   :)

   You should try running Apache as a single process (-X) in order to
   attach strace to it to observe what FrontPage is trying to do. For
   example:

   # cd /usr/local/apache
   # strace ./bin/httpd -X -f ./conf/httpd.conf

   Now try to connect. Hopefully you will get something meaningful.

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

Re: [mod-security-users] Advanced filtering

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

Katsuharu Watanabe wrote:
> 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.

    That's not possible at the moment. However, it makes sense and I'll
    make it possible in 1.9. (The "!ARG_xyz" syntax only works with
    "ARGS" at the moment.)


>  (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?

    In 1.9 it's:

    SecFilterSelective THE_REQUEST|POST_PAYLOAD|HEADERS foo deny,log

    I can add EVERYWHERE to make it even simpler :)

    Although do note OUTPUT only covers the response body at this time.
    It doesn't include the response headers.

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