mod-security-users — General discussion about mod_security

Re: [mod-security-users] Bigger test fails but chained rule is recorded in audit_log

[Dionysios G. S. <ds...@no...>]

Ivan Ristic wrote:

> Dionysios G. Synodinos wrote:
>
>> I use the following "big test":
>>
>>    SecFilterSelective REMOTE_ADDR "!^148.101.211" chain
>>    SecFilterSelective SCRIPT_FILENAME "(admin\.php|user\.php)$"
>>
>> which restricts access to admin.php & user.php (*) from outside my LAN.
>>
>> It seems that since the first filter matches for any other request 
>> from the internet, it is recorded in the audit_log, even if the "big 
>> test" doesn't match.
>>
>> Is there a way to avoid this behaviour since it clutters my logs with 
>> unneccesary information..?
>>
>> I use "SecAuditEngine RelevantOnly"
>
>
>   That sounds like a bug to me, so you can count on it
>   being fixed before 1.8.

When one of the chained rules fails then the message that is recorded in the audit_log informs that:

	mod_security-message: Access denied with code 403. Pattern match BLAH BAH BLAH 

If the whole chain fails then it adds a line (action):

	mod_security-message: Access denied with code 403. Pattern match BLAH BLAH BLAH 
	mod_security-action: 403

It all depends on what your definition of what "RelevantOnly" means. If it is "relevant" to record any match in a chain even if the whole chain fails then it is not a bug. I would hope thow that something like:

	SecAuditEngine ActionOnly &
	SecAuditEngine MessageOnly

comes ups that will assist in fine tuning of what is recorded in the audit_log.

Anyway I tried to reverse the rules to see what happens and the result was that NOTHING IS RECORDED in the audit_log. I attach a piece of the debug_log.

Kind regards,
-dsin

Re: [mod-security-users] Bigger test fails but chained rule is recorded in audit_log

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

Dionysios G. Synodinos wrote:

> I use the following "big test":
> 
>    SecFilterSelective REMOTE_ADDR "!^148.101.211" chain
>    SecFilterSelective SCRIPT_FILENAME "(admin\.php|user\.php)$"
> 
> which restricts access to admin.php & user.php (*) from outside my LAN.
> 
> It seems that since the first filter matches for any other request from 
> the internet, it is recorded in the audit_log, even if the "big test" 
> doesn't match.
> 
> Is there a way to avoid this behaviour since it clutters my logs with 
> unneccesary information..?
> 
> I use "SecAuditEngine RelevantOnly"

   That sounds like a bug to me, so you can count on it
   being fixed before 1.8.

Bye,
Ivan

[mod-security-users] Bigger test fails but chained rule is recorded in audit_log

[Dionysios G. S. <ds...@no...>]

I use the following "big test":

    SecFilterSelective REMOTE_ADDR "!^148.101.211" chain
    SecFilterSelective SCRIPT_FILENAME "(admin\.php|user\.php)$"

which restricts access to admin.php & user.php (*) from outside my LAN.

It seems that since the first filter matches for any other request from 
the internet, it is recorded in the audit_log, even if the "big test" 
doesn't match.

Is there a way to avoid this behaviour since it clutters my logs with 
unneccesary information..?

I use "SecAuditEngine RelevantOnly"

-dsin

(*) I also use mod_access for that after Ivan's suggestion

Re: [mod-security-users] mod_security rules for specific IPs or subnets

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

Dionysios G. Synodinos wrote:

> mod_security rules for specific IPs or subnets
> 
> Since our site is edited only from within our LAN (subnet), I would like
> to instruct mod_security to permit access to certain pages like eg.
> admin.php only from a specific subnet, or IP. Something like:
> 
> SecFilter "admin\.php"
> SecFilter "user\.php"

  These filters are too broad. If you want to match script filename
  use a selective filter:

   SecFilterSelective SCRIPT_FILENAME "admin\.php$"

  SecFilter will apply the signature to the filename, the query_string,
  post data and result in false positives.


