ModSec

From Just another day in the life of a linux sysadmin
Jump to navigation Jump to search


MODSEC WHITELIST /etc/apache2/conf.d/userdata/std/2_4/USERNAME/DOMAIN.com/whitelist.conf

Contents

Intro

ModSecurity is an open source, free web application firewall (WAF) Apache module. With over 70% of all attacks now carried out over the web application level, organizations need all the help they can get in making their systems secure. WAFs are deployed to establish an external security layer that increases security, detects and prevents attacks before they reach web applications. It provides protection from a range of attacks against web applications and allows for HTTP traffic monitoring and real-time analysis with little or no changes to existing infrastructure.

There are other fun things that you can do with modsec that are not covered here but if you need some voodoo performed please ask away. Here are two other good points of reference for modsec related info: GotRoot.com and modsecurity.org Docs

Plesk ModSec behaves quite differently. Although many of the core concepts and syntax are the same, the file locations are not - please review the information in this document and then consult the Plesk-specific article to finish up the task.

Template:Info

Shared Servers

So long as the server is NOT running DSO (the changes will be overridden) you can add rules in the vhost include. Be sure to test the conf before restarting apache.

httpd -t

Whitelist Rule(s) For Specific Domain(s)

Version

ModSecurity version is logged in the error log on a hard restart (i.e. stop/start) of Apache.

Usually you're only worried about if the server has the module compiled in at all. This can be checked with:

httpd -M |grep -i sec

For Apache 2 you should see:

security2_module (shared)
Syntax OK

If you need to know the exact version number, try to grep for it in the apache error_log, or stop/start apache while tailing that log (which will cause a few seconds of downtime).

Template:Warning

Apache 1.X

Configs

The main cpanel modsec config is here:

/usr/local/apache/conf/modsec.conf

modsec.conf (modsec1)

<IfModule mod_security.c>
SecFilterEngine On
SecFilterCheckURLEncoding On
SecFilterForceByteRange 0 255
SecAuditEngine RelevantOnly
SecAuditLog logs/audit_log
SecFilterDebugLog logs/modsec_debug_log
SecFilterDebugLevel 0
SecFilterDefaultAction "deny,log,status:406"
SecFilterSelective REMOTE_ADDR "^127.0.0.1$" nolog,allow
Include "/usr/local/apache/conf/modsec.user.conf"
</IfModule>

Our main config is here:

/usr/local/apache/conf/modsec.user.conf

This config includes our other configs located here:

/usr/local/apache/conf/modsec/exclude.conf
/usr/local/apache/conf/modsec/whitelist.conf
/usr/local/apache/conf/modsec/rootkits.conf


When modsec is triggered the user (or bot) will see 406 (or potentially a 403) error indicating Forbidden or Not Acceptable


Installing

cPanel 11 has blessed us with Apache 2 (And Mod Security 2.c).

In order to enable Mod Security, you need to compile Apache2 with UniqueId, and obviously, mod_security needs to be checked as well. If done correctly, you should see these two lines in the httpd.conf

LoadModule security2_module modules/mod_security2.so
Include "/usr/local/apache/conf/modsec2.conf"

Can't find the LoadModule statement in the httpd.conf file? Check in the modsec2.conf file.

To install our rules, just do so with lpyum

lpyum install lp-modsec2-rules.noarch

Install our rules on CENT 6

yum install lp-modsec2-rules.noarch

The Log

modsec logs here:

/usr/local/apache/logs/error_log
/usr/local/apache/logs/audit_log (older 2.x or 1.x installs)
/usr/local/apache/logs/modsec_audit.log (modern 2.x installs)

Once per hour cpanel parses the audit log with /etc/cron.hourly/modsecparse.pl, puts the contents in mysql and wipes the log.
The info it grabbed will then be located in the WHM interface under Plug-ins -> Mod Security

All (new) rules are now grouped by type with a description and rule ID. When a rule is flagged it will show in the audit log with the regex it matched, the rule description and the ID#. Use this to track down the rule getting hit.

Here is an example entry from the error_log. Note that the "hostname" is the domain being accessed, and the "id" is the rule id being triggered. "Unique_id" is a pointer to the modsec_audit.log for more information.

[Wed Dec 26 13:38:42 2012] [error] [client 188.143.232.176] ModSecurity: Access denied with code 406 (phase 2). Pattern match "select.*from.*information_schema\\\\.tables" at REQUEST_URI. [file "/usr/local/apache/conf/modsec2/rootkits.conf"] [line "155"] [id "3000086"] [hostname "fjmc.net"] [uri "/index.php"] [unique_id "UNtEMkPjo@cAAALOTc0AAAAA"]


(Placeholder for modern example from the modsec audit log..)

Whitelisting

If something needs to be whitelisted simply open the whitelist.conf and add something like one of these:

SecFilter "yourregex" allow,nolog
SecFilterSelective THE_REQUEST "yourregex" allow,nolog
SecFilterSelective REQUEST_URI "yourregex" allow,nolog
SecFilterSelective POST_PAYLOAD "yourregex" allow,nolog
SecFilterSelective HTTP_Referer "yourregex" allow,nolog
SecFilterSelective HTTP_CLIENT_IP "yourregex" allow,nolog
SecFilterSelective HTTP_USER_AGENT "yourregex" allow,nolog

N.B. Both SecFilter and SecFilterSelective are deprecated in favor of SecRule in ModSec2.

Those should cover just about anything getting caught by a filter. You should only need one of those though. Also please note that nolog can be change to log for troubleshooting and that yourregex is to be replaced with whatever expression you are trying to catch and whitelist.

For example if you wanted to whitelist any request containing zacsdomain.com you would add this:

SecFilterSelective THE_REQUEST "zacsdomain.com" allow,nolog

However, whitelisting by domain; you may get

Syntax error on line 43 of /usr/local/apache/conf/modsec2/whitelist.conf: Invalid command 'SecFilterSelective', perhaps mis-spelled or defined by a module not included in the server configuration

Try this:

SecRule SERVER_NAME "zacksdomain.com" phase:1,nolog,allow,ctl:ruleEngine=off,id:SOME-RANDOM-NUMBER

If you want to whitelist by IP, you might try these (replace with the proper IP of course):

SecRule REMOTE_ADDR "^69\.16\.222\.126$" phase:1,log,allow,ctl:ruleEngine=DetectionOnly,id:SOME-RANDOM-NUMBER
SecRule REMOTE_ADDR "^69\.16\.222\.126$" phase:1,log,allow,ctl:ruleEngine=Off,id:SOME-RANDOM-NUMBER

