mod-security-users — General discussion about mod_security

[mod-security-users] Apache2 / mod_sec per virtual host config?

[Jan G. <jan...@pr...>]

Hi there

As I fummbled around with this great mod I found out that in my 
configuration, as soon as I activate mod_security in one virtual host 
(name based), _all_ virtual hosts have mod_sec activated with the rules 
I defined for that one special vhost.

As I read from the documentation this should not be the case - so: what 
am I missing? Is it a mod_sec version-thing?

My setup in short:

Debian Sid
Apache/2.0.52
libapache2-mod-security 1.8.4-1.1 (most recent :-/ Debian package)

apache2.conf has no mod_sec defined, it includes multiple vhost-confs 
right before EOF, so it basically looks like this:

<VirtualHost ip.ad.re.ss:80>
ServerName A
... (no mod_sec)
</VirtualHost>

<VirtualHost ip.ad.re.ss:80>
ServerName B
-> mod_sec enabled
</VirtualHost>

<VirtualHost ip.ad.re.ss:80>
ServerName C
...  (no mod_sec)
</VirtualHost>


-> allthough mod_sec is only enabled and configured in vhost B, all 
three vhosts have it activated and the rules applied.

Thanks for your help,
Jan

-- 
You never see empty pot boil over
(Jamaican)

Re: [mod-security-users] Santy worm

[Gerwin K. -|- D. W. <ge...@di...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ye we already had some site being defaced. But i made a good filter i think:

SecFilterSelective ARGS "fwrite"
SecFilterSelective ARGS "fopen"
SecFilterSelective ARGS "chr\("
SecFilterSelective ARGS "echr\("
SecFilterSelective ARGS "system\("

Support wrote:
| Has anyone found a way to block the Santy worm with mod_security?
|
| http://www.f-secure.com/v-descs/santy_a.shtml
|
|
|
|
| -------------------------------------------------------
| 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://productguide.itmanagersjournal.com/
| _______________________________________________
| mod-security-users mailing list
| mod...@li...
| https://lists.sourceforge.net/lists/listinfo/mod-security-users
|
|


- --
Met vriendelijke groet/With kind regards,

Gerwin Krist

Digitalus
First-class Internet Webhosting

(w) http://www.digitalus.nl
(e) gerwin at digitalus.nl
(p) PGP-ID: 79B325D4
(t) +31 (0) 598 630000
(f) +31 (0) 598 631860


***************************************************************************************
This message may contain information which is confidential or privileged.
If you are not the intended recipient, please advise the sender immediately
by reply e-mail and delete this message and any attachments without
retaining
a copy.
***************************************************************************************


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFByRqsCwaJ0XmzJdQRAmrnAJ9rjD83f1EScGOMwHWqgWf66jrA6QCgrSW7
VwfHM7nnT9VLJLQCO5XGQNs=
=Y1xy
-----END PGP SIGNATURE-----

Re: [mod-security-users] Santy worm

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

Support wrote:
> Has anyone found a way to block the Santy worm with mod_security?
> 
> http://www.f-secure.com/v-descs/santy_a.shtml

   After looking at the information available online I think the
   following may work:

   SecFilterSelective ARG_highlight %27

   Assuming the worm attempts to exploit the PHPBB highlight problem. But
   I don't have a working (and vulnerable) copy of PHPBB installed so
   don't take my word for it. If you find the source code of the worm
   send it my way and I'll craft a rule to stop it.

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

[mod-security-users] Santy worm

[Support <su...@ez...>]

Has anyone found a way to block the Santy worm with mod_security?

http://www.f-secure.com/v-descs/santy_a.shtml

[mod-security-users] Re: Chroot, piped logging & failure to restart child process

[David F. <Da...@me...>]

Hi all,

Just a quick follow up on the problem I found with logging reliability when
using the chroot feature of mod_security. I suggested a fix on here before, but
it was rather clumsy.

I have been writing an additional test called "apache-status" for the Monit
project at http://www.tildeslash.com/monit/ which can check the mod_status
output of Apache. It's very configurable, and can take action if it spots that
(for example) more than 50% of Apache processes are logging, or over 25% of
processes are stuck doing DNS lookups. Actions can include restarting the
server, or simply sending an email to warn of problems.

The apache-status test is currently in the CVS version of Monit.

Regards,

David.

-- 
---------------------------------------
Email da...@me...
---------------------------------------

[mod-security-users] Re: problems with apache2 + chroot + httpd.pid

[David F. <Da...@me...>]

Hi Raphael and everyone,

I had the same issue with the pid file, but I solved it by making a change to
the etc/rc.d/httpd file which starts and stops Apache. The change makes this
script aware of the chroot, and also adds code to check that the pid
does point to a running httpd process. This covers the case where Apache dies,
or power is cut etc, leaving a pid which might point to a running process other
than Apache when the server is restarted

The entire script is below. You can compare to the standard one that comes with
Apache to see the changes.

Regards,

David.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/etc/rc.d/httpd
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#!/bin/sh

ARGV="$@"
#
# |||||||||||||||||||| START CONFIGURATION SECTION  ||||||||||||||||||||
# --------------------                              --------------------
# 
# the path to your PID file, prior to chroot set-up, if any
PIDFILE=/usr/local/apache/logs/httpd.pid
# the path to your httpd binary, including options if necessary
HTTPD='/usr/local/apache/bin/httpd'
# the path to the chroot created by mod_security, otherwise leave empty
CHROOT='/chroot/apache'
#
# pick up any necessary environment variables
if test -f /usr/local/apache/bin/envvars; then
  . /usr/local/apache/bin/envvars
fi
#
# a command that outputs a formatted text version of the HTML at the
# url given on the command line.  Designed for lynx, however other
# programs may work.  
LYNX="lynx -dump"
#
# the URL to your server's mod_status status page.  If you do not
# have one, then status and fullstatus will not work.
STATUSURL="http://localhost:80/server-status"
#
# Set this variable to a command that increases the maximum
# number of file descriptors allowed per child process. This is
# critical for configurations that use many file descriptors,
# such as mass vhosting, or a multithreaded server.
ULIMIT_MAX_FILES="ulimit -S -n `ulimit -H -n`"
# --------------------                              --------------------
# ||||||||||||||||||||   END CONFIGURATION SECTION  ||||||||||||||||||||

# Set the maximum number of file descriptors allowed per child process.
if [ "x$ULIMIT_MAX_FILES" != "x" ] ; then
    $ULIMIT_MAX_FILES
fi

ERROR=0
if [ "x$ARGV" = "x" ] ; then 
    ARGV="-h"
fi

#Check that an old PID file in chroot has got left after power outage etc.
#If a PID file exists, check it points to a running httpd
if [ -f $CHROOT$PIDFILE ] ; then
    PID=`cat $CHROOT$PIDFILE`
    PIDPROC=`ps -p $PID -o comm --no-headers 2>/dev/null`
    if [ "x$PID" != "x" ] && [ "x$PIDPROC" != "xhttpd" ] ; then
        #pid points to a valid process, but it is not httpd
        rm $CHROOT$PIDFILE 2>/dev/null
    fi
fi

case $ARGV in
start|restart|graceful)
    $HTTPD -k $ARGV
    ERROR=$?
    ;;