> but only for IPs outside our LAN (people that visit the site).
> 
> Does anyone know how to do that?

  Sure you can do it with mod_security, but it is natural to do it
  with Apache built-in features, using mod_access:

   http://httpd.apache.org/docs/mod/mod_access.html

  Like this:

   <Files ~ "(admin\.php|user\.php)$">
       # deny everything by default
       order allow,deny
       # only allow access from the LAN
       allow from 192.168.254.
   </Files>

  With mod_security, something like this would equally work:

   SecFilterSelective REMOTE_ADDR "!^192.168.254" chain
   SecFilterSelective SCRIPT_FILENAME "(admin\.php|user\.php)$"

  (examples not tested, please make sure they work for you)

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

[mod-security-users] mod_security rules for specific IPs or subnets

[Dionysios G. S. <ds...@no...>]

mod_security rules for specific IPs or subnets

Since our site is edited only from within our LAN (subnet), I would like 
to instruct mod_security to permit access to certain pages like eg. 
admin.php only from a specific subnet, or IP. Something like:

SecFilter "admin\.php"
SecFilter "user\.php"

but only for IPs outside our LAN (people that visit the site).

Does anyone know how to do that?

Re: [mod-security-users] Chroot and pid file

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

> 'If you choose to put the Apache binary and the supporting files outside
> of jail, you won't be able to use the "apachectl graceful" and "apachectl
> restart" commands anymore.

  Restart may work (although I presume I've checked before writing
  it to the manual ;), but graceful can't. That's because with graceful
  the root Apache process reconfigures, kills idle children, and
  creates new children (with new configuration active). So if the
  httpd.conf file resides outside the jail the root process won't
  be able to read it and that's that.

  With Apache 2, all of the start/stop/restart/etc functionality
  was moved into the binary. As David said, I belive the pidfile is
  now created after the chroot.

  Again, this discussion only applies if the web server binary and
  the supporting files are left outside jail.

  Because of all this I've mostly decided to practice the classic
  chroot approach where the jail contains all Apache-related files.

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

Re: [mod-security-users] Chroot and pid file

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

Hi Mark,

Thanks for your reply. 

What version of mod_security are you using? The chroot stuff has been
revised significantly in the development version. I was refering to the
pdf verion of the manual for the development version 1.8dev2. It states
that:

'If you choose to put the Apache binary and the supporting files outside
of jail, you won't be able to use the "apachectl graceful" and "apachectl
restart" commands anymore. That would require Apache reaching out of the
jail, which is not possible. With Apache 2, even the "apachectl stop"
command does not work. For future releases I will create replacement
scripts to work around this problem.'

I am using Apache 2 - I should have said that in my email. Apache is now
creating its PID file after the chroot, so the standard apachectl script
stops working.

I'm not sure about the soft link. I agree it would allow the standard
script to find the PID, but deleting the soft link rather than the real
PID file would leave an old PID file in the chroot.

Cheers,

David.

On Sun, 16 May 2004 18:59:29 GMT
Mark <ad...@as...> wrote:

> David Fletcher wrote:
> 
> > I'm using mod_security-1.8dev2 and the chroot function. As stated in
> > the manual, it is difficult to stop Apache when chrooted because it
> > cannot find its PID file.
> 
> Where did you read that? If so, your Apache must behave radically
> different from mine. My Apache (1.32.29) first creates its PID file, and
> only *then* chroots. It can easily be stopped with:
> 
>     kill -TERM `cat /var/run/httpd.pid`
> 
> If people have a pid within the chroot, a simple symlink, in /var/run/,
> will suffice:
> 
>     ln -s /chroot/apache/var/run/httpd.pid httpd.pid
> 
> Cheers,
> 
> - Mark
> 
>         System Administrator Asarian-host.org
> 
> ---
> "If you were supposed to understand it,
> we wouldn't call it code." - FedEx
> 
> 


-- 
-------------------------------------------------
Email: David at megapico dot co dot uk
-------------------------------------------------

Re: [mod-security-users] Chroot and pid file

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

David Fletcher wrote:

> I'm using mod_security-1.8dev2 and the chroot function. As stated in
> the manual, it is difficult to stop Apache when chrooted because it
> cannot find its PID file.

Where did you read that? If so, your Apache must behave radically =
different from mine. My Apache (1.32.29) first creates its PID file, and =
only *then* chroots. It can easily be stopped with:

    kill -TERM `cat /var/run/httpd.pid`