When you pick a rule number for your new rule make sure it is 10 or fewer digits or Apache will not start.

Apache 2

Configs

The main cpanel modsec config is here:

/usr/local/apache/conf/modsec2.conf

modsec2.conf (modsec2)

LoadFile /opt/xml2/lib/libxml2.so
LoadFile /opt/lua/lib/liblua.so
LoadModule security2_module  modules/mod_security2.so
<IfModule mod_security2.c>
SecRuleEngine On
# See http://www.modsecurity.org/documentation/ModSecurity-Migration-Matrix.pdf 
#  "Add the rules that will do exactly the same as the directives"
# SecFilterCheckURLEncoding On 
# SecFilterForceByteRange 0 255
SecAuditEngine RelevantOnly
SecAuditLog logs/modsec_audit.log 
SecDebugLog logs/modsec_debug_log
SecDebugLogLevel 0
SecDefaultAction "phase:2,deny,log,status:406"
SecRule REMOTE_ADDR "^127.0.0.1$" nolog,allow
Include "/usr/local/apache/conf/modsec2.user.conf"
</IfModule>


Our main config is here:

/usr/local/apache/conf/modsec2.user.conf

You will find additional configs in /usr/local/apache/conf/modsec2/, which are

exclude.conf
whitelist.conf
rootkits.conf

There should be much of a reason to touch those, but in case, it's pretty straight forward what they do.

Installing

cPanel 11 has blessed us with Apache 2 (And Mod Security 2.c).

In order to enable Mod Security, you need to compile Apache2 with UniqueId, and obviously, mod_security needs to be checked as well. If done correctly, you should see these two lines in the httpd.conf

LoadModule security2_module modules/mod_security2.so
Include "/usr/local/apache/conf/modsec2.conf"

Can't find the LoadModule statement in the httpd.conf file? Check in the modsec2.conf file.

To install our rules, just do so with lpyum

lpyum install lp-modsec2-rules.noarch


If Cent 6 is running on the box, use

 yum install lp-modsec2-rules.noarch

The Log

modsec logs here:

/usr/local/apache/logs/modsec_audit.log

Most of the errors you need will be in the standard apache error log

/usr/local/apache/logs/error_log

For now, the logs are pretty basic. It's pretty obvious what triggered the rule in the example below. This will help you trouble shoot whats going on if you get a 406 Not Acceptable.

--99dcce71-H--
Message: Access denied with code 406 (phase 2). Pattern match "mkdir" at REQUEST_URI.
Action: Intercepted (phase 2)
Stopwatch: 1191523307325575 2609 (1105 1654 -)
Producer: ModSecurity v2.1.3 (Apache 2.x)
Server: Apache/2.0.61 (Unix) mod_ssl/2.0.61 OpenSSL/0.9.7a mod_auth_passthrough/2.1 mod_bwlimited/1.4 PHP/5.2.4

Blocking per IP or Domain

Zeus Load Balanced blocking

When using a mod_zeus with the zeus cluster you can block per IP by using the syntax below:

SecRule REQUEST_HEADERS:X-Cluster-Client-Ip "^10.30.6.147$" "deny,log,status:412,msg:'Test Block'"

This needs to go on each server in the cluster this is of course simply example information and you would change the IP to be the IP you need it to be and you can customize the logging, message and also provide an ID if you wanted to so you can whitelist the rule, but since you have to manually put this information into a configuration file there is no reason to. This entry would go in the modsec2.user.conf file or can go in a customer file as long as you put the call for the customer file in the modsec2.user.conf file for Apache restarts.

Of course, once you apply a rule you would restart Apache on the server.


Whitelisting

Rules are rules for a reason. Don't just remove them...

Template:Warning

ModSecurity Phases and Variables

Whitelisting is a lot different with modsec2. For our "Standard" ruleset, You'll want to add the rules to

/usr/local/apache/conf/modsec2/whitelist.conf  (or for EA4: /etc/apache2/conf.d/modsec2/whitelist.conf)

or for the Server Secure + rules, use

/usr/local/apache/conf/modsec2/lw_whitelist.conf  (If this file does not exist, make it, and add it as an include file in modsec2.user.conf)
/etc/httpd/modsecurity.d/lwrules/whitelist.conf for Plesk.


The syntax is as follows:

<LocationMatch "/URI/From/Error">
  SecRuleRemoveById 123456
</LocationMatch>

The first issue to realize is that in ModSecurity 2.0, the allow action is only applied to the current phase. This means that if a rule matches in a subsequent phase it may still take a disruptive action.

You can get very specific with what gets filtered and what doesn't. But this should get the errors out of the customers face. If they need something more specific, direct them to Steven Collins (tread lightly), or visit Mod Security for more information.

The easiest way to whitelist a rule is to add a LocationMatch directive to the whitelist.conf. Alternately, to whitelist a single rule for a single domain, you will need to use an include file for the domain. See below, or see Customize httpd.conf for setting up custom vhost includes.

Template:Warning

Using CMC

CMC is Configserver's ModSec Control plugin for WHM. Its free, and makes whitelisting problem ModSec rules easy. It does require that all of the ModSec rule files be located in /usr/local/apache/conf/modsec* and/or are named beginning with the word "modsec" and that each rule has an ID number to identify it. Thus it will not help with some of the "generic" rules (which don't have rule IDs) from our old modsec1 and 2 rpm's. For those you will want to either modify the modsec2.user.conf file and give the problem rule an ID, or use one of the other methods outlined below.

Download and install CMC

cd /usr/src
wget https://download.configserver.com/cmc.tgz
tar xvfz cmc.tgz
cd cmc
./install.sh

The plugin automagically adds these lines to /usr/local/apache/conf/modsec2.user.conf at the top:

# ConfigServer ModSecurity whitelist file
Include /usr/local/apache/conf/modsec2/whitelist.conf

If you need to whitelist something, go to "WHM > Plugins > ConfigServer ModSec Control" - the interface is pretty self-explanatory. You'll need the ID number of the problem rule, and/or the domain having issues. It can also be used to turn ModSec on and off server wide, or on an account- or domain-level basis.

LocationMatch

To whitelist a specific rule, you need to add an entry to the whitelist.conf. /usr/local/apache/conf/modsec2/whitelist.conf for EA3 /etc/apache2/conf.d/modsec2/whitelist.conf for EA4