stop)
    $HTTPD -k $ARGV -c "PidFile $CHROOT$PIDFILE"
    ERROR=$?
    ;;
startssl|sslstart|start-SSL)
    $HTTPD -k start -DSSL
    ERROR=$?
    ;;
configtest)
    $HTTPD -t
    ERROR=$?
    ;;
status)
    $LYNX $STATUSURL | awk ' /process$/ { print; exit } { print } '
    ;;
fullstatus)
    $LYNX $STATUSURL
    ;;
*)
    $HTTPD $ARGV
    ERROR=$?
esac

exit $ERROR

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



-- 
---------------------------------------
Email da...@me...
---------------------------------------

Re: [mod-security-users] problems with apache2 + chroot + httpd.pid

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

Raphael Koifman wrote:
> Hello,
> The setup is as follows:
> 
> - apache2 is located at /usr/local/sbin/apache2.0.52/
> - the jail is at /chroot/ust/local/sbin/apache2.0.52/logs

   I think you should have a symbolic link from
   /usr/local/sbin/apache2.0.52/ to /chroot/usr/local/sbin/apache2.0.52/


> in httpd.conf:
> - the pid location is PidFile /usr/local/sbin/apache2.0.52/logs/httpd.pid
> - chroot is SecChrootDir /chroot
> 
> 1) First case
> If I use this configuration, Apache2 starts well and chroot is setup
> [taken from error.log]
> 
> [Sun Dec 12 16:05:57 2004] [notice] mod_security: chroot checkpoint #1 (pid=18071 
> ppid=18069)
> [Sun Dec 12 16:05:57 2004] [notice] mod_security: chroot checkpoint #2 
> (pid=18072ppid=18071)
> [Sun Dec 12 16:05:57 2004] [notice] mod_security: chroot successful, path=/chroot
> [Sun Dec 12 16:05:57 2004] [notice] Apache configured -- resuming normal operations
> 
> however, when I try to stop apache (bin/apachectl stop), I get the following error:
> httpd (no pid file) not running

   In this case, the pidfile is created at the correct location, at
   /chroot/usr/local/sbin/apache2.0.52/logs/httpd.pid (since it's done
   after chroot takes place). The reason Apache can't find it later is
   because it's looking for it at
   /usr/local/sbin/apache2.0.52/logs/httpd.pid.

   A symbolic link, as I suggested at the beginning of this email, would
   make these two locations identical, solving your problem.