If people have a pid within the chroot, a simple symlink, in /var/run/, =
will suffice:

    ln -s /chroot/apache/var/run/httpd.pid httpd.pid

Cheers,

- Mark

        System Administrator Asarian-host.org

---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx

[mod-security-users] Chroot and pid file

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

Hi,

I'm using mod_security-1.8dev2 and the chroot function. As stated in the
manual, it is difficult to stop Apache when chrooted because it cannot
find its PID file. I attach a start/stop script below that overcomes this
problem. I hope it will be useful.

Your httpd.conf file should contain the PidFile configuration option as
normal, ignoring any chroot. The 'stop' section of the script below makes
use of the -c option to httpd, allowing a new value of PidFile to be used,
which overrides the one in httpd.conf.

David.

-- 
-------------------------------------------------
Email: David at megapico dot co dot uk
-------------------------------------------------


#!/bin/sh

ARGV="$@"
#
# |||||||||||||||||||| START CONFIGURATION SECTION  ||||||||||||||||||||
# --------------------                              --------------------
# 
# the path to your PID file, ignoring 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

#If a PID file exists, check it points to a running httpd
#Deals with PID left after power-cut or crash.
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

Re: [mod-security-users] help

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

psy...@in... wrote:
> Hello mod-security-users,
> 
> tell me please, how can i correct this error ?
> [error] [client 213.182.221.133] mod_security: Invalid Unicode encoding: invalid byte value

  Add

    SecFilterCheckUnicodeEncoding Off

  to your web server configuration.

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

[mod-security-users] help

[<psy...@in...>]

Hello mod-security-users,

  tell me please, how can i correct this error ?
  [error] [client 213.182.221.133] mod_security: Invalid Unicode encoding: invalid byte value

-- 
Best regards,
 psyonic                          mailto:psy...@in...

Re: [mod-security-users] nice article about using regex for detection rules

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

M.E. Post wrote:

> Don't know if mod_security supports these kinds of filter rules but there's
> a nice article on securityfocus on how to finetune your snort detection
> rules for xss and sql injection attacks:
> 
> http://www.securityfocus.com/infocus/1768

  There has been some controversy about it recently,
  with Imperva releasing a paper releasing a paper mentioning
  the article too many times (in negative context).

http://www.imperva.com/application_defense_center/white_papers/sql_injection_signatures_evasion.html

  So they exchanged a couple of emails on Bugtraq:

  http://www.securityfocus.com/archive/1/361486/2004-04-24/2004-04-30/0
  http://www.securityfocus.com/archive/1/361490/2004-04-24/2004-04-30/0

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

[mod-security-users] nice article about using regex for detection rules

[M.E. P. <mei...@bi...>]

Don't know if mod_security supports these kinds of filter rules but there's
a nice article on securityfocus on how to finetune your snort detection
rules for xss and sql injection attacks:

http://www.securityfocus.com/infocus/1768

Cheers,

Meint

Re: [mod-security-users] When will we see 1.8?

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

Ivan Ristic wrote:

>>>   Sure, but mod_security will kill every child Apache spawns. I've
>>>   added a delay to prevent too many processes to get created and
>>>   killed at the same time, but the whole thing will prevent Apache
>>>   from serving any requests.
>>
>> Hmm, in that case, why can mod_security not simply kill the "mother"
>> Apache process itself? (the child, running as "nobody", or "www",
>> can obviously not kill the parent, who runs as root; but
>> mod_security could kill its own Apache process, right?). Or am I
>> missing something again?
>
>    It does just that (exits its own process). But it is the parent
>    process running as root that spawns new children.

For now, due to a time limit, I have decided to install 1.7.6 on the
production server, after all. But I wrote a small startup-script that
examines the log, after starting up Apache, to see whether mod_security did
the chroot. If not, it kills the pid in /var/run/httpd.pid, and restarts the
process (in a limited loop). Not pretty, I know; but at least this way I am
sure the chroot succeeded.

>    Anyway, if I got it right this time it will never have to
>    manifest itself.

True. This issue is largely academic. And I have *never* seen it gone wrong
on 1.7.6 either, btw.

