ModSecurity

Lee Mehlhorn wrote:
> 
> I'm running Apache 2.0.53 using mod_security 1.8.7.  I've installed 
> modsecurity successfully and it seems to be working using a very simple 
> ruleset on my test box.
> 
> Apache Installation:  /usr/local/apache
> Document Root: /webs
> Apache Logs: /webs/logs
> 
> Setting up SecChrootDir  /chroot/apache
> Okay, this is probably the part I'm confused about, setting up the 
> directories underneath the /chroot directory.   Do I symbolic links to 
> the apache install directory for each subfolder?  what do I do about my 
> document root and or logs directory?  Should I use symbolic links for 
> them as well?

   You could put your document root into the jail:

   cd /
   mv /webs /chroot/apache/webs
   ln -s /chroot/apache/webs

   and try with:

   SecChrootDir /chroot/apache

   Everything else can remain outside jail but there are consequences
   (e.g. you won't be able to restart Apache, just stop-start it).

   You will probably need to have /chroot/apache/usr/local/apache/logs
   too, as Apache 2 attempts to create some files after the chroot
   and that's the default directory for them.

   There's extensive documentation available here:
   http://www.apachesecurity.net/download/apachesecurity-ch02.pdf

-- 
Ivan Ristic
Apache Security (O'Reilly) - http://www.apachesecurity.net
Open source web application firewall - http://www.modsecurity.org

Ivan Ristic wrote:

>   SecChrootDir /chroot/apache
> 
>   Everything else can remain outside jail but there are consequences
>   (e.g. you won't be able to restart Apache, just stop-start it).

And what about Perl/Python/* libraries needed for CGIs? Let's suppose we
have cgi-bin directory inside chroot jail (for instance,
/chroot/apache/www/cgi-bin). That's ok, but what will be happen when the
 invoked cgi try to execute /usr/bin/perl or moreover when it needs
/usr/lib/perl/* files (all of them are out of the jail)?

-- 

Saludos,
-Roman

PGP Fingerprint:
09BB EFCD 21ED 4E79 25FB  29E1 E47F 8A7D EAD5 6742
[Key ID: 0xEAD56742. Available at KeyServ]

Roman Medina-Heigl Hernandez wrote:
> Ivan Ristic wrote:
> 
> 
>>  SecChrootDir /chroot/apache
>>
>>  Everything else can remain outside jail but there are consequences
>>  (e.g. you won't be able to restart Apache, just stop-start it).
> 
> And what about Perl/Python/* libraries needed for CGIs? Let's suppose we
> have cgi-bin directory inside chroot jail (for instance,
> /chroot/apache/www/cgi-bin). That's ok, but what will be happen when the
>  invoked cgi try to execute /usr/bin/perl or moreover when it needs
> /usr/lib/perl/* files (all of them are out of the jail)?

   Nothing, it won't work. If you have a need for CGI scripts or
   any other type of external binary execution you will have to
   create a proper jail. You won't be needing mod_security.

-- 
Ivan Ristic
Apache Security (O'Reilly) - http://www.apachesecurity.net
Open source web application firewall - http://www.modsecurity.org

Christian Martorella wrote:
> Hi i was doing some test with mod_proxy and mod_security.
> 
> I have a mod_security working as an appliance, so in the configuration i 
> have 2 virtual_host,
> One have: Header set Server "x"
> and the other: Header set Server "y"
 >
> But when i connect to the server y, and i telnet to port 80 and do a   
> "HEAD / HTTP/1.0"  i get the Server "x"  header.

   You are not connecting to server Y. You are connecting to the proxy
   server Z, and you are not telling it which virtual host you want to
   talk to. So the proxy is either using the default virtual host or
   responding as itself.


> Is there a way to get differents Server headers, for each virtual_host?

   You already have that. What really troubles you is that someone can
   talk to the proxy directly and figure out it is a proxy.

   In theory, if you can allocate one IP address per virtual host then
   it may be possible to change mod_security to use different signature
   for each IP address.

-- 
Ivan Ristic
Apache Security (O'Reilly) - http://www.apachesecurity.net
Open source web application firewall - http://www.modsecurity.org

Christian Martorella wrote:
> Hi, i was looking others Application firewalls and i saw that some of 
> them use tokens to sign forms or variables with a hash.

   Can you be more specific? What are they signing? The hidden fields,
   the names of the fields?


> There are 
> plans to implement this on Mod_Security?  or there is someone already 
> working on it?

   No. I am not convinced such feature would have significant value in
   real life. I can see how it can help in a specific case (e.g. when
   someone has an app with a hidden field that should never change). But
   I do not think it can work as a generic protection measure people can
   turn on and forget about it. In this day and age many applications are
   creating forms dynamically at runtime, and using JavaScript to change
   the values in the hidden fields.


> P.S: I also noted that there is no TODO list, could be very interesting 
> to see what things are needed, or what are the people expecting from the 
> mod? :)

   I used to have a public TODO list but it was frequently out of sync.

-- 
Ivan Ristic
Apache Security (O'Reilly) - http://www.apachesecurity.net
Open source web application firewall - http://www.modsecurity.org

From: "Rudi Starcevic" <tech@...>
> I'm about to start a small PHP web app. to analyze mod security alerts.

Are you going to use modsec's "exec" action to trigger the program, or are 
you going to just passively read the log file?

Tom

Hi,

 >> Are you going to use modsec's "exec" action to trigger the program, 
or are you going
 >> to just passively read the log file?

I'm planning to parse the audit_log file into a relational database.
Perhaps parse the rules in as well, though I'd like to start small and 
simple.

 From the log-file/alert database there will be dynamic reports and
be able to run queries on the database. Eg select all by alert, select 
by IP etc.
It will handle log files from more than one Apache server.

Cheers,
RS.


Tom Anderson wrote:

> From: "Rudi Starcevic" <tech@...>
>
>> I'm about to start a small PHP web app. to analyze mod security alerts.
>
>
>
>
> Tom
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Tell us your software development plans!
> Take this survey and enter to win a one-year sub to SourceForge.net
> Plus IDC's 2005 look-ahead and a copy of this survey
> Click here to start!  http://www.idcswdc.com/cgi-bin/survey?id=105hix
> _______________________________________________
> mod-security-users mailing list
> mod-security-users@...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
>
>

From: "Rudi Starcevic" <tech@...>
> I'm planning to parse the audit_log file into a relational database.
> Perhaps parse the rules in as well, though I'd like to start small and 
> simple.

Then you might find these useful:
http://orderamidchaos.com/modsec/modsec_auditlog_parser
http://prwdot.org/code/modsecauditlogparse.txt

They're written in Perl, not PHP, though.

Tom

raja agireddy wrote:
> Hello!
> 
> I have confiured modsecurity 1.8.7 and apache2 with the default
> configuration and I receive the following error. I had copied
> httpd.conf.regression-v2 to the httpd.conf.
> 
> [Wed Apr 27 17:20:59 2005] [error] [client xxx.xxx] mod_security: Access d
> enied with code 500. Pattern match "!(^$|^[a-zA-Z0-9]+$)" at COOKIES_VALUES [hos
> tname "xxx.xxx.xxx"] [uri "/cgi-bin/test-cgi"]
> 
> I get this error only through the IE browser but not through the
> firefox browser.
> 
> Please let me know if I can do something to work with IE.

   That is *not* the default configuration - remove it from httpd.conf

   httpd.conf.example-minimal is the default configuration:

http://cvs.sourceforge.net/viewcvs.py/mod-security/mod_security/httpd.conf.example-minimal?rev=1.9&view=auto

-- 
Ivan Ristic
Apache Security (O'Reilly) - http://www.apachesecurity.net
Open source web application firewall - http://www.modsecurity.org

From: "raja agireddy" <tagireddy@...>
> [Wed Apr 27 17:20:59 2005] [error] [client xxx.xxx] mod_security: Access d
> enied with code 500. Pattern match "!(^$|^[a-zA-Z0-9]+$)" at 
> COOKIES_VALUES [hos
> tname "xxx.xxx.xxx"] [uri "/cgi-bin/test-cgi"]

This is going to be triggered any time you set a cookie that contains any 
punctuation or other non-alphanumeric symbols (including spaces).  Comment 
out that line if you don't want to force your cookies into such narrow 
constraints, or modify the regex to include the characters you intend to 
use.  That's not even a very good regex since the blank case (^$) can simply 
be specified by changing the + to a *.  Here's a better filter for 
alphanumeric and space characters only...

SecFilterSelective COOKIES_VALUES "!^(\w|\s)*$"

Here's what you would use if you wanted to filter out the # sign in cookies:

SecFilterSelective COOKIES_VALUES "#"

Better would be to use such a filter on a _specific_ cookie:

SecFilterSelective COOKIE_password "!([0-9]|\W)" "deny,nolog,status:406"

This rule would block anyone using a weak password which got past your 
client-side checks.  Maybe not the best place to do something like this, but 
hey, it's just an example.

Google for "perlre" to get the perl documentation on regular expressions.

Tom

Tom Anderson wrote:
> From: "raja agireddy" <tagireddy@...>
> 
>> [Wed Apr 27 17:20:59 2005] [error] [client xxx.xxx] mod_security: 
>> Access d
>> enied with code 500. Pattern match "!(^$|^[a-zA-Z0-9]+$)" at 
>> COOKIES_VALUES [hos
>> tname "xxx.xxx.xxx"] [uri "/cgi-bin/test-cgi"]
> 
> That's not even a very good regex since the blank case 
> (^$) can simply be specified by changing the + to a *.  Here's a better 
> filter for alphanumeric and space characters only...
> 
> SecFilterSelective COOKIES_VALUES "!^(\w|\s)*$"

   It may be better when you are working with Apache 2.x, but it
   doesn't work at all when you are using Apache 1.x :)

   As far as I am aware Apache 1.x supports POSIX regular expressions,
   and Apache 2.x supports Perl-compatible regular expressions.

-- 
Ivan Ristic
Apache Security (O'Reilly) - http://www.apachesecurity.net
Open source web application firewall - http://www.modsecurity.org

chingu@... wrote:
> Hi,
> 
> I am recieving a 406 error when attempting to publish to a FrontPage subweb.
> This error does not happen when someone is publishing to the root web.
 >
 > ...
 >
> [Wed Apr 27 00:08:16 2005] [error] [client 68.192.115.60] mod_security:
> Access denied with code 406. Pattern match
> "!(^$|^application/x-www-form-urlencoded$|^multipart/form-data;)" at HEADER.
> [hostname "deb.terzano.com"] [uri "/Deb/_vti_bin/_vti_aut/author.exe"]
> [unique_id Qm8eQEI3TBIAAGz@...]
 >
 > ...
 >
> [Wed Apr 27 00:08:23 2005] [error] [client 68.192.115.60] mod_security:
> Warning. Pattern match "/_vti_bin/_vti_aut/author\\.exe" at THE_REQUEST.
> [hostname "deb.terzano.com"] [uri "/Deb/_vti_bin/_vti_aut/author.exe"]
> [unique_id Qm8eR0I3TBIAAGz@...]
> [Wed Apr 27 00:08:23 2005] [error] [client 68.192.115.60] mod_security:
> Warning. Pattern match "/_vti_bin/" at THE_REQUEST. [hostname
> "deb.terzano.com"] [uri "/Deb/_vti_bin/_vti_aut/author.exe"] [unique_id
> Qm8eR0I3TBIAAGz@...]

   Since you want to allow FrontPage requests it does not make sense
   to have warnings in the log when someone uses it.


> So with Frontpage (v. 2000) they can do everything as normal to the root
> web.  In the subwebs you can change security permissions, create new
> directories, and even new subwebs of subwebs, but you cannot save a new or
> edited page.
> 
> Any ideas?

   Send use the audit log fragment of the rejected entry. There is
   something in the Content-Type that clashes with your mod_security
   configuration.

-- 
Ivan Ristic
Apache Security (O'Reilly) - http://www.apachesecurity.net
Open source web application firewall - http://www.modsecurity.org

caleb racey wrote:
> Hello 
> 
> 
> Kudos on an excellent module and kudos to ivan on the excellent o'reilly
> apache security book.

   Thanks!


> When monitoring the server logs I have two questions:
> 
> 1) are there any tools for monitoring the audit logs, since the output
> per hit is multi line the normal approach of "grep"ing is not effective.
> For example my logs are overwhelmingly phpBB exploit attempts (a bot is
> doing the rounds) the noise from this in the logs is making it very
> difficult to track down other "hits" 

   Not at the moment. In May work will begin on a web-based console to
   track the audit entries. Since for that I need to build a (Perl)
   parser I am likely to make it usable from the command line too.

   BTW, you don't have to grep access_logs either. Have a look at
   the logscan utility: http://www.apachesecurity.net/tools


> 2) is there any way to tie down a "hit" to the rule that caught it? Once
> I have identified false positives it is difficult to track down the rule
> causing it, It would be useful if the log would give some form of rule
> identifier for which rule caused the match

   There is, since yesterday, if you are not afraid to deploy 1.9dev2.
   I've just added three more actions: id, msg, severity. They are
   just plain text fields that will appear in the error message created
   by a rule.

-- 
Ivan Ristic
Apache Security (O'Reilly) - http://www.apachesecurity.net
Open source web application firewall - http://www.modsecurity.org

----- Original Message ----- 
From: "Ivan Ristic" <ivanr@...>
>> 1) are there any tools for monitoring the audit logs, since the output
>> per hit is multi line the normal approach of "grep"ing is not effective.
>> For example my logs are overwhelmingly phpBB exploit attempts (a bot is
>> doing the rounds) the noise from this in the logs is making it very
>> difficult to track down other "hits"
>
>   Not at the moment. In May work will begin on a web-based console to
>   track the audit entries. Since for that I need to build a (Perl)
>   parser I am likely to make it usable from the command line too.

Here's a little something I threw together:
http://orderamidchaos.com/modsec/modsec_auditlog_parser

Use it like this:
 ./modsec_auditlog_parser < /var/log/apache2/modsec_audit_log |less

Maybe it will solve the current problem of weeding through entries, and 
maybe it will help serve as the basis of a more in depth parser.  Right now 
it just grabs a few scraps of info (user agent, message, action) and sums 
them over domains.  BTW, I'm running version 1.7.6, so I don't know if the 
log has changed at all since then.  Let me know if you'd like me to do any 
tweaking for you.

Tom

> Here's a little something I threw together:
> http://orderamidchaos.com/modsec/modsec_auditlog_parser
>=20
> Use it like this:
>  ./modsec_auditlog_parser < /var/log/apache2/modsec_audit_log |less

I wrote something similar:

http://prwdot.org/code/modsecauditlogparse.txt

But it's more quick and dirty... you are welcome to use the code if it
suits you.

Peter
--=20
Peter R. Wood | email: prw.lists@... | blog: http://prwdot.org/