In the following examples, the beginning / is the path as seen from the account's DocumentRoot (aka public_html directory on most cPanel servers).

So "/private/test.pl" will match all domains thusly:

/home/username/public_html/private/test.pl

The syntax is as follows:

<LocationMatch "/URI/From/Error">
  SecRuleRemoveById 123456
</LocationMatch>

The Id needs to be the Id listed in /usr/local/apache/conf/modsec2.user.conf.

You can also whitelist more than one rule, just separate them with a space

<LocationMatch "/private/test.pl">
  SecRuleRemoveById 950910 950013
</LocationMatch>


You can also whitelist whole directories in the same manner.

<LocationMatch "/private/*">
  SecRuleRemoveById 950910 950013
</LocationMatch>

Below is a simple temporary function that allows for the user to plug in various values to create the modsec whitelisting rule, using the SecRuleRemoveById method.

addmswl () { uri=$1;ruleids="$3 $4 $5 $6 $7 $8 $9"; file=$2;echo Adding entry to $file; echo '<LocationMatch' \"$uri\"'>' >> $file; echo SecRuleRemoveById $ruleids >> $file; echo '</LocationMatch>' >> $file; }

After running the above, you can use the function during that terminal session in the following manner, calling the function by name, entering the uri to be whitelisted exactly as it is shown in the modsec error, listing the file to be used as the whitelist, and then up to 7 rule id's separated by spaces. Example of usage syntax shown below.

addmswl index.php /usr/local/apache/conf/modsec2/whitelist.conf 9990001 8836799

LocationMatch does not seem to work properly with LiteSpeed. Instead, use REQUEST_URI. Example:

SecRule REQUEST_URI  "/private*" phase:1,nolog,allow,ctl:ruleEngine=Off,id:9991569

SecRule Request_Uri

You can also turn off mod_security entirely for a specific URI:

SecRule REQUEST_URI  "/blog/wp-admin/async-upload.php" phase:1,nolog,allow,ctl:ruleEngine=Off,id:3000000

Placing that in /usr/local/apache/conf/modsec2/whitelist.conf turns modsec off for any domain on the server with that in the url. DO NOT DO THIS FOR /index.php IN THE MAIN WHITELIST.

Template:Warning

Whitelistling When Creating the Rule ID; Whitelisting a Flash Uploader

    NOTE: This information is now deprecated. All rules should have ID's as of the latest modsec update (2.7.0). Update the rules RPM if need be and that should identify all rules for you. If you're on a box that has not had EA run since modsec 2.7 was released, you might still need this info, but you should really update the ruleset to one where all rules are already assigned ID numbers. -AKwiecinski

Error found with no rule id:

ModSecurity: Access denied with code 406 (phase 2). Pattern match "^Shockwave Flash" at REQUEST_HEADERS:User-Agent. [file "/usr/local/apache/conf/modsec2.user.conf"] [line "203"] [hostname "www.domainname.com"] [uri "/designonline/php/upload.php"] [unique_id "byevW0Wnsx4AAGyHtncAAAA-"]

1) In this example we have to ID the rule for Adobe Shockwave Flash.

    vim /usr/local/apache/conf/modsec2.user.conf

2) Search for 'Shockwave' Note you have to ID this rule to whitelist it.

3) Make the line with 'Shockwave' read: SecRule HTTP_User-Agent "^Shockwave Flash" "id:1000001"

    Note - all user created unique id errors are assigned numbers above 1000000.

4) Then edit /usr/local/apache/conf/modsec2/whitelist.conf to add the location match.

    Example below (in reference to the ModSec rule violation from the Apache error_log)
 <LocationMatch "/designonline/php/upload.php*">
   SecRuleRemoveById 1000001
 </LocationMatch>

5) Restart Apache - service httpd restart

Whitelist A Specific IP Address or multiple addresses

The old way (single customer IP)

To whitelist a single ip address (Customers IP address), use the following format :

 SecRule REMOTE_ADDR "^111\.222\.333\.444" "phase:1,nolog,allow,ctl:ruleEngine=off,id:SOMERANDOMNUMBER"

Where 111.222.333.444 is the IP address you'd like to whitelist. SOMERANDOMNUMBER needs to be some random number, literally. Try to use either a 5 digit or 8 digit number to avoid ID collisions with commercial rule sets (purchased rules generally use 6 or 7 digit IDs)

The new way (Create a whitelist file for a single IP or multiple IPs)

This allows you to make an IP whitelist for modsecurity. This requires a pretty recent build of modsecurity to be supported, but most customers on newer servers should be able to use this. If in doubt run httpd configtest before restarting apache to ensure the feature is supported.

First, make this file:

touch /usr/local/apache/conf/modsec2/ip_whitelist.txt

Then, add this to /usr/local/apache/conf/modsec2/custom.conf (this assumes the user is using lp-modsec2-rules. If they are not, then you may need to use modsec2.user.conf)

SecRule REMOTE_ADDR "@ipMatchFromFile /usr/local/apache/conf/modsec2/ip_whitelist.txt" "phase:1,allow,nolog,id:39558"

Add any IP address(es) you need whitelisted, one per line, to /usr/local/apache/conf/modsec2/ip_whitelist.txt As with all ModSecurity changes you should run a httpd configtest to check your work, and then restart Apache. Changes will not be effective until Apache is restarted.


Using EA4

To whitelist a rule for a particular php process is no different than with EA3. Just edit the following file.

vim /etc/apache2/conf.d/whitelist.conf

Create the file for the IP addresses to whitelist, add any IP addresses needed to the file and proceed with the next step.

touch /etc/apache2/conf.d/modsec/ip_whitelist.txt

Edit the ModSec User config file as follows

vim /etc/apache2/conf.d/modsec/modsec2.user.conf
# Whitelist IP address for modsec
SecRule REMOTE_ADDR "@ipMatchFromFile /etc/apache2/conf.d/modsec/ip_whitelist.txt" "phase:1,allow,nolog,id:39558"

Then as noted above:

"As with all ModSecurity changes you should run a httpd configtest to check your work, and then restart Apache. Changes will not be effective until Apache is restarted."

Whitelist An Entire Domain

Template:Warning Template:Warning

It's best to do this through a userdata include on a cPanel server. Simply add this in:

/usr/local/apache/conf/userdata/(1 or 2)/std/user/domain/whitelist.conf

Continue the chain to completion. Then, create a conf and put in the rule to disable modsec. You could disable particular rules with this, or disable it entirely. You would use a rule like:

To exclude a domain from being filtered by modesec:
Hint: only change domain.com, leave SERVER_NAME as it is. As of modsec 2.7 this rule will need a numeric ID. replace 123123123 with a random number

SecRule SERVER_NAME "domain.com" phase:1,nolog,allow,ctl:ruleEngine=Off,id:123123123

The same can be done with the ip, rather than the domain name:

SecRule SERVER_ADDR "^192\.168\.1\.100$" phase:1,nolog,allow,ctl:ruleEngine=Off,id:123123124

Sometimes this needs to be done for PayPal IPN messages to get through, for instance:

 SecRule REMOTE_HOST "\.paypal\.com$" "allow,log,logdata:'Permitting incoming connection from PayPal',id:6000001"

Template:Info

In general however, turning off Modsec on an entire domain or on an entire server is a bad idea on someone's server.

Whitelist Rule(s) For Specific Domain(s)

This is the preferred method for ModSec whitelisting on shared servers. Please consult escalations before doing so.

Whitelisting rules for specific domains can be done using includes files. You could also use this method to do a locationmatch for only one domain.

  • *Note for sites that use SSL and Non-SSL, you'll have to do this in a couple of folders.*

First, back up and rebuild httpd.conf to make sure there are no errors;

cd /usr/local/apache/conf
cp -p httpd.conf httpd.conf.lwbak
/scripts/rebuildhttpdconf 

[OUTPUT] Built /usr/local/apache/conf/httpd.conf OK

Now, we have to make an includes file, since cPanel doesn't like having httpd.conf edited directly. You can open up httpd.conf and look for the path where we need to make the file, or just issue a command like this one to find the line(s) we need:

Template:Warning

egrep -i 'DOMAIN.TLD' /usr/local/apache/conf/httpd.conf |grep -i include

[OUTPUT] # Include "/usr/local/apache/conf/userdata/std/2/USERNAME/DOMAIN.TLD/*.conf"

It is ideal to register that account's includes with cPanel data; this will avoid losing the include during updates to that account's vhost.

The ensure_vhost_includes and verify_vhost_includes scripts add and test this. Please see the below wiki's subsection for directions:

'Customize_httpd.conf' # 'Changes that ARE Contained in a <VirtualHost>'

Notice the line in the output is commented out. That's OK, because if we make an includes file at that location and rebuild httpd.conf again, it will uncomment that line for us. Note on newer servers, the above line may not be there at all. Make the file in the right location, and it should add it upon rebuild. So, time to make the folder, change to it, and make our includes file:

mkdir -p /usr/local/apache/conf/userdata/std/2/USERNAME/DOMAIN.TLD/
cd /usr/local/apache/conf/userdata/std/2/USERNAME/DOMAIN.TLD/ 
vim modsecexclude.conf

Note: Due to cPanel updates, this might not work. In this case, try:

mkdir -p /usr/local/apache/conf/userdata/std/2/USERNAME/
cd /usr/local/apache/conf/userdata/std/2/USERNAME/
vim modsecexclude.conf

For example, if your customer has a lot of forum and blogging software tripping these rules, put in the following to remove these rules site-wide:

<IfModule mod_security2.c>
  <LocationMatch .*>
    SecRuleRemoveById 300016
    SecRuleRemoveById 300013
    SecRuleRemoveById 300015
    SecRuleRemoveById 300017
  </LocationMatch>   
</IfModule>

BE SURE TO INCLUDE THE IFMODULE STATEMENTS. Not including it in these files can cause EA not to complete, as it can try to parse these files before realizing that modsec is compiled in.

Save and quit. Now to check our includes file and restart apache:

cd /usr/local/apache/conf
/scripts/rebuildhttpdconf 
cat httpd.conf |egrep -i 'DOMAIN.TLD'|grep -i include

[OUTPUT] Include "/usr/local/apache/conf/userdata/std/2/USERNAME/DOMAIN.TLD/*.conf"

[notice the output has the line uncommented, and we can make anything.conf in that directory and have it work]

/etc/init.d/httpd restart

Or for Centos 7/RHEL 7 or later, SystemD version:

systemctl restart httpd


Make sure apache starts. If you made a mistake in an includes file, or manually uncommented the line in httpd.conf for the includes directory but did not make an includes file there, apache may not start.

Whitelisting Common Commands used within WordPress wp-admin sub-directory

The following format provides you with a way to whitelist the most commonly used php files in wp-admin without whitelisting the entire sub-directory:

 <LocationMatch "/wp-admin/(post|admin-ajax|page|theme-editor).php">
    SecRuleRemoveById 300013 300014 300015 300016 300017
 </LocationMatch>

These excluded rules you will find are the most common ones that Mod_Sec sees being triggered as suspected MySQL attacks by the WordPress Administrators.

Can't Find Rule ID

This is deprecated. All rules should have ID numbers as of mod_security 2.7.0. Either update the modsec2 rules RPM (lp-modsec2-rules.noarch) or install the serversecure+ rules so that all rules have ID numbers.


Preferred method:

<LocationMatch "/private/path/to/script.php">
  SecRuleRemoveById RULEID
</LocationMatch>

You can also whitelist them as follows (WARNING: THIS COMPLETELY REMOVES PROTECTION FROM THE URL SPECIFIED)

<LocationMatch "/private/path/to/script.php">
  SecRuleEngine Off
</LocationMatch>

Be careful with this, as with whitelisting a domain it turns off ModSecurity for that script entirely, and may make it vulnerable to remote inclusion or SQL injection.
If a script is catching on one of these rules it is likely poorly coded.

WHM Whitelist Specific Rule Server Wide

To do this easily in WHM:

First, determine which rule it is catching...


Step 1: Find the page and error you need, copy the [id xxxxxx] code.

Step 2: In the WHM menu , "Apache Configuration" (you can type apache in top search box to go faster)

Step 3: Select "Include Editor"

Step 4: Select "Pre Virtual Host Include" and "All Versions"

Step 5: Copy/Paste the similar configs and replace the mod sec rule ID number

Step 6: Update, then Restart Apache.

Step 7: Recheck problem... it might hit more rules after that one, they can be slightly similar.

Plesk 11.x and Prior White Listing

To do this you use the normal LocationMatch syntaxes but in a specific location

See Modsec in Plesk for specific commands to run based on Plesk version.

Step 1: Find the rule in the vhost error_log file /var/www/vhosts/<domain name>/statistics/logs/error_log or the Apache error_log file /var/log/httpd/error_log