Cheers,

- Mark

        System Administrator Asarian-host.org

---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx

RE: [mod-security-users] Suggestions re installation and documentation

[Regence 2. <reg...@ho...>]

Christopher's suggestion works great on RH EL 3.0. Update with:

up2date http-devel

and apxs is installed in /usr/sbin.

Another documentation note - the 'Configuration' section doesn't name the 
file in which these mod_security commands are entered. I'm assuming it is 
httpd.conf but it should be spelt out.

Thanks!

>In answer to the "where is apxs utility", under Red Hat 8.0, the apxs =
>utility was only installed when the "httpd-devel-2.0.40" package was =
>installed.  That is, the utility is not included as a part of the =
>standard httpd RPM.  I suspect that RHEL is similar. =20

_________________________________________________________________
Watch LIVE baseball games on your computer with MLB.TV, included with MSN 
Premium! 
http://join.msn.com/?page=features/mlb&pgmarket=en-us/go/onm00200439ave/direct/01/

RE: [mod-security-users] Suggestions re installation and documentation

[L. C. L. <CL...@Xy...>]

In answer to the "where is apxs utility", under Red Hat 8.0, the apxs =
utility was only installed when the "httpd-devel-2.0.40" package was =
installed.  That is, the utility is not included as a part of the =
standard httpd RPM.  I suspect that RHEL is similar. =20

HTH

-----Original Message-----
From: mod...@li...
[mailto:mod...@li...]On Behalf Of Ivan
Ristic
Sent: Saturday, April 24, 2004 6:58 PM
To: Regence 21
Cc: mod...@li...
Subject: Re: [mod-security-users] Suggestions re installation and
documentation


Regence 21 wrote:
[snip...]
> Issue #1
>=20
> The dynamic install from source doesn't work on RHEL 3.0 because the
> apache 'apxs' utility isn't standard as far as I can tell.
>=20
> Suggestion: Explain what apxs is and why/where it is installed? Can it
> be installed after the fact?

  I am not familiar with RHEL3. What does it say in the documentation
  about a preferred way to install additional Apache modules?

[...snip]

CONFIDENTIALITY NOTE:  This communication contains information that is =
confidential and/or legally privileged.  This information is intended =
only for the use of the individual or entity named on this =
communication.  If you are not the intended recipient, you are hereby =
notified that any disclosure, copying, distribution, printing or other =
use of, or any action in reliance on, the contents of this communication =
is strictly prohibited.  If you received this communication in error, =
please immediately notify us by telephone at (703) 631-6925.

Re: [mod-security-users] When will we see 1.8?

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

>>   Sure, but mod_security will kill every child Apache spawns. I've
>>   added a delay to prevent too many processes to get created and
>>   killed at the same time, but the whole thing will prevent Apache
>>   from serving any requests.
> 
> Hmm, in that case, why can mod_security not simply kill the "mother" Apache
> process itself? (the child, running as "nobody", or "www", can obviously not
> kill the parent, who runs as root; but mod_security could kill its own
> Apache process, right?). Or am I missing something again?

   It does just that (exits its own process). But it is the parent
   process running as root that spawns new children.

   I've put this mechanism in place just in case. Apache not running
   is a bug. Chroot not working is a but *and* a security issue.

   Anyway, if I got it right this time it will never have to
   manifest itself.

Bye,
Ivan

Re: [mod-security-users] When will we see 1.8?

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

Ivan Ristic wrote:

>>>>>  BTW, I've also added a check to v1.8. If chroot fails for any
>>>>>  reasons, Apache will refuse to serve requests.
>>>>
>>>> I have a request, though. Can you make it so, that, instead of not
>>>> serving requests, Apache will exit? (with a log message, of
>>>> course).
>>>
>>>  Actually, that's what it does at the moment. But there is a catch.
>>>  Since at that time the configuration phase is over, it is only
>>>  one child that exits. I cannot affect other Apache processes.
>>
>> I hadn't thought of that. No big deal, though: "MinSpareServers"
>> should take care of respawning a new child.
>
>    Sure, but mod_security will kill every child Apache spawns. I've
>    added a delay to prevent too many processes to get created and
>    killed at the same time, but the whole thing will prevent Apache
>    from serving any requests.

