Hi Ryan, thanks for the response, it has proven to be quite helpfull. Please review my comments below.
 
-Grant
----- Original Message -----
From: Ryan Barnett
To: Grant Peel ; ModSecurity
Sent: Tuesday, October 30, 2007 10:19 AM
Subject: RE: [mod-security-users] Is it working?

Comments inline below.

--
Ryan C. Barnett
ModSecurity Community Manager
Breach Security: Director of Training
Web Application Security Consortium (WASC) Member
CIS Apache Benchmark Project Lead
SANS Instructor, GCIA, GCFA, GCIH, GSNA, GCUX, GSEC
Author: Preventing Web Attacks with Apache



> -----Original Message-----
> From: mod-security-users-bounces@lists.sourceforge.net [mailto:mod-
> security-users-bounces@lists.sourceforge.net] On Behalf Of Grant Peel
> Sent: Tuesday, October 30, 2007 9:45 AM
> To: ModSecurity
> Subject: [mod-security-users] Is it working?
>
> Hi all,
>
> I have recently installed modsecurity2 from FreeBSD ports.
>
> The install went fine. I have the rules installed and the include file
> appears loaded as I am seeing the occasional reference in the debug
and
> audit logs.
>
> I have tried a few methods of spoofing an attack and cant seem to
trigger
> anything. i.e. FOrbidden or Access Denied responses.
[Ryan Barnett] What attack string did you use? Also, an important item
to keep in mind is that just because you configure SecRuleEngine to On
does not necessarily mean that it will block everything. What this
directive configuration means is that ModSecurity will actually execute
whatever disruptive action is specified in each rule. If the rule uses
the "deny" action then it will be executed. If, however, the rule is
configured to "alert only" then that is what it will do. If you want
Mod to block just about everything the make sure to use the rule sets
under the "blocking" directory.
Um, do I just change my config line in apache to point to the blocking rules or is there some other way to use them? (Perhaps I missed reading about them in the docs).
>
> That having been said, I do have lots of audit log and debug log
activity.
> The logs appear to be saying it scanning things etc etc.
>
[Ryan Barnett] What are the ModSecurity Messages in the audit_log? They
will tell you if/why Mod took action.
With the egrep command you sent, I now see lots of access denied and forbidden messages.

> What I am looking for is an answer as to weather I am just paranoid,
or if
> mod_sec just isn't catching anything, or if it is working, and I am
just
> not
> being attacked much.
>
[Ryan Barnett] Looks like you have a "healthy" dose of paranoia which is
good ;) Let me ask you this question - where there attacks that you
identified prior to installing ModSecurity but you needed a way to block
them?

To get an idea of the types of attack categories that Mod is
identifying, you could run a simple grep on your ModSecurity audit_log
file like this -

# egrep '^Message:' modsec_audit.log | sort | uniq -c | sort -rn

> I am seeing thousands of warnings that mod_sec does not handle
compressed
> (mod_deflate) output. Should I turn off outbound scanning?
>
[Ryan Barnett] That is up to you. Currently, ModSecurity can not
inspect compressed data so this rule was included just to alert you to
this fact. There is a rule that will create a RESOURCE collection for
each file that uses compression and it will only alert once for each
file. If you use compression on your entire site then you may want to
consider disabling this rule.
 
Yes, I currently compress everything that id compressable with mod_deflate, so I am hoping turnung off this rule will save a little CPU.

We will look into trying to have Mod inspect outbound data prior to
Apache using mod_deflate however it can get tricky to have Mod inspect
in phase:4 at just the right moment as it may have to run before some
modules and after others...

> Here is the line I have in my httpd.conf:
>
> Include /usr/local/etc/apache22/Includes/conf/modsecurity/*.conf
>
> Does it matter WHERE in the httpd.conf file the (above) line is
located?
> Right now, it is the last config line before my virtual hosts start.
[Ryan Barnett] That should work fine. The important thing about
location in the file is that it just needs to come after the LoadModule
for mod_security2.so.

>
> Also, my mod_security is the second to last module to load. My mod_ssl
> file
> is one of the first directives to load.
[Ryan Barnett] This looks fine.

> ...
> LoadModule rewrite_module libexec/apache22/mod_rewrite.so
> LoadModule speedycgi_module libexec/apache22/mod_speedycgi.so
> LoadModule security2_module libexec/apache22/mod_security2.so
> LoadModule php4_module libexec/apache22/libphp4.so
>
> I have also heard of mlogc. Where can I read what it really does.
Pouring
> through the logs makes me cross eyed. Would mlogc help? (I don't run
any
> xservers).
 
I think I can safely grep the files once in a while and that will suffice.
 
Other than debugging, does anyone think there is a real reason to keep using debug log or can I turn it off and simply rely on the audit logs for production use.

[Ryan Barnett] Well then, you need to consider testing out the
ModSecurity Community Console then :)
http://www.modsecurity.org/projects/console/index.html

The Console helps to manage ModSecurity alerts. All mlogc is is a
client program that will monitor the audit_log files in real time and
then send them over the network to the Console.

Take a look at the FAQ section on Managing Alerts -
http://www.modsecurity.org/documentation/faq.html#d0e456


Total Control Panel Login
To: gpeel@thenetnow.com
From: ryan.barnett@breach.com
Message Score: 50 High (60): Pass
My Spam Blocking Level: High Medium (75): Pass
Low (90): Pass
Block this sender / Block this sender enterprise-wide
Block breach.com / Block breach.com enterprise-wide
This message was delivered because the content filter score did not exceed your filter level.