Step 2: In /var/www/vhosts/<domain name>/conf see if a vhost.conf file exists

  1. If it does Append to it
  2. If it doesn't create it

Step 3: Add the normal mod security white listing syntax as shown below in this wiki in the vhost.conf file. You may need to add extra lines:

 <LocationMatch ".*">
   <IfModule mod_security2.c>
    SecRuleRemoveById 970901
   </IfModule>
 </LocationMatch>

Step 4: Depending upon the Plesk installation, you will need to run one of the following:

 Plesk 9: /usr/local/psa/admin/sbin/websrvmng -u --vhost-name=$domain_name.ext
 Plesk 10+: /usr/local/psa/admin/sbin/httpdmng --reconfigure-domain $domain_name.ext

To reconfigure all the domains:

/usr/local/psa/admin/sbin/httpdmng --reconfigure-all

To find the plesk version:

 [root@host ~]# plesk version

Step 5: Restart Apache on the server

Step 6: Check your work

Plesk 12.x White Listing

To do this you use the normal LocationMatch syntaxes but in a specific location

See Modsec in Plesk for specific commands to run based on Plesk version.

Step 1: Find the rule in the vhost error_log file /var/www/vhosts/<domain name>/logs/error_log or the Apache error_log file /var/log/httpd/error_log

Step 2: In /var/www/vhosts/system/<domain name>/conf/siteapp.d/ see if a vhost.conf file exists

  1. If it does Append to it
  2. If it doesn't create it

Step 3: Add the normal mod security white listing syntax as shown below in this wiki in the vhost.conf file. You may need to add extra lines:

 <LocationMatch ".*">
   <IfModule mod_security2.c>
    SecRuleRemoveById 970901
   </IfModule>
 </LocationMatch>

Step 4: You will need to run one of the following:

  /usr/local/psa/admin/sbin/httpdmng --reconfigure-domain $domain_name.tld

To reconfigure all the domains:

/usr/local/psa/admin/sbin/httpdmng --reconfigure-all

To find the plesk version:

 [root@host ~]# plesk version

Step 5: Restart Apache on the server

Step 6: Check your work

Note: The hostname of the server can be whitelisted just for itself, like a regular domain using the above method. This needs to be done sometimes because the ModSec rules in use can block some of Plesk's own internal functions. Check /var/www/vhosts/HOSTNAME/logs/error_log (your IP might not be logged) if the issue seems to be within Plesk itself rather than on a site.

Global way on Plesk

Just like on a cPanel server edit the whitelist.conf here:

/etc/httpd/modsecurity.d/lwrules/whitelist.conf

Other files also exist in this same location for say adding a rule ID for shockwave flash and are similar to that of those on a cPanel server:

/etc/httpd/modsecurity.d/lwrules/custom.conf
/etc/httpd/modsecurity.d/lwrules/exclude.conf
/etc/httpd/modsecurity.d/lwrules/modsec2.user.conf
/etc/httpd/modsecurity.d/lwrules/rootkits.conf
/etc/httpd/modsecurity.d/lwrules/whitelist.conf

Then reconfigure httpd with:

/usr/local/psa/admin/sbin/httpdmng --reconfigure-all

Restart Apache on the server, and check your work.


NOTE ABOUT PLESK 12, CENTOS 7 & ModSec

Currently on this particular setup, ModSec doesn't work 100%. There is a micro-update available to get ModSec working on these servers, but it is not in our kicks at this time.

Should you encounter a Plesk 12 server running CentOS 7 without ModSec enabled you can follow these steps (provided by Joshua Henry):


This is just an update on the Plesk on Cent 7 modsec issue. It appears that Plesk has partially fixed the issue with a recent microupdate. I was able to confirm after the update was applied that the following allowed modsec to be installed and work properly.

/usr/local/psa/bin/server_pref --update-web-app-firewall -waf-rule-engine on -waf-rule-set tortix

Between the ticket I opened and the offshoot ticket regarding custom modsec rules, we managed to get four internal cases opened:

  1. PPPM-3734

Basic Atomic ruleset fails to install because of duplicated config. Wiping duplicate config via the following commands should allow installation without error:

aum -u plesk sbin modsecurity_ctl --disable plesk sbin modsecurity_ctl --enable service httpd restart

  1. PPPM-4162 & PPP-21128

Custom ruleset modification:

To workaround the issue I have modified section 'install_config()' in /usr/local/psa/admin/sbin/modsecurity_ctl the following way:

install_config() {
          local config="$1"
          local target_dir="$2"
          cp -f "$config" "$target_dir/$config"
 }


and the latest PPPM-4198

The only possible workaround is to install custom ModSecurity rules via Plesk GUI. In order to do it the following steps have to be done:

1. The section 'install_config()' in file /usr/local/psa/admin/sbin/modsecurity_ctl has to be modified the following way:

install_config() {
        local config="$1"
        local target_dir="$2"
        cp -f "$config" "$target_dir/${config##*/}"
 }



NOTE ABOUT SUBDOMAINS IN PLESK

If the ModSec error is happening on a subdomain in Plesk you will need to add the vhost.conf file to the following location:

 /var/www/vhosts/domain.com/subdomains/NameOfSubdomain/conf/

Add the vhost.conf file to that folder like normal, and enter the standard whitelisting. Then, it's helpful to run the Plesk rebuild command for both the domain and the subdomain as follows:

 /usr/local/psa/admin/sbin/websrvmng -u --vhost-name=domain.com
 /usr/local/psa/admin/sbin/websrvmng -u --vhost-name=sub.domain.com

Newer versions of plesk may need to use:

    /usr/local/psa/admin/bin/httpdmng --reconfigure-domain domain.com

Reporting

ModSecParse in WHM makes this unnecessary, however if you need to get a look at what is in the current audit log without waiting for it to be parsed this is useful.

To list all sites that have mod sec errors and the rule number and location:

echo;printf "hostname                         ruleid  uri\n";echo;\
IFS=$'\n';for i in $(cat /usr/local/apache/logs/error_log |grep -i modsecurity|grep -e '\[id\ ');\
do id=$(echo -n $i | sed 's/^.*\[id\ "//g' | sed 's/".*$//'); host=$(echo -n $i | sed 's/^.*\[hostname\ "//g' | sed 's/".*$//');\
loc=$(echo -n $i | sed 's/^.*\[uri\ "//g' | sed 's/".*$//');printf "%-30s%9s%2s%-29s\n" $host $id "  " $loc;done;IFS=$' '