Hmm, in that case, why can mod_security not simply kill the "mother" Apache
process itself? (the child, running as "nobody", or "www", can obviously not
kill the parent, who runs as root; but mod_security could kill its own
Apache process, right?). Or am I missing something again?

- Mark

        System Administrator Asarian-host.org

---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx

Re: [mod-security-users] When will we see 1.8?

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

>>>>  BTW, I've also added a check to v1.8. If chroot fails for any
>>>>  reasons, Apache will refuse to serve requests.
>>>
>>>I have a request, though. Can you make it so, that, instead of not
>>>serving requests, Apache will exit? (with a log message, of course).
>>
>>  Actually, that's what it does at the moment. But there is a catch.
>>  Since at that time the configuration phase is over, it is only
>>  one child that exits. I cannot affect other Apache processes.
> 
> 
> I hadn't thought of that. No bid deal, though: "MinSpareServers" should
> take care of respawning a new child.

   Sure, but mod_security will kill every child Apache spawns. I've added
   a delay to prevent too many processes to get created and killed at
   the same time, but the whole thing will prevent Apache from serving
   any requests.

Bye,
Ivan

Re: [mod-security-users] When will we see 1.8?

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

Ivan Ristic wrote:

>>>   BTW, I've also added a check to v1.8. If chroot fails for any
>>>   reasons, Apache will refuse to serve requests.
>>
>> I have a request, though. Can you make it so, that, instead of not
>> serving requests, Apache will exit? (with a log message, of course).
>
>   Actually, that's what it does at the moment. But there is a catch.
>   Since at that time the configuration phase is over, it is only
>   one child that exits. I cannot affect other Apache processes.

I hadn't thought of that. No bid deal, though: "MinSpareServers" should
take care of respawning a new child.

>> Besides, I believe it is quite fair for mod_security to treat not
>> being able to chroot as a critical, abortable, error, like Apache
>> missing a log-file (after which Apache exists too).
>
>   I agree but it can't be done any other way. That's the drawback
>   of not patching the source code and working from a module.

Thanks for your hard work anyway. I am quite happy with the mod approach as
it is. :) I just grabbed 1.8dev2, and will try it out.

Cheers!

- Mark

        System Administrator Asarian-host.org

---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx

Re: [mod-security-users] When will we see 1.8?

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

>>   BTW, I've also added a check to v1.8. If chroot fails for any
>>   reasons, Apache will refuse to serve requests.
> 
> I have a request, though. Can you make it so, that, instead of not serving
> requests, Apache will exit? (with a log message, of course).

  Actually, that's what it does at the moment. But there is a catch.
  Since at that time the configuration phase is over, it is only
  one child that exits. I cannot affect other Apache processes.


> Besides, I believe it is quite fair for mod_security to treat not being able
> to chroot as a critical, abortable, error, like Apache missing a log-file
> (after which Apache exists too).

  I agree but it can't be done any other way. That's the drawback
  of not patching the source code and working from a module.


Bye,
Ivan

Re: [mod-security-users] When will we see 1.8?

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

Ivan Ristic wrote:

>> Can you tell me, though, what are the conditions the parent process
>> ID != 1? The children, of course, have the PPID of the 'mother'
>> Apache process; but the parent itself always seems to have PPID 1.
>> Are you referring to Apache being started from within a new shell,
>> or something?
>
>    I haven't been able to pin-point that. My guess is that is a
>    problem with timing since the ppid of the main process must,
>    eventually, become 1. In the end I switched to a new, reliable,
>    approach.

The chroot issue is really why I am looking forward to 1.8. I cannot deploy
mod_security in a production environment yet, until that is resolved.

>    BTW, I've also added a check to v1.8. If chroot fails for any
>    reasons, Apache will refuse to serve requests.

I have a request, though. Can you make it so, that, instead of not serving
requests, Apache will exit? (with a log message, of course). I have several
cron scripts that monitor if any of the major daemons went down, and restart
them. Apache not serving requests, though, is not a condition I can easily,
and reliably, alert myself to (like a down daemon).

