ModSecurity

Here are some general guidelines.  You may need to adjust these slightly
depending on how you are using Vhosts.

1) Load the ModSecurity DSO in the main httpd.conf file

2) Enable Mod rules in the main httpd.conf file to handle requests whose
Host header does not match a Vhost.  Most often, people call up the Core
Rules using a wild-card Include like this -

Include conf/rules/*.conf

This will activate all Core Rule files that end with ".conf".  Also keep
in mind that when using the wild-card, the names of the files become
important from a rule ordering perspective.  The impact to Vhosts of
activating these rules in the main section of the httpd.conf file is
that you then probably use "SecRuleInheritance Off" to disable them
later in the Vhost configs so that you start with a clean slate.  Any
SecRules configured in the main config could impact all Vhosts.

3) Use Includes in the main httpd.conf file to call up the individual
Vhost file(s).  For example, in Apache 2.2.4 -

# Virtual hosts
Include conf/extra/httpd-vhosts.conf

4) In the Vhost file(s) - place all relevant Mod rules in each Vhost
container.  Again, make sure to use SecRuleInheritance Off at the
beginning of the Vhost to clear out any inherited configs.

5) Within the Vhost container, you can then handle custom rules BEFORE
and AFTER the Core Rules by either specifying the individual rules or
using more Includes.

Hope this helps.

--=20
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
=20
=20
> -----Original Message-----
> From: mod-security-users-bounces@... [mailto:mod-
> security-users-bounces@...] On Behalf Of Yoann Juet
> Sent: Thursday, August 23, 2007 9:50 AM
> To: mod-security-users@...
> Subject: [mod-security-users] Custom ruleset per vhost
>=20
> Hi all,
>=20
> Can you please tell me what is the best practice for defining custom
> rulesets per vhost. I'm planning to create a MS2 subdirectory per
vhost
> with the following files :
> - modsecurity_crs_15_customrules.conf (custom rules)
> - modsecurity_crs_60_customrules.conf (custom rules)
> - symlink to modsecurity_crs_20-55_* files from the core ruleset
>=20
> and then add an Include directive inside each apache's vhost
> configuration file.
>=20
> Does that make sense ? Is there a better approach ?
>=20
> Thanks, --Yoann

I set mine up like this:

In the httpd.conf:

<IfModule security2_module>
  Include conf/modsecurity_crs_10_config.conf
</IfModule>

In the httpd-vhosts.conf
<Virtual x.x.x.x:80>
<IfModule security2_module>
        SecRule RESPONSE_STATUS "!^(?:30[12]|[45]\d\d)$"
"phase:3,pass,nolog,initcol:resource=3D%{REQUEST_FILENAME}"
        Include conf/modsecurity_crs_20_protocol_violations.conf
        Include conf/modsecurity_crs_21_protocol_anomalies.conf
        Include conf/modsecurity_crs_30_http_policy.conf
        Include conf/modsecurity_crs_35_bad_robots.conf
        Include conf/modsecurity_crs_40_generic_attacks.conf
        Include conf/modsecurity_crs_45_trojans.conf
        Include conf/modsecurity_crs_50_outbound.conf
        Include conf/modsecurity_crs_55_marketing.conf
</IfModule>

I don't know if this is the right way to do it but it has been working
for a month now for my wiki and ecommerce site.

paul


-----Original Message-----
From: mod-security-users-bounces@...
[mailto:mod-security-users-bounces@...] On Behalf Of
Ryan Barnett
Sent: Thursday, August 23, 2007 2:11 PM
To: yoann.juet@...; mod-security-users@...
Subject: Re: [mod-security-users] Custom ruleset per vhost

Here are some general guidelines.  You may need to adjust these slightly
depending on how you are using Vhosts.

1) Load the ModSecurity DSO in the main httpd.conf file

2) Enable Mod rules in the main httpd.conf file to handle requests whose
Host header does not match a Vhost.  Most often, people call up the Core
Rules using a wild-card Include like this -

Include conf/rules/*.conf

This will activate all Core Rule files that end with ".conf".  Also keep
in mind that when using the wild-card, the names of the files become
important from a rule ordering perspective.  The impact to Vhosts of
activating these rules in the main section of the httpd.conf file is
that you then probably use "SecRuleInheritance Off" to disable them
later in the Vhost configs so that you start with a clean slate.  Any
SecRules configured in the main config could impact all Vhosts.

3) Use Includes in the main httpd.conf file to call up the individual
Vhost file(s).  For example, in Apache 2.2.4 -

# Virtual hosts
Include conf/extra/httpd-vhosts.conf

4) In the Vhost file(s) - place all relevant Mod rules in each Vhost
container.  Again, make sure to use SecRuleInheritance Off at the
beginning of the Vhost to clear out any inherited configs.

5) Within the Vhost container, you can then handle custom rules BEFORE
and AFTER the Core Rules by either specifying the individual rules or
using more Includes.

Hope this helps.

-- =

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@... [mailto:mod-
> security-users-bounces@...] On Behalf Of Yoann Juet
> Sent: Thursday, August 23, 2007 9:50 AM
> To: mod-security-users@...
> Subject: [mod-security-users] Custom ruleset per vhost
> =

> Hi all,
> =

> Can you please tell me what is the best practice for defining custom
> rulesets per vhost. I'm planning to create a MS2 subdirectory per
vhost
> with the following files :
> - modsecurity_crs_15_customrules.conf (custom rules)
> - modsecurity_crs_60_customrules.conf (custom rules)
> - symlink to modsecurity_crs_20-55_* files from the core ruleset
> =

> and then add an Include directive inside each apache's vhost
> configuration file.
> =

> Does that make sense ? Is there a better approach ?
> =

> Thanks, --Yoann

------------------------------------------------------------------------
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
mod-security-users mailing list
mod-security-users@...
https://lists.sourceforge.net/lists/listinfo/mod-security-users


                           Email Policy
____________________________________________________________________
The information in this email, including any attachments, is
confidential to the intended recipient and may be legally privileged.
If you are not the intended recipient of this message you may not
copy, distribute, disclose or rely on the information contained in it
nor use it's contents in any way. Please contact the sender
immediately and delete this message, together with any attachments,
from your system. The unauthorized use, dissemination, distribution
or reproduction of this e-mail, including attachments is prohibited
and may be unlawful.
We do not accept any liability or responsibility for changes made to
this e-mail after it was sent, or viruses transmitted through this
e-mail or any attachment. You should take full responsibility for
virus checking.

Thanks for sharing Paul.  I think that it is valuable for Mod users to
share this type of information to how others are handling things.

Two questions -

1) Do you only have 1 vhost?  If so, they you don't really need a Vhost
:)  If you have more than 1, how are your other Vhost configured?
2) How are you handling exceptions and custom rules?  Are you applying
them directly to the Vhosts or handling them within their own custom
rule files?

If you have custom rule files that will apply to all Vhosts, then you
can call them up like this -

<Virtual x.x.x.x:80>
<IfModule security2_module>
        SecRule RESPONSE_STATUS "!^(?:30[12]|[45]\d\d)$"
"phase:3,pass,nolog,initcol:resource=3D%{REQUEST_FILENAME}"
        Include conf/modsecurity_crs_15_customrules.conf
        Include conf/modsecurity_crs_20_protocol_violations.conf
        Include conf/modsecurity_crs_21_protocol_anomalies.conf
        Include conf/modsecurity_crs_30_http_policy.conf
        Include conf/modsecurity_crs_35_bad_robots.conf
        Include conf/modsecurity_crs_40_generic_attacks.conf
        Include conf/modsecurity_crs_45_trojans.conf
        Include conf/modsecurity_crs_50_outbound.conf
        Include conf/modsecurity_crs_55_marketing.conf
        Include conf/modsecurity_crs_60_customrules.conf
</IfModule>

If you have individual custom rules that only apply the current Vhost,
then you should probably handle it just as your are with the 1st SecRule
that you have.  This way, the rule is tied to the Vhost container.



--=20
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
=20
=20

> -----Original Message-----
> From: Paul Greenwood [mailto:Paul.Greenwood@...]
> Sent: Thursday, August 23, 2007 4:13 PM
> To: Ryan Barnett; yoann.juet@...; mod-security-
> users@...
> Subject: RE: [mod-security-users] Custom ruleset per vhost
>=20
> I set mine up like this:
>=20
> In the httpd.conf:
>=20
> <IfModule security2_module>
>   Include conf/modsecurity_crs_10_config.conf
> </IfModule>
>=20
> In the httpd-vhosts.conf
> <Virtual x.x.x.x:80>
> <IfModule security2_module>
>         SecRule RESPONSE_STATUS "!^(?:30[12]|[45]\d\d)$"
> "phase:3,pass,nolog,initcol:resource=3D%{REQUEST_FILENAME}"
>         Include conf/modsecurity_crs_20_protocol_violations.conf
>         Include conf/modsecurity_crs_21_protocol_anomalies.conf
>         Include conf/modsecurity_crs_30_http_policy.conf
>         Include conf/modsecurity_crs_35_bad_robots.conf
>         Include conf/modsecurity_crs_40_generic_attacks.conf
>         Include conf/modsecurity_crs_45_trojans.conf
>         Include conf/modsecurity_crs_50_outbound.conf
>         Include conf/modsecurity_crs_55_marketing.conf
> </IfModule>
>=20
> I don't know if this is the right way to do it but it has been working
> for a month now for my wiki and ecommerce site.
>=20
> paul
>=20
>=20
> -----Original Message-----
> From: mod-security-users-bounces@...
> [mailto:mod-security-users-bounces@...] On Behalf Of
> Ryan Barnett
> Sent: Thursday, August 23, 2007 2:11 PM
> To: yoann.juet@...;
mod-security-users@...
> Subject: Re: [mod-security-users] Custom ruleset per vhost
>=20
> Here are some general guidelines.  You may need to adjust these
slightly
> depending on how you are using Vhosts.
>=20
> 1) Load the ModSecurity DSO in the main httpd.conf file
>=20
> 2) Enable Mod rules in the main httpd.conf file to handle requests
whose
> Host header does not match a Vhost.  Most often, people call up the
Core
> Rules using a wild-card Include like this -
>=20
> Include conf/rules/*.conf
>=20
> This will activate all Core Rule files that end with ".conf".  Also
keep
> in mind that when using the wild-card, the names of the files become
> important from a rule ordering perspective.  The impact to Vhosts of
> activating these rules in the main section of the httpd.conf file is
> that you then probably use "SecRuleInheritance Off" to disable them
> later in the Vhost configs so that you start with a clean slate.  Any
> SecRules configured in the main config could impact all Vhosts.
>=20
> 3) Use Includes in the main httpd.conf file to call up the individual
> Vhost file(s).  For example, in Apache 2.2.4 -
>=20
> # Virtual hosts
> Include conf/extra/httpd-vhosts.conf
>=20
> 4) In the Vhost file(s) - place all relevant Mod rules in each Vhost
> container.  Again, make sure to use SecRuleInheritance Off at the
> beginning of the Vhost to clear out any inherited configs.
>=20
> 5) Within the Vhost container, you can then handle custom rules BEFORE
> and AFTER the Core Rules by either specifying the individual rules or
> using more Includes.
>=20
> Hope this helps.
>=20
> --
> 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
>=20
>=20
> > -----Original Message-----
> > From: mod-security-users-bounces@... [mailto:mod-
> > security-users-bounces@...] On Behalf Of Yoann
Juet
> > Sent: Thursday, August 23, 2007 9:50 AM
> > To: mod-security-users@...
> > Subject: [mod-security-users] Custom ruleset per vhost
> >
> > Hi all,
> >
> > Can you please tell me what is the best practice for defining custom
> > rulesets per vhost. I'm planning to create a MS2 subdirectory per
> vhost
> > with the following files :
> > - modsecurity_crs_15_customrules.conf (custom rules)
> > - modsecurity_crs_60_customrules.conf (custom rules)
> > - symlink to modsecurity_crs_20-55_* files from the core ruleset
> >
> > and then add an Include directive inside each apache's vhost
> > configuration file.
> >
> > Does that make sense ? Is there a better approach ?
> >
> > Thanks, --Yoann
>=20
>
------------------------------------------------------------------------
> -
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a
browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> mod-security-users mailing list
> mod-security-users@...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
>=20
>=20
>                            Email Policy
> ____________________________________________________________________
> The information in this email, including any attachments, is
> confidential to the intended recipient and may be legally privileged.
> If you are not the intended recipient of this message you may not
> copy, distribute, disclose or rely on the information contained in it
> nor use it's contents in any way. Please contact the sender
> immediately and delete this message, together with any attachments,
> from your system. The unauthorized use, dissemination, distribution
> or reproduction of this e-mail, including attachments is prohibited
> and may be unlawful.
> We do not accept any liability or responsibility for changes made to
> this e-mail after it was sent, or viruses transmitted through this
> e-mail or any attachment. You should take full responsibility for
> virus checking.
>=20

Thanks all for your tips. As previously described, I will place custom 
modsec rules before and after core rules inside each vhost definition 
(and disable rule inheritance); I wonder if there's a performance or 
memory consumption big issue doing so with 50-100 vhosts ? In fact, in 
this situation, core rules are duplicated in memory per vhost, aren't 
they ? Could be a big issue with gotroot complete ruleset...

Ryan Barnett wrote:
> Here are some general guidelines.  You may need to adjust these slightly
> depending on how you are using Vhosts.
> 
> 1) Load the ModSecurity DSO in the main httpd.conf file
> 
> 2) Enable Mod rules in the main httpd.conf file to handle requests whose
> Host header does not match a Vhost.  Most often, people call up the Core
> Rules using a wild-card Include like this -
> 
> Include conf/rules/*.conf
> 
> This will activate all Core Rule files that end with ".conf".  Also keep
> in mind that when using the wild-card, the names of the files become
> important from a rule ordering perspective.  The impact to Vhosts of
> activating these rules in the main section of the httpd.conf file is
> that you then probably use "SecRuleInheritance Off" to disable them
> later in the Vhost configs so that you start with a clean slate.  Any
> SecRules configured in the main config could impact all Vhosts.
> 
> 3) Use Includes in the main httpd.conf file to call up the individual
> Vhost file(s).  For example, in Apache 2.2.4 -
> 
> # Virtual hosts
> Include conf/extra/httpd-vhosts.conf
> 
> 4) In the Vhost file(s) - place all relevant Mod rules in each Vhost
> container.  Again, make sure to use SecRuleInheritance Off at the
> beginning of the Vhost to clear out any inherited configs.
> 
> 5) Within the Vhost container, you can then handle custom rules BEFORE
> and AFTER the Core Rules by either specifying the individual rules or
> using more Includes.
> 
> Hope this helps.
>

You are correct in that memory could potentially be an issue in that
type of a setup, especially if you are using the entire GotRoot rules,
as they are not optimized in the same way that the Core Rules are
(http://www.modsecurity.org/blog/archives/2007/01/key_advantages.html).
This means that if you activate the entire rules package then you will
take a big performance hit.  The best way to use the GotRoot rules is to
only activate the individual rules that apply to your platform (ASP,
PHP, etc...) or if there is a specific vulnerability identified. =20

Back to the Core Rules - If the majority of your rules will apply to all
Vhosts and you only need to use exceptions to disable certain rules that
are causing false positives, then you could probably activate the rules
just once in the main config file and then use the appropriate
SecRuleRemoveById directives in the Vhosts.

FYI - in the future, the SecRuleRemoveById directive functionality will
be migrated to an action.  This will allow for much more flexible rule
exclusions.

--=20
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
=20
=20

> -----Original Message-----
> From: mod-security-users-bounces@... [mailto:mod-
> security-users-bounces@...] On Behalf Of Yoann Juet
> Sent: Friday, August 24, 2007 8:35 AM
> Cc: mod-security-users@...
> Subject: Re: [mod-security-users] Custom ruleset per vhost
>=20
> Thanks all for your tips. As previously described, I will place custom
> modsec rules before and after core rules inside each vhost definition
> (and disable rule inheritance); I wonder if there's a performance or
> memory consumption big issue doing so with 50-100 vhosts ? In fact, in
> this situation, core rules are duplicated in memory per vhost, aren't
> they ? Could be a big issue with gotroot complete ruleset...
>=20
> Ryan Barnett wrote:
> > Here are some general guidelines.  You may need to adjust these
slightly
> > depending on how you are using Vhosts.
> >
> > 1) Load the ModSecurity DSO in the main httpd.conf file
> >
> > 2) Enable Mod rules in the main httpd.conf file to handle requests
whose
> > Host header does not match a Vhost.  Most often, people call up the
Core
> > Rules using a wild-card Include like this -
> >
> > Include conf/rules/*.conf
> >
> > This will activate all Core Rule files that end with ".conf".  Also
keep
> > in mind that when using the wild-card, the names of the files become
> > important from a rule ordering perspective.  The impact to Vhosts of
> > activating these rules in the main section of the httpd.conf file is
> > that you then probably use "SecRuleInheritance Off" to disable them
> > later in the Vhost configs so that you start with a clean slate.
Any
> > SecRules configured in the main config could impact all Vhosts.
> >
> > 3) Use Includes in the main httpd.conf file to call up the
individual
> > Vhost file(s).  For example, in Apache 2.2.4 -
> >
> > # Virtual hosts
> > Include conf/extra/httpd-vhosts.conf
> >
> > 4) In the Vhost file(s) - place all relevant Mod rules in each Vhost
> > container.  Again, make sure to use SecRuleInheritance Off at the
> > beginning of the Vhost to clear out any inherited configs.
> >
> > 5) Within the Vhost container, you can then handle custom rules
BEFORE
> > and AFTER the Core Rules by either specifying the individual rules
or
> > using more Includes.
> >
> > Hope this helps.
> >