You can also output to a report for sorting:

IFS=$'\n';for i in $(cat /usr/local/apache/logs/error_log |grep -i modsecurity|grep -e '\[id\ ');\
do id=$(echo -n $i | sed 's/^.*\[id\ "//g' | sed 's/".*$//'); host=$(echo -n $i | sed 's/^.*\[hostname\ "//g' | sed 's/".*$//');\
loc=$(echo -n $i | sed 's/^.*\[uri\ "//g' | sed 's/".*$//');printf "%-30s%9s%2s%-29s\n" $host $id "  " $loc >> modsecrep.txt;done;IFS=$' '

The you can sort it out

cat modsecrep.txt | sort | uniq -c | sort -nr

or

cat modsecrep.txt | grep domain.com | sort | uniq -c | sort -nr

Troubleshooting

(Edit eammons 06-01-2009 - I'm not sure who originally added this to the wiki. I run wordpress 2.7.1 on my personal site along with Modsec2/Apache2 with SuPhp and open_basedir protection on. I've never had to whitelist anything to get posting to work with wordpress. If support is getting issues like these, secteam needs to be notified. Thank you!)

Template:Note

There seems to be some bugs with Apache 2 WordPress and mod_security2 playing nicely with each other. After much research I have found the fix.

Add the following line to the httpd.conf file at the end of the <VirtualHost> entry for the domain

SecRuleInheritance Off

So it should read something like this

<VirtualHost IP:80>
...

SecRuleInheritance Off
</VirtualHost>

Don't forget to do this to any SSL enabled sites as well in the <VirtualHost IP:443> entry as well. Otherwise it won't work for the site when in SSL mode.

After all that is added run the following to make the changes permanent:

/usr/local/cpanel/bin/apache_conf_distiller --update
/etc/init.d/httpd restart


PCRE Limits Exceeded

Template:Warning Template:Info Template:Warning Template:Info This "error" is simply starting modsec wasn't able to recurse far enough to parse the entirety of an incoming request, and instead let the request through instead of spending additional resources in order to parse the entire request body.

ReDoS

If you just want to get rid of the errors showing up in the logs, you can do the following:

Template:Warning Add these two options to the loaded php.ini :

pcre.backtrack_limit = 10000000
pcre.recursion_limit = 10000000

Then, add these two directives to /usr/local/apache/conf/modsec2/custom.conf (or /etc/apache2/conf.d/modsec2/custom.conf if easyApache 4)

SecPcreMatchLimit 150000
SecPcreMatchLimitRecursion 150000

Restart apache, and you're done.

Template:Info

Request body no files data length is larger than the configured limit

[Thu May 09 09:27:23 2013] [error] [client x.x.x.x] ModSecurity: Request body no files data length is larger than the configured limit (1048576).. Deny with code (413) [hostname "www.hostname.com"] [uri "/admin/index.php"] [unique_id "UYtPvEg0uj0AABTCHsoAAAAG"] Just add the following to the whitelist file of your choice (either whitelist.conf or custom.conf)

Unlimited up to 2GB:
LimitRequestBody 0 
2MB which fits for most cases:
LimitRequestBody 2097152

If the above isn't working, try this:

SecRequestBodyLimit 2097152
SecRequestBodyNoFilesLimit 2097152

Implementing the below solution will disable this rule for a given file.

Request body (Content-Length) is larger than the configured limit

When trying to upload a large file, a customer may get this error:

[Wed Oct 13 19:48:02 2010] [error] [client xxx.xxx.xxx.xxx] ModSecurity: Request body (Content-Length) is larger than the configured limit (134217728). [hostname "www.hostname.com"] [uri "/upload/ft2.php"] [unique_id "TLZFMkUQ5mIAAEa0PiAAAAAB"]

Theoretically a locationmatch with "SecRequestBodyLimit 0" or "SecRuleEngine Off" should fix this, however I've found at times it does not. To fix the above error put this into whitelist.conf, replacing only the /upload/ft2.php with the appropriate path:

SecRule REQUEST_FILENAME "^/upload/ft2.php$" "phase:1,t:none,allow,nolog,ctl:requestBodyAccess=Off,id:123456879"

You can also just set "SecRequestBodyLimit 1047483647" in modsec2/custom.conf to set it to the max hard limit of 1GB. Not the most recommend solution, but it will work.

Output filter: Response body too large

When trying to export a file this modsec error might show up.

 [Tue Oct 16 09:16:39 2012] [error] [client xxx.xxx.xxx.xxx] ModSecurity: Output filter: Response body too large (over limit of 524288, total length not known). [hostname "www.domain.com"] [uri "/eesys/index.php"] [unique_id "UH2IZ38AAAEAABwlDzsAAAAD"]

You can correct this by increasing the limit by putting this line in the whitelistfile.

 SecResponseBodyLimit 1572864 (This sets the limit to 1.5M but set it to what you need)

Modsec Database Issues

If you encounter an error that looks something like this from your cron.daily:

DBI connect('modsec:localhost','modsec',...) failed: Access denied for user 'modsec'@'localhost' (using password: YES) at /etc/cron.hourly/modsecparse.pl line 19 Unable to connect to mysql database at /etc/cron.hourly/modsecparse.pl line 19.

Look to see what the modsec user's password is in this file first:

 /etc/cron.hourly/modsecparse.pl

Then open up PHPmyadmin from WHM (as root), go to the privileges tab, click M for modsec and "edit privileges" for the modsec user. From here, go down to the New Password area, enter it twice and click Go!

The mysql syntax for this is:

 SET PASSWORD FOR 'modsec'@'localhost' = PASSWORD( '************' );

run this to confirm working, no errors will show if all is well:

 perl /etc/cron.hourly/modsecparse.pl

If you still are getting an error like this. DBI connect('modsec:localhost','modsec',...) failed: Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2) at /etc/cron.hourly/modsecparse.pl line 19 Unable to connect to mysql database at /etc/cron.hourly/modsecparse.pl line 19\

You have to specify the socket in the /etc/my.cnf file with this line because it is not finding the socket file

First stop mysql

service mysql stop

Edit my.cnf

socket=/tmp/mysql.sock  #this is telling mysql to create the socket file in /tmp/mysql.sock

write it out and start mysql back up

service mysql start

run the command again to confirm it works.

perl /etc/cron.hourly/modsecparse.pl

cPanel 11.46

http://forums.cpanel.net/f185/etc-cron-hourly-modsecparse-pl-dbi-connect-modsec-localhost-modsec-errors-394421.html