Besides, I believe it is quite fair for mod_security to treat not being able
to chroot as a critical, abortable, error, like Apache missing a log-file
(after which Apache exists too). Starting up "normally", but simply not
serving any requests, is the worst, really.

Thanks,

- Mark

        System Administrator Asarian-host.org

---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx

Re: [mod-security-users] When will we see 1.8?

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

> Not to rush you either, but how is 1.8 coming along? I am preparing a brand
> new production server; and, if at all possible, I'd like to include 1.8 on
> there. With April drawing to a close and all, I thought I inquire once more.

  :)

  Since you are that curious, I finished the code over the last weekend
  but decided not to release it then because there were too many changes
  made. I plan to do some more work tomorrow, test the new code, update
  the documentation, and then release 1.8dev2. So you may have it
  tomorrow.

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

Re: [mod-security-users] Suggestions re installation and documentation

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

Regence 21 wrote:
> I have some install issues and I thought I would put these suggestions
> out there for future improvements in the mod_security install and/or
> documentation.

  Hi,

  Thanks for your comments.


> Issue #1
> 
> The dynamic install from source doesn't work on RHEL 3.0 because the
> apache 'apxs' utility isn't standard as far as I can tell.
> 
> Suggestion: Explain what apxs is and why/where it is installed? Can it
> be installed after the fact?

  I am not familiar with RHEL3. What does it say in the documentation
  about a preferred way to install additional Apache modules?


> Issue #2
> 
> The static install from source doesn't install much confidence (the
> instructions state "there is no definitive documentation" on how to do
> this on Apache 2!?) and they are also very unclear e.g.

  You are correct about that. What you've read is a hack that
  worked for me. Some people have already complained that it
  doesn't work for them and I'll remove it from the documentation
  alltogether.


> Issue #3
> 
> The binary installation instructions are also unclear, because they
> refer to mod_security.so which is the compiled version of
> mod_security.c, but they don't spell out how you should compile it or
> where you should get the compiled version from.

  The apxs binary is supposed to compile, install, and configure
  the module.


> There are mod_security RPM's and binaries around, but they are for
> mandrake systems. If there is a compiled binary for Red Hat, I couldn't
> find it.

  Not that I know of.


> Suggestion: Explain the .so only comes with the compiled version, and
> that it is system specific. (or is it?)

  It is system specific.


> I hope these suggestions make it into future documentation.

  I will take a look at the documentation tomorrow and see if I can
  make some things more clear.


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

[mod-security-users] Suggestions re installation and documentation

[Regence 2. <reg...@ho...>]

I have some install issues and I thought I would put these suggestions out 
there for future improvements in the mod_security install and/or 
documentation.

I'm running Apache 2.0 on Red Hat Enterprise Linux 3.0. The mod_security 
manual shows how to do a source and binary install starting on page 5.

Issue #1

The dynamic install from source doesn't work on RHEL 3.0 because the apache 
'apxs' utility isn't standard as far as I can tell.

Suggestion: Explain what apxs is and why/where it is installed? Can it be 
installed after the fact?

Issue #2

The static install from source doesn't install much confidence (the 
instructions state "there is no definitive documentation" on how to do this 
on Apache 2!?) and they are also very unclear e.g.

./configure --prefix=(my prefix) --with-module=mappers:security

What is '(my prefix)'? It isn't explained in the documentation.

They also require you to recompile Apache, which I am reluctant to do.

Suggestion: Explain '(my prefix)'. Find the definitive way to install static 
modules on Apache 2.0 and document it.

Issue #3

The binary installation instructions are also unclear, because they refer to 
mod_security.so which is the compiled version of mod_security.c, but they 
don't spell out how you should compile it or where you should get the 
compiled version from.

There are mod_security RPM's and binaries around, but they are for mandrake 
systems. If there is a compiled binary for Red Hat, I couldn't find it.

Suggestion: Explain the .so only comes with the compiled version, and that 
it is system specific. (or is it?)

I hope these suggestions make it into future documentation. Thanks for such 
a great piece of software.

_________________________________________________________________
MSN Toolbar provides one-click access to Hotmail from any Web page – FREE 
download! http://toolbar.msn.com/go/onm00200413ave/direct/01/