> 2) Second case
> If I modify httpd.conf to point the pid file to /chroot/usr/local/sbin/apache2.0.52/logs/httpd.pid
> I get the following error
> 
> [Sun Dec 12 16:38:08 2004] [notice] mod_security: chroot checkpoint #1 (pid=18110 
> ppid=18108)
> [Sun Dec 12 16:38:08 2004] [notice] mod_security: chroot checkpoint #2 (pid=18111 
> ppid=18110)
> [Sun Dec 12 16:38:08 2004] [notice] mod_security: chroot successful, path=/chroot
> [Sun Dec 12 16:38:08 2004] [error] (2)No such file or directory: could not create 
> /chroot/usr/local/sbin/apache2.0.52/logs/httpd.pid
> [Sun Dec 12 16:38:08 2004] [error] httpd: could not log pid to file 
> /chroot/usr/local/sbin/apache2.0.52/logs/httpd.pid
> 
> Can somebody please shed some light on the mistake I am making ? (is it a permission 
> problem on the /chroot/usr/local/sbin/apache2.0.52/logs/ fodler ?)

   No. After the chroot that location simply does not exist in the new
   filesystem.

   P.S. You need to subscribe to the mailing list if you wish to continue
        to send emails.

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

[mod-security-users] problems with apache2 + chroot + httpd.pid

[Raphael K. <di...@ko...>]

Hello,

First of all, thank you Ivan for this software.

I have a small problem setting up chroot for Apache2.0.52. 

The setup is as follows:

- apache2 is located at /usr/local/sbin/apache2.0.52/
- the jail is at /chroot/ust/local/sbin/apache2.0.52/logs

in httpd.conf:
- the pid location is PidFile /usr/local/sbin/apache2.0.52/logs/httpd.pid
- chroot is SecChrootDir /chroot

1) First case
If I use this configuration, Apache2 starts well and chroot is setup
[taken from error.log]

[Sun Dec 12 16:05:57 2004] [notice] mod_security: chroot checkpoint #1 (pid=18071 
ppid=18069)
[Sun Dec 12 16:05:57 2004] [notice] mod_security: chroot checkpoint #2 
(pid=18072ppid=18071)
[Sun Dec 12 16:05:57 2004] [notice] mod_security: chroot successful, path=/chroot
[Sun Dec 12 16:05:57 2004] [notice] Apache configured -- resuming normal operations

however, when I try to stop apache (bin/apachectl stop), I get the following error:
httpd (no pid file) not running

2) Second case
If I modify httpd.conf to point the pid file to /chroot/usr/local/sbin/apache2.0.52/logs/httpd.pid
I get the following error

[Sun Dec 12 16:38:08 2004] [notice] mod_security: chroot checkpoint #1 (pid=18110 
ppid=18108)
[Sun Dec 12 16:38:08 2004] [notice] mod_security: chroot checkpoint #2 (pid=18111 
ppid=18110)
[Sun Dec 12 16:38:08 2004] [notice] mod_security: chroot successful, path=/chroot
[Sun Dec 12 16:38:08 2004] [error] (2)No such file or directory: could not create 
/chroot/usr/local/sbin/apache2.0.52/logs/httpd.pid
[Sun Dec 12 16:38:08 2004] [error] httpd: could not log pid to file 
/chroot/usr/local/sbin/apache2.0.52/logs/httpd.pid

Can somebody please shed some light on the mistake I am making ? (is it a permission 
problem on the /chroot/usr/local/sbin/apache2.0.52/logs/ fodler ?)