Modsecparse.pl appears to be deprecated in cPanel 11.46 so the password for modsec@localhost should be located in /var/cpanel/modsec_db_pass.

Upload tmpdir issues

Template:Info

Seeing this?

[Fri Nov 18 14:49:50 2011] [error] [client 72.52.142.215] mod_security: Access denied with code 406. read_post_payload: Failed to create file "/root/tmp/20111118-144950-72.52.142.215-request_body-xGPNPd" because 13("Permission denied") [severity "EMERGENCY"] [hostname "lakedonpedro.org"] [uri "/wp-cron.php?doing_wp_cron"] [unique_id "TsbhJkg0jtcAACYIFDk"]

This actually happens because PHP's being set to use /root/tmp and the upload tmp dir. Let's set a few things then! Yay!

Make sure these are all set in /usr/local/lib/php.ini (session.save_path will probably already be set)

upload_tmp_dir = /tmp
session.save_path = /tmp

Make sure these are all set in /usr/local/apache/conf/modsec2.user.conf (or the applicable file for your system)

SecUploadDir /tmp
SecTmpDir /tmp

Restart apache.

Template:Warning

Problems after EasyApache run

The error in question:

Syntax error on line 29 of /usr/local/apache/conf/modsec2.conf:
ModSecurity: No action id present within the rule

To resolve you need to replace the formatting and add a proper rule ID.

For example it could show this:

SecRule MULTIPART_STRICT_ERROR "!@eq 0" \
"phase:2,t:none,log,deny,status:44,msg:'Multipart request body \
failed strict validation: \
PE %{REQBODY_PROCESSOR_ERROR}, \
BQ %{MULTIPART_BOUNDARY_QUOTED}, \
BW %{MULTIPART_BOUNDARY_WHITESPACE}, \
DB %{MULTIPART_DATA_BEFORE}, \
DA %{MULTIPART_DATA_AFTER}, \
HF %{MULTIPART_HEADER_FOLDING}, \
LF %{MULTIPART_LF_LINE}, \
SM %{MULTIPART_MISSING_SEMICOLON}, \
IQ %{MULTIPART_INVALID_QUOTING}, \
IP %{MULTIPART_INVALID_PART}, \
IH %{MULTIPART_INVALID_HEADER_FOLDING}, \
FL %{MULTIPART_FILE_LIMIT_EXCEEDED}'"

Change it to this though:

SecRule MULTIPART_STRICT_ERROR "!@eq 0" "phase:2,t:none,log,deny,status:44,msg:'Multipart request body failed strict validation: PE %{REQBODY_PROCESSOR_ERROR}, BQ %{MULTIPART_BOUNDARY_QUOTED}, BW %{MULTIPART_BOUNDARY_WHITESPACE}, DB %{MULTIPART_DATA_BEFORE}, DA %{MULTIPART_DATA_AFTER}, HF %{MULTIPART_HEADER_FOLDING}, LF %{MULTIPART_LF_LINE}, SM %{MULTIPART_MISSING_SEMICOLON}, IQ %{MULTIPART_INVALID_QUOTING}, IP %{MULTIPART_INVALID_PART}, IH %{MULTIPART_INVALID_HEADER_FOLDING}, FL %{MULTIPART_FILE_LIMIT_EXCEEDED}',id:1234123456"

Then you should be able to restart apache after that. There is basically two problems here... One being there is a missing rule ID, the second is the formatting with the slashes. Also try an run Easyapache again to make sure if builds properly. If it still continues to fail even when the proper rule is in place consult secteam.

ModSecurity Failing to Compile on CentOS 4

Getting errors like:

