Difference between revisions of "Mod security"
m (→Customizing a rule) |
m (→Customizing a rule) |
||
| Line 270: | Line 270: | ||
* 900,000-999,999; reserved for the Core Rules project. | * 900,000-999,999; reserved for the Core Rules project. | ||
* 1,000,000 and above; unused (available for reservation). | * 1,000,000 and above; unused (available for reservation). | ||
| + | |||
| + | === For a domain === | ||
| + | |||
| + | ==== Apache ==== | ||
| + | |||
| + | If you just want to customize the rule, or add a supported configuration setting for a domain you will want to add your modifications within the VirtualHost definition for the domain. | ||
== Creating custom rules == | == Creating custom rules == | ||
Revision as of 14:02, 3 October 2013
Disabling Mod_Security Globally
Step 1) Disable config file
mv /etc/httpd/conf.d/00_mod_security.conf /etc/httpd/conf.d/00_mod_security.conf.disabled
Step 2) Restart Apache
service httpd restart
Disabling Mod_security per domain
For Plesk and similar systems you can also disable modsecurity in the Apache configuration.
Step 1) Edit the vhost/vhost_ssl.conf for the domain
vim /var/www/vhosts/<DOMAINNAME>/conf/vhost.conf
Step 2) Add the following
<IfModule mod_security2.c> SecRuleEngine Off </IfModule>
Then restart apache, if you are using Plesk then you will also need follow steps 3 and 4.
Step 3) Add vhost.conf to domain config
Plesk 9:
/usr/local/psa/admin/bin/websrvmng -a
Plesk 10/11:
/usr/local/psa/admin/bin/httpdmng --reconfigure-domain <domain_name>
Step 4) Restart Apache
service httpd restart
Disabling Mod_security per domain for an IP address
For Plesk and similar systems you can also disable modsecurity in the Apache configuration.
Step 1) Edit the vhost/vhost_ssl.conf for the domain
vim /var/www/vhosts/<DOMAINNAME>/conf/vhost.conf
Step 2) Add the following
<IfModule mod_security2.c> SecRule REMOTE_ADDR "^1.2.3.4$" "phase:1,t:none,nolog,allow,ctl:ruleEngine=Off,ctl:auditEngine=Off,id:9999" </IfModule>
Note: You must change id: to a number that you have not used for any other custom rules. Customer generated rules should use the range 1-99999. Numbers about 99999 are reserved and will cause conflicts and are not supported.
Then restart apache, if you are using Plesk then you will also need follow steps 3 and 4.
Step 3) Add vhost.conf to domain config
Plesk 9:
/usr/local/psa/admin/bin/websrvmng -a
Plesk 10/11:
/usr/local/psa/admin/bin/httpdmng --reconfigure-domain <domain_name>
Step 4) Restart Apache
service httpd restart
Disable Mod_security on a global URL
Step 1) Create a global exclude file
vim /etc/httpd/modsecurity.d/00_custom_exclude.conf
Step 2) Add the LocationMatch for the url to exclude. Example: /server.php
<LocationMatch /server.php>
<IfModule mod_security2.c>
SecRuleEngine Off
</IfModule>
</LocationMatch>
Step 3) Restart apache
service httpd restart
Disable Mod_security for an IP address
In ASL, just click the "Whitelist" button.
If you are not using ASL, simply add your IP address to the file:
/etc/asl/whitelist
And restart Apache.
Note: For this rule to work, in ASL you must have the MODSEC_00_WHITELIST ruleset enabled.
If you are not using ASL, then you must have the 00_asl_whitelist.conf ruleset loaded.
Whitelist an IP
See above, "Disable Mod_security for an IP address"
Disable a rule for a single domain
If you have ASL installed:
Method 1:
Log into the ASL GUI, and click on the "Configuration" tab. Then click "Rule Management", then click the "Rules" tab, then click the "WAF" tab. Type in the rule ID and the rule manager will pull up the rule. Click on the green down error which will pull up the options for this rule.
Type in the vhost name into the Text box on the left side of the options, then click "add".
Keep in mind this is literal, so if you have a vhost with the name "example.com" that serves content for "ftp.example.com" and "www.example.com" you will need to add those FQDNs as well.
Method 2: Run this command as root:
asl -dr RULE_ID --vhost www.example.com
Replace RULE_ID with the ID of the rule you want to disable for the vhost. Keep in mind this is literal, so if you have a vhost with the name "example.com" that serves content for "ftp.example.com" and "www.example.com" you will need to add those as well. For example:
asl -dr RULE_ID --vhost www.example.com
asl -dr RULE_ID --vhost ftp.example.com
asl -dr RULE_ID --vhost example.com
If you do not have ASL installed you will have to do this manually:
Step 1) Edit the vhost/vhost_ssl.conf for the domain
vim /var/www/vhosts/<DOMAINNAME>/conf/vhost.conf
Step 2) Add the LocationMatch for the rule to exclude. Example, ruleid 950005
<LocationMatch .*>
<IfModule mod_security2.c>
SecRuleRemoveById 950005
</IfModule>
</LocationMatch>
If you want to disable multiple rules:
Step 2) Add the LocationMatch for the rule to exclude. Example, ruleids 950005 and 950006
<LocationMatch .*>
<IfModule mod_security2.c>
SecRuleRemoveById 950005
SecRuleRemoveById 950006
</IfModule>
</LocationMatch>
Disable Mod_security rule for a specific application in a single domain
Step 1) Edit the virtual servers configuration for the domain for the domain
Example:
vim /var/www/vhosts/<DOMAINNAME>/conf/vhost.conf
Step 2) Add the LocationMatch for the rule to exclude. Example, ruleid 950005
<LocationMatch /URL/path/to/application.php>
<IfModule mod_security2.c>
SecRuleRemoveById 950005
</IfModule>
</LocationMatch>
Disable Mod_security rule for all domains
Method 1:
Log into the ASL GUI, and click on the "Configuration" tab. Then click "Rule Management", then click the "Rules" tab, then click the "WAF" tab. Type in the rule ID and the rule manager will pull up the rule. Click on the green down error which will pull up the options for this rule.
Set "disabled" to yes and click update.
Method 2:
Use ASL utility to disable rule by ID. Example: 950005
asl --disable-rule 950005
Note: This requires that Atomic Secured Linux be installed. If you do not have Atomic Secured Linux installed you can disable a rule globally manually by adding a rule to your own custom rules files that contains a line similar to this:
<LocationMatch .*>
<IfModule mod_security2.c>
SecRuleRemoveById 340000
</IfModule>
</LocationMatch>
Custom rules should be loaded after atomicorp rules. A good place to add this, again only if you do not have ASL installed, is in the 999_user_exclude.conf file. If you don't have this file, just create it. Then make sure your modsecurity configuration is setup to load this file.
Disable Mod_security rules globally for a specific application
Add this to either you vhost.conf file, or if your want to make this global make sure this exclusion is loaded after your rules are loaded. A good place to add this in the 999_user_exclude.conf file. If you don't have this file, just create it. Then make sure your modsecurity configuration is setup to load this file.
<LocationMatch /url/to/your/application>
<IfModule mod_security2.c>
SecRuleRemoveById 1234567
SecRuleRemoveById 9999999
</IfModule>
</LocationMatch>
Whats important to remember is that the LocationMatch variable must match the URL, not the path on the system.
Disable Mod_security rules by domain, for a specific application, for a list of IPs
Step 1) Edit the vhost/vhost_ssl.conf for the domain
vim /var/www/vhosts/<DOMAINNAME>/conf/vhost.conf
Step 2) Add the LocationMatch for the rule to exclude.
<LocationMatch /foo/bar.php>
<IfModule mod_security2.c>
SecRule REMOTE_ADDR "@pmFromFile /etc/asl/whitelist" "nolog,phase:1,allow"
</IfModule>
</LocationMatch>
Step 3) Add IP to /etc/asl/whitelist
echo "10.11.12.13" >> /etc/asl/whitelist
Or:
If you want to create a special whitelist for just that application:
Step 1) Edit the vhost/vhost_ssl.conf for the domain
vim /var/www/vhosts/<DOMAINNAME>/conf/vhost.conf
Step 2) Add the LocationMatch for the rule to exclude.
<LocationMatch /foo/bar.php>
<IfModule mod_security2.c>
SecRule REMOTE_ADDR "@pmFromFile /path/to/your/custom/whitelist_for_this_application" "nolog,phase:1,allow,id:9999"
</IfModule>
</LocationMatch>
Note: You must change id: to a number that you have not used for any other custom rules. Customer generated rules should use the range 1-99999. Numbers about 99999 are reserved and will cause conflicts and are not supported.
Step 3) Create your custom whitelist and add IP to /etc/asl/whitelist
echo "10.11.12.13" >> /path/to/your/custom/whitelist_for_this_application
Keep in mind these custom lists are *not* managed by ASL, so if you want to add IPs to these lists you will need to do it from the command line.
Customizing a rule
If you need to customize a rule do not change the asl*conf files. These files will be overwritten by updates.
The use of "asl" in the filename is also reserved. Do not name custom file with "asl" in the filename, for example, 99_asl_custom.conf. This file may be overwritten or deleted by the rule management system. Do not create custom rules with "asl" in the filename.
If you need to change a rule because it is incorrectly blocking something we recommend you report it to use as a False Postive, using the Reporting_False_Positives procedure. If you simply want to modify a rule to perform different actions, then copy the entire rule into your own rule file, and make sure you tell mod_security not to enable the original ASL rule. You can do that by using the mod_security action SecRuleRemoveById. Here is a simple example:
If you had an original rule like this:
SecRule REQUEST_URI "/foo" "t:normalisePath,id:9000,rev:1,severity:2,msg:'Atomicorp.com WAF Rules: Block /foo'"
And you want it to block "bar" instead of "foo", then you would copy the entire rule into your own custom rule file. If you are using our rules we recommend you use the filename 99_zzz_custom.conf and change the id: field to an unused ID. You will need to configure Apache to load this file. You should load this file after the *asl*conf rule files have been loaded.
SecRuleRemoveById 9000000 SecRule REQUEST_URI "/bar" "t:normalisePath,id:9999,rev:1,severity:2,msg:'Atomicorp.com WAF Rules: Block /foo'"
Note: You must change id: to a number that you have not used for any other custom rules. Customer generated rules should use the range 1-99999. Numbers about 99999 are reserved and will cause conflicts and are not supported.
These are the reserved ranges:
* 1-99,999; reserved for local (internal) use. Use as you see fit but do not use this range for rules that are distributed to others. * 100,000-199,999; reserved for internal use of the engine, to assign to rules that do not have explicit IDs. * 200,000-299,999; reserved for rules published at modsecurity.org. * 300,000-399,999; reserved for rules published at gotroot.com. * 400,000-419,999; unused (available for reservation). * 420,000-429,999; reserved for ScallyWhack. * 430,000-699,999; unused (available for reservation). * 700,000-799,999; reserved for Ivan Ristic. * 900,000-999,999; reserved for the Core Rules project. * 1,000,000 and above; unused (available for reservation).
For a domain
Apache
If you just want to customize the rule, or add a supported configuration setting for a domain you will want to add your modifications within the VirtualHost definition for the domain.
Creating custom rules
If you need to create your own custom rules, do not change the asl*conf files. These files will be overwritten by updates.
The use of "asl" in the filename is also reserved. Do not name custom files with "asl" in the filename, for example, 99_asl_custom.conf. This file may be overwritten or deleted by the rule management system. Do not create custom rules with "asl" in the filename.
If you are using our rules we recommend you use the filename 99_zzz_custom.conf and make sure your rules have unique id: fields, using the local (internal) use range (see below for the reserved id ranges). You will need to configure Apache to load this file. You should load this file after the *asl*conf rule files have been loaded.
These are the reserved ranges:
* 1-99,999; reserved for local (internal) use. Use as you see fit but do not use this range for rules that are distributed to others. * 100,000-199,999; reserved for internal use of the engine, to assign to rules that do not have explicit IDs. * 200,000-299,999; reserved for rules published at modsecurity.org. * 300,000-399,999; reserved for rules published at gotroot.com. * 400,000-419,999; unused (available for reservation). * 420,000-429,999; reserved for ScallyWhack. * 430,000-699,999; unused (available for reservation). * 700,000-799,999; reserved for Ivan Ristic. * 900,000-999,999; reserved for the Core Rules project. * 1,000,000 and above; unused (available for reservation).
To load a custom modsecurity rule file, we recommend you create a directory for your custom rules in this directory:
/etc/httpd/modsecurity.custom.d
Add an Include to your apache configuration. For example:
Include modsecurity.custom/99_zzz_custom.conf
A simple way to do this is to create this file:
01_modsecurity.conf
And add it to this directory:
/etc/httpd/conf.d
And add the Include statement above to the 01_modsecurity.conf file. If you are using a control panel that does not follow the file system standards for Linux, such as cpanel, you will need to add these files to different locations on your system.
Disabling rules using .htaccess
This is a new feature in modsecurity 2.7.3. This capability is available if you compile modsecurity using this option:
--enable-htaccess-config
From there, you will be able to disable rules using .htaccess files. The format to disable a rule via .htaccess is:
SecRuleRemoveById 12345
Where 12345 is the rule id.
Note: This capability is not enabled by default in modsecurity, and must be enabled specifically when modsecurity is compiled. If .htaccess directives do not work for you, then modsecurity is either not version 2.7.3 or higher, or this option has not been enabled.
Specific actions available in .htaccess
- SecAction
- SecRule
- SecRuleRemoveByMsg
- SecRuleRemoveByTag
- SecRuleRemoveById
- SecRuleUpdateActionById
- SecRuleUpdateTargetById
- SecRuleUpdateTargetByTag
- SecRuleUpdateTargetByMsg
Note: This capability is not enabled by default in modsecurity, and must be enabled specifically when modsecurity is compiled. If .htaccess directives do not work for you, then modsecurity is either not version 2.7.3 or higher, or this option has not been enabled.
Configuring and Setting up mod_security
If you are running ASL you do not need to do this. ASL will setup and manage mod_security for you. The page linked to below is only for non-ASL customers that must setup mod_security manually.
To setup and configured modsecurity, please see the Atomic_ModSecurity_Rules wiki page.