Thank you very much in advance.





 

Re: [mod-security-users] Error: apache-monitor.pl

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

> This email is with regard to the apache-monitor.pl found at 
> http://www.apachesecurity.net.
> 
> I found the link via modsecurity.org and I believe the author is the same.

   Yep, that's me.


> Sorry if this is off-topic and/or not apporpriate but I didn't know 
> where else to ask.

   You are right, the subject is slightly off-topic. Let's move to
   private communication after this.


> I've installed the require perl modules and got the script to execute OK 
> but there is no data.
> 
> First I kept getting this error:
> 
> ./apache-monitor.pl /root/scripts/httpd/me 
> http://xxx.xxxxxxx.xxx/server-status
> Illegal division by zero at ./apache-monitor.pl line 170.

   The script has very little error handling at the moment. After I add
   error handling (soon) I will make an official release.

   In my experiments the message above appears if you omit to append
   "?auto" to the URL. It should work properly if you execute it like
   this:

   ./apache-monitor.pl prefix http://www.apache.org/server-status/?auto

   Let me know if it doesn't work after this and I'll chase the problem
   for you. Otherwise use the current version until the official version
   is released (which will be accompanied by the proper documentation).

Bye,
Ivan

[mod-security-users] Error: apache-monitor.pl

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

Hi,

This email is with regard to the apache-monitor.pl found at 
http://www.apachesecurity.net.

I found the link via modsecurity.org and I believe the author is the same.

Sorry if this is off-topic and/or not apporpriate but I didn't know 
where else to ask.

I've installed the require perl modules and got the script to execute OK 
but there is no data.

First I kept getting this error:

./apache-monitor.pl /root/scripts/httpd/me 
http://xxx.xxxxxxx.xxx/server-status
Illegal division by zero at ./apache-monitor.pl line 170.

After I hacked the script a little I got it work but no data.
For example:

RRDupdate(/root/scripts/httpd/me.rrd)=1102232242:::::0:0:0::::::::::::
RRDupdate(/root/scripts/httpd/me.rrd)=1102232547:::::0:0:0::::::::::::
RRDupdate(/root/scripts/httpd/me.rrd)=1102232659:::::0:0:0::::::::::::
RRDupdate(/root/scripts/httpd/me.rrd)=1102232670:::::0:0:0::::::::::::
RRDupdate(/root/scripts/httpd/me.rrd)=1102232672:::::0:0:0::::::::::::

Seems like it's always ::::0:0:0:::::::

If you could help that would be awesome. These scripts look very useful, 
I'd like to use them.

Many thanks.
Regards,
Rudi

Re: [mod-security-users] Chroot, piped logging & failure to restart child process

[David F. <Da...@me...>]

Hi Ivan & everyone,

Re: Chroot, piped logging & failure to restart child process

I think I have found a fix for this problem, which can be applied to any
piped logging process in the chroot, including rotatelogs. It
makes use of the Monit server monitoring package
(www.tildeslash.com/monit) which can take action from outside the chroot
when the piped logging process dies. This solution isn't as nice as getting
everything to 'just work', but I think it is the best I can do for piped
logging from the chroot.

Monit can easily restart apache, therefore restarting any failed piped
logging process. However, Monit has to know that something is wrong, and it
is nice if it can find this out *before* the web server begins to lock up.

When apache tries to re-start the piped logging process it looks for the
binary it was previously running, but on the inside of the chroot. Actually
putting a copy of the binary there is a nuisance, and in any case the log
files would start going inside the chroot rather than the normal
place, which is messy. Much better is to put a simple statically linked
binary as a 'fake' rotatelogs on the inside of the chroot. When apache runs
this fake rotatelogs, this binary updates a status file (e.g.
/tmp/log_fail.txt), which Monit notices by a timestamp change, and the
server is automatically re-started.

Code for the fake fakerotatelogs.c:
-----------------------------------------------------------
#include <stdio.h>
#include <stdlib.h>

//Fake rotatelogs: compile with
//gcc -static -o rotatelogs fakerotatelogs.c

int
main(int argc, char *argv[])
{

  FILE * out;
  time_t timer;

  timer=time(NULL);

  /*Open logging state file and write time of failure*/
  out = fopen("/tmp/log_fail.txt", "w");
  
  fprintf(out, "Logging failed on %s", asctime(localtime(&timer)));

  fclose(out);

  return 0;
}
-----------------------------------------------------------