make  install-exec-hook
make[3]: Entering directory `/home/cpeasyapache/src/modsecurity-apache_2.7.1/apache2'
Removing unused static libraries...
install: cannot overwrite directory `/usr/local/apache/modules' with non-directory
make[3]: *** [install-exec-hook] Error 1
make[3]: Leaving directory `/home/cpeasyapache/src/modsecurity-apache_2.7.1/apache2'
make[2]: *** [install-exec-am] Error 2
make[2]: Leaving directory `/home/cpeasyapache/src/modsecurity-apache_2.7.1/apache2'
make[1]: *** [install-am] Error 2
make[1]: Leaving directory `/home/cpeasyapache/src/modsecurity-apache_2.7.1/apache2'
make: *** [install-recursive] Error 1
!! 'make install' failed with exit code '512' !!
!! Restoring original working apache !!
!! Executing '/scripts/initsslhttpd' !!
!! Restarting 'httpd' ... !!
!! 'httpd' restart complete. !!

See: https://wiki.int.liquidweb.com/articles/EasyApache#EasyApache_failing_to_compile_ModSecurity_on_CentOS_4

Turtle (Atomic) Rules (AKA ServerSecure+ rules)

Template:Warning

To install Turtle rules, see https://wiki.int.liquidweb.com/articles/ServerSecure%2B#Mod_Security_Rules

This is not much different than a modsec whitelisting. You will find an error as normal in the apache error_log like the following:


[Thu Jan 20 09:53:57 2011] [error] [client 98.109.77.186] ModSecurity: Access denied with code 403 (phase 2). Pattern match "(< ?(?:(?:java|vb)?script|about|applet|activex|chrome) ?>|> ?< ?(img ?src|a ?href) ?= ?(ht|f)tps?:/|" ?> ?<|" ?[a-z]+ ?<.*>|> ?"? ?(>|<)|< ?/?i?frame|\\%env)" at ARGS:_qf_Settings_next. [file "/usr/local/apache/conf/turtle-rules/modsec/10_asl_rules.conf"] [line "903"] [id "340147"] [rev "81"] [msg "Atomicorp.com - FREE UNSUPPORTED DELAYED FEED - WAF Rules: Generic XSS filter"] [data "189"] [severity "CRITICAL"] [hostname "sholomnj.org"] [uri "/civicrm/mailing/send"] [unique_id "TThMhUWnkgUAAHTaKlEAAAGV"]


The error tells you where the turtle rules are located: /usr/local/apache/conf/turtle-rules/modsec/ (recently updated to /usr/local/apache/conf/turtle-rules/modsec2/)

This is where you will find both the rules (10_asl_rules.conf) as well as the whitelist

/usr/local/apache/conf/turtle-rules/modsec/00_asl_whitelist.conf

or

/usr/local/apache/conf/modsec/lw_whitelist.conf

Whitelisting works the same for this as it does for a regular modsec whitelisting.

Disable Mod_security on a global URL

Step 1) Create a global exclude file if necessary

vim /usr/local/apache/conf/modsec2/lw_whitelist.conf

Step 2) Make sure the above file is called as an include in modsec2.user.conf

Step 3) Add the LocationMatch for the url to exclude. Example: /server.php

<LocationMatch /server.php>
  <IfModule mod_security2.c>
    SecRuleEngine Off 
  </IfModule>
</LocationMatch>

Step 4) Restart apache

service httpd restart

Wordpress

As of the new version of our modsec rules for modsec 2.7, /wp-admin/ is now whitelisted against the flash uploader and generic SQL rules. This is done in modsec2/exclude.conf. If you need to make additional adjustments for wp-admin, use /usr/local/apache/conf/modsec2/whitelist.conf or custom.conf as these files are not over-written in the case of updates to the rules RPM. Don't edit exclude.conf as your changes may be over-written. If you're getting errors for rule 300016 etc., in wp-admin, update the rules RPM by running:

Centos4 or Centos5

lpyum clean all 
lpyum update lp-modsec2-rules
/etc/init.d/httpd restart 

Or if the server has centos6

yum clean all
yum update lp-modsec2-rules
/etc/init.d/httpd restart

Cpanel

modsec db missing

Problem: Cpanel didn't create the modsec database, and there was an error in the WHM > Mod Security section.

You can manually create the database and user, the settings are in this file:

/etc/cron.hourly/modsecparse.pl

This might be able to be fixed by upcp or perhaps running EA also, probably would be the more elegant solution. This isn't necessary for modsecurity to function at all.

A upcp did not fix this in an instance I ran into. EA likely would. To manually create the db, which is inelegant, but resolves the issue:

vim /etc/cron.hourly/modsecparse.pl

Note: my $dbpassword = 'PASSWORD';

# mysql
mysql> create database modsec;
mysql> grant all privileges on modsec.* to modsec@localhost identified by 'PASSWORD';
mysql> quit

Remove all mod_security blocks from CSF deny

Occasionally on a new set-up, where mod_security has not yet been configured correctly, a large number of users can be rapidly blocked.

Here is a quick one-liner to remove all mod_security blocks from csf.deny:

 sed -i.lwbak '/mod_security/d' /etc/csf/csf.deny
 /etc/init.d/csf restart

This will also create /etc/csf/csf.deny.lwbak if there are any issues. Remove when done.

Problems with mod_ruid2

ruid2 was previously incompatible with ModSecurity. This is fixed according to cPanel.

Installing on Core Managed (for experienced techs)

Template:Info Install the prereqs:

yum install gcc make
yum install libxml2 libxml2-devel httpd-devel pcre-devel curl-devel

Download and compile:

cd /home/temp/
wget https://www.modsecurity.org/tarball/2.7.5/modsecurity-apache_2.7.5.tar.gz
tar -xvzf modsecurity-apache_2.7.5.tar.gz
cd modsecurity-apache_2.7.5
./configure
make install
cp modsecurity.conf-recommended /etc/httpd/conf.d/modsecurity.conf

Start configuring.

vim /etc/httpd/conf/httpd.conf

In httpd.conf:
UNCOMMENT LoadModule unique_id_module modules/mod_unique_id.so
ADD (right under the line you just uncommented):

LoadModule security2_module modules/mod_security2.so

Keep configuring

cd /etc/httpd/
wget http://layer3.liquidweb.com/server_secure_plus_modsec_rules.tar.gz
tar -xvzf server_secure_plus_modsec_rules.tar.gz
mkdir /etc/asl
touch /etc/asl/whitelist
mkdir -p /opt/modsecurity/var/upload/
chown apache:apache /opt/modsecurity/var/upload

More configuring

vim /etc/httpd/conf.d/modsecurity.conf

Change:
SecRuleEngine DetectionOnly
To:
SecRuleEngine On

Uncomment: SecUploadDir /opt/modsecurity/var/upload/

Add to end of file:

Include "/etc/httpd/modsec2/00_asl_whitelist.conf"
Include "/etc/httpd/modsec2/05_asl_exclude.conf"
Include "/etc/httpd/modsec2/10_asl_antimalware.conf"
Include "/etc/httpd/modsec2/10_asl_rules.conf"
Include "/etc/httpd/modsec2/11_asl_data_loss.conf"
Include "/etc/httpd/modsec2/20_asl_useragents.conf"
Include "/etc/httpd/modsec2/30_asl_antispam.conf"
Include "/etc/httpd/modsec2/30_asl_antispam_referrer.conf"
Include "/etc/httpd/modsec2/40_asl_apache2-rules.conf"
Include "/etc/httpd/modsec2/50_asl_rootkits.conf"
Include "/etc/httpd/modsec2/60_asl_recons.conf"
Include "/etc/httpd/modsec2/99_asl_exclude.conf"
Include "/etc/httpd/modsec2/99_asl_jitp.conf"
Include "/etc/httpd/modsec2/99_asl_redactor.conf"
Include "/etc/httpd/modsec2/lw_whitelist.conf"

Check config:

httpd -t

Syntax OK? restart apache:

[root@s conf.d]# service httpd restart 
Stopping httpd:                                            [  OK  ]
Starting httpd:                                            [  OK  ]
[root@s conf.d]#

Check for errors. Open this URL in your browser, replacing 123.123.123.123 with the hosts IP address:

http://123.123.123.123/?../../../

Then

grep -i modsec /etc/httpd/logs/error_log

You should see a [notice] with the modsec version (and other information), and an error for "Generic Path Recursion denied"

Whitelisting remote IP's can be done with one IP per line in /etc/asl/whitelist
Whitelisting rules, or custom rules, can be added as needed to /etc/httpd/modsec2/lw_whitelist.conf


Block Rogue Domains

Modify the following for $domain. Add to appropriate custom conf. This will block all traffic that comes in with $domain as the host header. It's not very often that you need to do this.

Examples for needing to use this would be:

- Traffic for vhost domainb.com is hitting the customers server, but the customer does not host domainb.com at all.

- Blocking nameservers from showing a domain (i.e. ns2.domain.com serves a customer site in a browser).

 SecRule SERVER_NAME "$domain.com" "id:60000015"

Should that happen to prove insufficient, you can explicitly drop the connection like so:

SecRule SERVER_NAME "domain\.com$" "t:lowercase,drop,id:60000015"