Compile it and place the output inside the chroot as (in my case)

/chroot/apache/usr/local/apache/bin/rotatelogs

Add to the /etc/monitrc file an additional entry for watching the timestamp
on the state file at /chroot/apache/tmp/log_fail.txt.

/etc/monitrc entry
-----------------------------------------------------------
check file logging_indicator with path /chroot/apache/tmp/log_fail.txt  
group www   
start program = "/usr/bin/touch /chroot/apache/tmp/log_fail.txt"   
if changed timestamp then exec"/usr/local/bin/monit restart apache"
alert xx...@xx...
-----------------------------------------------------------

This Monit entry also contains a "start" entry, which will create an
initial empty state file if one doesn't already exist.

Hopefully, with this in place the server will be restarted if a logging
process dies, rather than locking up. Restarting is more drastic than
simply creating a new logging process, but it should be a rare event. 

One worry is that the state file inside the chroot provides a way for
someone to maliciously cause the server to re-start from inside the
chroot. However, if the chroot is compromised things are fairly bad
already!!

An alternative approach might be to use Monit to spot the growing number of
locked child httpd processes, and just assume a problem rather than getting
into all these details.

I hope this is of use to someone.

Regards,

David.

-- 
-------------------------------------------------
Email: Da...@me...
-------------------------------------------------

Re: [mod-security-users] Chroot, piped logging & failure to restart child process

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

> I have just found an interesting problem with a server running
> mod_security with the chroot option. It leads to a total lock-up of the
> server :-(
> 
> ...
>
> However, when apache is running in a chroot with mod_security, the piped
> logging binary is outside the chroot, and the running httpd can't find it.
> More and more httpd processes get stuck trying to log, and eventually the
> server locks up as it reaches the maximum number of child processes.
>
> ... 
> 
> Any ideas & help appreciated. I'll have a look at the code myself, but
> don't know if I'll find a fix.

  I don't think you can do much about it. As you say yourself, if the piped
logging binary is outside jail Apache won't be able to restart it. The best
you can do is move it into the jail again.

Bye,
Ivan

[mod-security-users] Chroot, piped logging & failure to restart child process

[David F. <Da...@me...>]

Hi,

I have just found an interesting problem with a server running
mod_security with the chroot option. It leads to a total lock-up of the
server :-(

I use a piped logging process, which for the last 6 months has run without
any problem. For some reason it died (nothing to do with mod_security, and
still being investigated). Apache normally restarts these child logging
processes automatically. To quote from the manual:

'Apache will start the piped-log process when the server starts, and will
restart it if it crashes while the server is running. (This last feature is
why we can refer to this technique as "reliable piped logging".)'

However, when apache is running in a chroot with mod_security, the piped
logging binary is outside the chroot, and the running httpd can't find it.
More and more httpd processes get stuck trying to log, and eventually the
server locks up as it reaches the maximum number of child processes.

This is different to the behaviour with a more traditional chroot, in which
everything is placed inside the chroot, and then started in there. I used
to do it that way, but mod_security is much easier. I wonder if there is a
way round this problem of child process restart? Would placing a second
copy of the logging binary inside the chroot help? (This would be annoying
since it is going back to the old way of doing a chroot.)

The error log file during the failure contained:

[Sun Nov 28 16:14:18 2004] [notice] child pid 3516 exit signal Segmentation
fault (11)
piped log program '/usr/bin/mysqllog7' failed unexpectedly
unable to start piped log program '/usr/bin/mysqllog7': No such file or
directory
piped_log_maintenance: unable to respawn '/usr/bin/mysqllog7':
Unknown error 4294967295

The logging process I was using is based on the code
at http://logtomysql.sourceforge.net/ which I developed around a year ago.
It is generally reliable, but I still take it as a beta version. I have
been trying things out, and found that the failure to restart the logging
process also affects the standard "rotatelogs" program that comes with
Apache.

You can test all this by running a server with mod-security in a chroot. Do
"killall rotatelogs" and you should find that rotatelogs does not restart,
and the server quickly locks up. Without the chroot, rotatelogs restarts in
seconds, and everything continues to run.

Any ideas & help appreciated. I'll have a look at the code myself, but
don't know if I'll find a fix.

Regards,

David.


-- 
-------------------------------------------------
Email: Da...@me...
-------------------------------------------------

Re: RE: RE: [mod-security-users] [ANNOUNCE] mod_security 1.8.5 released

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

The SecFilterInheritance directive never affects the configuration data,
only rules. Maybe I should change its name to "SecFilterRuleInheritance"...
Small inconsistencies are a drawback of organic growth, I am afraid.

BTW, if you want to turn the filtering engine off, use "SecFilterEngine Off"
:)

Bye,
Ivan

----- Original Message -----
Subject: RE: RE: [mod-security-users] [ANNOUNCE] mod_security 1.8.5 released
From: Mark <ad...@as...>
To: 'Ivan
Ristic'<iv...@we...>;<mod...@li...>
Date: 28-11-2004 14:40


> > -----Original Message-----
> > From: Ivan Ristic [mailto:iv...@we...] 
> > Sent: zondag 28 november 2004 15:22
> > To: Mark; mod...@li...
> > Subject: Re: RE: [mod-security-users] [ANNOUNCE] mod_security 
> > 1.8.5 released
> > 
> > It's the SecFilterForceByteRange directive. Set it to "1 255"
> > and the problem should go away.
> 
> I will try that; thanks. I had:
> 
>     SecFilterForceByteRange 32 126
>  
> > mod_security 1.8.x is more thorough than 1.7.x. That's why you
> > are getting the error. As for the audit log, didn't you turn
> > the audit log off with "SecAuditEngine Off"?
> 
> Yes, I did:
> 
> <Location /cgi-bin>
>     SecFilterInheritance Off
>     SecAuditEngine Off
> </Location>
> 
> But my point was, that since I had turned off SecFilterInheritance for
> /cgi-bin/, and all its subdirs, I did not expect the SecFilterEngine to
> work in their to begin with.
> 
> - Mark 
>  
>         System Administrator Asarian-host.org
>  
> ---
> "If you were supposed to understand it,
> we wouldn't call it code." - FedEx

RE: RE: [mod-security-users] [ANNOUNCE] mod_security 1.8.5 released

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

> -----Original Message-----
> From: Ivan Ristic [mailto:iv...@we...] 
> Sent: zondag 28 november 2004 15:22
> To: Mark; mod...@li...
> Subject: Re: RE: [mod-security-users] [ANNOUNCE] mod_security 
> 1.8.5 released
> 
> It's the SecFilterForceByteRange directive. Set it to "1 255"
> and the problem should go away.

I will try that; thanks. I had:

    SecFilterForceByteRange 32 126
 
> mod_security 1.8.x is more thorough than 1.7.x. That's why you
> are getting the error. As for the audit log, didn't you turn
> the audit log off with "SecAuditEngine Off"?

Yes, I did:

<Location /cgi-bin>
    SecFilterInheritance Off
    SecAuditEngine Off
</Location>

But my point was, that since I had turned off SecFilterInheritance for
/cgi-bin/, and all its subdirs, I did not expect the SecFilterEngine to
work in their to begin with.

- Mark 
 
        System Administrator Asarian-host.org
 
---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx

Re: RE: [mod-security-users] [ANNOUNCE] mod_security 1.8.5 released

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

It's the SecFilterForceByteRange directive. Set it to "1 255"
and the problem should go away.

mod_security 1.8.x is more thorough than 1.7.x. That's why you
are getting the error. As for the audit log, didn't you turn
the audit log off with "SecAuditEngine Off"?

Bye,
Ivan

RE: [mod-security-users] [ANNOUNCE] mod_security 1.8.5 released

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

> >>Mod_security 1.8.5 has been released. It is available for immediate
> >>download from:
> >>
> >>   http://www.modsecurity.org/download/
> >>
> >>This maintenance release relaxes several minor problems discovered
> >>in 1.8.4. Please see the changes below for more details.
> > 
> > I am still running 1.7.7. Can I upgrade to 1.8.5 without significant
> > changes? (especially to the chroot thingy).
> 
>   I don't think you should experience any difficulties. But wait for
>   a couple days, I will release 1.8.6 early next week to fix another
>   small issue that has just popped up.

Darn. I just upgrade to 1.8.6, and already my first problem appears:

mod_security: Access denied with code 406. Error parsing multipart
parameters: Error normalizing parameter value: Invalid character detected
[13] [hostname "asarian-host.net"] [uri
"/cgi-bin/openwebmail/openwebmail-send.pl?action=composemessage ...

I have this in my vhosts.conf:

<Location /cgi-bin>
    SecFilterInheritance Off
    SecAuditEngine Off
</Location>

How do I fix this?? It work fine under 1.7.7. :(

Also, why is this error not in mod_security_audit.log?

- Mark 
 
        System Administrator Asarian-host.org
 
---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx

Re: [mod-security-users] Postfix in a jail

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

Hmmm, why would you want to put Postfix into the same jail
as Apache? It's better to keep it outside, possibly in a
jail of its own. To send email from a jailed Apache I often
use direct delivery over SMTP. In some rare cases you may
use mini sendmail.

Bye,
Ivan

----- Original Message -----
Subject: [mod-security-users] Postfix in a jail
From: UpFront Technology <upf...@rr...>
To: Mod Security Users List
(E-mail)<mod...@li...>
Date: 25-11-2004 20:43


> Has anybody had any success using Postfix inside the chroot?  If so I
could
> sure use some help.
> 
> 
> 
> thanks
> 
> --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.289 / Virus Database: 265.4.2 - Release Date: 11/24/2004
> 
> 
> 
> 
> 
> -------------------------------------------------------
> 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://productguide.itmanagersjournal.com/
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users

[mod-security-users] Postfix in a jail

[UpFront T. <upf...@rr...>]

Has anybody had any success using Postfix inside the chroot?  If so I could
sure use some help.



thanks

--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.289 / Virus Database: 265.4.2 - Release Date: 11/24/2004

Re: [mod-security-users] Restricting a forward proxy

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

----- Original Message -----
Subject: [mod-security-users] Restricting a forward proxy
From: Charles Duffy <cd...@sp...>
>
> I wish to configure Apache to support CONNECT-based proxying to a single
> destination host and port only, and deny all other proxy requests
> (CONNECT-based and otherwise). mod_proxy, as written, appears to be too
> weak to allow this (no AllowProxy directive for whitelisting the single
> allowed target address, no obvious-to-me way to disallow all methods but
> CONNECT), so I'm interested in using mod_security to implement these
> rules.

  Perhaps you should be looking at mod_rewrite instead, since it
  is designed for that sort of stuff.

  Have a look at the rewrite guide, under the section "URL-Restricted
proxy":
  http://httpd.apache.org/docs/misc/rewriteguide.html

  Since you only want to allow one site your configuration would
  probably be simpler.

Bye,
Ivan

[mod-security-users] Restricting a forward proxy

[Charles D. <cd...@sp...>]

All,

I wish to configure Apache to support CONNECT-based proxying to a single
destination host and port only, and deny all other proxy requests
(CONNECT-based and otherwise). mod_proxy, as written, appears to be too
weak to allow this (no AllowProxy directive for whitelisting the single
allowed target address, no obvious-to-me way to disallow all methods but
CONNECT), so I'm interested in using mod_security to implement these
rules.

Because I have no prior experience with mod_proxy and an iffy-at-best
understanding of how non-CONNECT-based HTTP/FTP-over-HTTP proxying works,
I'm hesitant to try to do this on my own (given the risk of creating an
open proxy both out to the world and in to my company's network). Might
anyone suggest a set of configuration directives appropriate to the task?

Thanks!

[mod-security-users] Re: HTTPD Dos

[David F. <Da...@me...>]

On Sat, 13 Nov 2004 20:23:31 -0800
mod...@li... wrote:

> From: Gerwin Krist -|- Digitalus Webhosting <ge...@di...>
> To: Mod_security <mod...@li...>
> Date: Sat, 13 Nov 2004 11:29:25 +0000
> 
> Well the problem is it there are many ip addresses but only 1 request
> once a while. So you can't easily detect the ddos.

In the case I quoted in my last post, all the requests actually came from
the same IP, so it was just DOS, not distributed.

I think Ivan is right that in many cases these are better stopped at a
firewall if that is possible. However, blocking at the web server
would prevent, for example, lots of PHP sessions or database connections
getting started. The OPTIONS type attack wasn't too bad - one with GET or
POST on a real page would have consumed far more resources.

David.
-- 
-------------------------------------------------
Email: Da...@me...
-------------------------------------------------

Re: [mod-security-users] Re: HTTPD Dos

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

> I have been getting attacks with over 1000 per second requests like this:
> 
> default.domain 141.150.49.213 - - [04/Nov/2004:09:30:52 +0000] "OPTIONS /
> HTTP/1.1" 403 266 "-" "Microsoft-WebDAV-MiniRedir/5.1.2600" (-)
> 
> They seem to have stopped before I did anything about them, but I was
> looking at mod_dosevasive available here:
> 
> http://www.nuclearelephant.com/projects/dosevasive/
> 
> It doesn't look like its been developed in over a year (perhaps it doesn't
> need it?) but it might be useful. I wonder if there is any case for
> integrating it with mod_security?
> 
> Another approach in this case will be just to block OPTIONS requests, but
> other DOS attacks might not use this request method.

  I don't think you would benefit from blocking such attacks on the
  web server level. An OPTIONS request is handled quickly anyway.
  Handling it differently would not increase performance or slow down
  the attack. Blocking on the web server would help if the target of
  the attack is a script that consumes a lot of server resources, for
  example a script that performs intensive database operations.

  But, in general, I think the only feasible DoS defence is
  with a firewall, on the network level. My idea about DoS defence
  is to log relevant events to the error log, and then use a parallel
  process (either in real-time or started from cron every couple of
  minutes) to examine what is happening and configure firewall
  accordingly.

  As far as I am aware mod_dosevasive does not need to develop
  further if the general concept it uses is going to stay. The only
  thing I don't like about it is that it doesn't share information
  about attacks between processes. So every Apache child needs to
  activate its own defences.

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

Re: [mod-security-users] Re: HTTPD Dos

[Gerwin K. -|- D. W. <ge...@di...>]

Well the problem is it there are many ip addresses but only 1 request
once a while. So you can't easily detect the ddos. Ivan was so nice to
give me some tips. If i'm done with it (in other words, if it works), i
will make a little howto, and maybe it's usefull for some other persons
:)

Gerwin

Op za 13-11-2004, om 10:08 schreef David Fletcher:
> On Fri, 12 Nov 2004 20:23:12 -0800
> mod...@li... wrote:
> 
> > Subject: [mod-security-users] HTTPD Dos
> > 
> > Hello there,
> > 
> > One of our servers is being ddossed (httpd based), 100ths of clients are
> > trying to download 1 certain file. My question, is it possible
> > to filter on the download and put the the ip in an iptables rule?
> > 
> > Regards,
> > Gerwin
> 
> Hi,
> 
> I have been getting attacks with over 1000 per second requests like this:
> 
> default.domain 141.150.49.213 - - [04/Nov/2004:09:30:52 +0000] "OPTIONS /
> HTTP/1.1" 403 266 "-" "Microsoft-WebDAV-MiniRedir/5.1.2600" (-)
> 
> They seem to have stopped before I did anything about them, but I was
> looking at mod_dosevasive available here:
> 
> http://www.nuclearelephant.com/projects/dosevasive/
> 
> It doesn't look like its been developed in over a year (perhaps it doesn't
> need it?) but it might be useful. I wonder if there is any case for
> integrating it with mod_security?
> 
> Another approach in this case will be just to block OPTIONS requests, but
> other DOS attacks might not use this request method.
> 
> David.

Re: [mod-security-users] Re: HTTPD Dos

[Zach R. <ad...@li...>]

David Fletcher wrote:
> 
> On Fri, 12 Nov 2004 20:23:12 -0800
> mod...@li... wrote:
> 
> 
>>Subject: [mod-security-users] HTTPD Dos
>>
>>Hello there,
>>
>>One of our servers is being ddossed (httpd based), 100ths of clients are
>>trying to download 1 certain file. My question, is it possible
>>to filter on the download and put the the ip in an iptables rule?
>>
>>Regards,
>>Gerwin
> 
> 
> Hi,
> 
> I have been getting attacks with over 1000 per second requests like this:
> 
> default.domain 141.150.49.213 - - [04/Nov/2004:09:30:52 +0000] "OPTIONS /
> HTTP/1.1" 403 266 "-" "Microsoft-WebDAV-MiniRedir/5.1.2600" (-)
> 
> They seem to have stopped before I did anything about them, but I was
> looking at mod_dosevasive available here:
> 
> http://www.nuclearelephant.com/projects/dosevasive/
> 
> It doesn't look like its been developed in over a year (perhaps it doesn't
> need it?) but it might be useful. I wonder if there is any case for
> integrating it with mod_security?
> 
> Another approach in this case will be just to block OPTIONS requests, but
> other DOS attacks might not use this request method.
> 
> David.
> 

That could prove to be a very useful addition to the mod_security 
codebase. I currently use it but, due to the incompatibility with 
frontpage I can't use it on all servers.

If possible, I would definately like to see it added.

Zach