https://wiki.atomicorp.com/wiki/api.php?action=feedcontributions&user=Mshinn&feedformat=atomAtomicorp Wiki - User contributions [en]2024-03-28T11:30:02ZUser contributionsMediaWiki 1.20.2https://wiki.atomicorp.com/wiki/index.php/Mod_securityMod security2023-11-17T20:50:18Z<p>Mshinn: /* Linux */</p>
<hr />
<div>=Installing modsecurity Rules =<br />
<br />
Please see this article:<br />
<br />
[[Atomic ModSecurity Rules]]<br />
<br />
=Tuning and managing modsecurity Rules=<br />
<br />
== Disabling Rules ==<br />
<br />
=== Important Notes ===<br />
<br />
==== phase:1 rules ====<br />
<br />
Note: ASL/AWP/AEO users should disable rules from the rule manager. There is no need to create custom rules, apache configuration files or other customizations when using ASL/AWP/AEO, and ASL/AWP/AEO supports disabling any rule on both a global and per domain basis.<br />
<br />
For non-ASL users, LocationMatch and Location do not work for phase:1 rules. Location and LocationMatch are not available in apache until phase:2. If you need to disable a phase:1 rule, use ASL/AWP/AEO which can disable phase:1 rules on a per domain and global basis.<br />
<br />
<br />
If you are not using ASL/AWP/AEO, and need to disable a phase:1 rule, you will need to create a custom rule to do this. This following is an example of a custom rule to do this for rule 123456.<br />
<br />
<br />
''SecRule REQUEST_HEADERS:Host "example.com$" "phase:1,id:91001,t:none,t:lowercase,pass,nolog,noauditlog,ctl:ruleRemovebyID=123456"''<br />
<br />
<br />
In the example above, "example.com" is the domain to exclude this rule. This custom rule must be loaded before the rule you want to disable. This custom rule *must be loaded before the rule you wish to disable*.<br />
<br />
If you do not know how to create this kind of custom rule, please contact support and we'll put a quote together to help develop these custom rules for you.<br />
<br />
=== Global ===<br />
<br />
==== Disabling Mod_Security Globally ====<br />
<br />
If you are using ASL, just change this setting:<br />
<br />
https://www.atomicorp.com/wiki/index.php/ASL_WAF#MODSEC_ENABLED<br />
<br />
If you are not using ASL, you will need to do this manually:<br />
<br />
Step 1) Disable config file<br />
mv /etc/httpd/conf.d/00_mod_security.conf /etc/httpd/conf.d/00_mod_security.conf.disabled<br />
<br />
Step 2) Restart Apache<br />
service httpd restart<br />
<br />
==== Disable Mod_security on a global URL ====<br />
<br />
Step 1) Create a global exclude file<br />
<br />
vim /etc/httpd/modsecurity.d/00_custom_exclude.conf<br />
<br />
Step 2) Add the LocationMatch for the url to exclude. Example: /server.php<br />
<br />
<LocationMatch /server.php><br />
<IfModule mod_security2.c><br />
SecRuleEngine Off <br />
</IfModule><br />
</LocationMatch><br />
<br />
Step 3) Restart apache<br />
<br />
service httpd restart<br />
<br />
<br />
<br />
Step 3) Restart apache<br />
<br />
service httpd restart<br />
<br />
==== Set a URL to alert only ====<br />
<br />
Step 1) Create a global exclude file<br />
<br />
vim /etc/httpd/modsecurity.d/00000_custom_exclude.conf<br />
<br />
Step 2) Add a custom rule<br />
<br />
In this example the URL is: /foo/bar<br />
<br />
Add this line to the file you created in Step 1:<br />
<br />
SecRule REQUEST_URI "/foo/bar" "phase:1,id:1000000,t:none,t:lowercase,pass,nolog,noauditlog,ctl:ruleEngine=DetectionOnly"<br />
<br />
Important Note: See the section customizing rules below to pick a unique id for your rule above. Duplicate rule ids will cause the rule to not load.<br />
<br />
Step 3) Restart apache<br />
<br />
service httpd restart<br />
<br />
=== Per domain ===<br />
<br />
==== Disabling Mod_security per domain ====<br />
<br />
Note: If you only want to disable a specific rule for a domain, please see this article:<br />
<br />
https://wiki.atomicorp.com/wiki/index.php/Mod_security#Per_application<br />
<br />
===== For Plesk Based Systems =====<br />
<br />
For Plesk and similar systems you can also disable modsecurity in the Apache configuration.<br />
<br />
Step 1) Edit the vhost/vhost_ssl.conf for the domain<br />
vim /var/www/vhosts/<DOMAINNAME>/conf/vhost.conf<br />
<br />
Step 2) Add the following<br />
<IfModule mod_security2.c><br />
SecRuleEngine Off<br />
</IfModule><br />
<br />
Then restart apache, if you are using Plesk then you will also need follow steps 3 and 4.<br />
<br />
Step 3) Add vhost.conf to domain config <br />
<br />
Plesk 9:<br />
/usr/local/psa/admin/bin/websrvmng -a<br />
<br />
Plesk 10/11:<br />
/usr/local/psa/admin/bin/httpdmng --reconfigure-domain <domain_name><br />
<br />
Step 4) Restart Apache<br />
service httpd restart<br />
<br />
===== For Cpanel based systems with EasyApache 4 =====<br />
<br />
For full information about include file path expectations, see the official cPanel documentation at [https://documentation.cpanel.net/display/EA4/Modify+Apache+Virtual+Hosts+with+Include+Files Modify Apache Virtual Hosts with Include Files]<br />
<br />
Step 1) Create the following paths, replacing <user> and <domain> with the correct values for your needs:<br />
<br />
* mkdir -p /etc/apache2/conf.d/userdata/ssl/2_4/<user>/<domain><br />
* mkdir -p /etc/apache2/conf.d/userdata/std/2_4/<user>/<domain><br />
<br />
Step 2) In each of the above paths, create a file named 'vhost.conf'<br />
<br />
Step 3) Add in the lines below to this file:<br />
<br />
<pre><br />
<IfModule mod_security2.c><br />
SecRuleEngine Off<br />
</IfModule><br />
</pre><br />
<br />
Step 4) After any addition, modification or removal of userdata files, cPanel requires both of the following scripts to be run:<br />
<br />
* /usr/local/cpanel/scripts/rebuildhttpdconf<br />
* /usr/local/cpanel/scripts/restartsrv_httpd<br />
<br />
<br />
===== For Cpanel based systems with EasyApache 3 =====<br />
<br />
Step 1) Create the custom modsecurity configuration directory for the domain<br />
<br />
For example, if the domain is example.com, you would need to create this directory:<br />
<br />
<br />
mkdir /usr/local/apache/conf/userdata/std/2/username/example.com<br />
<br />
Step 2) Create the file vhost.conf in this directory<br />
<br />
cd /usr/local/apache/conf/userdata/std/2/username/example.com<br />
<br />
touch vhost.conf<br />
<br />
Step 3) Add in the lines below to this file:<br />
<br />
<pre><br />
<IfModule mod_security2.c><br />
SecRuleEngine Off<br />
</IfModule><br />
</pre><br />
<br />
Step 4) Run the vhost includes script, for example if the domains username is "example":<br />
<br />
/scripts/ensure_vhost_includes --user=example<br />
<br />
<br />
<br />
==== Disabling Mod_security per domain for an IP address ====<br />
<br />
===== For a list of IPs or CIDRs =====<br />
<br />
====== Linux ======<br />
<br />
To disable a specific rule for a specific IP or network range follow this process:<br />
<br />
Step 1. Create the file:<br />
<br />
/etc/custom_ips<br />
<br />
Step 2: Add IPs or CIDRs to the /etc/custom_ips file<br />
<br />
The format is one IP or CIDR per line, for example:<br />
<br />
1.2.3.4<br />
1.2.4.0/24<br />
<br />
Regular expressions are not supported. You must use either an IP address or a CIDR.<br />
<br />
Step 3. Add the following custom rule to your custom rules file:<br />
<br />
SecRule REMOTE_ADDR "@ipMatchFromFile /etc/customips" "id:1234,phase:1,t:none,nolog,pass,noauditlog,ctl:ruleRemovebyID=350000"<br />
<br />
Note: Change the variable in the example above from 350000 to the rule ID you want to disable for these IPs.<br />
<br />
Step 4. Change the Rule ID.<br />
<br />
This is absolutely required. No two rules can have the same ID. See this article for chosing a custom rule id: https://wiki.atomicorp.com/wiki/index.php/Mod_security#Rule_Ids_for_custom_rules<br />
<br />
In the example above which is 1234, to a unique id that is not being used by your system.<br />
<br />
===== For Plesk based systems =====<br />
<br />
For Plesk and similar systems you can also disable modsecurity in the Apache configuration.<br />
<br />
Step 1) Edit the vhost/vhost_ssl.conf for the domain<br />
vim /var/www/vhosts/<DOMAINNAME>/conf/vhost.conf<br />
<br />
Step 2) Add the following<br />
<IfModule mod_security2.c><br />
SecRule REMOTE_ADDR "^1.2.3.4$" "phase:1,t:none,nolog,allow,ctl:ruleEngine=Off,ctl:auditEngine=Off,id:9999"<br />
</IfModule><br />
<br />
'''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.'''<br />
<br />
Then restart apache, if you are using Plesk then you will also need follow steps 3 and 4.<br />
<br />
Step 3) Add vhost.conf to domain config <br />
<br />
Plesk 9:<br />
/usr/local/psa/admin/bin/websrvmng -a<br />
<br />
Plesk 10/11:<br />
/usr/local/psa/admin/bin/httpdmng --reconfigure-domain <domain_name><br />
<br />
Step 4) Restart Apache<br />
service httpd restart<br />
<br />
===== For cpanel based systems =====<br />
<br />
Step 1) Create the custom modsecurity configuration directory for the domain<br />
<br />
For example, if the domain is example.com, you would need to create this directory:<br />
<br />
mkdir /usr/local/apache/conf/userdata/std/2/username/example.com<br />
<br />
Step 2) Create the file vhost.conf in this directory<br />
<br />
cd /usr/local/apache/conf/userdata/std/2/username/example.com<br />
<br />
touch vhost.conf<br />
<br />
Step 3) Add in the lines below to this file:<br />
<br />
<IfModule mod_security2.c><br />
SecRule REMOTE_ADDR "^1.2.3.4$" "phase:1,t:none,nolog,allow,ctl:ruleEngine=Off,ctl:auditEngine=Off,id:9999"<br />
</IfModule><br />
<br />
'''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.'''<br />
<br />
Step 4) Run the vhost includes script, for example if the domains username is "example":<br />
<br />
/scripts/ensure_vhost_includes –user=example<br />
<br />
==== Disable a rule for a single domain ====<br />
<br />
'''If you have ASL installed''':<br />
<br />
Method 1:<br />
<br />
Log into the ASL GUI, and click on the "ASL" tab. Then click "WAF & HIDS Rules", 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.<br />
<br />
Type in the hostname into the Text box on the left side of the options you want to exclude the rule for, then click "add".<br />
<br />
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, or a regular expression *.example.com.<br />
<br />
Note: You can use regular expressions in this field, but each end of the expression is anchored.<br />
<br />
<br />
Method 2: Run this command as root:<br />
<br />
In ASL v3.x:<br />
asl -dr RULE_ID --vhost www.example.com<br />
<br />
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:<br />
<br />
asl -dr RULE_ID --vhost www.example.com<br />
<br />
asl -dr RULE_ID --vhost ftp.example.com<br />
<br />
asl -dr RULE_ID --vhost example.com<br />
<br />
<br />
In ASL v4:<br />
asl -drv RULE_ID[,RULE_ID...] VHOST[,VHOST...]<br />
or <br />
asl --disable-rule-vhost RULE_ID[,RULE_ID...] VHOST[,VHOST...]<br />
<br />
All supplied rules will be disabled on all supplied vhosts.<br />
<br />
asl -drv 111111,222222,333333 www.example.com,ftp.example.com,example.com<br />
<br />
<br />
<br />
<br />
'''If you do not have ASL installed''' you will have to do this manually:<br />
<br />
Step 1) Edit your domains vhost.conf file (the location of this file will vary based on your control panel, contact your control panel vendor for assistance)<br />
<br />
vim vhost.conf<br />
<br />
Step 2) Add the LocationMatch for the rule to exclude. Example, ruleid 950005<br />
<LocationMatch .*><br />
<IfModule mod_security2.c><br />
SecRuleRemoveById 950005<br />
</IfModule><br />
</LocationMatch><br />
<br />
If you want to disable multiple rules:<br />
<br />
Step 2) Add the LocationMatch for the rule to exclude. Example, ruleids 950005 and 950006<br />
<LocationMatch .*><br />
<IfModule mod_security2.c><br />
SecRuleRemoveById 950005<br />
SecRuleRemoveById 950006<br />
</IfModule><br />
</LocationMatch><br />
<br />
<br />
==== Non Control Panel systems ====<br />
<br />
For nginx, or phase:1 rules rules can be disabled for a domain/FQDN by adding a custom rule before the rule you wish to disable is loaded. For example, if you wanted to disable rule 123456 for domain example.com, you would add this rule to your custom rules:<br />
<br />
SecRule REQUEST_HEADERS:Host "example.com$" "phase:1,id:91001,t:none,t:lowercase,pass,nolog,noauditlog,ctl:ruleRemovebyID=123456"<br />
<br />
This method can also be used for Apache.<br />
<br />
==== Disable a rule for all domains ====<br />
<br />
Method 1:<br />
<br />
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.<br />
<br />
Set "disabled" to yes and click update.<br />
<br />
Method 2:<br />
<br />
Use ASL utility to disable rule by ID. Example: 950005<br />
asl --disable-rule 950005<br />
<br />
Note: This requires that [[Atomic Secured Linux]] be installed.<br />
'''<br />
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:<br />
<br />
<LocationMatch .*><br />
<IfModule mod_security2.c><br />
SecRuleRemoveById 340000<br />
</IfModule><br />
</LocationMatch><br />
<br />
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.<br />
<br />
=== Per IP or network ===<br />
<br />
==== Disable Mod_security for an IP address ====<br />
<br />
In ASL, just click the "Whitelist" button.<br />
<br />
If you are not using ASL, simply add your IP address to the file:<br />
<br />
/etc/asl/whitelist<br />
<br />
And restart Apache.<br />
<br />
Note: For this rule to work, in ASL you must have the MODSEC_00_WHITELIST ruleset enabled.<br />
<br />
If you are not using ASL, then you must have the 00_asl_whitelist.conf ruleset loaded.<br />
<br />
==== Whitelist an IP ====<br />
<br />
See above, "Disable Mod_security for an IP address"<br />
<br />
==== Disable a rule by IP or network====<br />
<br />
You will need to create a custom rule, loaded after all your other rules. Lets say you wanted to exclude rule id 330039 for the network 1.2.0.0/16. You would construct a custom rule like this:<br />
<br />
<pre><br />
SecRule REMOTE_HOST "@ipmatch 1.2.0.0/16" \<br />
"id:12345,phase:2,t:none,pass,nolog,noauditlog,ctl:ruleRemovebyID=330039"<br />
</pre><br />
<br />
Note: ipmatch can also use a list, with a combination of IPs and network for example:<br />
<br />
@ipmatch 1.2.0.0/16,5.6.7.8,127.0.0.0/8<br />
<br />
Warning: If the CIDR is invalid, this may cause a segfault of the mod_security module. Check to make sure your CIDR is valid before use.<br />
<br />
=== Per application ===<br />
<br />
==== Disable modsecurity for a specific web application ====<br />
<br />
Note: this is not recommended<br />
<br />
Add a custom rule (see the section below on creating [https://www.atomicorp.com/wiki/index.php/Mod_security#Creating_custom_rules custom rules]) after all your rules have been loaded. For example, if you wanted to disable modsecurity for the application /foo/bar.cgi you would add a custom rule like this:<br />
<br />
<pre><br />
<LocationMatch /foo/bar.cgi><br />
SecRuleEngine Off<br />
<br />
</LocationMatch><br />
</pre><br />
<br />
<br />
<br />
==== Disable a rule for a specific web application ====<br />
Add a custom rule (see the section below on creating [https://www.atomicorp.com/wiki/index.php/Mod_security#Creating_custom_rules custom rules]) after all your rules have been loaded. For example, if you wanted to disable rule 950005, you would add a custom rule like this:<br />
<br />
<pre><br />
<LocationMatch /URL/path/to/application.php><br />
SecRuleRemoveById 950005<br />
<br />
</LocationMatch><br />
</pre><br />
<br />
==== Disable a rule for a single domain or FQDN ====<br />
<br />
===== For non control panel systems =====<br />
<br />
If you are using any of our GUI products, just click on the rule event, and type in the domain or hostname you want to exclude for this rule. <br />
<br />
For DIY users, you will need to create custom rules that load *before* the rule that you wish to exclude. This means you will need to add a custom rule file that loads before the rules we supply.<br />
<br />
Once you have set this up for your DIY modsecurity configuration, you will add a rule that inspects the Host: header sent by the client, which will the disable the rule(s) you wish to disable when that field is populated by that value. Keep in mind this field is completely controlled by the client, not the server. In the example below, the entire domain "example.com" is excluded for rule 123456:<br />
<br />
''SecRule REQUEST_HEADERS:Host ".example.com$" "phase:1,id:91010,t:none,t:lowercase,pass,nolog,noauditlog,ctl:ruleRemovebyID=123456"''<br />
<br />
Then restart the web server to apply this custom exclusion.<br />
<br />
===== For Plesk systems =====<br />
<br />
<br />
Step 1) Edit the virtual servers configuration for the domain for the domain<br />
<br />
Example:<br />
<br />
vim /var/www/vhosts/<DOMAINNAME>/conf/vhost.conf<br />
<br />
Step 2) Add the LocationMatch for the rule to exclude. Example, ruleid 950005<br />
<br />
<pre><br />
<LocationMatch /URL/path/to/application.php><br />
<br />
SecRuleRemoveById 950005<br />
</IfModule><br />
<br />
</pre><br />
<br />
==== Disable Mod_security rules globally for a specific application ====<br />
<br />
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.<br />
<br />
<LocationMatch /url/to/your/application><br />
<IfModule mod_security2.c><br />
SecRuleRemoveById 1234567<br />
SecRuleRemoveById 9999999<br />
</IfModule><br />
</LocationMatch><br />
<br />
Whats important to remember is that the LocationMatch variable must match the URL, not the path on the system.<br />
<br />
==== Disable Mod_security rules by domain, for a specific application, for a list of IPs ====<br />
<br />
Step 1) Edit the vhost/vhost_ssl.conf for the domain<br />
vim /var/www/vhosts/<DOMAINNAME>/conf/vhost.conf<br />
<br />
Step 2) Add the LocationMatch for the rule to exclude.<br />
<LocationMatch /foo/bar.php><br />
<IfModule mod_security2.c><br />
SecRule REMOTE_ADDR "@pmFromFile /etc/asl/whitelist" "nolog,phase:1,allow"<br />
</IfModule><br />
</LocationMatch><br />
<br />
Step 3) Add IP to /etc/asl/whitelist<br />
echo "10.11.12.13" >> /etc/asl/whitelist<br />
<br />
Or:<br />
<br />
If you want to create a special whitelist for just that application:<br />
<br />
Step 1) Edit the vhost/vhost_ssl.conf for the domain<br />
vim /var/www/vhosts/<DOMAINNAME>/conf/vhost.conf<br />
<br />
Step 2) Add the LocationMatch for the rule to exclude.<br />
<LocationMatch /foo/bar.php><br />
<IfModule mod_security2.c><br />
SecRule REMOTE_ADDR "@pmFromFile /path/to/your/custom/whitelist_for_this_application" "nolog,phase:1,allow,id:9999"<br />
</IfModule><br />
</LocationMatch><br />
<br />
'''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.'''<br />
<br />
<br />
Step 3) Create your custom whitelist and add IP to /etc/asl/whitelist<br />
echo "10.11.12.13" >> /path/to/your/custom/whitelist_for_this_application<br />
<br />
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.<br />
<br />
==== Disable rule for a specific argument for a specific application ====<br />
<br />
You can also tell modsecurity to change a rule, in some cases, without editing or forking the rule. For example, if you want to configure modsecurity to ignore a specific argument (in the argument below the argument is "foo"), for a specific application (in the example the application name is /example/application), for a specific rule (in the example below the rule if is 12345), you would create a custom rule like this:<br />
<br />
<br />
<pre><br />
SecRule REQUEST_URI "^/example/application" \<br />
"id:9999,phase:1,t:none,t:lowercase,nolog,pass,ctl:ruleRemoveTargetByID=12345;ARGS:foo"<br />
</pre><br />
<br />
As with all custom rules, this rule also needs a unique id as explained in the article above. And this type of custom rule must be loaded '''before''' the rule it modifies.<br />
<br />
Note: This does not support regular expressions for the excluded argument. At this time, they must be explicitly defined.<br />
<br />
==== Disable rule for a specific argument ====<br />
<br />
As is the example above, a rule can also be changed to exclude a specific argument, but for all applications. For example, if you want to configure modsecurity to ignore a specific argument (in the argument below the argument is "foo"), for a specific rule (in the example below the rule if is 12345), you would create a custom rule like this:<br />
<br />
<pre><br />
SecAction "phase:1,id:9999,t:none,auditlog,nolog,pass,ctl:ruleRemoveTargetById=12345;ARGS:foo"<br />
</pre><br />
<br />
As with all custom rules, this rule also needs a unique id as explained in the article above. And this type of custom rule must be loaded '''before''' the rule it modifies.<br />
<br />
Note: This does not support regular expressions for the excluded argument. At this time, they must be explicitly defined.<br />
<br />
==== Disable modsecurity for a specific argument ====<br />
<br />
As is the example above, modsecurity can also be configured to exclude a specific argument for all rules. For example, if you want to configure modsecurity to ignore a specific argument (in the argument below the argument is "foo"),you would create a custom rule like this:<br />
<br />
<pre><br />
SecAction "phase:1,id:9999,t:none,auditlog,nolog,pass,ctl:ruleRemoveTargetById=1-1000000;ARGS:foo"<br />
</pre><br />
<br />
When 1-100000 is the rule IDs you want to exclude. As with all custom rules, this rule also needs a unique id as explained in the article above. <br />
<br />
Note: This does not support regular expressions for the excluded argument. At this time, they must be explicitly defined.<br />
<br />
== Changing the action for a rule ==<br />
<br />
You can also change the default action for a rule by using the SecRuleActionById directive. <br />
<br />
=== Changing a rule to be detect only by ID===<br />
<br />
To change a rule to only detect, but not block attacks, simply change the action for the rule with the above directive. For example, to change the action for rule 12345, simply add this rule directive to your custom rules. <br />
<br />
SecRuleUpdateActionById 12345 "pass,status:200"<br />
<br />
Note 1: this directive must be added after the rule it is modifying has been loaded.<br />
<br />
Note 2: This does not work if you are using the redirect action.<br />
<br />
=== Changing a range of rules to be detect only by ID===<br />
<br />
This is similar to the method above, however you can define a range of rule IDs. For example, if you want to disable rules 1000-2000:<br />
<br />
SecRuleUpdateActionById 1000-2000 "pass,status:200"<br />
<br />
Note 1: this directive must be added after the rule it is modifying has been loaded.<br />
<br />
Note 2: This does not work if you are using the redirect action.<br />
<br />
== Disabling POST inspection for a specific URL ==<br />
<br />
Should you want to disable inspection of a POST for a specific URL, use the format below.<br />
<br />
Assuming the URL you wanted to skip POST inspection was "upload", your exclusion rule would look like this:<br />
<br />
''SecRule REQUEST_URI "^/upload" \<br />
"phase:1,id:1234567,t:none,t:lowercase,pass,nolog,ctl:requestBodyAccess=off"''<br />
<br />
Install this rule before any of your other rules. For example, in the file /etc/httpd/modsecurity.d/00_custom_exclude.conf.<br />
<br />
== Enabling rules for only specific domains ==<br />
<br />
If you wish to disable all the rules, except for specific domains, you need to copy in the two files from the subdirectory "special" where you have the rules installed. Then create this file:<br />
<br />
/etc/asl/custom_include_domains<br />
<br />
<br />
Include the domains and/or FQDNs you want the rules to apply to. Anything not on that list will cause those rules to skip all of our rules. <br />
<br />
#File must contain exactly one domain or FQDN per line. End of line markers (both LF and CRLF) will be stripped from each phrase and any whitespace trimmed from both the beginning and the end. Empty lines and comment lines (those beginning with the # character) will be ignored.<br />
#This file does not support metacharacters. (For example, * is not supported)<br />
<br />
Example:<br />
<br />
<br />
<pre><br />
www.example.com<br />
.foo.com<br />
</pre><br />
<br />
== Disabling rules using .htaccess ==<br />
<br />
This is a new feature in modsecurity 2.7.3. This capability is available if you compile modsecurity using this option:<br />
<br />
--enable-htaccess-config<br />
<br />
From there, you will be able to disable rules using .htaccess files. The format to disable a rule via .htaccess is:<br />
<br />
SecRuleRemoveById 12345<br />
<br />
Where 12345 is the rule id.<br />
<br />
'''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 and/or this option has not been enabled. <br />
<br />
Warning: Enabling this capability will allow users to disable rules, including on compromised accounts which may cause the system to become compromised. This capability was specifically disabled by default in modsecurity to prevent this from occurring. Use this option with extreme caution!<br />
<br />
=== Specific actions available in .htaccess ===<br />
<br />
<br />
* SecAction<br />
* SecRule<br />
* SecRuleRemoveByMsg<br />
* SecRuleRemoveByTag<br />
* SecRuleRemoveById<br />
* SecRuleUpdateActionById<br />
* SecRuleUpdateTargetById<br />
* SecRuleUpdateTargetByTag<br />
* SecRuleUpdateTargetByMsg<br />
<br />
'''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.<br />
<br />
Warning: Enabling this capability in modsecurity can allow an attacker to disable modsecurity rules that you may be using to protect the entire server. We do not recommend you enable this capability on a shared server.<br />
<br />
== Customizing a rule ==<br />
<br />
If you need to customize a rule do not change the asl*conf files. These files will be overwritten by updates. <br />
<br />
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.<br />
<br />
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:<br />
<br />
If you had an original rule like this:<br />
<br />
SecRule REQUEST_URI "/foo" "t:normalisePath,id:9000,rev:1,severity:2,msg:'Atomicorp.com WAF Rules: Block /foo'"<br />
<br />
<br />
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.<br />
<br />
SecRuleRemoveById 9000000<br />
SecRule REQUEST_URI "/bar" "t:normalisePath,id:9999,rev:1,severity:2,msg:'Atomicorp.com WAF Rules: Block /foo'"<br />
<br />
'''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.'''<br />
<br />
<br />
These are the reserved ranges:<br />
<br />
* 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.<br />
* 100,000-199,999; reserved for internal use of the engine, to assign to rules that do not have explicit IDs.<br />
* 200,000-299,999; reserved for rules published at modsecurity.org.<br />
* 300,000-399,999; reserved for rules published at gotroot.com.<br />
* 400,000-419,999; unused (available for reservation).<br />
* 420,000-429,999; reserved for ScallyWhack.<br />
* 430,000-699,999; unused (available for reservation).<br />
* 700,000-799,999; reserved for Ivan Ristic.<br />
* 900,000-999,999; reserved for the Core Rules project.<br />
* 1,000,000 and above; unused (available for reservation).<br />
<br />
=== For a domain ===<br />
<br />
==== Apache ====<br />
<br />
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.<br />
<br />
==== Changing the argument separator ====<br />
<br />
If you have a web application that uses the uncommon ";" argument separator, as opposed to the widely used "&" you will want to change SecArgumentSeparator value for that application. You can do this in one of two ways:<br />
<br />
1) Globally<br />
<br />
If all your applications use the older delimiter, just change the SecArgumentSeparator in the tortix_waf.conf file. Do not change this if your applications use other delimiters.<br />
<br />
''SecArgumentSeparator ";"'' <br />
<br />
2) Per Application<br />
<br />
You can also configure this per application. For example, if your web applications URL is /foo/bar.php you can create a customer rule like this:<br />
<br />
<br />
<pre><br />
<LocationMatch /foo/bar.php><br />
SecArgumentSeparator ";"<br />
</LocationMatch><br />
</pre><br />
<br />
This will only work if modsecurity is loaded before your virtual host definitions. This is the case with most control panels, but some control panels are known to load modsecurity after vhosts are defined. In which case this will fail because Apache will not know how to process this directive (it will need modsecurity loaded to understand what this means). If you get a syntax error, that means your apache configuration is loaded modsecurity after your vhosts are defined. You will need to change your apache configuration to ensure this loading occurs before vhosts are defined.<br />
<br />
[[ASL]] will automatically configure modsecurity to load first.<br />
<br />
= Creating custom rules =<br />
<br />
== Discussion ==<br />
<br />
If you need to create your own custom rules, do not change the asl*conf files. These files will be overwritten by updates. <br />
<br />
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.<br />
<br />
== Rule Ids for custom rules ==<br />
<br />
For custom rules, '''you must create your own rule ids which must be unique'''. The id: fields contain the rule ids. For custom rules you should use the local (internal) use range (see below for the reserved id ranges). '''Do not use assigned ranges.'''<br />
<br />
These are the reserved ranges:<br />
<br />
* 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.<br />
* 100,000-199,999; reserved for internal use of the engine, to assign to rules that do not have explicit IDs. (deprecated, all rules require assigned ids in 2.7.x and up)<br />
* 200,000-299,999; reserved for rules published at modsecurity.org.<br />
* 300,000-399,999; reserved for rules published by atomicorp.com<br />
* 400,000-419,999; unused (available for reservation).<br />
* 420,000-429,999; reserved for ScallyWhack.<br />
* 430,000-699,999; unused (available for reservation).<br />
* 700,000-799,999; reserved for Ivan Ristic.<br />
* 900,000-999,999; reserved for the Core Rules project.<br />
* 1,000,000 and above; unused (available for reservation).<br />
<br />
== Installing custom rules ==<br />
<br />
<br />
=== Linux ===<br />
<br />
==== Apache ====<br />
<br />
'''Step 1) Create your custom rules directory:'''<br />
<br />
''mkdir /etc/httpd/modsecurity.custom.d''<br />
<br />
'''Step 2) Create a configuration file for your custom rules in /etc/httpd/conf.d directory. For example:'''<br />
<br />
Create the file 01_modsecurity.conf and add this line to it:<br />
<br />
''Include modsecurity.custom.d/[https://www.atomicorp.com/examples/99_zzz_custom.conf 99_zzz_custom.conf]''<br />
<br />
You can download an example file from the URL below that will do this:<br />
<br />
[https://www.atomicorp.com/examples/01_modsecurity.conf 01_modsecurity.conf]<br />
<br />
And add 01_modsecurity.conf to this directory:<br />
<br />
/etc/httpd/conf.d<br />
<br />
If you have wget installed on your system, the following commands will do this automatically for you:<br />
''<br />
<br />
cd /etc/httpd/conf.d<br />
<br />
wget https://www.atomicorp.com/examples/01_modsecurity.conf''<br />
<br />
Note: 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. Please contact your control panel vendor for assistance.<br />
<br />
'''Step 3) Install your custom rules in the /etc/httpd/modsecurity.custom.d directory'''<br />
<br />
''cd /etc/httpd/modsecurity.custom.d''<br />
<br />
and edit the file 99_zzz_custom.conf and put in your custom rules.<br />
<br />
You can also download an example custom rule file by running these commands:<br />
<br />
''cd /etc/httpd/modsecurity.custom.d<br />
<br />
wget https://www.atomicorp.com/examples/99_zzz_custom.conf''<br />
<br />
'''Step 4) Test your apache configuration'''<br />
<br />
''service httpd configtest''<br />
<br />
If you have any errors, do not restart apache. You will need to correct these errors or apache will not start.<br />
<br />
'''Step 5) If your test was successful, restart apache.'''<br />
<br />
''service httpd restart''<br />
<br />
Our professional services group would be happy to help you with your custom rules needs, including developing the rules for you. If your request is something that we can safely include in the rules for all our customers, we're generally able to develop these new rules for free. Please contact us to discuss your rules needs.<br />
<br />
=== Windows ===<br />
<br />
==== IIS ====<br />
<br />
'''Step 1) Modify your modsecurity configuration file on windows and add this line to the end of your configuration. For example:'''<br />
<br />
''Include [https://www.atomicorp.com/examples/99_zzz_custom.conf 99_zzz_custom.conf]''<br />
<br />
'''Step 2) Edit the file 99_zzz_custom.conf and save it in the same directory as your modsecurity config file'''<br />
<br />
'''Step 3)Restart IIS'''<br />
<br />
<br />
Our professional services group would be happy to help you with your custom rules needs, including developing the rules for you. If your request is something that we can safely include in the rules for all our customers, we're generally able to develop these new rules for free. Please contact us to discuss your rules needs.<br />
<br />
== Modifying a rule ==<br />
<br />
If you want to modify the internal logic of a rule, you will want to "fork" or copy that rule into a custom rule. Do not modify the actual rules provided by us, your modifications will be overwritten with the next update.<br />
<br />
'''Step 1: Copy the rule you want to modify into your custom rules file.'''<br />
<br />
Copy the rule in its entirety into your custom rule file. For example, if you wanted to modify rule 390707, you would copy the entire rule into your custom rules file. For example:<br />
<br />
<pre><br />
# Restrict the maximum number of arguments in a request<br />
SecRule &ARGS "@gt 1000" \<br />
"chain,phase:2,t:none,log,auditlog,deny,status:403,msg:'Atomicorp.com WAF Rules: Too many arguments in request (max set to 1000, increase as necessary for your system)',id:'390707',severity:'4',rev:'8'"<br />
SecRule REQUEST_URI "!((?:^/(?:imaclean|massdelete)/)|^/cgi-bin/dada/mail\.cgi$|^/index\.php/mageworx/customoptions_options|^/za/|^/back-?office/|^/moderate\.php|^/backend/configdomains\.php|\.do$|^/admin[a-z0-9]+?/index\.php\?controller=adminmodules)" "t:none,t:lowercase"<br />
</pre><br />
<br />
'''Step 2: Change the rule id.''' <br />
<br />
This is absolutely required. No two rules can have the same ID. See this article for chosing a custom rule id: https://wiki.atomicorp.com/wiki/index.php/Mod_security#Rule_Ids_for_custom_rules<br />
<br />
For example:<br />
<br />
<pre><br />
# Restrict the maximum number of arguments in a request<br />
SecRule &ARGS "@gt 1000" \<br />
"chain,phase:2,t:none,log,auditlog,deny,status:403,msg:'Atomicorp.com WAF Rules: Too many arguments in request (max set to 1000, increase as necessary for your system)',id:'12345678',severity:'4',rev:'8'"<br />
SecRule REQUEST_URI "!((?:^/(?:imaclean|massdelete)/)|^/cgi-bin/dada/mail\.cgi$|^/index\.php/mageworx/customoptions_options|^/za/|^/back-?office/|^/moderate\.php|^/backend/configdomains\.php|\.do$|^/admin[a-z0-9]+?/index\.php\?controller=adminmodules)" "t:none,t:lowercase"<br />
</pre><br />
<br />
'''Step 3: Disable the original rule'''<br />
<br />
If you want your custom rule to be global, that is your modification applies to the entire system, then you will want to disable the original rule per this article:<br />
<br />
https://wiki.atomicorp.com/wiki/index.php/Mod_security#Disable_a_rule_for_all_domains<br />
<br />
If you want to disable the rule for a single application, see this article:<br />
<br />
https://wiki.atomicorp.com/wiki/index.php/Mod_security#Disable_a_rule_for_a_specific_web_application<br />
<br />
If you want to disable the rule for a specific IP or network:<br />
<br />
https://wiki.atomicorp.com/wiki/index.php/Mod_security#Disable_a_rule_by_IP_or_network<br />
<br />
If you want to disable the rule for a single domain:<br />
<br />
https://wiki.atomicorp.com/wiki/index.php/Mod_security#Disable_a_rule_for_a_single_domain<br />
<br />
'''Step 4: Set the scope of the rule.'''<br />
<br />
If you havent disabled the original rule globally, or for one or more domains, then you will need to set the scope of your custom rule. To limit your modification to a specific application, place your custom rule inside <LocationMatch> tags. For example:<br />
<br />
<pre><br />
<br />
<LocationMatch /url/to/your/custom/application><br />
# Restrict the maximum number of arguments in a request<br />
SecRule &ARGS "@gt 2048" \<br />
"chain,phase:2,t:none,log,auditlog,deny,status:403,msg:'Atomicorp.com WAF Rules: Too many arguments in request (max set to 1000, increase as necessary for your system)',id:'12345678',severity:'4',rev:'8'"<br />
SecRule REQUEST_URI "!((?:^/(?:imaclean|massdelete)/)|^/cgi-bin/dada/mail\.cgi$|^/index\.php/mageworx/customoptions_options|^/za/|^/back-?office/|^/moderate\.php|^/backend/configdomains\.php|\.do$|^/admin[a-z0-9]+?/index\.php\?controller=adminmodules)" "t:none,t:lowercase"<br />
</LocationMatch><br />
<br />
</pre><br />
<br />
= Configuring and Setting up mod_security =<br />
'''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.'''<br />
<br />
To setup and configured modsecurity, please see the [[Atomic_ModSecurity_Rules]] wiki page.</div>Mshinnhttps://wiki.atomicorp.com/wiki/index.php/Mod_securityMod security2023-11-17T20:49:56Z<p>Mshinn: /* Linux */</p>
<hr />
<div>=Installing modsecurity Rules =<br />
<br />
Please see this article:<br />
<br />
[[Atomic ModSecurity Rules]]<br />
<br />
=Tuning and managing modsecurity Rules=<br />
<br />
== Disabling Rules ==<br />
<br />
=== Important Notes ===<br />
<br />
==== phase:1 rules ====<br />
<br />
Note: ASL/AWP/AEO users should disable rules from the rule manager. There is no need to create custom rules, apache configuration files or other customizations when using ASL/AWP/AEO, and ASL/AWP/AEO supports disabling any rule on both a global and per domain basis.<br />
<br />
For non-ASL users, LocationMatch and Location do not work for phase:1 rules. Location and LocationMatch are not available in apache until phase:2. If you need to disable a phase:1 rule, use ASL/AWP/AEO which can disable phase:1 rules on a per domain and global basis.<br />
<br />
<br />
If you are not using ASL/AWP/AEO, and need to disable a phase:1 rule, you will need to create a custom rule to do this. This following is an example of a custom rule to do this for rule 123456.<br />
<br />
<br />
''SecRule REQUEST_HEADERS:Host "example.com$" "phase:1,id:91001,t:none,t:lowercase,pass,nolog,noauditlog,ctl:ruleRemovebyID=123456"''<br />
<br />
<br />
In the example above, "example.com" is the domain to exclude this rule. This custom rule must be loaded before the rule you want to disable. This custom rule *must be loaded before the rule you wish to disable*.<br />
<br />
If you do not know how to create this kind of custom rule, please contact support and we'll put a quote together to help develop these custom rules for you.<br />
<br />
=== Global ===<br />
<br />
==== Disabling Mod_Security Globally ====<br />
<br />
If you are using ASL, just change this setting:<br />
<br />
https://www.atomicorp.com/wiki/index.php/ASL_WAF#MODSEC_ENABLED<br />
<br />
If you are not using ASL, you will need to do this manually:<br />
<br />
Step 1) Disable config file<br />
mv /etc/httpd/conf.d/00_mod_security.conf /etc/httpd/conf.d/00_mod_security.conf.disabled<br />
<br />
Step 2) Restart Apache<br />
service httpd restart<br />
<br />
==== Disable Mod_security on a global URL ====<br />
<br />
Step 1) Create a global exclude file<br />
<br />
vim /etc/httpd/modsecurity.d/00_custom_exclude.conf<br />
<br />
Step 2) Add the LocationMatch for the url to exclude. Example: /server.php<br />
<br />
<LocationMatch /server.php><br />
<IfModule mod_security2.c><br />
SecRuleEngine Off <br />
</IfModule><br />
</LocationMatch><br />
<br />
Step 3) Restart apache<br />
<br />
service httpd restart<br />
<br />
<br />
<br />
Step 3) Restart apache<br />
<br />
service httpd restart<br />
<br />
==== Set a URL to alert only ====<br />
<br />
Step 1) Create a global exclude file<br />
<br />
vim /etc/httpd/modsecurity.d/00000_custom_exclude.conf<br />
<br />
Step 2) Add a custom rule<br />
<br />
In this example the URL is: /foo/bar<br />
<br />
Add this line to the file you created in Step 1:<br />
<br />
SecRule REQUEST_URI "/foo/bar" "phase:1,id:1000000,t:none,t:lowercase,pass,nolog,noauditlog,ctl:ruleEngine=DetectionOnly"<br />
<br />
Important Note: See the section customizing rules below to pick a unique id for your rule above. Duplicate rule ids will cause the rule to not load.<br />
<br />
Step 3) Restart apache<br />
<br />
service httpd restart<br />
<br />
=== Per domain ===<br />
<br />
==== Disabling Mod_security per domain ====<br />
<br />
Note: If you only want to disable a specific rule for a domain, please see this article:<br />
<br />
https://wiki.atomicorp.com/wiki/index.php/Mod_security#Per_application<br />
<br />
===== For Plesk Based Systems =====<br />
<br />
For Plesk and similar systems you can also disable modsecurity in the Apache configuration.<br />
<br />
Step 1) Edit the vhost/vhost_ssl.conf for the domain<br />
vim /var/www/vhosts/<DOMAINNAME>/conf/vhost.conf<br />
<br />
Step 2) Add the following<br />
<IfModule mod_security2.c><br />
SecRuleEngine Off<br />
</IfModule><br />
<br />
Then restart apache, if you are using Plesk then you will also need follow steps 3 and 4.<br />
<br />
Step 3) Add vhost.conf to domain config <br />
<br />
Plesk 9:<br />
/usr/local/psa/admin/bin/websrvmng -a<br />
<br />
Plesk 10/11:<br />
/usr/local/psa/admin/bin/httpdmng --reconfigure-domain <domain_name><br />
<br />
Step 4) Restart Apache<br />
service httpd restart<br />
<br />
===== For Cpanel based systems with EasyApache 4 =====<br />
<br />
For full information about include file path expectations, see the official cPanel documentation at [https://documentation.cpanel.net/display/EA4/Modify+Apache+Virtual+Hosts+with+Include+Files Modify Apache Virtual Hosts with Include Files]<br />
<br />
Step 1) Create the following paths, replacing <user> and <domain> with the correct values for your needs:<br />
<br />
* mkdir -p /etc/apache2/conf.d/userdata/ssl/2_4/<user>/<domain><br />
* mkdir -p /etc/apache2/conf.d/userdata/std/2_4/<user>/<domain><br />
<br />
Step 2) In each of the above paths, create a file named 'vhost.conf'<br />
<br />
Step 3) Add in the lines below to this file:<br />
<br />
<pre><br />
<IfModule mod_security2.c><br />
SecRuleEngine Off<br />
</IfModule><br />
</pre><br />
<br />
Step 4) After any addition, modification or removal of userdata files, cPanel requires both of the following scripts to be run:<br />
<br />
* /usr/local/cpanel/scripts/rebuildhttpdconf<br />
* /usr/local/cpanel/scripts/restartsrv_httpd<br />
<br />
<br />
===== For Cpanel based systems with EasyApache 3 =====<br />
<br />
Step 1) Create the custom modsecurity configuration directory for the domain<br />
<br />
For example, if the domain is example.com, you would need to create this directory:<br />
<br />
<br />
mkdir /usr/local/apache/conf/userdata/std/2/username/example.com<br />
<br />
Step 2) Create the file vhost.conf in this directory<br />
<br />
cd /usr/local/apache/conf/userdata/std/2/username/example.com<br />
<br />
touch vhost.conf<br />
<br />
Step 3) Add in the lines below to this file:<br />
<br />
<pre><br />
<IfModule mod_security2.c><br />
SecRuleEngine Off<br />
</IfModule><br />
</pre><br />
<br />
Step 4) Run the vhost includes script, for example if the domains username is "example":<br />
<br />
/scripts/ensure_vhost_includes --user=example<br />
<br />
<br />
<br />
==== Disabling Mod_security per domain for an IP address ====<br />
<br />
===== For a list of IPs or CIDRs =====<br />
<br />
====== Linux ======<br />
<br />
To disable a specific rule for a specific IP or network range follow this process:<br />
<br />
Step 1. Create the file:<br />
<br />
/etc/custom_ips<br />
<br />
Step 2: Add IPs or CIDRs to the /etc/custom_ips file<br />
<br />
The format is one IP or CIDR per line, for example:<br />
<br />
1.2.3.4<br />
1.2.4.0/24<br />
<br />
Regular expressions are not supported. You must use either an IP address or a CIDR.<br />
<br />
Step 3. Add the following custom rule to your custom rules file:<br />
<br />
"SecRule REMOTE_ADDR ""@ipMatchFromFile /etc/customips" "id:1234,phase:1,t:none,nolog,pass,noauditlog,ctl:ruleRemovebyID=350000"<br />
<br />
Note: Change the variable in the example above from 350000 to the rule ID you want to disable for these IPs.<br />
<br />
Step 4. Change the Rule ID.<br />
<br />
This is absolutely required. No two rules can have the same ID. See this article for chosing a custom rule id: https://wiki.atomicorp.com/wiki/index.php/Mod_security#Rule_Ids_for_custom_rules<br />
<br />
In the example above which is 1234, to a unique id that is not being used by your system.<br />
<br />
===== For Plesk based systems =====<br />
<br />
For Plesk and similar systems you can also disable modsecurity in the Apache configuration.<br />
<br />
Step 1) Edit the vhost/vhost_ssl.conf for the domain<br />
vim /var/www/vhosts/<DOMAINNAME>/conf/vhost.conf<br />
<br />
Step 2) Add the following<br />
<IfModule mod_security2.c><br />
SecRule REMOTE_ADDR "^1.2.3.4$" "phase:1,t:none,nolog,allow,ctl:ruleEngine=Off,ctl:auditEngine=Off,id:9999"<br />
</IfModule><br />
<br />
'''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.'''<br />
<br />
Then restart apache, if you are using Plesk then you will also need follow steps 3 and 4.<br />
<br />
Step 3) Add vhost.conf to domain config <br />
<br />
Plesk 9:<br />
/usr/local/psa/admin/bin/websrvmng -a<br />
<br />
Plesk 10/11:<br />
/usr/local/psa/admin/bin/httpdmng --reconfigure-domain <domain_name><br />
<br />
Step 4) Restart Apache<br />
service httpd restart<br />
<br />
===== For cpanel based systems =====<br />
<br />
Step 1) Create the custom modsecurity configuration directory for the domain<br />
<br />
For example, if the domain is example.com, you would need to create this directory:<br />
<br />
mkdir /usr/local/apache/conf/userdata/std/2/username/example.com<br />
<br />
Step 2) Create the file vhost.conf in this directory<br />
<br />
cd /usr/local/apache/conf/userdata/std/2/username/example.com<br />
<br />
touch vhost.conf<br />
<br />
Step 3) Add in the lines below to this file:<br />
<br />
<IfModule mod_security2.c><br />
SecRule REMOTE_ADDR "^1.2.3.4$" "phase:1,t:none,nolog,allow,ctl:ruleEngine=Off,ctl:auditEngine=Off,id:9999"<br />
</IfModule><br />
<br />
'''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.'''<br />
<br />
Step 4) Run the vhost includes script, for example if the domains username is "example":<br />
<br />
/scripts/ensure_vhost_includes –user=example<br />
<br />
==== Disable a rule for a single domain ====<br />
<br />
'''If you have ASL installed''':<br />
<br />
Method 1:<br />
<br />
Log into the ASL GUI, and click on the "ASL" tab. Then click "WAF & HIDS Rules", 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.<br />
<br />
Type in the hostname into the Text box on the left side of the options you want to exclude the rule for, then click "add".<br />
<br />
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, or a regular expression *.example.com.<br />
<br />
Note: You can use regular expressions in this field, but each end of the expression is anchored.<br />
<br />
<br />
Method 2: Run this command as root:<br />
<br />
In ASL v3.x:<br />
asl -dr RULE_ID --vhost www.example.com<br />
<br />
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:<br />
<br />
asl -dr RULE_ID --vhost www.example.com<br />
<br />
asl -dr RULE_ID --vhost ftp.example.com<br />
<br />
asl -dr RULE_ID --vhost example.com<br />
<br />
<br />
In ASL v4:<br />
asl -drv RULE_ID[,RULE_ID...] VHOST[,VHOST...]<br />
or <br />
asl --disable-rule-vhost RULE_ID[,RULE_ID...] VHOST[,VHOST...]<br />
<br />
All supplied rules will be disabled on all supplied vhosts.<br />
<br />
asl -drv 111111,222222,333333 www.example.com,ftp.example.com,example.com<br />
<br />
<br />
<br />
<br />
'''If you do not have ASL installed''' you will have to do this manually:<br />
<br />
Step 1) Edit your domains vhost.conf file (the location of this file will vary based on your control panel, contact your control panel vendor for assistance)<br />
<br />
vim vhost.conf<br />
<br />
Step 2) Add the LocationMatch for the rule to exclude. Example, ruleid 950005<br />
<LocationMatch .*><br />
<IfModule mod_security2.c><br />
SecRuleRemoveById 950005<br />
</IfModule><br />
</LocationMatch><br />
<br />
If you want to disable multiple rules:<br />
<br />
Step 2) Add the LocationMatch for the rule to exclude. Example, ruleids 950005 and 950006<br />
<LocationMatch .*><br />
<IfModule mod_security2.c><br />
SecRuleRemoveById 950005<br />
SecRuleRemoveById 950006<br />
</IfModule><br />
</LocationMatch><br />
<br />
<br />
==== Non Control Panel systems ====<br />
<br />
For nginx, or phase:1 rules rules can be disabled for a domain/FQDN by adding a custom rule before the rule you wish to disable is loaded. For example, if you wanted to disable rule 123456 for domain example.com, you would add this rule to your custom rules:<br />
<br />
SecRule REQUEST_HEADERS:Host "example.com$" "phase:1,id:91001,t:none,t:lowercase,pass,nolog,noauditlog,ctl:ruleRemovebyID=123456"<br />
<br />
This method can also be used for Apache.<br />
<br />
==== Disable a rule for all domains ====<br />
<br />
Method 1:<br />
<br />
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.<br />
<br />
Set "disabled" to yes and click update.<br />
<br />
Method 2:<br />
<br />
Use ASL utility to disable rule by ID. Example: 950005<br />
asl --disable-rule 950005<br />
<br />
Note: This requires that [[Atomic Secured Linux]] be installed.<br />
'''<br />
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:<br />
<br />
<LocationMatch .*><br />
<IfModule mod_security2.c><br />
SecRuleRemoveById 340000<br />
</IfModule><br />
</LocationMatch><br />
<br />
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.<br />
<br />
=== Per IP or network ===<br />
<br />
==== Disable Mod_security for an IP address ====<br />
<br />
In ASL, just click the "Whitelist" button.<br />
<br />
If you are not using ASL, simply add your IP address to the file:<br />
<br />
/etc/asl/whitelist<br />
<br />
And restart Apache.<br />
<br />
Note: For this rule to work, in ASL you must have the MODSEC_00_WHITELIST ruleset enabled.<br />
<br />
If you are not using ASL, then you must have the 00_asl_whitelist.conf ruleset loaded.<br />
<br />
==== Whitelist an IP ====<br />
<br />
See above, "Disable Mod_security for an IP address"<br />
<br />
==== Disable a rule by IP or network====<br />
<br />
You will need to create a custom rule, loaded after all your other rules. Lets say you wanted to exclude rule id 330039 for the network 1.2.0.0/16. You would construct a custom rule like this:<br />
<br />
<pre><br />
SecRule REMOTE_HOST "@ipmatch 1.2.0.0/16" \<br />
"id:12345,phase:2,t:none,pass,nolog,noauditlog,ctl:ruleRemovebyID=330039"<br />
</pre><br />
<br />
Note: ipmatch can also use a list, with a combination of IPs and network for example:<br />
<br />
@ipmatch 1.2.0.0/16,5.6.7.8,127.0.0.0/8<br />
<br />
Warning: If the CIDR is invalid, this may cause a segfault of the mod_security module. Check to make sure your CIDR is valid before use.<br />
<br />
=== Per application ===<br />
<br />
==== Disable modsecurity for a specific web application ====<br />
<br />
Note: this is not recommended<br />
<br />
Add a custom rule (see the section below on creating [https://www.atomicorp.com/wiki/index.php/Mod_security#Creating_custom_rules custom rules]) after all your rules have been loaded. For example, if you wanted to disable modsecurity for the application /foo/bar.cgi you would add a custom rule like this:<br />
<br />
<pre><br />
<LocationMatch /foo/bar.cgi><br />
SecRuleEngine Off<br />
<br />
</LocationMatch><br />
</pre><br />
<br />
<br />
<br />
==== Disable a rule for a specific web application ====<br />
Add a custom rule (see the section below on creating [https://www.atomicorp.com/wiki/index.php/Mod_security#Creating_custom_rules custom rules]) after all your rules have been loaded. For example, if you wanted to disable rule 950005, you would add a custom rule like this:<br />
<br />
<pre><br />
<LocationMatch /URL/path/to/application.php><br />
SecRuleRemoveById 950005<br />
<br />
</LocationMatch><br />
</pre><br />
<br />
==== Disable a rule for a single domain or FQDN ====<br />
<br />
===== For non control panel systems =====<br />
<br />
If you are using any of our GUI products, just click on the rule event, and type in the domain or hostname you want to exclude for this rule. <br />
<br />
For DIY users, you will need to create custom rules that load *before* the rule that you wish to exclude. This means you will need to add a custom rule file that loads before the rules we supply.<br />
<br />
Once you have set this up for your DIY modsecurity configuration, you will add a rule that inspects the Host: header sent by the client, which will the disable the rule(s) you wish to disable when that field is populated by that value. Keep in mind this field is completely controlled by the client, not the server. In the example below, the entire domain "example.com" is excluded for rule 123456:<br />
<br />
''SecRule REQUEST_HEADERS:Host ".example.com$" "phase:1,id:91010,t:none,t:lowercase,pass,nolog,noauditlog,ctl:ruleRemovebyID=123456"''<br />
<br />
Then restart the web server to apply this custom exclusion.<br />
<br />
===== For Plesk systems =====<br />
<br />
<br />
Step 1) Edit the virtual servers configuration for the domain for the domain<br />
<br />
Example:<br />
<br />
vim /var/www/vhosts/<DOMAINNAME>/conf/vhost.conf<br />
<br />
Step 2) Add the LocationMatch for the rule to exclude. Example, ruleid 950005<br />
<br />
<pre><br />
<LocationMatch /URL/path/to/application.php><br />
<br />
SecRuleRemoveById 950005<br />
</IfModule><br />
<br />
</pre><br />
<br />
==== Disable Mod_security rules globally for a specific application ====<br />
<br />
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.<br />
<br />
<LocationMatch /url/to/your/application><br />
<IfModule mod_security2.c><br />
SecRuleRemoveById 1234567<br />
SecRuleRemoveById 9999999<br />
</IfModule><br />
</LocationMatch><br />
<br />
Whats important to remember is that the LocationMatch variable must match the URL, not the path on the system.<br />
<br />
==== Disable Mod_security rules by domain, for a specific application, for a list of IPs ====<br />
<br />
Step 1) Edit the vhost/vhost_ssl.conf for the domain<br />
vim /var/www/vhosts/<DOMAINNAME>/conf/vhost.conf<br />
<br />
Step 2) Add the LocationMatch for the rule to exclude.<br />
<LocationMatch /foo/bar.php><br />
<IfModule mod_security2.c><br />
SecRule REMOTE_ADDR "@pmFromFile /etc/asl/whitelist" "nolog,phase:1,allow"<br />
</IfModule><br />
</LocationMatch><br />
<br />
Step 3) Add IP to /etc/asl/whitelist<br />
echo "10.11.12.13" >> /etc/asl/whitelist<br />
<br />
Or:<br />
<br />
If you want to create a special whitelist for just that application:<br />
<br />
Step 1) Edit the vhost/vhost_ssl.conf for the domain<br />
vim /var/www/vhosts/<DOMAINNAME>/conf/vhost.conf<br />
<br />
Step 2) Add the LocationMatch for the rule to exclude.<br />
<LocationMatch /foo/bar.php><br />
<IfModule mod_security2.c><br />
SecRule REMOTE_ADDR "@pmFromFile /path/to/your/custom/whitelist_for_this_application" "nolog,phase:1,allow,id:9999"<br />
</IfModule><br />
</LocationMatch><br />
<br />
'''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.'''<br />
<br />
<br />
Step 3) Create your custom whitelist and add IP to /etc/asl/whitelist<br />
echo "10.11.12.13" >> /path/to/your/custom/whitelist_for_this_application<br />
<br />
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.<br />
<br />
==== Disable rule for a specific argument for a specific application ====<br />
<br />
You can also tell modsecurity to change a rule, in some cases, without editing or forking the rule. For example, if you want to configure modsecurity to ignore a specific argument (in the argument below the argument is "foo"), for a specific application (in the example the application name is /example/application), for a specific rule (in the example below the rule if is 12345), you would create a custom rule like this:<br />
<br />
<br />
<pre><br />
SecRule REQUEST_URI "^/example/application" \<br />
"id:9999,phase:1,t:none,t:lowercase,nolog,pass,ctl:ruleRemoveTargetByID=12345;ARGS:foo"<br />
</pre><br />
<br />
As with all custom rules, this rule also needs a unique id as explained in the article above. And this type of custom rule must be loaded '''before''' the rule it modifies.<br />
<br />
Note: This does not support regular expressions for the excluded argument. At this time, they must be explicitly defined.<br />
<br />
==== Disable rule for a specific argument ====<br />
<br />
As is the example above, a rule can also be changed to exclude a specific argument, but for all applications. For example, if you want to configure modsecurity to ignore a specific argument (in the argument below the argument is "foo"), for a specific rule (in the example below the rule if is 12345), you would create a custom rule like this:<br />
<br />
<pre><br />
SecAction "phase:1,id:9999,t:none,auditlog,nolog,pass,ctl:ruleRemoveTargetById=12345;ARGS:foo"<br />
</pre><br />
<br />
As with all custom rules, this rule also needs a unique id as explained in the article above. And this type of custom rule must be loaded '''before''' the rule it modifies.<br />
<br />
Note: This does not support regular expressions for the excluded argument. At this time, they must be explicitly defined.<br />
<br />
==== Disable modsecurity for a specific argument ====<br />
<br />
As is the example above, modsecurity can also be configured to exclude a specific argument for all rules. For example, if you want to configure modsecurity to ignore a specific argument (in the argument below the argument is "foo"),you would create a custom rule like this:<br />
<br />
<pre><br />
SecAction "phase:1,id:9999,t:none,auditlog,nolog,pass,ctl:ruleRemoveTargetById=1-1000000;ARGS:foo"<br />
</pre><br />
<br />
When 1-100000 is the rule IDs you want to exclude. As with all custom rules, this rule also needs a unique id as explained in the article above. <br />
<br />
Note: This does not support regular expressions for the excluded argument. At this time, they must be explicitly defined.<br />
<br />
== Changing the action for a rule ==<br />
<br />
You can also change the default action for a rule by using the SecRuleActionById directive. <br />
<br />
=== Changing a rule to be detect only by ID===<br />
<br />
To change a rule to only detect, but not block attacks, simply change the action for the rule with the above directive. For example, to change the action for rule 12345, simply add this rule directive to your custom rules. <br />
<br />
SecRuleUpdateActionById 12345 "pass,status:200"<br />
<br />
Note 1: this directive must be added after the rule it is modifying has been loaded.<br />
<br />
Note 2: This does not work if you are using the redirect action.<br />
<br />
=== Changing a range of rules to be detect only by ID===<br />
<br />
This is similar to the method above, however you can define a range of rule IDs. For example, if you want to disable rules 1000-2000:<br />
<br />
SecRuleUpdateActionById 1000-2000 "pass,status:200"<br />
<br />
Note 1: this directive must be added after the rule it is modifying has been loaded.<br />
<br />
Note 2: This does not work if you are using the redirect action.<br />
<br />
== Disabling POST inspection for a specific URL ==<br />
<br />
Should you want to disable inspection of a POST for a specific URL, use the format below.<br />
<br />
Assuming the URL you wanted to skip POST inspection was "upload", your exclusion rule would look like this:<br />
<br />
''SecRule REQUEST_URI "^/upload" \<br />
"phase:1,id:1234567,t:none,t:lowercase,pass,nolog,ctl:requestBodyAccess=off"''<br />
<br />
Install this rule before any of your other rules. For example, in the file /etc/httpd/modsecurity.d/00_custom_exclude.conf.<br />
<br />
== Enabling rules for only specific domains ==<br />
<br />
If you wish to disable all the rules, except for specific domains, you need to copy in the two files from the subdirectory "special" where you have the rules installed. Then create this file:<br />
<br />
/etc/asl/custom_include_domains<br />
<br />
<br />
Include the domains and/or FQDNs you want the rules to apply to. Anything not on that list will cause those rules to skip all of our rules. <br />
<br />
#File must contain exactly one domain or FQDN per line. End of line markers (both LF and CRLF) will be stripped from each phrase and any whitespace trimmed from both the beginning and the end. Empty lines and comment lines (those beginning with the # character) will be ignored.<br />
#This file does not support metacharacters. (For example, * is not supported)<br />
<br />
Example:<br />
<br />
<br />
<pre><br />
www.example.com<br />
.foo.com<br />
</pre><br />
<br />
== Disabling rules using .htaccess ==<br />
<br />
This is a new feature in modsecurity 2.7.3. This capability is available if you compile modsecurity using this option:<br />
<br />
--enable-htaccess-config<br />
<br />
From there, you will be able to disable rules using .htaccess files. The format to disable a rule via .htaccess is:<br />
<br />
SecRuleRemoveById 12345<br />
<br />
Where 12345 is the rule id.<br />
<br />
'''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 and/or this option has not been enabled. <br />
<br />
Warning: Enabling this capability will allow users to disable rules, including on compromised accounts which may cause the system to become compromised. This capability was specifically disabled by default in modsecurity to prevent this from occurring. Use this option with extreme caution!<br />
<br />
=== Specific actions available in .htaccess ===<br />
<br />
<br />
* SecAction<br />
* SecRule<br />
* SecRuleRemoveByMsg<br />
* SecRuleRemoveByTag<br />
* SecRuleRemoveById<br />
* SecRuleUpdateActionById<br />
* SecRuleUpdateTargetById<br />
* SecRuleUpdateTargetByTag<br />
* SecRuleUpdateTargetByMsg<br />
<br />
'''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.<br />
<br />
Warning: Enabling this capability in modsecurity can allow an attacker to disable modsecurity rules that you may be using to protect the entire server. We do not recommend you enable this capability on a shared server.<br />
<br />
== Customizing a rule ==<br />
<br />
If you need to customize a rule do not change the asl*conf files. These files will be overwritten by updates. <br />
<br />
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.<br />
<br />
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:<br />
<br />
If you had an original rule like this:<br />
<br />
SecRule REQUEST_URI "/foo" "t:normalisePath,id:9000,rev:1,severity:2,msg:'Atomicorp.com WAF Rules: Block /foo'"<br />
<br />
<br />
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.<br />
<br />
SecRuleRemoveById 9000000<br />
SecRule REQUEST_URI "/bar" "t:normalisePath,id:9999,rev:1,severity:2,msg:'Atomicorp.com WAF Rules: Block /foo'"<br />
<br />
'''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.'''<br />
<br />
<br />
These are the reserved ranges:<br />
<br />
* 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.<br />
* 100,000-199,999; reserved for internal use of the engine, to assign to rules that do not have explicit IDs.<br />
* 200,000-299,999; reserved for rules published at modsecurity.org.<br />
* 300,000-399,999; reserved for rules published at gotroot.com.<br />
* 400,000-419,999; unused (available for reservation).<br />
* 420,000-429,999; reserved for ScallyWhack.<br />
* 430,000-699,999; unused (available for reservation).<br />
* 700,000-799,999; reserved for Ivan Ristic.<br />
* 900,000-999,999; reserved for the Core Rules project.<br />
* 1,000,000 and above; unused (available for reservation).<br />
<br />
=== For a domain ===<br />
<br />
==== Apache ====<br />
<br />
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.<br />
<br />
==== Changing the argument separator ====<br />
<br />
If you have a web application that uses the uncommon ";" argument separator, as opposed to the widely used "&" you will want to change SecArgumentSeparator value for that application. You can do this in one of two ways:<br />
<br />
1) Globally<br />
<br />
If all your applications use the older delimiter, just change the SecArgumentSeparator in the tortix_waf.conf file. Do not change this if your applications use other delimiters.<br />
<br />
''SecArgumentSeparator ";"'' <br />
<br />
2) Per Application<br />
<br />
You can also configure this per application. For example, if your web applications URL is /foo/bar.php you can create a customer rule like this:<br />
<br />
<br />
<pre><br />
<LocationMatch /foo/bar.php><br />
SecArgumentSeparator ";"<br />
</LocationMatch><br />
</pre><br />
<br />
This will only work if modsecurity is loaded before your virtual host definitions. This is the case with most control panels, but some control panels are known to load modsecurity after vhosts are defined. In which case this will fail because Apache will not know how to process this directive (it will need modsecurity loaded to understand what this means). If you get a syntax error, that means your apache configuration is loaded modsecurity after your vhosts are defined. You will need to change your apache configuration to ensure this loading occurs before vhosts are defined.<br />
<br />
[[ASL]] will automatically configure modsecurity to load first.<br />
<br />
= Creating custom rules =<br />
<br />
== Discussion ==<br />
<br />
If you need to create your own custom rules, do not change the asl*conf files. These files will be overwritten by updates. <br />
<br />
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.<br />
<br />
== Rule Ids for custom rules ==<br />
<br />
For custom rules, '''you must create your own rule ids which must be unique'''. The id: fields contain the rule ids. For custom rules you should use the local (internal) use range (see below for the reserved id ranges). '''Do not use assigned ranges.'''<br />
<br />
These are the reserved ranges:<br />
<br />
* 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.<br />
* 100,000-199,999; reserved for internal use of the engine, to assign to rules that do not have explicit IDs. (deprecated, all rules require assigned ids in 2.7.x and up)<br />
* 200,000-299,999; reserved for rules published at modsecurity.org.<br />
* 300,000-399,999; reserved for rules published by atomicorp.com<br />
* 400,000-419,999; unused (available for reservation).<br />
* 420,000-429,999; reserved for ScallyWhack.<br />
* 430,000-699,999; unused (available for reservation).<br />
* 700,000-799,999; reserved for Ivan Ristic.<br />
* 900,000-999,999; reserved for the Core Rules project.<br />
* 1,000,000 and above; unused (available for reservation).<br />
<br />
== Installing custom rules ==<br />
<br />
<br />
=== Linux ===<br />
<br />
==== Apache ====<br />
<br />
'''Step 1) Create your custom rules directory:'''<br />
<br />
''mkdir /etc/httpd/modsecurity.custom.d''<br />
<br />
'''Step 2) Create a configuration file for your custom rules in /etc/httpd/conf.d directory. For example:'''<br />
<br />
Create the file 01_modsecurity.conf and add this line to it:<br />
<br />
''Include modsecurity.custom.d/[https://www.atomicorp.com/examples/99_zzz_custom.conf 99_zzz_custom.conf]''<br />
<br />
You can download an example file from the URL below that will do this:<br />
<br />
[https://www.atomicorp.com/examples/01_modsecurity.conf 01_modsecurity.conf]<br />
<br />
And add 01_modsecurity.conf to this directory:<br />
<br />
/etc/httpd/conf.d<br />
<br />
If you have wget installed on your system, the following commands will do this automatically for you:<br />
''<br />
<br />
cd /etc/httpd/conf.d<br />
<br />
wget https://www.atomicorp.com/examples/01_modsecurity.conf''<br />
<br />
Note: 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. Please contact your control panel vendor for assistance.<br />
<br />
'''Step 3) Install your custom rules in the /etc/httpd/modsecurity.custom.d directory'''<br />
<br />
''cd /etc/httpd/modsecurity.custom.d''<br />
<br />
and edit the file 99_zzz_custom.conf and put in your custom rules.<br />
<br />
You can also download an example custom rule file by running these commands:<br />
<br />
''cd /etc/httpd/modsecurity.custom.d<br />
<br />
wget https://www.atomicorp.com/examples/99_zzz_custom.conf''<br />
<br />
'''Step 4) Test your apache configuration'''<br />
<br />
''service httpd configtest''<br />
<br />
If you have any errors, do not restart apache. You will need to correct these errors or apache will not start.<br />
<br />
'''Step 5) If your test was successful, restart apache.'''<br />
<br />
''service httpd restart''<br />
<br />
Our professional services group would be happy to help you with your custom rules needs, including developing the rules for you. If your request is something that we can safely include in the rules for all our customers, we're generally able to develop these new rules for free. Please contact us to discuss your rules needs.<br />
<br />
=== Windows ===<br />
<br />
==== IIS ====<br />
<br />
'''Step 1) Modify your modsecurity configuration file on windows and add this line to the end of your configuration. For example:'''<br />
<br />
''Include [https://www.atomicorp.com/examples/99_zzz_custom.conf 99_zzz_custom.conf]''<br />
<br />
'''Step 2) Edit the file 99_zzz_custom.conf and save it in the same directory as your modsecurity config file'''<br />
<br />
'''Step 3)Restart IIS'''<br />
<br />
<br />
Our professional services group would be happy to help you with your custom rules needs, including developing the rules for you. If your request is something that we can safely include in the rules for all our customers, we're generally able to develop these new rules for free. Please contact us to discuss your rules needs.<br />
<br />
== Modifying a rule ==<br />
<br />
If you want to modify the internal logic of a rule, you will want to "fork" or copy that rule into a custom rule. Do not modify the actual rules provided by us, your modifications will be overwritten with the next update.<br />
<br />
'''Step 1: Copy the rule you want to modify into your custom rules file.'''<br />
<br />
Copy the rule in its entirety into your custom rule file. For example, if you wanted to modify rule 390707, you would copy the entire rule into your custom rules file. For example:<br />
<br />
<pre><br />
# Restrict the maximum number of arguments in a request<br />
SecRule &ARGS "@gt 1000" \<br />
"chain,phase:2,t:none,log,auditlog,deny,status:403,msg:'Atomicorp.com WAF Rules: Too many arguments in request (max set to 1000, increase as necessary for your system)',id:'390707',severity:'4',rev:'8'"<br />
SecRule REQUEST_URI "!((?:^/(?:imaclean|massdelete)/)|^/cgi-bin/dada/mail\.cgi$|^/index\.php/mageworx/customoptions_options|^/za/|^/back-?office/|^/moderate\.php|^/backend/configdomains\.php|\.do$|^/admin[a-z0-9]+?/index\.php\?controller=adminmodules)" "t:none,t:lowercase"<br />
</pre><br />
<br />
'''Step 2: Change the rule id.''' <br />
<br />
This is absolutely required. No two rules can have the same ID. See this article for chosing a custom rule id: https://wiki.atomicorp.com/wiki/index.php/Mod_security#Rule_Ids_for_custom_rules<br />
<br />
For example:<br />
<br />
<pre><br />
# Restrict the maximum number of arguments in a request<br />
SecRule &ARGS "@gt 1000" \<br />
"chain,phase:2,t:none,log,auditlog,deny,status:403,msg:'Atomicorp.com WAF Rules: Too many arguments in request (max set to 1000, increase as necessary for your system)',id:'12345678',severity:'4',rev:'8'"<br />
SecRule REQUEST_URI "!((?:^/(?:imaclean|massdelete)/)|^/cgi-bin/dada/mail\.cgi$|^/index\.php/mageworx/customoptions_options|^/za/|^/back-?office/|^/moderate\.php|^/backend/configdomains\.php|\.do$|^/admin[a-z0-9]+?/index\.php\?controller=adminmodules)" "t:none,t:lowercase"<br />
</pre><br />
<br />
'''Step 3: Disable the original rule'''<br />
<br />
If you want your custom rule to be global, that is your modification applies to the entire system, then you will want to disable the original rule per this article:<br />
<br />
https://wiki.atomicorp.com/wiki/index.php/Mod_security#Disable_a_rule_for_all_domains<br />
<br />
If you want to disable the rule for a single application, see this article:<br />
<br />
https://wiki.atomicorp.com/wiki/index.php/Mod_security#Disable_a_rule_for_a_specific_web_application<br />
<br />
If you want to disable the rule for a specific IP or network:<br />
<br />
https://wiki.atomicorp.com/wiki/index.php/Mod_security#Disable_a_rule_by_IP_or_network<br />
<br />
If you want to disable the rule for a single domain:<br />
<br />
https://wiki.atomicorp.com/wiki/index.php/Mod_security#Disable_a_rule_for_a_single_domain<br />
<br />
'''Step 4: Set the scope of the rule.'''<br />
<br />
If you havent disabled the original rule globally, or for one or more domains, then you will need to set the scope of your custom rule. To limit your modification to a specific application, place your custom rule inside <LocationMatch> tags. For example:<br />
<br />
<pre><br />
<br />
<LocationMatch /url/to/your/custom/application><br />
# Restrict the maximum number of arguments in a request<br />
SecRule &ARGS "@gt 2048" \<br />
"chain,phase:2,t:none,log,auditlog,deny,status:403,msg:'Atomicorp.com WAF Rules: Too many arguments in request (max set to 1000, increase as necessary for your system)',id:'12345678',severity:'4',rev:'8'"<br />
SecRule REQUEST_URI "!((?:^/(?:imaclean|massdelete)/)|^/cgi-bin/dada/mail\.cgi$|^/index\.php/mageworx/customoptions_options|^/za/|^/back-?office/|^/moderate\.php|^/backend/configdomains\.php|\.do$|^/admin[a-z0-9]+?/index\.php\?controller=adminmodules)" "t:none,t:lowercase"<br />
</LocationMatch><br />
<br />
</pre><br />
<br />
= Configuring and Setting up mod_security =<br />
'''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.'''<br />
<br />
To setup and configured modsecurity, please see the [[Atomic_ModSecurity_Rules]] wiki page.</div>Mshinnhttps://wiki.atomicorp.com/wiki/index.php/Mod_securityMod security2023-11-17T20:45:44Z<p>Mshinn: /* For Plesk based systems */</p>
<hr />
<div>=Installing modsecurity Rules =<br />
<br />
Please see this article:<br />
<br />
[[Atomic ModSecurity Rules]]<br />
<br />
=Tuning and managing modsecurity Rules=<br />
<br />
== Disabling Rules ==<br />
<br />
=== Important Notes ===<br />
<br />
==== phase:1 rules ====<br />
<br />
Note: ASL/AWP/AEO users should disable rules from the rule manager. There is no need to create custom rules, apache configuration files or other customizations when using ASL/AWP/AEO, and ASL/AWP/AEO supports disabling any rule on both a global and per domain basis.<br />
<br />
For non-ASL users, LocationMatch and Location do not work for phase:1 rules. Location and LocationMatch are not available in apache until phase:2. If you need to disable a phase:1 rule, use ASL/AWP/AEO which can disable phase:1 rules on a per domain and global basis.<br />
<br />
<br />
If you are not using ASL/AWP/AEO, and need to disable a phase:1 rule, you will need to create a custom rule to do this. This following is an example of a custom rule to do this for rule 123456.<br />
<br />
<br />
''SecRule REQUEST_HEADERS:Host "example.com$" "phase:1,id:91001,t:none,t:lowercase,pass,nolog,noauditlog,ctl:ruleRemovebyID=123456"''<br />
<br />
<br />
In the example above, "example.com" is the domain to exclude this rule. This custom rule must be loaded before the rule you want to disable. This custom rule *must be loaded before the rule you wish to disable*.<br />
<br />
If you do not know how to create this kind of custom rule, please contact support and we'll put a quote together to help develop these custom rules for you.<br />
<br />
=== Global ===<br />
<br />
==== Disabling Mod_Security Globally ====<br />
<br />
If you are using ASL, just change this setting:<br />
<br />
https://www.atomicorp.com/wiki/index.php/ASL_WAF#MODSEC_ENABLED<br />
<br />
If you are not using ASL, you will need to do this manually:<br />
<br />
Step 1) Disable config file<br />
mv /etc/httpd/conf.d/00_mod_security.conf /etc/httpd/conf.d/00_mod_security.conf.disabled<br />
<br />
Step 2) Restart Apache<br />
service httpd restart<br />
<br />
==== Disable Mod_security on a global URL ====<br />
<br />
Step 1) Create a global exclude file<br />
<br />
vim /etc/httpd/modsecurity.d/00_custom_exclude.conf<br />
<br />
Step 2) Add the LocationMatch for the url to exclude. Example: /server.php<br />
<br />
<LocationMatch /server.php><br />
<IfModule mod_security2.c><br />
SecRuleEngine Off <br />
</IfModule><br />
</LocationMatch><br />
<br />
Step 3) Restart apache<br />
<br />
service httpd restart<br />
<br />
<br />
<br />
Step 3) Restart apache<br />
<br />
service httpd restart<br />
<br />
==== Set a URL to alert only ====<br />
<br />
Step 1) Create a global exclude file<br />
<br />
vim /etc/httpd/modsecurity.d/00000_custom_exclude.conf<br />
<br />
Step 2) Add a custom rule<br />
<br />
In this example the URL is: /foo/bar<br />
<br />
Add this line to the file you created in Step 1:<br />
<br />
SecRule REQUEST_URI "/foo/bar" "phase:1,id:1000000,t:none,t:lowercase,pass,nolog,noauditlog,ctl:ruleEngine=DetectionOnly"<br />
<br />
Important Note: See the section customizing rules below to pick a unique id for your rule above. Duplicate rule ids will cause the rule to not load.<br />
<br />
Step 3) Restart apache<br />
<br />
service httpd restart<br />
<br />
=== Per domain ===<br />
<br />
==== Disabling Mod_security per domain ====<br />
<br />
Note: If you only want to disable a specific rule for a domain, please see this article:<br />
<br />
https://wiki.atomicorp.com/wiki/index.php/Mod_security#Per_application<br />
<br />
===== For Plesk Based Systems =====<br />
<br />
For Plesk and similar systems you can also disable modsecurity in the Apache configuration.<br />
<br />
Step 1) Edit the vhost/vhost_ssl.conf for the domain<br />
vim /var/www/vhosts/<DOMAINNAME>/conf/vhost.conf<br />
<br />
Step 2) Add the following<br />
<IfModule mod_security2.c><br />
SecRuleEngine Off<br />
</IfModule><br />
<br />
Then restart apache, if you are using Plesk then you will also need follow steps 3 and 4.<br />
<br />
Step 3) Add vhost.conf to domain config <br />
<br />
Plesk 9:<br />
/usr/local/psa/admin/bin/websrvmng -a<br />
<br />
Plesk 10/11:<br />
/usr/local/psa/admin/bin/httpdmng --reconfigure-domain <domain_name><br />
<br />
Step 4) Restart Apache<br />
service httpd restart<br />
<br />
===== For Cpanel based systems with EasyApache 4 =====<br />
<br />
For full information about include file path expectations, see the official cPanel documentation at [https://documentation.cpanel.net/display/EA4/Modify+Apache+Virtual+Hosts+with+Include+Files Modify Apache Virtual Hosts with Include Files]<br />
<br />
Step 1) Create the following paths, replacing <user> and <domain> with the correct values for your needs:<br />
<br />
* mkdir -p /etc/apache2/conf.d/userdata/ssl/2_4/<user>/<domain><br />
* mkdir -p /etc/apache2/conf.d/userdata/std/2_4/<user>/<domain><br />
<br />
Step 2) In each of the above paths, create a file named 'vhost.conf'<br />
<br />
Step 3) Add in the lines below to this file:<br />
<br />
<pre><br />
<IfModule mod_security2.c><br />
SecRuleEngine Off<br />
</IfModule><br />
</pre><br />
<br />
Step 4) After any addition, modification or removal of userdata files, cPanel requires both of the following scripts to be run:<br />
<br />
* /usr/local/cpanel/scripts/rebuildhttpdconf<br />
* /usr/local/cpanel/scripts/restartsrv_httpd<br />
<br />
<br />
===== For Cpanel based systems with EasyApache 3 =====<br />
<br />
Step 1) Create the custom modsecurity configuration directory for the domain<br />
<br />
For example, if the domain is example.com, you would need to create this directory:<br />
<br />
<br />
mkdir /usr/local/apache/conf/userdata/std/2/username/example.com<br />
<br />
Step 2) Create the file vhost.conf in this directory<br />
<br />
cd /usr/local/apache/conf/userdata/std/2/username/example.com<br />
<br />
touch vhost.conf<br />
<br />
Step 3) Add in the lines below to this file:<br />
<br />
<pre><br />
<IfModule mod_security2.c><br />
SecRuleEngine Off<br />
</IfModule><br />
</pre><br />
<br />
Step 4) Run the vhost includes script, for example if the domains username is "example":<br />
<br />
/scripts/ensure_vhost_includes --user=example<br />
<br />
<br />
<br />
==== Disabling Mod_security per domain for an IP address ====<br />
<br />
===== For a list of IPs or CIDRs =====<br />
<br />
====== Linux ======<br />
<br />
To disable a specific rule for a specific IP or network range follow this process:<br />
<br />
Step 1. Create the file:<br />
<br />
/etc/custom_ips<br />
<br />
Step 2: Add IPs or CIDRs to the /etc/custom_ips file<br />
<br />
The format is one IP or CIDR per line, for example:<br />
<br />
1.2.3.4<br />
1.2.4.0/24<br />
<br />
Regular expressions are not supported. You must use either an IP address or a CIDR.<br />
<br />
Step 3. Add the following custom rule to your custom rules file:<br />
<br />
''SecRule REMOTE_ADDR ""@ipMatchFromFile /etc/customips" "id:1234,phase:1,t:none,nolog,pass,noauditlog,ctl:ruleRemovebyID=350000"''<br />
<br />
Note: Change the variable in the example above from 350000 to the rule ID you want to disable for these IPs.<br />
<br />
Step 4. Change the Rule ID.<br />
<br />
This is absolutely required. No two rules can have the same ID. See this article for chosing a custom rule id: https://wiki.atomicorp.com/wiki/index.php/Mod_security#Rule_Ids_for_custom_rules<br />
<br />
In the example above which is 1234, to a unique id that is not being used by your system. <br />
<br />
<br />
===== For Plesk based systems =====<br />
<br />
For Plesk and similar systems you can also disable modsecurity in the Apache configuration.<br />
<br />
Step 1) Edit the vhost/vhost_ssl.conf for the domain<br />
vim /var/www/vhosts/<DOMAINNAME>/conf/vhost.conf<br />
<br />
Step 2) Add the following<br />
<IfModule mod_security2.c><br />
SecRule REMOTE_ADDR "^1.2.3.4$" "phase:1,t:none,nolog,allow,ctl:ruleEngine=Off,ctl:auditEngine=Off,id:9999"<br />
</IfModule><br />
<br />
'''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.'''<br />
<br />
Then restart apache, if you are using Plesk then you will also need follow steps 3 and 4.<br />
<br />
Step 3) Add vhost.conf to domain config <br />
<br />
Plesk 9:<br />
/usr/local/psa/admin/bin/websrvmng -a<br />
<br />
Plesk 10/11:<br />
/usr/local/psa/admin/bin/httpdmng --reconfigure-domain <domain_name><br />
<br />
Step 4) Restart Apache<br />
service httpd restart<br />
<br />
===== For cpanel based systems =====<br />
<br />
Step 1) Create the custom modsecurity configuration directory for the domain<br />
<br />
For example, if the domain is example.com, you would need to create this directory:<br />
<br />
mkdir /usr/local/apache/conf/userdata/std/2/username/example.com<br />
<br />
Step 2) Create the file vhost.conf in this directory<br />
<br />
cd /usr/local/apache/conf/userdata/std/2/username/example.com<br />
<br />
touch vhost.conf<br />
<br />
Step 3) Add in the lines below to this file:<br />
<br />
<IfModule mod_security2.c><br />
SecRule REMOTE_ADDR "^1.2.3.4$" "phase:1,t:none,nolog,allow,ctl:ruleEngine=Off,ctl:auditEngine=Off,id:9999"<br />
</IfModule><br />
<br />
'''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.'''<br />
<br />
Step 4) Run the vhost includes script, for example if the domains username is "example":<br />
<br />
/scripts/ensure_vhost_includes –user=example<br />
<br />
==== Disable a rule for a single domain ====<br />
<br />
'''If you have ASL installed''':<br />
<br />
Method 1:<br />
<br />
Log into the ASL GUI, and click on the "ASL" tab. Then click "WAF & HIDS Rules", 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.<br />
<br />
Type in the hostname into the Text box on the left side of the options you want to exclude the rule for, then click "add".<br />
<br />
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, or a regular expression *.example.com.<br />
<br />
Note: You can use regular expressions in this field, but each end of the expression is anchored.<br />
<br />
<br />
Method 2: Run this command as root:<br />
<br />
In ASL v3.x:<br />
asl -dr RULE_ID --vhost www.example.com<br />
<br />
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:<br />
<br />
asl -dr RULE_ID --vhost www.example.com<br />
<br />
asl -dr RULE_ID --vhost ftp.example.com<br />
<br />
asl -dr RULE_ID --vhost example.com<br />
<br />
<br />
In ASL v4:<br />
asl -drv RULE_ID[,RULE_ID...] VHOST[,VHOST...]<br />
or <br />
asl --disable-rule-vhost RULE_ID[,RULE_ID...] VHOST[,VHOST...]<br />
<br />
All supplied rules will be disabled on all supplied vhosts.<br />
<br />
asl -drv 111111,222222,333333 www.example.com,ftp.example.com,example.com<br />
<br />
<br />
<br />
<br />
'''If you do not have ASL installed''' you will have to do this manually:<br />
<br />
Step 1) Edit your domains vhost.conf file (the location of this file will vary based on your control panel, contact your control panel vendor for assistance)<br />
<br />
vim vhost.conf<br />
<br />
Step 2) Add the LocationMatch for the rule to exclude. Example, ruleid 950005<br />
<LocationMatch .*><br />
<IfModule mod_security2.c><br />
SecRuleRemoveById 950005<br />
</IfModule><br />
</LocationMatch><br />
<br />
If you want to disable multiple rules:<br />
<br />
Step 2) Add the LocationMatch for the rule to exclude. Example, ruleids 950005 and 950006<br />
<LocationMatch .*><br />
<IfModule mod_security2.c><br />
SecRuleRemoveById 950005<br />
SecRuleRemoveById 950006<br />
</IfModule><br />
</LocationMatch><br />
<br />
<br />
==== Non Control Panel systems ====<br />
<br />
For nginx, or phase:1 rules rules can be disabled for a domain/FQDN by adding a custom rule before the rule you wish to disable is loaded. For example, if you wanted to disable rule 123456 for domain example.com, you would add this rule to your custom rules:<br />
<br />
SecRule REQUEST_HEADERS:Host "example.com$" "phase:1,id:91001,t:none,t:lowercase,pass,nolog,noauditlog,ctl:ruleRemovebyID=123456"<br />
<br />
This method can also be used for Apache.<br />
<br />
==== Disable a rule for all domains ====<br />
<br />
Method 1:<br />
<br />
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.<br />
<br />
Set "disabled" to yes and click update.<br />
<br />
Method 2:<br />
<br />
Use ASL utility to disable rule by ID. Example: 950005<br />
asl --disable-rule 950005<br />
<br />
Note: This requires that [[Atomic Secured Linux]] be installed.<br />
'''<br />
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:<br />
<br />
<LocationMatch .*><br />
<IfModule mod_security2.c><br />
SecRuleRemoveById 340000<br />
</IfModule><br />
</LocationMatch><br />
<br />
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.<br />
<br />
=== Per IP or network ===<br />
<br />
==== Disable Mod_security for an IP address ====<br />
<br />
In ASL, just click the "Whitelist" button.<br />
<br />
If you are not using ASL, simply add your IP address to the file:<br />
<br />
/etc/asl/whitelist<br />
<br />
And restart Apache.<br />
<br />
Note: For this rule to work, in ASL you must have the MODSEC_00_WHITELIST ruleset enabled.<br />
<br />
If you are not using ASL, then you must have the 00_asl_whitelist.conf ruleset loaded.<br />
<br />
==== Whitelist an IP ====<br />
<br />
See above, "Disable Mod_security for an IP address"<br />
<br />
==== Disable a rule by IP or network====<br />
<br />
You will need to create a custom rule, loaded after all your other rules. Lets say you wanted to exclude rule id 330039 for the network 1.2.0.0/16. You would construct a custom rule like this:<br />
<br />
<pre><br />
SecRule REMOTE_HOST "@ipmatch 1.2.0.0/16" \<br />
"id:12345,phase:2,t:none,pass,nolog,noauditlog,ctl:ruleRemovebyID=330039"<br />
</pre><br />
<br />
Note: ipmatch can also use a list, with a combination of IPs and network for example:<br />
<br />
@ipmatch 1.2.0.0/16,5.6.7.8,127.0.0.0/8<br />
<br />
Warning: If the CIDR is invalid, this may cause a segfault of the mod_security module. Check to make sure your CIDR is valid before use.<br />
<br />
=== Per application ===<br />
<br />
==== Disable modsecurity for a specific web application ====<br />
<br />
Note: this is not recommended<br />
<br />
Add a custom rule (see the section below on creating [https://www.atomicorp.com/wiki/index.php/Mod_security#Creating_custom_rules custom rules]) after all your rules have been loaded. For example, if you wanted to disable modsecurity for the application /foo/bar.cgi you would add a custom rule like this:<br />
<br />
<pre><br />
<LocationMatch /foo/bar.cgi><br />
SecRuleEngine Off<br />
<br />
</LocationMatch><br />
</pre><br />
<br />
<br />
<br />
==== Disable a rule for a specific web application ====<br />
Add a custom rule (see the section below on creating [https://www.atomicorp.com/wiki/index.php/Mod_security#Creating_custom_rules custom rules]) after all your rules have been loaded. For example, if you wanted to disable rule 950005, you would add a custom rule like this:<br />
<br />
<pre><br />
<LocationMatch /URL/path/to/application.php><br />
SecRuleRemoveById 950005<br />
<br />
</LocationMatch><br />
</pre><br />
<br />
==== Disable a rule for a single domain or FQDN ====<br />
<br />
===== For non control panel systems =====<br />
<br />
If you are using any of our GUI products, just click on the rule event, and type in the domain or hostname you want to exclude for this rule. <br />
<br />
For DIY users, you will need to create custom rules that load *before* the rule that you wish to exclude. This means you will need to add a custom rule file that loads before the rules we supply.<br />
<br />
Once you have set this up for your DIY modsecurity configuration, you will add a rule that inspects the Host: header sent by the client, which will the disable the rule(s) you wish to disable when that field is populated by that value. Keep in mind this field is completely controlled by the client, not the server. In the example below, the entire domain "example.com" is excluded for rule 123456:<br />
<br />
''SecRule REQUEST_HEADERS:Host ".example.com$" "phase:1,id:91010,t:none,t:lowercase,pass,nolog,noauditlog,ctl:ruleRemovebyID=123456"''<br />
<br />
Then restart the web server to apply this custom exclusion.<br />
<br />
===== For Plesk systems =====<br />
<br />
<br />
Step 1) Edit the virtual servers configuration for the domain for the domain<br />
<br />
Example:<br />
<br />
vim /var/www/vhosts/<DOMAINNAME>/conf/vhost.conf<br />
<br />
Step 2) Add the LocationMatch for the rule to exclude. Example, ruleid 950005<br />
<br />
<pre><br />
<LocationMatch /URL/path/to/application.php><br />
<br />
SecRuleRemoveById 950005<br />
</IfModule><br />
<br />
</pre><br />
<br />
==== Disable Mod_security rules globally for a specific application ====<br />
<br />
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.<br />
<br />
<LocationMatch /url/to/your/application><br />
<IfModule mod_security2.c><br />
SecRuleRemoveById 1234567<br />
SecRuleRemoveById 9999999<br />
</IfModule><br />
</LocationMatch><br />
<br />
Whats important to remember is that the LocationMatch variable must match the URL, not the path on the system.<br />
<br />
==== Disable Mod_security rules by domain, for a specific application, for a list of IPs ====<br />
<br />
Step 1) Edit the vhost/vhost_ssl.conf for the domain<br />
vim /var/www/vhosts/<DOMAINNAME>/conf/vhost.conf<br />
<br />
Step 2) Add the LocationMatch for the rule to exclude.<br />
<LocationMatch /foo/bar.php><br />
<IfModule mod_security2.c><br />
SecRule REMOTE_ADDR "@pmFromFile /etc/asl/whitelist" "nolog,phase:1,allow"<br />
</IfModule><br />
</LocationMatch><br />
<br />
Step 3) Add IP to /etc/asl/whitelist<br />
echo "10.11.12.13" >> /etc/asl/whitelist<br />
<br />
Or:<br />
<br />
If you want to create a special whitelist for just that application:<br />
<br />
Step 1) Edit the vhost/vhost_ssl.conf for the domain<br />
vim /var/www/vhosts/<DOMAINNAME>/conf/vhost.conf<br />
<br />
Step 2) Add the LocationMatch for the rule to exclude.<br />
<LocationMatch /foo/bar.php><br />
<IfModule mod_security2.c><br />
SecRule REMOTE_ADDR "@pmFromFile /path/to/your/custom/whitelist_for_this_application" "nolog,phase:1,allow,id:9999"<br />
</IfModule><br />
</LocationMatch><br />
<br />
'''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.'''<br />
<br />
<br />
Step 3) Create your custom whitelist and add IP to /etc/asl/whitelist<br />
echo "10.11.12.13" >> /path/to/your/custom/whitelist_for_this_application<br />
<br />
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.<br />
<br />
==== Disable rule for a specific argument for a specific application ====<br />
<br />
You can also tell modsecurity to change a rule, in some cases, without editing or forking the rule. For example, if you want to configure modsecurity to ignore a specific argument (in the argument below the argument is "foo"), for a specific application (in the example the application name is /example/application), for a specific rule (in the example below the rule if is 12345), you would create a custom rule like this:<br />
<br />
<br />
<pre><br />
SecRule REQUEST_URI "^/example/application" \<br />
"id:9999,phase:1,t:none,t:lowercase,nolog,pass,ctl:ruleRemoveTargetByID=12345;ARGS:foo"<br />
</pre><br />
<br />
As with all custom rules, this rule also needs a unique id as explained in the article above. And this type of custom rule must be loaded '''before''' the rule it modifies.<br />
<br />
Note: This does not support regular expressions for the excluded argument. At this time, they must be explicitly defined.<br />
<br />
==== Disable rule for a specific argument ====<br />
<br />
As is the example above, a rule can also be changed to exclude a specific argument, but for all applications. For example, if you want to configure modsecurity to ignore a specific argument (in the argument below the argument is "foo"), for a specific rule (in the example below the rule if is 12345), you would create a custom rule like this:<br />
<br />
<pre><br />
SecAction "phase:1,id:9999,t:none,auditlog,nolog,pass,ctl:ruleRemoveTargetById=12345;ARGS:foo"<br />
</pre><br />
<br />
As with all custom rules, this rule also needs a unique id as explained in the article above. And this type of custom rule must be loaded '''before''' the rule it modifies.<br />
<br />
Note: This does not support regular expressions for the excluded argument. At this time, they must be explicitly defined.<br />
<br />
==== Disable modsecurity for a specific argument ====<br />
<br />
As is the example above, modsecurity can also be configured to exclude a specific argument for all rules. For example, if you want to configure modsecurity to ignore a specific argument (in the argument below the argument is "foo"),you would create a custom rule like this:<br />
<br />
<pre><br />
SecAction "phase:1,id:9999,t:none,auditlog,nolog,pass,ctl:ruleRemoveTargetById=1-1000000;ARGS:foo"<br />
</pre><br />
<br />
When 1-100000 is the rule IDs you want to exclude. As with all custom rules, this rule also needs a unique id as explained in the article above. <br />
<br />
Note: This does not support regular expressions for the excluded argument. At this time, they must be explicitly defined.<br />
<br />
== Changing the action for a rule ==<br />
<br />
You can also change the default action for a rule by using the SecRuleActionById directive. <br />
<br />
=== Changing a rule to be detect only by ID===<br />
<br />
To change a rule to only detect, but not block attacks, simply change the action for the rule with the above directive. For example, to change the action for rule 12345, simply add this rule directive to your custom rules. <br />
<br />
SecRuleUpdateActionById 12345 "pass,status:200"<br />
<br />
Note 1: this directive must be added after the rule it is modifying has been loaded.<br />
<br />
Note 2: This does not work if you are using the redirect action.<br />
<br />
=== Changing a range of rules to be detect only by ID===<br />
<br />
This is similar to the method above, however you can define a range of rule IDs. For example, if you want to disable rules 1000-2000:<br />
<br />
SecRuleUpdateActionById 1000-2000 "pass,status:200"<br />
<br />
Note 1: this directive must be added after the rule it is modifying has been loaded.<br />
<br />
Note 2: This does not work if you are using the redirect action.<br />
<br />
== Disabling POST inspection for a specific URL ==<br />
<br />
Should you want to disable inspection of a POST for a specific URL, use the format below.<br />
<br />
Assuming the URL you wanted to skip POST inspection was "upload", your exclusion rule would look like this:<br />
<br />
''SecRule REQUEST_URI "^/upload" \<br />
"phase:1,id:1234567,t:none,t:lowercase,pass,nolog,ctl:requestBodyAccess=off"''<br />
<br />
Install this rule before any of your other rules. For example, in the file /etc/httpd/modsecurity.d/00_custom_exclude.conf.<br />
<br />
== Enabling rules for only specific domains ==<br />
<br />
If you wish to disable all the rules, except for specific domains, you need to copy in the two files from the subdirectory "special" where you have the rules installed. Then create this file:<br />
<br />
/etc/asl/custom_include_domains<br />
<br />
<br />
Include the domains and/or FQDNs you want the rules to apply to. Anything not on that list will cause those rules to skip all of our rules. <br />
<br />
#File must contain exactly one domain or FQDN per line. End of line markers (both LF and CRLF) will be stripped from each phrase and any whitespace trimmed from both the beginning and the end. Empty lines and comment lines (those beginning with the # character) will be ignored.<br />
#This file does not support metacharacters. (For example, * is not supported)<br />
<br />
Example:<br />
<br />
<br />
<pre><br />
www.example.com<br />
.foo.com<br />
</pre><br />
<br />
== Disabling rules using .htaccess ==<br />
<br />
This is a new feature in modsecurity 2.7.3. This capability is available if you compile modsecurity using this option:<br />
<br />
--enable-htaccess-config<br />
<br />
From there, you will be able to disable rules using .htaccess files. The format to disable a rule via .htaccess is:<br />
<br />
SecRuleRemoveById 12345<br />
<br />
Where 12345 is the rule id.<br />
<br />
'''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 and/or this option has not been enabled. <br />
<br />
Warning: Enabling this capability will allow users to disable rules, including on compromised accounts which may cause the system to become compromised. This capability was specifically disabled by default in modsecurity to prevent this from occurring. Use this option with extreme caution!<br />
<br />
=== Specific actions available in .htaccess ===<br />
<br />
<br />
* SecAction<br />
* SecRule<br />
* SecRuleRemoveByMsg<br />
* SecRuleRemoveByTag<br />
* SecRuleRemoveById<br />
* SecRuleUpdateActionById<br />
* SecRuleUpdateTargetById<br />
* SecRuleUpdateTargetByTag<br />
* SecRuleUpdateTargetByMsg<br />
<br />
'''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.<br />
<br />
Warning: Enabling this capability in modsecurity can allow an attacker to disable modsecurity rules that you may be using to protect the entire server. We do not recommend you enable this capability on a shared server.<br />
<br />
== Customizing a rule ==<br />
<br />
If you need to customize a rule do not change the asl*conf files. These files will be overwritten by updates. <br />
<br />
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.<br />
<br />
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:<br />
<br />
If you had an original rule like this:<br />
<br />
SecRule REQUEST_URI "/foo" "t:normalisePath,id:9000,rev:1,severity:2,msg:'Atomicorp.com WAF Rules: Block /foo'"<br />
<br />
<br />
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.<br />
<br />
SecRuleRemoveById 9000000<br />
SecRule REQUEST_URI "/bar" "t:normalisePath,id:9999,rev:1,severity:2,msg:'Atomicorp.com WAF Rules: Block /foo'"<br />
<br />
'''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.'''<br />
<br />
<br />
These are the reserved ranges:<br />
<br />
* 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.<br />
* 100,000-199,999; reserved for internal use of the engine, to assign to rules that do not have explicit IDs.<br />
* 200,000-299,999; reserved for rules published at modsecurity.org.<br />
* 300,000-399,999; reserved for rules published at gotroot.com.<br />
* 400,000-419,999; unused (available for reservation).<br />
* 420,000-429,999; reserved for ScallyWhack.<br />
* 430,000-699,999; unused (available for reservation).<br />
* 700,000-799,999; reserved for Ivan Ristic.<br />
* 900,000-999,999; reserved for the Core Rules project.<br />
* 1,000,000 and above; unused (available for reservation).<br />
<br />
=== For a domain ===<br />
<br />
==== Apache ====<br />
<br />
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.<br />
<br />
==== Changing the argument separator ====<br />
<br />
If you have a web application that uses the uncommon ";" argument separator, as opposed to the widely used "&" you will want to change SecArgumentSeparator value for that application. You can do this in one of two ways:<br />
<br />
1) Globally<br />
<br />
If all your applications use the older delimiter, just change the SecArgumentSeparator in the tortix_waf.conf file. Do not change this if your applications use other delimiters.<br />
<br />
''SecArgumentSeparator ";"'' <br />
<br />
2) Per Application<br />
<br />
You can also configure this per application. For example, if your web applications URL is /foo/bar.php you can create a customer rule like this:<br />
<br />
<br />
<pre><br />
<LocationMatch /foo/bar.php><br />
SecArgumentSeparator ";"<br />
</LocationMatch><br />
</pre><br />
<br />
This will only work if modsecurity is loaded before your virtual host definitions. This is the case with most control panels, but some control panels are known to load modsecurity after vhosts are defined. In which case this will fail because Apache will not know how to process this directive (it will need modsecurity loaded to understand what this means). If you get a syntax error, that means your apache configuration is loaded modsecurity after your vhosts are defined. You will need to change your apache configuration to ensure this loading occurs before vhosts are defined.<br />
<br />
[[ASL]] will automatically configure modsecurity to load first.<br />
<br />
= Creating custom rules =<br />
<br />
== Discussion ==<br />
<br />
If you need to create your own custom rules, do not change the asl*conf files. These files will be overwritten by updates. <br />
<br />
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.<br />
<br />
== Rule Ids for custom rules ==<br />
<br />
For custom rules, '''you must create your own rule ids which must be unique'''. The id: fields contain the rule ids. For custom rules you should use the local (internal) use range (see below for the reserved id ranges). '''Do not use assigned ranges.'''<br />
<br />
These are the reserved ranges:<br />
<br />
* 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.<br />
* 100,000-199,999; reserved for internal use of the engine, to assign to rules that do not have explicit IDs. (deprecated, all rules require assigned ids in 2.7.x and up)<br />
* 200,000-299,999; reserved for rules published at modsecurity.org.<br />
* 300,000-399,999; reserved for rules published by atomicorp.com<br />
* 400,000-419,999; unused (available for reservation).<br />
* 420,000-429,999; reserved for ScallyWhack.<br />
* 430,000-699,999; unused (available for reservation).<br />
* 700,000-799,999; reserved for Ivan Ristic.<br />
* 900,000-999,999; reserved for the Core Rules project.<br />
* 1,000,000 and above; unused (available for reservation).<br />
<br />
== Installing custom rules ==<br />
<br />
<br />
=== Linux ===<br />
<br />
==== Apache ====<br />
<br />
'''Step 1) Create your custom rules directory:'''<br />
<br />
''mkdir /etc/httpd/modsecurity.custom.d''<br />
<br />
'''Step 2) Create a configuration file for your custom rules in /etc/httpd/conf.d directory. For example:'''<br />
<br />
Create the file 01_modsecurity.conf and add this line to it:<br />
<br />
''Include modsecurity.custom.d/[https://www.atomicorp.com/examples/99_zzz_custom.conf 99_zzz_custom.conf]''<br />
<br />
You can download an example file from the URL below that will do this:<br />
<br />
[https://www.atomicorp.com/examples/01_modsecurity.conf 01_modsecurity.conf]<br />
<br />
And add 01_modsecurity.conf to this directory:<br />
<br />
/etc/httpd/conf.d<br />
<br />
If you have wget installed on your system, the following commands will do this automatically for you:<br />
''<br />
<br />
cd /etc/httpd/conf.d<br />
<br />
wget https://www.atomicorp.com/examples/01_modsecurity.conf''<br />
<br />
Note: 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. Please contact your control panel vendor for assistance.<br />
<br />
'''Step 3) Install your custom rules in the /etc/httpd/modsecurity.custom.d directory'''<br />
<br />
''cd /etc/httpd/modsecurity.custom.d''<br />
<br />
and edit the file 99_zzz_custom.conf and put in your custom rules.<br />
<br />
You can also download an example custom rule file by running these commands:<br />
<br />
''cd /etc/httpd/modsecurity.custom.d<br />
<br />
wget https://www.atomicorp.com/examples/99_zzz_custom.conf''<br />
<br />
'''Step 4) Test your apache configuration'''<br />
<br />
''service httpd configtest''<br />
<br />
If you have any errors, do not restart apache. You will need to correct these errors or apache will not start.<br />
<br />
'''Step 5) If your test was successful, restart apache.'''<br />
<br />
''service httpd restart''<br />
<br />
Our professional services group would be happy to help you with your custom rules needs, including developing the rules for you. If your request is something that we can safely include in the rules for all our customers, we're generally able to develop these new rules for free. Please contact us to discuss your rules needs.<br />
<br />
=== Windows ===<br />
<br />
==== IIS ====<br />
<br />
'''Step 1) Modify your modsecurity configuration file on windows and add this line to the end of your configuration. For example:'''<br />
<br />
''Include [https://www.atomicorp.com/examples/99_zzz_custom.conf 99_zzz_custom.conf]''<br />
<br />
'''Step 2) Edit the file 99_zzz_custom.conf and save it in the same directory as your modsecurity config file'''<br />
<br />
'''Step 3)Restart IIS'''<br />
<br />
<br />
Our professional services group would be happy to help you with your custom rules needs, including developing the rules for you. If your request is something that we can safely include in the rules for all our customers, we're generally able to develop these new rules for free. Please contact us to discuss your rules needs.<br />
<br />
== Modifying a rule ==<br />
<br />
If you want to modify the internal logic of a rule, you will want to "fork" or copy that rule into a custom rule. Do not modify the actual rules provided by us, your modifications will be overwritten with the next update.<br />
<br />
'''Step 1: Copy the rule you want to modify into your custom rules file.'''<br />
<br />
Copy the rule in its entirety into your custom rule file. For example, if you wanted to modify rule 390707, you would copy the entire rule into your custom rules file. For example:<br />
<br />
<pre><br />
# Restrict the maximum number of arguments in a request<br />
SecRule &ARGS "@gt 1000" \<br />
"chain,phase:2,t:none,log,auditlog,deny,status:403,msg:'Atomicorp.com WAF Rules: Too many arguments in request (max set to 1000, increase as necessary for your system)',id:'390707',severity:'4',rev:'8'"<br />
SecRule REQUEST_URI "!((?:^/(?:imaclean|massdelete)/)|^/cgi-bin/dada/mail\.cgi$|^/index\.php/mageworx/customoptions_options|^/za/|^/back-?office/|^/moderate\.php|^/backend/configdomains\.php|\.do$|^/admin[a-z0-9]+?/index\.php\?controller=adminmodules)" "t:none,t:lowercase"<br />
</pre><br />
<br />
'''Step 2: Change the rule id.''' <br />
<br />
This is absolutely required. No two rules can have the same ID. See this article for chosing a custom rule id: https://wiki.atomicorp.com/wiki/index.php/Mod_security#Rule_Ids_for_custom_rules<br />
<br />
For example:<br />
<br />
<pre><br />
# Restrict the maximum number of arguments in a request<br />
SecRule &ARGS "@gt 1000" \<br />
"chain,phase:2,t:none,log,auditlog,deny,status:403,msg:'Atomicorp.com WAF Rules: Too many arguments in request (max set to 1000, increase as necessary for your system)',id:'12345678',severity:'4',rev:'8'"<br />
SecRule REQUEST_URI "!((?:^/(?:imaclean|massdelete)/)|^/cgi-bin/dada/mail\.cgi$|^/index\.php/mageworx/customoptions_options|^/za/|^/back-?office/|^/moderate\.php|^/backend/configdomains\.php|\.do$|^/admin[a-z0-9]+?/index\.php\?controller=adminmodules)" "t:none,t:lowercase"<br />
</pre><br />
<br />
'''Step 3: Disable the original rule'''<br />
<br />
If you want your custom rule to be global, that is your modification applies to the entire system, then you will want to disable the original rule per this article:<br />
<br />
https://wiki.atomicorp.com/wiki/index.php/Mod_security#Disable_a_rule_for_all_domains<br />
<br />
If you want to disable the rule for a single application, see this article:<br />
<br />
https://wiki.atomicorp.com/wiki/index.php/Mod_security#Disable_a_rule_for_a_specific_web_application<br />
<br />
If you want to disable the rule for a specific IP or network:<br />
<br />
https://wiki.atomicorp.com/wiki/index.php/Mod_security#Disable_a_rule_by_IP_or_network<br />
<br />
If you want to disable the rule for a single domain:<br />
<br />
https://wiki.atomicorp.com/wiki/index.php/Mod_security#Disable_a_rule_for_a_single_domain<br />
<br />
'''Step 4: Set the scope of the rule.'''<br />
<br />
If you havent disabled the original rule globally, or for one or more domains, then you will need to set the scope of your custom rule. To limit your modification to a specific application, place your custom rule inside <LocationMatch> tags. For example:<br />
<br />
<pre><br />
<br />
<LocationMatch /url/to/your/custom/application><br />
# Restrict the maximum number of arguments in a request<br />
SecRule &ARGS "@gt 2048" \<br />
"chain,phase:2,t:none,log,auditlog,deny,status:403,msg:'Atomicorp.com WAF Rules: Too many arguments in request (max set to 1000, increase as necessary for your system)',id:'12345678',severity:'4',rev:'8'"<br />
SecRule REQUEST_URI "!((?:^/(?:imaclean|massdelete)/)|^/cgi-bin/dada/mail\.cgi$|^/index\.php/mageworx/customoptions_options|^/za/|^/back-?office/|^/moderate\.php|^/backend/configdomains\.php|\.do$|^/admin[a-z0-9]+?/index\.php\?controller=adminmodules)" "t:none,t:lowercase"<br />
</LocationMatch><br />
<br />
</pre><br />
<br />
= Configuring and Setting up mod_security =<br />
'''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.'''<br />
<br />
To setup and configured modsecurity, please see the [[Atomic_ModSecurity_Rules]] wiki page.</div>Mshinnhttps://wiki.atomicorp.com/wiki/index.php/Atomicorp_WAF_Rules_TroubleshootingAtomicorp WAF Rules Troubleshooting2023-11-10T19:31:07Z<p>Mshinn: /* Failed to create subdirectories */</p>
<hr />
<div>= Specific Errors =<br />
<br />
== Invalid command 'SecRemoteRulesFailAction', perhaps misspelled or defined by a module not included in the server configuration ==<br />
<br />
This means that your system is using an out of date version of modsecurity that does not support 2.9.1 and higher rule syntax. <br />
<br />
Solutions:<br />
<br />
1) Upgrade to [[ASL]]. [[ASL]] will automatically ensure you have the latest version of modsecurity installed on your system.<br />
<br />
2) Use [[aum]], which will automatically ensure you have the latest version of modsecurity installed on your system.<br />
<br />
3) use our rpms which are built using 2.9.1, and support remote rules.<br />
<br />
4) If you do not wish to upgrade to [[ASL]], use [[aum]], or use our rpms then you will need to manually upgrade modsecurity to at least version 2.9.1, and enable remote rules support when you compile modsecurity.<br />
<br />
== Invalid command 'SecTmpSaveUploadedFiles' ==<br />
<br />
This means that your system is using an out of date version of modsecurity that does not support 2.9.0 and higher rule syntax. <br />
<br />
Solutions:<br />
<br />
1) Upgrade to [[ASL]]. [[ASL]] will automatically ensure you have the latest version of modsecurity installed on your system.<br />
<br />
2) Use [[aum]], which will automatically ensure you have the latest version of modsecurity installed on your system.<br />
<br />
3) If you do not wish to upgrade to [[ASL]], or use [[aum]] and can not upgrade to 2.9.0, you will need to remove the ruleset(s) that are generating this error.<br />
<br />
== Error creating rule: Unknown variable: FILES_TMP_CONTENT ==<br />
<br />
This means that your system is using an out of date version of modsecurity that does not support 2.9.0 and higher rule syntax. <br />
<br />
Solutions:<br />
<br />
1) Upgrade to [[ASL]]. [[ASL]] will automatically ensure you have the latest version of modsecurity installed on your system.<br />
<br />
2) If you do not wish to upgrade to [[ASL]], and can not upgrade to 2.9.0, you will need to remove the ruleset(s) that are generating this error.<br />
<br />
== Error creating rule: Failed to resolve operator: fuzzyHash ==<br />
<br />
This means that your system is an out of date version of modsecurity that does not support 2.9.0 and higher rule syntax. <br />
<br />
Solutions:<br />
<br />
1) Upgrade to [[ASL]]. [[ASL]] will automatically ensure you have the latest version of modsecurity installed on your system.<br />
<br />
2) If you do not wish to upgrade to [[ASL]], and can not upgrade to 2.9.0, you will need to remove the ruleset(s) that are generating this error.<br />
<br />
== Error creating rule: Could not open phrase file "/etc/asl/custom-domain-blocks": No such file or directory ==<br />
<br />
This means that you have not setup this ruleset correctly. Please see the link below for installation instructions:<br />
<br />
https://www.atomicorp.com/wiki/index.php/WAF_rule_families#01_asl_domain_blocks.conf<br />
<br />
<br />
== SecReadStateLimit is depricated, use SecConnReadStateLimit instead. ==<br />
<br />
This means your system is using the very buggy 2.8.0 modsecurity release. Do not use 2.8.0. Please see the article below for more information on 2.8.0.<br />
<br />
If you must use 2.8.0, this error is benign and you can ignore it.<br />
<br />
== Error creating rule: Could not add entry ==<br />
<br />
See below if you are using mod_security 2.8.0.<br />
<br />
== ModSecurity: IPmatch: bad IPv4 specification ==<br />
<br />
This error is not caused by the rule. It is caused by a buggy version of modsecurity, specifically 2.8.0. '''2.8.0 has a known critical bug in its IP matching code. It can not properly use IP addresses with rules''', as documented in the github bug report below:<br />
<br />
https://github.com/SpiderLabs/ModSecurity/issues/706<br />
<br />
'''Do not use 2.8.0.''' Users should only use the currently supported version of modsecurity documented at the URL below:<br />
<br />
https://www.atomicorp.com/wiki/index.php/Atomic_ModSecurity_Rules#Minimum_Version_of_Modsecurity_Required_to_use_the_rules<br />
<br />
===Solutions===<br />
<br />
==== cpanel ====<br />
<br />
'''Step 1) Remove 2.8.0 from your system'''<br />
<br />
Disable modsecurity in cpanel and uninstall it (dont worry, the next step will show you how to install a bug free version)<br />
<br />
'''Step 2) Install aum on your system'''<br />
<br />
[[aum]] will install modsecurity and keep both modsecurity and your rules up to date, automatically, with stable bug free versions that will never conflict with our rules. Please see the URL below for installation instructions for aum:<br />
<br />
https://www.atomicorp.com/wiki/index.php/Downloading_Rules#Just_a_downloader<br />
<br />
Note: If you are using an older modsecurity management tool that does not support the faster concurrent logging method, you need to manually configure modsecurity to use the slower serial method as documented at the URL below:<br />
<br />
https://www.atomicorp.com/wiki/index.php/Atomic_ModSecurity_Rules#Serial_logging<br />
<br />
<br />
==== Plesk ====<br />
<br />
<br />
<br />
<br />
'''Step 1) Disable buggy modsecurity from the plesk interface under server settings'''<br />
<br />
Note: Run these commands in the steps below as the root user.<br />
<br />
'''Step 2) Remove the buggy modsecurity packages'''<br />
<br />
''yum remove plesk-modsecurity*''<br />
<br />
<br />
'''Step 3) Change the rules path to the correct systemwide path in /etc/asl/config'''<br />
<br />
MODSEC_RULES_PATH="/etc/httpd/modsecurity.d"<br />
<br />
<br />
'''Step 4) Make a directory for the rules'''<br />
<br />
''mkdir /etc/httpd/modsecurity.d''<br />
<br />
<br />
'''Step 5) Run the Atomicorp Update Manager'''<br />
<br />
''aum -u''<br />
<br />
==== Custom ====<br />
<br />
If you have installed modsecurity either from source, or via some other third party method remove 2.8.0 and use 2.7.7 or 2.9.0. This bug is not fixed in 2.8.0 or in subversion.<br />
<br />
== httpd: ModSecurity: WARNING Using transformations in SecDefaultAction is deprecated ==<br />
<br />
This means that you are using out of date rules. If you are using Atomicorp rules, then this means you are not using the latest real time rules. The latest real time rules do not use transformations in the SecDefaultAction. <br />
<br />
If you are using third party rules, this means that the rules contain a transform function in the SecDefaultAction setting. This is a deprecated setting.<br />
<br />
<br />
== ModSecurity: Failed to access DBM file "/var/asl/data/msa/ ==<br />
<br />
This means that you do not have the correct permissions setup for modsecurity to work correctly. Please make sure you have followed all the setup and installation instructions in the [[Atomic ModSecurity Rules]] wiki article. Specific guidance is provided in this section of the Setting Up Modsecurity guide:<br />
<br />
https://www.atomicorp.com/wiki/index.php/Atomic_ModSecurity_Rules#Step_3:_Set_permissions_for_directories<br />
<br />
== Failed to create subdirectories ==<br />
<br />
This means that the permissions on those subdirectories do not match the user that apache is running as. For example, if apache is running as the user "apache" those directories must be owned by apache. <br />
<br />
Important note: If you are using an apache module that changes the user that apache runs as, on the fly, then those directories must be writable by all users. The use of modules that require you to set these directories as world writable and world readable is a serious security vulnerability, and should not be done. This will allow all users on the system to both change these logs, as well as to see both the logs and the payloads for all other users on the system.<br />
<br />
Some modules, for example mod_ruid2, write logs as the user for that instance, but will set permissions on subdirectories such that other users can not write or read from them. <br />
<br />
The most secure option is for these directories to be writable and readable only by a trusted user, and not by general users on the system.<br />
<br />
Please follow this guidance at the URL below:<br />
<br />
https://wiki.atomicorp.com/wiki/index.php/Atomic_ModSecurity_Rules#Step_3:_Set_permissions_for_directories<br />
<br />
== Error creating rule: Unknown variable: MATCHED_VARS ==<br />
<br />
Causes:<br />
<br />
If you are getting this error, it means that you are using an old version of modsecurity that does not support the modern rule language and you are not running [[ASL]]. We recommend you install [[ASL]]. <br />
<br />
ASL will not allow incompatible versions of the modsecurity rules to be installed. It will also automatically upgrade mod_security provided you have UPDATE_TYPE set to "all", which is the default. If you have updates disabled in ASL, then you will need to manually upgrade modsecurity:<br />
<br />
yum upgrade mod_security <br />
<br />
If you are not using [[ASL]], then you will need to upgrade modsecurity using whatever method you used to install it. You will need to be running at least version 2.6.3.<br />
<br />
<br />
== Exec: Execution failed while reading output: /usr/bin/modsec-clamscan.pl (End of file found) ==<br />
<br />
=== Without ASL ===<br />
<br />
This error occurs if you install the 05_asl_scanner.conf file and/or the 99_asl_scanner.conf ruleset. These rulesets are not supported without ASL, as malware scanning is not included in the rules only subscription. [[ASL]] comes with malware upload scanning for HTTP, SSH, FTP and other protocols, including real time malware protection and much more. If you want malware upload protection, upgrade to [[ASL]].<br />
<br />
Solution:<br />
<br />
Option 1. Update to [[ASL]]<br />
<br />
Option 2: disable this setting in /etc/asl/config<br />
<br />
https://www.atomicorp.com/wiki/index.php?title=ASL_WAF#MODSEC_99_SCANNER<br />
<br />
Option 3. Remove the file 05_asl_scanner.conf and/or 99_asl_scanner.conf and restart apache.<br />
<br />
=== With ASL ===<br />
<br />
This means someone or something has disabled the malware protection system on your system. ASL can not and will not do this.<br />
<br />
== /usr/bin/modsec-clamscan.pl is not installed on the server. ==<br />
<br />
Malware scanning is not included in the rules only subscription. [[ASL]] comes with malware upload scanning for HTTP, SSH, FTP and other protocols, including real time malware protection and much more. If you want malware upload protection, upgrade to [[ASL]].<br />
<br />
We also don't include that file or use the methods demonstrated in it because it doesn't scale very well. ASL has a binary streaming system that scales.<br />
<br />
<br />
== No action id present within the rule ==<br />
<br />
This means that you using out of date rules. If you are using Atomicorp rules, then this means you are not using the latest real time rules. The latest real time rules have an id action for every rule. <br />
<br />
== httpd: ModSecurity: WARNING Using transformations in SecDefaultAction is deprecated ==<br />
<br />
This means that you are using out of date rules. If you are using Atomicorp rules, then this means you are not using the latest real time rules. The latest real time rules do not use transformations in the SecDefaultAction. <br />
<br />
If you are using third party rules, this means that the rules contain a transform function in the SecDefaultAction setting. This is a deprecated setting.<br />
<br />
<br />
== ModSecurity: Found another rule with the same id==<br />
<br />
This means that you have a modsecurity rule with the same id. All of our rules have unique id's. This error can only occur for one of two reasons:<br />
<br />
1) You have loaded our rules twice. Please follow this installation guide and ensure that you have modsecurity configured as described in this document. These installation procedures will only load the rules once.<br />
<br />
2) You have rules that are using id's already assigned to other rules.<br />
<br />
If you are using third party or custom rules, check to make sure they have unique id's. Modsecurity requires a unique id for each rule. The range 300000-399999 is used by our rules, do not use this range for any custom rules, and if you have third party rules with these id's be sure to remove these rules.<br />
<br />
== Rule execution error - PCRE limits exceeded (-8): (null). ==<br />
<br />
This is an internal limit to prevent a special type of DOS attack on the WAF itself. '''This is not caused by any of the rules.''' This is caused by the content the rules are inspecting. In certain cases, the content may be so complex that the WAF is stopping itself from doing too much work which could lead to a DOS attack on the system itself. If your system is generating these kinds of errors, it means you need to set the limits higher on your system, while it is beyond the scope of this article, another solution is to reduce the complexity of the content you are inspecting. <br />
<br />
It is also possible this is occurring due to an actual DOS attack on your system. If you are certain this is not a DOS attack, simply increase these limits accordingly for your system. <br />
we recommend a minimum of 250000 for a modern system.<br />
<br />
SecPcreMatchLimit 250000<br />
SecPcreMatchLimitRecursion 250000<br />
<br />
'''You may have to increase these limits for your system if you continue to get PCRE limit errors.'''<br />
<br />
= High memory usage =<br />
<br />
If apache is growing and growing in memory usage, and does not stablize please see the checklist below. If apache is simply using more memory, but has stablized (for example, Apache is using 100MB of memory, as opposed to 40MB of memory without modsecurity) this is normal. modsecurity caches the rules, and certain activities to speed up processing. Memory is infinitely faster than your hard drives, and loading the rules from the hard drive would be terrifyingly slow, too slow to be usable.<br />
<br />
== Ensure that modsecurity is setup correctly ==<br />
<br />
An incorrectly configured modsecurity setup can cause this to happen. Some vendors that install modsecurity with their control panels do so incorrectly, and configure it in a manner that will lead to memory leaks with advanced security rules. The correct solution is to setup modsecurity correctly. There are two ways to do this:<br />
<br />
Solution 1) Install [[ASL]].<br />
<br />
This will setup modsecurity correctly, and automatically.<br />
<br />
Solution 2) Manually configure and setup modsecurity yourself.<br />
<br />
Documentation for setting up modsecurity is available on the [[Atomic ModSecurity Rules]] page. <br />
<br />
== Ensure that modsecurity is built correctly ==<br />
<br />
Solution 1) Install [[ASL]]<br />
<br />
ASL will setup a correctly built version of modsecurity.<br />
<br />
Solution 2) Install a modsecurity build from our rpm repositories.<br />
<br />
You can [https://www.atomicorp.com/wiki/index.php/Atomic_ModSecurity_Rules#Step_1:_Download_ModSecurity download modsecurity here].<br />
<br />
Solution 3) Install asl-lite<br />
<br />
Please see the [[ASL Lite]] page for details. ASL Lite is unsupported software.<br />
<br />
== Check for leaking web applications ==<br />
<br />
Web applications can and do leak memory. Check to make sure your memory leak isnt from a web application. Or a web application isnt amplifying a memory leak in something else.<br />
<br />
== Ensure that apache is built correctly ==<br />
<br />
The major OS vendors, Redhat, Suse, Ubuntu and others do an excellent job of building Apache correctly. However, all software has bugs, and you should make sure that you are both running the latest updates from your vendor for a currently supported version of operating system from that vendor, and that you have ruled out an actual bug in apache. modsecurity is a complex piece of software, that relies of an even more complex piece of software, Apache, to work correctly. To improve performance, modsecurity will use apaches built in memory caching capabilities, and if there is a bug in these Apache supplied capabilities memory leaks can occur. We always recommend you discuss Apache memory leaks with your OS vendor first.<br />
<br />
Please be especially diligent with source builds and Apache builds form non OS vendors. These builds are generally not as well tested, and so far are the only ones we have seen with memory management problems. If you use an Apache build from a non-OS vendor, you should discuss any memory management issues with them first if you have rules out the previous causes, as they are most likely a byproduct of a build error, or a bug in Apache.<br />
<br />
= Site loads slowly when the rules are loaded =<br />
<br />
There can be a number of reasons for this. Below is a list of the more common issues:<br />
<br />
'''1. DNS based rules are activated, but there is no local DNS server on the system'''<br />
<br />
Check to see if you have any DNS based rules loaded. Please see the [[mod_security]] page for a list of rules and which ones are DNS based.<br />
<br />
These rules use DNS lookups to check for various characteristics of the connecting system, for example is it on a blacklist, is the IP address known to be used by a trusted source (Google for example). This means that for every connection to your system, a DNS lookup is done against the IP to see if the source IP is listed in some zone or blacklist. If you do not have a local DNS server, this can take a very long time depending on how busy the DNS server is that you are communicating with, and because the request is not cached, your system is asking the DNS server the same question several times in a row. This is because of the way HTTP works. A typical user request may need to open 100 or more connections to your site, and each time a DNS request is made to the RBL.<br />
<br />
The simple fast solution is to make sure you are running a local DNS server on your system and that it caches requests. That way your RBL lookups are only to your local system, and if it already has the answer it will not have to ask the RBLs DNS server across the Internet. The difference in performance is night and day with a local DNS server, so we highly recommend you use on if you are going to use any RBL with any product.<br />
<br />
'''2. The system is low on resources'''<br />
<br />
As with any piece of software, the WAF will consume some resources on the system. If the system is short on resources the WAF has to compete with other parts of the system for those resources. Check to make sure you have free memory and CPU cycles for the WAF.<br />
<br />
'''3. Custom rules may be inefficient'''<br />
<br />
If you are using custom rules, try disabling them. If a rule is written in an inefficient manner it can kill performance on the system.<br />
<br />
'''4. Rules are loaded twice'''<br />
<br />
If you have setup modsecurity yourself, check to make sure you arent loading the rules more than once. One several cpanel installations we've seen cases where users inadvertently setup modsecurity to load the same rules twice, and in one case a user set them up to load three times. Apache is a literal animal, if you load the same rule twice it will process that same rule twice, doubling the work on the system! And because our rules use advanced branching logic, if you load them multiple times that can have a very adverse effect on performance as the branching tree logic won't work correctly and you lose our on all the performance benefits a modern ruleset provides.<br />
<br />
'''5. Suboptimal custom configuration'''<br />
<br />
If you setup modsecurity yourself, your configuration could be suboptimal. You may have serial logging enabled, debugging enabled, pour inspection options selected, or any number of things could be wrong. We recommend you use our [[ASL]] product to setup modsecurity, its automatic and it will always configure the optimal settings for your system. <br />
<br />
If you prefer to do it yourself, then please make sure you have read the modsecurity documentation and understand the options for modsecurity before you enable them. modsecurity is a powerful piece of software that can easily be misconfigured. Care should be taken when setting up this software yourself.<br />
<br />
For do it yourselfers, we have put together a guide to help you on the [[Atomic ModSecurity Rules]] page.</div>Mshinnhttps://wiki.atomicorp.com/wiki/index.php/Modsecurity_rule_familiesModsecurity rule families2023-11-09T19:21:34Z<p>Mshinn: /* 30_asl_antispam_advanced.conf */</p>
<hr />
<div>The Atomicorp modsecurity rules are broken into families - please see the documentation for your platform as to which rulesets to load. <br />
<br />
====000000000000000000000000_asl_notconfigured.conf====<br />
<br />
'''This rule file should not be used.''' <br />
<br />
This file is a "canary" file included in the archive to prevent users from accidentally loading all the rule files at the same. This ruleset will prevent this condition by disabling the WAF and logging a warning that the installation instructions have not been followed.<br />
<br />
If you are getting any errors about this file and you are using a third party product that installs our rules, please contact the vendor for that product.<br />
<br />
====000_asl_threat_intelligence.conf====<br />
<br />
These rules use the Atomicorp Threat Intelligence system to detect if an IP is a known threat. These rules look for DOS, brute force, spam, known attackers and advanced threats.<br />
<br />
Note: Requires modsecurity 2.7.7 and up.<br />
<br />
====00_asl_x_searchengines.conf====<br />
<br />
'''This ruleset is Deprecated'''<br />
<br />
Note: this is a legacy ruleset and should only be used on platform that do not support lua, and may experience performance issues. Please use 00_asl_z_searchengines.conf instead.<br />
<br />
This ruleset tells the WAF to trust defined search engines, and to not block or shun them.<br />
<br />
<br />
Note: Requires modsecurity 2.7.7 and up.<br />
<br />
====00_asl_y_searchengines.conf ====<br />
<br />
'''This ruleset is Deprecated'''<br />
<br />
Note: this is a legacy ruleset and should only be used on platform that do not support lua, and may experience performance issues. Please use 00_asl_z_searchengines.conf instead.<br />
<br />
''(Available in ASL and the real time rules only)''<br />
<br />
This ruleset detects clients pretending to be a search engine, as well as valid search engines. You must have either [[ASL]] installed, or apache configured with "HostnameLookups Double" and a very fast local DNS server. <br />
<br />
These rules also allow you to auto-whitelist real search engines. To do this, you will need to either use [[ASL]], or you will need to manually set the variable WHITELIST_SEARCH_ENGINES to "1".<br />
<br />
'''Warning: If you do not have either [[ASL]] installed, or apache configured correctly to use these rules they will not work correctly.'''<br />
<br />
Note: If you do not have a fast local DNS server, do not use these rules. These rules perform forward and reverse lookups and require a fast local DNS server, otherwise you should expect your websites to be very slow.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
Excluded: Modsecurity 2.8.0. Because 2.8.0 has a serious bug in the @ipmatch code( https://github.com/SpiderLabs/ModSecurity/issues/706).<br />
<br />
====00_asl_z_searchengines.conf====<br />
<br />
'(Available in ASL and the real time rules only)''<br />
<br />
Note: The rules must be used with a [[Local DNS resolver]]. If you do not have a fast local DNS server (not a remote DNS server), do not use these rules. These rules perform forward and reverse lookups and require a fast local DNS server. Failure to use a local resolver will result in performance degradation, these rules may also not work at all in these cases.<br />
<br />
This ruleset detects clients pretending to be a search engine, as well as valid search engines. You must have a very fast local DNS server to use these rules. These rules also allow you to auto-whitelist real search engines. To do this, in the /etc/asl/config set WAF_LUA_00_SEARCHENGINE to "yes"<br />
<br />
For DIY installations, you must install the "advanced" subdirectory in your modsecurity rules directory. If you are manually extracting the rules archive files this should be created for you automatically, and will contain the actual .lua files this config file will load. <br />
<br />
Requires: Modsecurity 2.9.3 and up.<br />
<br />
====00_asl_zz_strict.conf====<br />
<br />
'''Note: Requires modsecurity 2.7.0 and higher.'''<br />
<br />
This enforces strict adherence to the HTTP RFCs.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====00_asl_0_global.conf====<br />
<br />
This is a global variable file, it is only used if you have modsecurity 2.5.13 and above installed. <br />
<br />
====00_asl_rbl.conf====<br />
<br />
This rule family checks an incoming host to see if its on a RBL. By default only the spamhaus XBL-SBL list is enabled which is operated by the Spamhaus project. This RBL is not operated or controlled by Atomicorp. Please contact Spamhaus if you have issues with the IPs on this RBL, or disable this option. Several other RBLs are including in this rule file and must be either enabled in ASL (ASL will generate this rule file) or if you are not running ASL you must manually enable the other RBLs.<br />
<br />
This ruleset will look up every request in the DNS to see if its on a blacklist, and will not finish serving the request until the DNS server responds. This can slow down requests if the DNS server is slow. Basically, web requests will move at the speed of the DNS servers replies.<br />
<br />
If your web server is responding slowly to requests, and you have this ruleset enabled your DNS server is too slow to meet your lookup needs. You will need to either disable this ruleset, or tune your DNS server to respond to queries more quickly.<br />
<br />
''If you use this ruleset, make sure you have a fast locally caching DNS server. This ruleset will query spamhaus for every incoming IP to see if its on a blacklist, if your DNS is slow (or non local) this will make your system seem to crawl, as the read request will be blocked by Apache until it finished the DNS lookup. If you do not have a fast and local DNS server, do not use this ruleset.''<br />
<br />
Requires: Modsecurity 2.6.0 and up.<br />
<br />
====00_asl_blacklist.conf====<br />
<br />
Allows you to blacklist hosts or CIDRs from the WAF.<br />
<br />
Requires: Modsecurity 2.9.0 and up.<br />
<br />
The format is single IPs or CIDRs per line, for example:<br />
<br />
<pre><br />
1.2.3.4<br />
5.6.7.0/24<br />
8.9.0.0/16<br />
</pre><br />
<br />
Note: You must define your own blacklist file. The default location is /etc/asl/blacklist. <br />
<br />
====00_asl_whitelist.conf====<br />
<br />
Allows you to whitelist hosts from the WAF.<br />
<br />
Requires: Modsecurity 2.9.0 and up.<br />
<br />
The format is single IPs or CIDRs per line, for example:<br />
<br />
<pre><br />
1.2.3.4<br />
5.6.7.0/24<br />
8.9.0.0/16<br />
</pre><br />
<br />
Note: You must define your own whitelist entires. The default location is /etc/asl/whitelist. '''Do not use the whitelist.txt file. It is not used for this rule. We do not provide a default whitelist for these rules.'''<br />
<br />
Note: Requires modsecurity 2.7.7 and up.<br />
<br />
====01_asl_content.conf====<br />
<br />
These rules restrict the server to known content types that the WAF can correctly decipher.<br />
<br />
Requires: Apache, and Modsecurity 2.9.2 and up.<br />
<br />
==== 01_asl_domain_blocks.conf====<br />
<br />
Optional ruleset that allows you to block connections from hosts, based on their DNS hostname and/or domain. This is a user defined list.<br />
<br />
Domains and/or hostnames are stored in this file:<br />
<br />
/etc/asl/custom-domain-blocks<br />
<br />
The format is one entry, per line, for example:<br />
<br />
<pre><br />
example.com<br />
www.hostname.some-tld<br />
</pre><br />
<br />
Note: You must have either [[ASL]] installed, or apache configured with "HostnameLookups Double" and a very fast local DNS server for these rules to work.\<br />
<br />
Note: Requires modsecurity 2.7.7 and up.<br />
<br />
====01_asl_rules_special.conf====<br />
<br />
This ruleset changes the behavior of the WAF for applications that behavior in nonstandard ways. For example, OTRS uses ";" and not "&" for argument separation. You should not use these rules if you do not have OTRS installed on your system.<br />
<br />
If you do not know what this means, you do not need this ruleset.<br />
<br />
Requires: Modsecurity 2.7.0 and up. <br />
<br />
Note: If you get an error regarding SecArgumentSeparator with these rules, your modsecurity configuration is being loaded too late in your Apache stack. Ensure that your modsecurity configuration is loaded first. This has been seen with cpanel when not using [[ASL]]. Please contact your apache vendor for assistance with this issue, or use [[ASL]] which will fix your apache configuration so this error does not occur.<br />
<br />
====03_asl_dos.conf====<br />
<br />
This ruleset protects apache from slow DOS attacks. It is only supported with Apache and requires the installation of the mod_reqtimeout module. The rule is fail safe with Apache, that is if the mod_reqtimeout module is not loaded the rules also will not load into Apache.<br />
<br />
[[ASL]] automatically ensures mod_reqtimeout is installed. If you are a rules only user please contact your Apache vendor for assistance installing this module.<br />
<br />
Note: Requires Apache and modsecurity 2.7.7 and up.<br />
<br />
====05_asl_exclude.conf====<br />
<br />
Pre-load rule exclusion list. Turns off rules that need to be disabled early in the process. ASL manages this process automatically.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====00_asl_z_antievasion.conf====<br />
<br />
This is a ruleset to detect attempts to bypass modsecurity itself, through evasion methods for example. Do not use this ruleset unless you are using 2.6.1 and up.<br />
<br />
====05_asl_scanner.conf ====<br />
<br />
Deprecated.<br />
<br />
====06_asl_honeypot.conf ====<br />
<br />
This ruleset lets you define URLs you want to specifically block, for example the URL of an application that may not be installed on the system. This can work as a honeypot of sorts, allowing the system to be configured to treat probes for non-existant applications as attacks. [[ASL]] has a more advanced system that can detect when URLs do not correspond to files on the system, which can be used in place of this ruleset or to augment it.<br />
<br />
For this ruleset to work, populate the honeypot-files.txt file in the same directory as 06_asl_honeypot.conf with one URL per line. For example:<br />
<br />
<br />
<pre><br />
/application/not/installed/on/system<br />
file_name_not_on_system.extension<br />
</pre><br />
<br />
==== 11_asl_rules.conf====<br />
<br />
This ruleset is reserved and is not currently used.<br />
<br />
====10_asl_antimalware.conf====<br />
<br />
Checks payload and RFI contents for known sources of malware and malware payloads and will block them.<br />
<br />
Requires: Modsecurity 2.6.0 and up.<br />
<br />
====09_asl_rules.conf====<br />
<br />
These are supplementation rules to the 10_asl_rules.conf, but only work on 2.6.6 and up installations. Do not use this ruleset unless you are using 2.6.6 and up.<br />
<br />
====10_asl_rules.conf ====<br />
<br />
The main rules, contains all the generic security rules to protect against classes of attacks, such as SQL injection, XSS, code injection, recursion, etc. '''These rules require modsecurity 2.9.1 and above.'''<br />
<br />
Requires: Modsecurity 2.9.1 and up.<br />
<br />
====11_asl_adv_rules.conf====<br />
<br />
These are advanced rules, and '''can only be used with modsecurity 2.7.5 and above.'''<br />
<br />
Requires: Modsecurity 2.7.5 and up.<br />
<br />
====11_asl_data_loss.conf====<br />
<br />
Experimental data leakage rules. Looks for credit card numbers and other potentially sensitive information leaking from the system.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====11_asl_brute_enhanced.conf====<br />
<br />
Requires: Modsecurity 2.9.2 and up.<br />
<br />
These rules are for platforms that do not have either [[ASL]] or Atomic Protector installed. These rules create the collections in modsecurity to block brute force attacks. The defaults are > 5 failures within 60 seconds.<br />
<br />
''Note: These rules are not necessary if the systen has ASL or Atomic Protector installed, and should not be used with ASL or AP.<br />
<br />
''Note 1: These rules will only work if the web server can write to the SecDataDir directory. That directory will contain sqllite databases that modsecurity will create and use to count events, without the collection modsecurity can not maintain state for composite events, like multiple login failures, and these rules will not work.''<br />
<br />
''Note 2: Enable this setting in /etc/asl/config to create the collections:''<br />
<br />
<br />
https://wiki.atomicorp.com/wiki/index.php/Aum_configuration#MODSEC_00_THREAT<br />
<br />
====12_asl_adv_xss_rules.conf====<br />
<br />
'''This ruleset require mod_security 2.9.0 and above.'''<br />
<br />
This is the advanced Cross Site Scripting (XSS) protection rule set. It performs deep level inspections of web requests and responses to look for potential XSS attacks.<br />
<br />
====12_asl_brute.conf====<br />
<br />
'''This ruleset is only available with [[ASL]] or the Real Time Rules.''' <br />
<br />
This ruleset detects authentication failures against all major web applications (Joomla, WordPress, MovableType, Drupal, ModX, ZenCart, OsCommerce, VBulletin, PHPBB and more).<br />
<br />
When used with [[ASL]], fast and "low and slow" brute force attacks can be detected and blocked in real time.<br />
<br />
Requires: Modsecurity 2.6.8 and up. <br />
<br />
'''Note: [[ASL]] is necessary to perform active response to brute force attacks.'''<br />
<br />
====13_asl_brute_enhanced.conf====<br />
<br />
Requires: Modsecurity 2.9.2 and up.<br />
<br />
These rules are for platforms that do not have either [ASL] or Atomic Protector installed. These rules create the collections in modsecurity to block brute force attacks. The defaults are > 10 failures within 60 seconds.<br />
<br />
''Note: These rules are not necessary if the systen has ASL or Atomic Protector installed, and should not be used with ASL or AP.<br />
<br />
Note 1: These rules will only work if the web server can write to the SecDataDir directory. That directory will contain sqllite databases that modsecurity will create and use to count events, without the collection modsecurity can not maintain state for composite events, like multiple login failures, and these rules will not work.''<br />
<br />
====20_asl_useragents.conf====<br />
<br />
Looks for malicious or suspicious user agents and known patterns of malicious activity. These rules require modsecurity 2.7.1 and up.<br />
<br />
====21_asl_useragents.conf====<br />
<br />
This alows the user to define a set of user-agents to block. These rules require modsecurity 2.9.3 and up.<br />
<br />
The user defined list of user-agents to block must be placed in the file bad_agents.txt, which must be in the same directory as the 21_asl_useragents.conf rules file.<br />
<br />
The format for the bad_agents.txt file is one user-agent per line, case does not matter the user-agent will be inspected against the list for any upper/lower case combinations automatically.. Regular expressions are not supported. Examples:<br />
<br />
<pre><br />
Internet Explorer 6<br />
hackk_too_12345<br />
Mozilla/991HFS.0 (Windows NT 10.3; Win128; x64) AppleWebKit/31337.36 (KHTML, like Gecko) Chrome/8675309.0.3945.88 Safari/1337.36<br />
</pre><br />
<br />
Requires: Modsecurity 2.9.3 and up.<br />
<br />
====30_asl_antispam.conf====<br />
<br />
Tuned antispam rules, designed to work with all known blogs, forums, guestbooks, CMS' and other web content management systems that allow users to post content.<br />
<br />
Requires: Modsecurity 2.6.8 and up.<br />
<br />
====30_asl_antispam_referrer.conf====<br />
<br />
Rules to block referrer spam. Generally not needed in most environments if you protect web log generation tools from public access (which is the default for most control panels).<br />
<br />
Requires: Modsecurity 2.6.0 and up.<br />
<br />
====40_asl_apache2-rules.conf====<br />
<br />
This ruleset has been retired. mod_security 2.x does not work with Apache 1.x and this ruleset existed just for those rules that only worked with apache 2. As mod_security 2.x does not work with Apache 1.x there is no need for this ruleset.<br />
<br />
====50_asl_rootkits.conf====<br />
<br />
Detects and blocks known web based rootkits, PHP/ASP/PERL shells, spam tools and other malicious web applications from being installed, and in some cases from running on the system. These rules exist for cases where malicious software may already be installed on the system, this is a defense in depth rule set)<br />
<br />
Not: ASL can prevent all malware from running on the system, modsecurity is limited in this regard so if you are only using the rules you should not expect modsecurity to prevent malware from running. It may prevent it in some cases, but without kernel level protection such as that provided in [[ASL]] no WAF can stop all malware from running on the system itself.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====51_asl_rootkits.conf====<br />
<br />
These rules look for known malware names in filenames, and URLs.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====60_asl_recons.conf====<br />
<br />
Blocks known "google hacks" or webserver probes that look for vulnerable applications and signs of compromised systems running unauthorized shells, or unprotected applications that allow uploads which would give an attacker access to the system.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====61_asl_recons_dlp.conf====<br />
<br />
These rules detect Data Loss Search engine "hacks". These are search engine probes for sensitive files, often used by malicious parties to find sensitive information accidentally exposed on web servers.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====99_asl_a_redactor.conf====<br />
<br />
ASL only rule set. Requires modsecurity 2.6.0 and up. Part of the malicious code removal system. Automatically removes malicious code from web pages, such as hidden iframes, encoded javascript and other malicious code. '''Do not enable this ruleset if you are not using ASL. ''' <br />
<br />
====99_asl_exclude.conf====<br />
<br />
Post exclude rules.<br />
<br />
====98_asl_adv_redactor.conf====<br />
<br />
This is the new advanced malware removal system. This ruleset will remove malware "on the fly" from web pages. For example, it will remove hidden iframes, malicous javascript, and other malicious code.<br />
<br />
'''Requires: modsecurity 2.7.5 and up.'''<br />
<br />
====98_asl_jitp.conf====<br />
<br />
This is a special ruleset used by [[ASL]]. If you do not have [[ASL]] you can not use these rules.<br />
<br />
====99_asl_jitp.conf====<br />
<br />
Just in Time Patches. We publish JITPs daily if there is a new web application vulnerability that the 10_asl_rules.conf do not protect the system against. These are tuned rules for specific vulnerabilities in a web application.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====99_asl_a_redactor.conf====<br />
<br />
This ruleset is reserved, and is not currently used.<br />
<br />
====99_asl_redactor.conf====<br />
<br />
'''Note: Do not enable this ruleset unless you have been instructed to do so by support.'''<br />
<br />
Special ruleset - requires mod_sed to be loaded on the system which is included and supported in [[ASL]] - removes malicious code from web pages, such as hidden iframes, encoded javascript and other malicious code. We highly recommend you use this rule set - its fast, multithreads and will automagically remove malicious code from infected webpages, which can occur if an adversary is able to log into the system and modify the code, such as by SSH or by uploading the code via FTP. If you are not using [[ASL]] then you will need to make sure your system has mod_sed installed to use these rules, they will not load and therefore will not do anything without mod_sed installed. This ruleset is only supported with [[ASL]].<br />
<br />
====99_asl_redactor_post.conf====<br />
<br />
This ruleset detects malicious content in webpages, such as known malicious domains.<br />
<br />
====99_asl_scanner.conf====<br />
<br />
This is the same as 05_asl_scanner.conf, its provided in a form to run last. This is the recommended location for the scanner function, as the rules before this stop some attacks that the scanner also detects, but do this in a faster and less CPU intensive manner. Running the scanner last does not compromise or lower the effectiveness of the rules. This is just a performance enhancement. This ruleset is only supported with [[ASL]].<br />
<br />
====99_asl_z_adv_scanner.conf====<br />
<br />
'''Note: Requires [[ASL]] and modsecurity 2.9.0 and higher.'''<br />
<br />
This ruleset uses a fuzzy hash to identify potentially malicious files.<br />
<br />
Warning: This ruleset is not supported on non-ASL systems. Do not use this without ASL.<br />
<br />
==== Paranoid mode rules ====<br />
<br />
===== 15_asl_paranoid_rules.conf =====<br />
<br />
'''Note: Do not use these rules if you have not read this section.'''<br />
<br />
'''Please do not report false positives with these rules. If you encounter a false positive with a rule from this file, please use its duplicate in 10_asl_rules.conf instead. If you have a false positive with a rule from 10_asl_rules.conf, please report it to us.'''<br />
<br />
These are a special version of the 10_asl_rules.conf file, they use the same rule id:s as the 10_asl_rules.conf file. Therefore, you can not use these rules along with the 10_asl_rules.conf file. You can use one, or the other, but not both.<br />
<br />
These rules are a paranoid replacement for the 10_asl_rules.conf file. These rules do not contain any known safe mode application tuning exceptions or bypasses. These rules will generate false positives. These rules are made available for users that wish to tune their own rules, and do not wish to use a ruleset that has been tuned for false positives.<br />
<br />
For example, if you had a application that safely used the argument "url" to accept URLs:<br />
<br />
GET /application?url=http://www.example.com/safething<br />
<br />
The normal rules would allow this, if this was known to be safe for the application. <br />
<br />
The paranoid rules, however, will NOT allow this, even if this is known to be safe for the application. They will alert, and if configured (or misconfigured) also block this as an RFI attack. These rules will alert on things that may be safe or are known to be non-malicious. This will generate a lot of false positives for most users, therefore you should not use these rules if you do not want to experience a high degree of false positives. These rules exist for paranoid users, who may want to tune the rules themselves, or may wish to know about every possible potentially malicious event, even when the event may in fact not be malicious.<br />
<br />
We do not recommend you use these rules in blocking mode, instead you should use these only in detect mode, and only if you feel that your applications are doing things in a very unsafe manner. If you do wish to use these rules, make sure that you load them from a special file so you can set the default behaviour of the rules. If you do not do this, the rules will inherit you systems default behavior, which is generally to block.<br />
<br />
Example configuration lines for the paranoid rules:<br />
<br />
<pre><br />
SecDefaultAction "log,pass,auditlog,phase:2,t:none,t:lowercase,t:replaceNulls,t:compressWhitespace"<br />
Include modsecurity.paranoid.rules.d/15_asl_paranoid_rules.conf<br />
</pre><br />
<br />
You must load these rules last.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
==== Using the paranoid rules ====<br />
<br />
If you want to use the paranoid rules because you have found a vulnerability in your application that the normal rules do not block, please let us know, we would be happy to take a look at either creating a Just In Time Patch for your vulnerability, or adjusting the tuned rules to not allow this. Remember, if you use our real time rules, we provide this service for free. One easy way to find out if you have applications that have unusual vulnerabilities is to scan the application with a web vulnerability application scanner, if you find something the normal rules dont stop just let us know. We'd be delighted to put out new rules for your applications vulnerabilities.<br />
<br />
Finally, if you do you use these rules you will need to set ATOMIC_PARANOID_MODE to 1 in your modsecurity configuration. If you do not know how to do this, we do not recommend you use these rules.<br />
<br />
'''Note: Do not use this ruleset with [[ASL]]. [[ASL]] uses intelligent defense in depth, and does need this kind of ruleset to protect you. You will get a greater level of protection from ASL, without all the false positives.'''<br />
<br />
==== Beta Rules ====<br />
<br />
==== Experimental Rules ====<br />
<br />
<br />
====70_asl_csrf_experimental.conf====<br />
<br />
These are experimental CSRF mitigation rules. The 10_asl_rules.conf rules are designed to also handle some types of CSRF attacks, however these rules are for more advanced environments.<br />
<br />
These rules work by injecting javascript code into the response, and special cookies, and must be tuned for the system to prevent false positives. If you do not understand what this means, do not use these rules.<br />
<br />
'''They are currently not supported and are experimental.'''<br />
<br />
Requires: Modsecurity 2.7.0 and up.</div>Mshinnhttps://wiki.atomicorp.com/wiki/index.php/Modsecurity_rule_familiesModsecurity rule families2023-11-09T19:20:47Z<p>Mshinn: /* 21_asl_useragents.conf */</p>
<hr />
<div>The Atomicorp modsecurity rules are broken into families - please see the documentation for your platform as to which rulesets to load. <br />
<br />
====000000000000000000000000_asl_notconfigured.conf====<br />
<br />
'''This rule file should not be used.''' <br />
<br />
This file is a "canary" file included in the archive to prevent users from accidentally loading all the rule files at the same. This ruleset will prevent this condition by disabling the WAF and logging a warning that the installation instructions have not been followed.<br />
<br />
If you are getting any errors about this file and you are using a third party product that installs our rules, please contact the vendor for that product.<br />
<br />
====000_asl_threat_intelligence.conf====<br />
<br />
These rules use the Atomicorp Threat Intelligence system to detect if an IP is a known threat. These rules look for DOS, brute force, spam, known attackers and advanced threats.<br />
<br />
Note: Requires modsecurity 2.7.7 and up.<br />
<br />
====00_asl_x_searchengines.conf====<br />
<br />
'''This ruleset is Deprecated'''<br />
<br />
Note: this is a legacy ruleset and should only be used on platform that do not support lua, and may experience performance issues. Please use 00_asl_z_searchengines.conf instead.<br />
<br />
This ruleset tells the WAF to trust defined search engines, and to not block or shun them.<br />
<br />
<br />
Note: Requires modsecurity 2.7.7 and up.<br />
<br />
====00_asl_y_searchengines.conf ====<br />
<br />
'''This ruleset is Deprecated'''<br />
<br />
Note: this is a legacy ruleset and should only be used on platform that do not support lua, and may experience performance issues. Please use 00_asl_z_searchengines.conf instead.<br />
<br />
''(Available in ASL and the real time rules only)''<br />
<br />
This ruleset detects clients pretending to be a search engine, as well as valid search engines. You must have either [[ASL]] installed, or apache configured with "HostnameLookups Double" and a very fast local DNS server. <br />
<br />
These rules also allow you to auto-whitelist real search engines. To do this, you will need to either use [[ASL]], or you will need to manually set the variable WHITELIST_SEARCH_ENGINES to "1".<br />
<br />
'''Warning: If you do not have either [[ASL]] installed, or apache configured correctly to use these rules they will not work correctly.'''<br />
<br />
Note: If you do not have a fast local DNS server, do not use these rules. These rules perform forward and reverse lookups and require a fast local DNS server, otherwise you should expect your websites to be very slow.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
Excluded: Modsecurity 2.8.0. Because 2.8.0 has a serious bug in the @ipmatch code( https://github.com/SpiderLabs/ModSecurity/issues/706).<br />
<br />
====00_asl_z_searchengines.conf====<br />
<br />
'(Available in ASL and the real time rules only)''<br />
<br />
Note: The rules must be used with a [[Local DNS resolver]]. If you do not have a fast local DNS server (not a remote DNS server), do not use these rules. These rules perform forward and reverse lookups and require a fast local DNS server. Failure to use a local resolver will result in performance degradation, these rules may also not work at all in these cases.<br />
<br />
This ruleset detects clients pretending to be a search engine, as well as valid search engines. You must have a very fast local DNS server to use these rules. These rules also allow you to auto-whitelist real search engines. To do this, in the /etc/asl/config set WAF_LUA_00_SEARCHENGINE to "yes"<br />
<br />
For DIY installations, you must install the "advanced" subdirectory in your modsecurity rules directory. If you are manually extracting the rules archive files this should be created for you automatically, and will contain the actual .lua files this config file will load. <br />
<br />
Requires: Modsecurity 2.9.3 and up.<br />
<br />
====00_asl_zz_strict.conf====<br />
<br />
'''Note: Requires modsecurity 2.7.0 and higher.'''<br />
<br />
This enforces strict adherence to the HTTP RFCs.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====00_asl_0_global.conf====<br />
<br />
This is a global variable file, it is only used if you have modsecurity 2.5.13 and above installed. <br />
<br />
====00_asl_rbl.conf====<br />
<br />
This rule family checks an incoming host to see if its on a RBL. By default only the spamhaus XBL-SBL list is enabled which is operated by the Spamhaus project. This RBL is not operated or controlled by Atomicorp. Please contact Spamhaus if you have issues with the IPs on this RBL, or disable this option. Several other RBLs are including in this rule file and must be either enabled in ASL (ASL will generate this rule file) or if you are not running ASL you must manually enable the other RBLs.<br />
<br />
This ruleset will look up every request in the DNS to see if its on a blacklist, and will not finish serving the request until the DNS server responds. This can slow down requests if the DNS server is slow. Basically, web requests will move at the speed of the DNS servers replies.<br />
<br />
If your web server is responding slowly to requests, and you have this ruleset enabled your DNS server is too slow to meet your lookup needs. You will need to either disable this ruleset, or tune your DNS server to respond to queries more quickly.<br />
<br />
''If you use this ruleset, make sure you have a fast locally caching DNS server. This ruleset will query spamhaus for every incoming IP to see if its on a blacklist, if your DNS is slow (or non local) this will make your system seem to crawl, as the read request will be blocked by Apache until it finished the DNS lookup. If you do not have a fast and local DNS server, do not use this ruleset.''<br />
<br />
Requires: Modsecurity 2.6.0 and up.<br />
<br />
====00_asl_blacklist.conf====<br />
<br />
Allows you to blacklist hosts or CIDRs from the WAF.<br />
<br />
Requires: Modsecurity 2.9.0 and up.<br />
<br />
The format is single IPs or CIDRs per line, for example:<br />
<br />
<pre><br />
1.2.3.4<br />
5.6.7.0/24<br />
8.9.0.0/16<br />
</pre><br />
<br />
Note: You must define your own blacklist file. The default location is /etc/asl/blacklist. <br />
<br />
====00_asl_whitelist.conf====<br />
<br />
Allows you to whitelist hosts from the WAF.<br />
<br />
Requires: Modsecurity 2.9.0 and up.<br />
<br />
The format is single IPs or CIDRs per line, for example:<br />
<br />
<pre><br />
1.2.3.4<br />
5.6.7.0/24<br />
8.9.0.0/16<br />
</pre><br />
<br />
Note: You must define your own whitelist entires. The default location is /etc/asl/whitelist. '''Do not use the whitelist.txt file. It is not used for this rule. We do not provide a default whitelist for these rules.'''<br />
<br />
Note: Requires modsecurity 2.7.7 and up.<br />
<br />
====01_asl_content.conf====<br />
<br />
These rules restrict the server to known content types that the WAF can correctly decipher.<br />
<br />
Requires: Apache, and Modsecurity 2.9.2 and up.<br />
<br />
==== 01_asl_domain_blocks.conf====<br />
<br />
Optional ruleset that allows you to block connections from hosts, based on their DNS hostname and/or domain. This is a user defined list.<br />
<br />
Domains and/or hostnames are stored in this file:<br />
<br />
/etc/asl/custom-domain-blocks<br />
<br />
The format is one entry, per line, for example:<br />
<br />
<pre><br />
example.com<br />
www.hostname.some-tld<br />
</pre><br />
<br />
Note: You must have either [[ASL]] installed, or apache configured with "HostnameLookups Double" and a very fast local DNS server for these rules to work.\<br />
<br />
Note: Requires modsecurity 2.7.7 and up.<br />
<br />
====01_asl_rules_special.conf====<br />
<br />
This ruleset changes the behavior of the WAF for applications that behavior in nonstandard ways. For example, OTRS uses ";" and not "&" for argument separation. You should not use these rules if you do not have OTRS installed on your system.<br />
<br />
If you do not know what this means, you do not need this ruleset.<br />
<br />
Requires: Modsecurity 2.7.0 and up. <br />
<br />
Note: If you get an error regarding SecArgumentSeparator with these rules, your modsecurity configuration is being loaded too late in your Apache stack. Ensure that your modsecurity configuration is loaded first. This has been seen with cpanel when not using [[ASL]]. Please contact your apache vendor for assistance with this issue, or use [[ASL]] which will fix your apache configuration so this error does not occur.<br />
<br />
====03_asl_dos.conf====<br />
<br />
This ruleset protects apache from slow DOS attacks. It is only supported with Apache and requires the installation of the mod_reqtimeout module. The rule is fail safe with Apache, that is if the mod_reqtimeout module is not loaded the rules also will not load into Apache.<br />
<br />
[[ASL]] automatically ensures mod_reqtimeout is installed. If you are a rules only user please contact your Apache vendor for assistance installing this module.<br />
<br />
Note: Requires Apache and modsecurity 2.7.7 and up.<br />
<br />
====05_asl_exclude.conf====<br />
<br />
Pre-load rule exclusion list. Turns off rules that need to be disabled early in the process. ASL manages this process automatically.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====00_asl_z_antievasion.conf====<br />
<br />
This is a ruleset to detect attempts to bypass modsecurity itself, through evasion methods for example. Do not use this ruleset unless you are using 2.6.1 and up.<br />
<br />
====05_asl_scanner.conf ====<br />
<br />
Deprecated.<br />
<br />
====06_asl_honeypot.conf ====<br />
<br />
This ruleset lets you define URLs you want to specifically block, for example the URL of an application that may not be installed on the system. This can work as a honeypot of sorts, allowing the system to be configured to treat probes for non-existant applications as attacks. [[ASL]] has a more advanced system that can detect when URLs do not correspond to files on the system, which can be used in place of this ruleset or to augment it.<br />
<br />
For this ruleset to work, populate the honeypot-files.txt file in the same directory as 06_asl_honeypot.conf with one URL per line. For example:<br />
<br />
<br />
<pre><br />
/application/not/installed/on/system<br />
file_name_not_on_system.extension<br />
</pre><br />
<br />
==== 11_asl_rules.conf====<br />
<br />
This ruleset is reserved and is not currently used.<br />
<br />
====10_asl_antimalware.conf====<br />
<br />
Checks payload and RFI contents for known sources of malware and malware payloads and will block them.<br />
<br />
Requires: Modsecurity 2.6.0 and up.<br />
<br />
====09_asl_rules.conf====<br />
<br />
These are supplementation rules to the 10_asl_rules.conf, but only work on 2.6.6 and up installations. Do not use this ruleset unless you are using 2.6.6 and up.<br />
<br />
====10_asl_rules.conf ====<br />
<br />
The main rules, contains all the generic security rules to protect against classes of attacks, such as SQL injection, XSS, code injection, recursion, etc. '''These rules require modsecurity 2.9.1 and above.'''<br />
<br />
Requires: Modsecurity 2.9.1 and up.<br />
<br />
====11_asl_adv_rules.conf====<br />
<br />
These are advanced rules, and '''can only be used with modsecurity 2.7.5 and above.'''<br />
<br />
Requires: Modsecurity 2.7.5 and up.<br />
<br />
====11_asl_data_loss.conf====<br />
<br />
Experimental data leakage rules. Looks for credit card numbers and other potentially sensitive information leaking from the system.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====11_asl_brute_enhanced.conf====<br />
<br />
Requires: Modsecurity 2.9.2 and up.<br />
<br />
These rules are for platforms that do not have either [[ASL]] or Atomic Protector installed. These rules create the collections in modsecurity to block brute force attacks. The defaults are > 5 failures within 60 seconds.<br />
<br />
''Note: These rules are not necessary if the systen has ASL or Atomic Protector installed, and should not be used with ASL or AP.<br />
<br />
''Note 1: These rules will only work if the web server can write to the SecDataDir directory. That directory will contain sqllite databases that modsecurity will create and use to count events, without the collection modsecurity can not maintain state for composite events, like multiple login failures, and these rules will not work.''<br />
<br />
''Note 2: Enable this setting in /etc/asl/config to create the collections:''<br />
<br />
<br />
https://wiki.atomicorp.com/wiki/index.php/Aum_configuration#MODSEC_00_THREAT<br />
<br />
====12_asl_adv_xss_rules.conf====<br />
<br />
'''This ruleset require mod_security 2.9.0 and above.'''<br />
<br />
This is the advanced Cross Site Scripting (XSS) protection rule set. It performs deep level inspections of web requests and responses to look for potential XSS attacks.<br />
<br />
====12_asl_brute.conf====<br />
<br />
'''This ruleset is only available with [[ASL]] or the Real Time Rules.''' <br />
<br />
This ruleset detects authentication failures against all major web applications (Joomla, WordPress, MovableType, Drupal, ModX, ZenCart, OsCommerce, VBulletin, PHPBB and more).<br />
<br />
When used with [[ASL]], fast and "low and slow" brute force attacks can be detected and blocked in real time.<br />
<br />
Requires: Modsecurity 2.6.8 and up. <br />
<br />
'''Note: [[ASL]] is necessary to perform active response to brute force attacks.'''<br />
<br />
====13_asl_brute_enhanced.conf====<br />
<br />
Requires: Modsecurity 2.9.2 and up.<br />
<br />
These rules are for platforms that do not have either [ASL] or Atomic Protector installed. These rules create the collections in modsecurity to block brute force attacks. The defaults are > 10 failures within 60 seconds.<br />
<br />
''Note: These rules are not necessary if the systen has ASL or Atomic Protector installed, and should not be used with ASL or AP.<br />
<br />
Note 1: These rules will only work if the web server can write to the SecDataDir directory. That directory will contain sqllite databases that modsecurity will create and use to count events, without the collection modsecurity can not maintain state for composite events, like multiple login failures, and these rules will not work.''<br />
<br />
====20_asl_useragents.conf====<br />
<br />
Looks for malicious or suspicious user agents and known patterns of malicious activity. These rules require modsecurity 2.7.1 and up.<br />
<br />
====21_asl_useragents.conf====<br />
<br />
This alows the user to define a set of user-agents to block. These rules require modsecurity 2.9.3 and up.<br />
<br />
The user defined list of user-agents to block must be placed in the file bad_agents.txt, which must be in the same directory as the 21_asl_useragents.conf rules file.<br />
<br />
The format for the bad_agents.txt file is one user-agent per line, case does not matter the user-agent will be inspected against the list for any upper/lower case combinations automatically.. Regular expressions are not supported. Examples:<br />
<br />
<pre><br />
Internet Explorer 6<br />
hackk_too_12345<br />
Mozilla/991HFS.0 (Windows NT 10.3; Win128; x64) AppleWebKit/31337.36 (KHTML, like Gecko) Chrome/8675309.0.3945.88 Safari/1337.36<br />
</pre><br />
<br />
Requires: Modsecurity 2.9.3 and up.<br />
<br />
====30_asl_antispam.conf====<br />
<br />
Tuned antispam rules, designed to work with all known blogs, forums, guestbooks, CMS' and other web content management systems that allow users to post content.<br />
<br />
Requires: Modsecurity 2.6.8 and up.<br />
<br />
====30_asl_antispam_advanced.conf====<br />
<br />
(Not released yet) These are advanced spam rules. They require modsecurity 2.7.1 and up.<br />
<br />
Requires: Modsecurity 2.7.1 and up.<br />
<br />
====30_asl_antispam_referrer.conf====<br />
<br />
Rules to block referrer spam. Generally not needed in most environments if you protect web log generation tools from public access (which is the default for most control panels).<br />
<br />
Requires: Modsecurity 2.6.0 and up.<br />
<br />
====40_asl_apache2-rules.conf====<br />
<br />
This ruleset has been retired. mod_security 2.x does not work with Apache 1.x and this ruleset existed just for those rules that only worked with apache 2. As mod_security 2.x does not work with Apache 1.x there is no need for this ruleset.<br />
<br />
====50_asl_rootkits.conf====<br />
<br />
Detects and blocks known web based rootkits, PHP/ASP/PERL shells, spam tools and other malicious web applications from being installed, and in some cases from running on the system. These rules exist for cases where malicious software may already be installed on the system, this is a defense in depth rule set)<br />
<br />
Not: ASL can prevent all malware from running on the system, modsecurity is limited in this regard so if you are only using the rules you should not expect modsecurity to prevent malware from running. It may prevent it in some cases, but without kernel level protection such as that provided in [[ASL]] no WAF can stop all malware from running on the system itself.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====51_asl_rootkits.conf====<br />
<br />
These rules look for known malware names in filenames, and URLs.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====60_asl_recons.conf====<br />
<br />
Blocks known "google hacks" or webserver probes that look for vulnerable applications and signs of compromised systems running unauthorized shells, or unprotected applications that allow uploads which would give an attacker access to the system.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====61_asl_recons_dlp.conf====<br />
<br />
These rules detect Data Loss Search engine "hacks". These are search engine probes for sensitive files, often used by malicious parties to find sensitive information accidentally exposed on web servers.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====99_asl_a_redactor.conf====<br />
<br />
ASL only rule set. Requires modsecurity 2.6.0 and up. Part of the malicious code removal system. Automatically removes malicious code from web pages, such as hidden iframes, encoded javascript and other malicious code. '''Do not enable this ruleset if you are not using ASL. ''' <br />
<br />
====99_asl_exclude.conf====<br />
<br />
Post exclude rules.<br />
<br />
====98_asl_adv_redactor.conf====<br />
<br />
This is the new advanced malware removal system. This ruleset will remove malware "on the fly" from web pages. For example, it will remove hidden iframes, malicous javascript, and other malicious code.<br />
<br />
'''Requires: modsecurity 2.7.5 and up.'''<br />
<br />
====98_asl_jitp.conf====<br />
<br />
This is a special ruleset used by [[ASL]]. If you do not have [[ASL]] you can not use these rules.<br />
<br />
====99_asl_jitp.conf====<br />
<br />
Just in Time Patches. We publish JITPs daily if there is a new web application vulnerability that the 10_asl_rules.conf do not protect the system against. These are tuned rules for specific vulnerabilities in a web application.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====99_asl_a_redactor.conf====<br />
<br />
This ruleset is reserved, and is not currently used.<br />
<br />
====99_asl_redactor.conf====<br />
<br />
'''Note: Do not enable this ruleset unless you have been instructed to do so by support.'''<br />
<br />
Special ruleset - requires mod_sed to be loaded on the system which is included and supported in [[ASL]] - removes malicious code from web pages, such as hidden iframes, encoded javascript and other malicious code. We highly recommend you use this rule set - its fast, multithreads and will automagically remove malicious code from infected webpages, which can occur if an adversary is able to log into the system and modify the code, such as by SSH or by uploading the code via FTP. If you are not using [[ASL]] then you will need to make sure your system has mod_sed installed to use these rules, they will not load and therefore will not do anything without mod_sed installed. This ruleset is only supported with [[ASL]].<br />
<br />
====99_asl_redactor_post.conf====<br />
<br />
This ruleset detects malicious content in webpages, such as known malicious domains.<br />
<br />
====99_asl_scanner.conf====<br />
<br />
This is the same as 05_asl_scanner.conf, its provided in a form to run last. This is the recommended location for the scanner function, as the rules before this stop some attacks that the scanner also detects, but do this in a faster and less CPU intensive manner. Running the scanner last does not compromise or lower the effectiveness of the rules. This is just a performance enhancement. This ruleset is only supported with [[ASL]].<br />
<br />
====99_asl_z_adv_scanner.conf====<br />
<br />
'''Note: Requires [[ASL]] and modsecurity 2.9.0 and higher.'''<br />
<br />
This ruleset uses a fuzzy hash to identify potentially malicious files.<br />
<br />
Warning: This ruleset is not supported on non-ASL systems. Do not use this without ASL.<br />
<br />
==== Paranoid mode rules ====<br />
<br />
===== 15_asl_paranoid_rules.conf =====<br />
<br />
'''Note: Do not use these rules if you have not read this section.'''<br />
<br />
'''Please do not report false positives with these rules. If you encounter a false positive with a rule from this file, please use its duplicate in 10_asl_rules.conf instead. If you have a false positive with a rule from 10_asl_rules.conf, please report it to us.'''<br />
<br />
These are a special version of the 10_asl_rules.conf file, they use the same rule id:s as the 10_asl_rules.conf file. Therefore, you can not use these rules along with the 10_asl_rules.conf file. You can use one, or the other, but not both.<br />
<br />
These rules are a paranoid replacement for the 10_asl_rules.conf file. These rules do not contain any known safe mode application tuning exceptions or bypasses. These rules will generate false positives. These rules are made available for users that wish to tune their own rules, and do not wish to use a ruleset that has been tuned for false positives.<br />
<br />
For example, if you had a application that safely used the argument "url" to accept URLs:<br />
<br />
GET /application?url=http://www.example.com/safething<br />
<br />
The normal rules would allow this, if this was known to be safe for the application. <br />
<br />
The paranoid rules, however, will NOT allow this, even if this is known to be safe for the application. They will alert, and if configured (or misconfigured) also block this as an RFI attack. These rules will alert on things that may be safe or are known to be non-malicious. This will generate a lot of false positives for most users, therefore you should not use these rules if you do not want to experience a high degree of false positives. These rules exist for paranoid users, who may want to tune the rules themselves, or may wish to know about every possible potentially malicious event, even when the event may in fact not be malicious.<br />
<br />
We do not recommend you use these rules in blocking mode, instead you should use these only in detect mode, and only if you feel that your applications are doing things in a very unsafe manner. If you do wish to use these rules, make sure that you load them from a special file so you can set the default behaviour of the rules. If you do not do this, the rules will inherit you systems default behavior, which is generally to block.<br />
<br />
Example configuration lines for the paranoid rules:<br />
<br />
<pre><br />
SecDefaultAction "log,pass,auditlog,phase:2,t:none,t:lowercase,t:replaceNulls,t:compressWhitespace"<br />
Include modsecurity.paranoid.rules.d/15_asl_paranoid_rules.conf<br />
</pre><br />
<br />
You must load these rules last.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
==== Using the paranoid rules ====<br />
<br />
If you want to use the paranoid rules because you have found a vulnerability in your application that the normal rules do not block, please let us know, we would be happy to take a look at either creating a Just In Time Patch for your vulnerability, or adjusting the tuned rules to not allow this. Remember, if you use our real time rules, we provide this service for free. One easy way to find out if you have applications that have unusual vulnerabilities is to scan the application with a web vulnerability application scanner, if you find something the normal rules dont stop just let us know. We'd be delighted to put out new rules for your applications vulnerabilities.<br />
<br />
Finally, if you do you use these rules you will need to set ATOMIC_PARANOID_MODE to 1 in your modsecurity configuration. If you do not know how to do this, we do not recommend you use these rules.<br />
<br />
'''Note: Do not use this ruleset with [[ASL]]. [[ASL]] uses intelligent defense in depth, and does need this kind of ruleset to protect you. You will get a greater level of protection from ASL, without all the false positives.'''<br />
<br />
==== Beta Rules ====<br />
<br />
==== Experimental Rules ====<br />
<br />
<br />
====70_asl_csrf_experimental.conf====<br />
<br />
These are experimental CSRF mitigation rules. The 10_asl_rules.conf rules are designed to also handle some types of CSRF attacks, however these rules are for more advanced environments.<br />
<br />
These rules work by injecting javascript code into the response, and special cookies, and must be tuned for the system to prevent false positives. If you do not understand what this means, do not use these rules.<br />
<br />
'''They are currently not supported and are experimental.'''<br />
<br />
Requires: Modsecurity 2.7.0 and up.</div>Mshinnhttps://wiki.atomicorp.com/wiki/index.php/Modsecurity_rule_familiesModsecurity rule families2023-11-09T19:18:51Z<p>Mshinn: /* 21_asl_useragents.conf */</p>
<hr />
<div>The Atomicorp modsecurity rules are broken into families - please see the documentation for your platform as to which rulesets to load. <br />
<br />
====000000000000000000000000_asl_notconfigured.conf====<br />
<br />
'''This rule file should not be used.''' <br />
<br />
This file is a "canary" file included in the archive to prevent users from accidentally loading all the rule files at the same. This ruleset will prevent this condition by disabling the WAF and logging a warning that the installation instructions have not been followed.<br />
<br />
If you are getting any errors about this file and you are using a third party product that installs our rules, please contact the vendor for that product.<br />
<br />
====000_asl_threat_intelligence.conf====<br />
<br />
These rules use the Atomicorp Threat Intelligence system to detect if an IP is a known threat. These rules look for DOS, brute force, spam, known attackers and advanced threats.<br />
<br />
Note: Requires modsecurity 2.7.7 and up.<br />
<br />
====00_asl_x_searchengines.conf====<br />
<br />
'''This ruleset is Deprecated'''<br />
<br />
Note: this is a legacy ruleset and should only be used on platform that do not support lua, and may experience performance issues. Please use 00_asl_z_searchengines.conf instead.<br />
<br />
This ruleset tells the WAF to trust defined search engines, and to not block or shun them.<br />
<br />
<br />
Note: Requires modsecurity 2.7.7 and up.<br />
<br />
====00_asl_y_searchengines.conf ====<br />
<br />
'''This ruleset is Deprecated'''<br />
<br />
Note: this is a legacy ruleset and should only be used on platform that do not support lua, and may experience performance issues. Please use 00_asl_z_searchengines.conf instead.<br />
<br />
''(Available in ASL and the real time rules only)''<br />
<br />
This ruleset detects clients pretending to be a search engine, as well as valid search engines. You must have either [[ASL]] installed, or apache configured with "HostnameLookups Double" and a very fast local DNS server. <br />
<br />
These rules also allow you to auto-whitelist real search engines. To do this, you will need to either use [[ASL]], or you will need to manually set the variable WHITELIST_SEARCH_ENGINES to "1".<br />
<br />
'''Warning: If you do not have either [[ASL]] installed, or apache configured correctly to use these rules they will not work correctly.'''<br />
<br />
Note: If you do not have a fast local DNS server, do not use these rules. These rules perform forward and reverse lookups and require a fast local DNS server, otherwise you should expect your websites to be very slow.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
Excluded: Modsecurity 2.8.0. Because 2.8.0 has a serious bug in the @ipmatch code( https://github.com/SpiderLabs/ModSecurity/issues/706).<br />
<br />
====00_asl_z_searchengines.conf====<br />
<br />
'(Available in ASL and the real time rules only)''<br />
<br />
Note: The rules must be used with a [[Local DNS resolver]]. If you do not have a fast local DNS server (not a remote DNS server), do not use these rules. These rules perform forward and reverse lookups and require a fast local DNS server. Failure to use a local resolver will result in performance degradation, these rules may also not work at all in these cases.<br />
<br />
This ruleset detects clients pretending to be a search engine, as well as valid search engines. You must have a very fast local DNS server to use these rules. These rules also allow you to auto-whitelist real search engines. To do this, in the /etc/asl/config set WAF_LUA_00_SEARCHENGINE to "yes"<br />
<br />
For DIY installations, you must install the "advanced" subdirectory in your modsecurity rules directory. If you are manually extracting the rules archive files this should be created for you automatically, and will contain the actual .lua files this config file will load. <br />
<br />
Requires: Modsecurity 2.9.3 and up.<br />
<br />
====00_asl_zz_strict.conf====<br />
<br />
'''Note: Requires modsecurity 2.7.0 and higher.'''<br />
<br />
This enforces strict adherence to the HTTP RFCs.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====00_asl_0_global.conf====<br />
<br />
This is a global variable file, it is only used if you have modsecurity 2.5.13 and above installed. <br />
<br />
====00_asl_rbl.conf====<br />
<br />
This rule family checks an incoming host to see if its on a RBL. By default only the spamhaus XBL-SBL list is enabled which is operated by the Spamhaus project. This RBL is not operated or controlled by Atomicorp. Please contact Spamhaus if you have issues with the IPs on this RBL, or disable this option. Several other RBLs are including in this rule file and must be either enabled in ASL (ASL will generate this rule file) or if you are not running ASL you must manually enable the other RBLs.<br />
<br />
This ruleset will look up every request in the DNS to see if its on a blacklist, and will not finish serving the request until the DNS server responds. This can slow down requests if the DNS server is slow. Basically, web requests will move at the speed of the DNS servers replies.<br />
<br />
If your web server is responding slowly to requests, and you have this ruleset enabled your DNS server is too slow to meet your lookup needs. You will need to either disable this ruleset, or tune your DNS server to respond to queries more quickly.<br />
<br />
''If you use this ruleset, make sure you have a fast locally caching DNS server. This ruleset will query spamhaus for every incoming IP to see if its on a blacklist, if your DNS is slow (or non local) this will make your system seem to crawl, as the read request will be blocked by Apache until it finished the DNS lookup. If you do not have a fast and local DNS server, do not use this ruleset.''<br />
<br />
Requires: Modsecurity 2.6.0 and up.<br />
<br />
====00_asl_blacklist.conf====<br />
<br />
Allows you to blacklist hosts or CIDRs from the WAF.<br />
<br />
Requires: Modsecurity 2.9.0 and up.<br />
<br />
The format is single IPs or CIDRs per line, for example:<br />
<br />
<pre><br />
1.2.3.4<br />
5.6.7.0/24<br />
8.9.0.0/16<br />
</pre><br />
<br />
Note: You must define your own blacklist file. The default location is /etc/asl/blacklist. <br />
<br />
====00_asl_whitelist.conf====<br />
<br />
Allows you to whitelist hosts from the WAF.<br />
<br />
Requires: Modsecurity 2.9.0 and up.<br />
<br />
The format is single IPs or CIDRs per line, for example:<br />
<br />
<pre><br />
1.2.3.4<br />
5.6.7.0/24<br />
8.9.0.0/16<br />
</pre><br />
<br />
Note: You must define your own whitelist entires. The default location is /etc/asl/whitelist. '''Do not use the whitelist.txt file. It is not used for this rule. We do not provide a default whitelist for these rules.'''<br />
<br />
Note: Requires modsecurity 2.7.7 and up.<br />
<br />
====01_asl_content.conf====<br />
<br />
These rules restrict the server to known content types that the WAF can correctly decipher.<br />
<br />
Requires: Apache, and Modsecurity 2.9.2 and up.<br />
<br />
==== 01_asl_domain_blocks.conf====<br />
<br />
Optional ruleset that allows you to block connections from hosts, based on their DNS hostname and/or domain. This is a user defined list.<br />
<br />
Domains and/or hostnames are stored in this file:<br />
<br />
/etc/asl/custom-domain-blocks<br />
<br />
The format is one entry, per line, for example:<br />
<br />
<pre><br />
example.com<br />
www.hostname.some-tld<br />
</pre><br />
<br />
Note: You must have either [[ASL]] installed, or apache configured with "HostnameLookups Double" and a very fast local DNS server for these rules to work.\<br />
<br />
Note: Requires modsecurity 2.7.7 and up.<br />
<br />
====01_asl_rules_special.conf====<br />
<br />
This ruleset changes the behavior of the WAF for applications that behavior in nonstandard ways. For example, OTRS uses ";" and not "&" for argument separation. You should not use these rules if you do not have OTRS installed on your system.<br />
<br />
If you do not know what this means, you do not need this ruleset.<br />
<br />
Requires: Modsecurity 2.7.0 and up. <br />
<br />
Note: If you get an error regarding SecArgumentSeparator with these rules, your modsecurity configuration is being loaded too late in your Apache stack. Ensure that your modsecurity configuration is loaded first. This has been seen with cpanel when not using [[ASL]]. Please contact your apache vendor for assistance with this issue, or use [[ASL]] which will fix your apache configuration so this error does not occur.<br />
<br />
====03_asl_dos.conf====<br />
<br />
This ruleset protects apache from slow DOS attacks. It is only supported with Apache and requires the installation of the mod_reqtimeout module. The rule is fail safe with Apache, that is if the mod_reqtimeout module is not loaded the rules also will not load into Apache.<br />
<br />
[[ASL]] automatically ensures mod_reqtimeout is installed. If you are a rules only user please contact your Apache vendor for assistance installing this module.<br />
<br />
Note: Requires Apache and modsecurity 2.7.7 and up.<br />
<br />
====05_asl_exclude.conf====<br />
<br />
Pre-load rule exclusion list. Turns off rules that need to be disabled early in the process. ASL manages this process automatically.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====00_asl_z_antievasion.conf====<br />
<br />
This is a ruleset to detect attempts to bypass modsecurity itself, through evasion methods for example. Do not use this ruleset unless you are using 2.6.1 and up.<br />
<br />
====05_asl_scanner.conf ====<br />
<br />
Deprecated.<br />
<br />
====06_asl_honeypot.conf ====<br />
<br />
This ruleset lets you define URLs you want to specifically block, for example the URL of an application that may not be installed on the system. This can work as a honeypot of sorts, allowing the system to be configured to treat probes for non-existant applications as attacks. [[ASL]] has a more advanced system that can detect when URLs do not correspond to files on the system, which can be used in place of this ruleset or to augment it.<br />
<br />
For this ruleset to work, populate the honeypot-files.txt file in the same directory as 06_asl_honeypot.conf with one URL per line. For example:<br />
<br />
<br />
<pre><br />
/application/not/installed/on/system<br />
file_name_not_on_system.extension<br />
</pre><br />
<br />
==== 11_asl_rules.conf====<br />
<br />
This ruleset is reserved and is not currently used.<br />
<br />
====10_asl_antimalware.conf====<br />
<br />
Checks payload and RFI contents for known sources of malware and malware payloads and will block them.<br />
<br />
Requires: Modsecurity 2.6.0 and up.<br />
<br />
====09_asl_rules.conf====<br />
<br />
These are supplementation rules to the 10_asl_rules.conf, but only work on 2.6.6 and up installations. Do not use this ruleset unless you are using 2.6.6 and up.<br />
<br />
====10_asl_rules.conf ====<br />
<br />
The main rules, contains all the generic security rules to protect against classes of attacks, such as SQL injection, XSS, code injection, recursion, etc. '''These rules require modsecurity 2.9.1 and above.'''<br />
<br />
Requires: Modsecurity 2.9.1 and up.<br />
<br />
====11_asl_adv_rules.conf====<br />
<br />
These are advanced rules, and '''can only be used with modsecurity 2.7.5 and above.'''<br />
<br />
Requires: Modsecurity 2.7.5 and up.<br />
<br />
====11_asl_data_loss.conf====<br />
<br />
Experimental data leakage rules. Looks for credit card numbers and other potentially sensitive information leaking from the system.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====11_asl_brute_enhanced.conf====<br />
<br />
Requires: Modsecurity 2.9.2 and up.<br />
<br />
These rules are for platforms that do not have either [[ASL]] or Atomic Protector installed. These rules create the collections in modsecurity to block brute force attacks. The defaults are > 5 failures within 60 seconds.<br />
<br />
''Note: These rules are not necessary if the systen has ASL or Atomic Protector installed, and should not be used with ASL or AP.<br />
<br />
''Note 1: These rules will only work if the web server can write to the SecDataDir directory. That directory will contain sqllite databases that modsecurity will create and use to count events, without the collection modsecurity can not maintain state for composite events, like multiple login failures, and these rules will not work.''<br />
<br />
''Note 2: Enable this setting in /etc/asl/config to create the collections:''<br />
<br />
<br />
https://wiki.atomicorp.com/wiki/index.php/Aum_configuration#MODSEC_00_THREAT<br />
<br />
====12_asl_adv_xss_rules.conf====<br />
<br />
'''This ruleset require mod_security 2.9.0 and above.'''<br />
<br />
This is the advanced Cross Site Scripting (XSS) protection rule set. It performs deep level inspections of web requests and responses to look for potential XSS attacks.<br />
<br />
====12_asl_brute.conf====<br />
<br />
'''This ruleset is only available with [[ASL]] or the Real Time Rules.''' <br />
<br />
This ruleset detects authentication failures against all major web applications (Joomla, WordPress, MovableType, Drupal, ModX, ZenCart, OsCommerce, VBulletin, PHPBB and more).<br />
<br />
When used with [[ASL]], fast and "low and slow" brute force attacks can be detected and blocked in real time.<br />
<br />
Requires: Modsecurity 2.6.8 and up. <br />
<br />
'''Note: [[ASL]] is necessary to perform active response to brute force attacks.'''<br />
<br />
====13_asl_brute_enhanced.conf====<br />
<br />
Requires: Modsecurity 2.9.2 and up.<br />
<br />
These rules are for platforms that do not have either [ASL] or Atomic Protector installed. These rules create the collections in modsecurity to block brute force attacks. The defaults are > 10 failures within 60 seconds.<br />
<br />
''Note: These rules are not necessary if the systen has ASL or Atomic Protector installed, and should not be used with ASL or AP.<br />
<br />
Note 1: These rules will only work if the web server can write to the SecDataDir directory. That directory will contain sqllite databases that modsecurity will create and use to count events, without the collection modsecurity can not maintain state for composite events, like multiple login failures, and these rules will not work.''<br />
<br />
====20_asl_useragents.conf====<br />
<br />
Looks for malicious or suspicious user agents and known patterns of malicious activity. These rules require modsecurity 2.7.1 and up.<br />
<br />
====21_asl_useragents.conf====<br />
<br />
This alows the user to define a set of user-agents to block. These rules require modsecurity 2.9.3 and up.<br />
<br />
The user defined list of user-agents to block must be placed in the file bad_agents.txt, which must be in the same directory as the 21_asl_useragents.conf rules file.<br />
<br />
The format for the bad_agents.txt file is one user-agent per line, case does not matter the user-agent will be inspected against the list for any upper/lower case combinations automatically.. Regular expressions are not supported. Examples:<br />
<br />
<pre><br />
Internet Explorer 6<br />
hackk_too_12345<br />
</pre><br />
<br />
Requires: Modsecurity 2.9.3 and up.<br />
<br />
====30_asl_antispam.conf====<br />
<br />
Tuned antispam rules, designed to work with all known blogs, forums, guestbooks, CMS' and other web content management systems that allow users to post content.<br />
<br />
Requires: Modsecurity 2.6.8 and up.<br />
<br />
====30_asl_antispam_advanced.conf====<br />
<br />
(Not released yet) These are advanced spam rules. They require modsecurity 2.7.1 and up.<br />
<br />
Requires: Modsecurity 2.7.1 and up.<br />
<br />
====30_asl_antispam_referrer.conf====<br />
<br />
Rules to block referrer spam. Generally not needed in most environments if you protect web log generation tools from public access (which is the default for most control panels).<br />
<br />
Requires: Modsecurity 2.6.0 and up.<br />
<br />
====40_asl_apache2-rules.conf====<br />
<br />
This ruleset has been retired. mod_security 2.x does not work with Apache 1.x and this ruleset existed just for those rules that only worked with apache 2. As mod_security 2.x does not work with Apache 1.x there is no need for this ruleset.<br />
<br />
====50_asl_rootkits.conf====<br />
<br />
Detects and blocks known web based rootkits, PHP/ASP/PERL shells, spam tools and other malicious web applications from being installed, and in some cases from running on the system. These rules exist for cases where malicious software may already be installed on the system, this is a defense in depth rule set)<br />
<br />
Not: ASL can prevent all malware from running on the system, modsecurity is limited in this regard so if you are only using the rules you should not expect modsecurity to prevent malware from running. It may prevent it in some cases, but without kernel level protection such as that provided in [[ASL]] no WAF can stop all malware from running on the system itself.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====51_asl_rootkits.conf====<br />
<br />
These rules look for known malware names in filenames, and URLs.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====60_asl_recons.conf====<br />
<br />
Blocks known "google hacks" or webserver probes that look for vulnerable applications and signs of compromised systems running unauthorized shells, or unprotected applications that allow uploads which would give an attacker access to the system.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====61_asl_recons_dlp.conf====<br />
<br />
These rules detect Data Loss Search engine "hacks". These are search engine probes for sensitive files, often used by malicious parties to find sensitive information accidentally exposed on web servers.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====99_asl_a_redactor.conf====<br />
<br />
ASL only rule set. Requires modsecurity 2.6.0 and up. Part of the malicious code removal system. Automatically removes malicious code from web pages, such as hidden iframes, encoded javascript and other malicious code. '''Do not enable this ruleset if you are not using ASL. ''' <br />
<br />
====99_asl_exclude.conf====<br />
<br />
Post exclude rules.<br />
<br />
====98_asl_adv_redactor.conf====<br />
<br />
This is the new advanced malware removal system. This ruleset will remove malware "on the fly" from web pages. For example, it will remove hidden iframes, malicous javascript, and other malicious code.<br />
<br />
'''Requires: modsecurity 2.7.5 and up.'''<br />
<br />
====98_asl_jitp.conf====<br />
<br />
This is a special ruleset used by [[ASL]]. If you do not have [[ASL]] you can not use these rules.<br />
<br />
====99_asl_jitp.conf====<br />
<br />
Just in Time Patches. We publish JITPs daily if there is a new web application vulnerability that the 10_asl_rules.conf do not protect the system against. These are tuned rules for specific vulnerabilities in a web application.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====99_asl_a_redactor.conf====<br />
<br />
This ruleset is reserved, and is not currently used.<br />
<br />
====99_asl_redactor.conf====<br />
<br />
'''Note: Do not enable this ruleset unless you have been instructed to do so by support.'''<br />
<br />
Special ruleset - requires mod_sed to be loaded on the system which is included and supported in [[ASL]] - removes malicious code from web pages, such as hidden iframes, encoded javascript and other malicious code. We highly recommend you use this rule set - its fast, multithreads and will automagically remove malicious code from infected webpages, which can occur if an adversary is able to log into the system and modify the code, such as by SSH or by uploading the code via FTP. If you are not using [[ASL]] then you will need to make sure your system has mod_sed installed to use these rules, they will not load and therefore will not do anything without mod_sed installed. This ruleset is only supported with [[ASL]].<br />
<br />
====99_asl_redactor_post.conf====<br />
<br />
This ruleset detects malicious content in webpages, such as known malicious domains.<br />
<br />
====99_asl_scanner.conf====<br />
<br />
This is the same as 05_asl_scanner.conf, its provided in a form to run last. This is the recommended location for the scanner function, as the rules before this stop some attacks that the scanner also detects, but do this in a faster and less CPU intensive manner. Running the scanner last does not compromise or lower the effectiveness of the rules. This is just a performance enhancement. This ruleset is only supported with [[ASL]].<br />
<br />
====99_asl_z_adv_scanner.conf====<br />
<br />
'''Note: Requires [[ASL]] and modsecurity 2.9.0 and higher.'''<br />
<br />
This ruleset uses a fuzzy hash to identify potentially malicious files.<br />
<br />
Warning: This ruleset is not supported on non-ASL systems. Do not use this without ASL.<br />
<br />
==== Paranoid mode rules ====<br />
<br />
===== 15_asl_paranoid_rules.conf =====<br />
<br />
'''Note: Do not use these rules if you have not read this section.'''<br />
<br />
'''Please do not report false positives with these rules. If you encounter a false positive with a rule from this file, please use its duplicate in 10_asl_rules.conf instead. If you have a false positive with a rule from 10_asl_rules.conf, please report it to us.'''<br />
<br />
These are a special version of the 10_asl_rules.conf file, they use the same rule id:s as the 10_asl_rules.conf file. Therefore, you can not use these rules along with the 10_asl_rules.conf file. You can use one, or the other, but not both.<br />
<br />
These rules are a paranoid replacement for the 10_asl_rules.conf file. These rules do not contain any known safe mode application tuning exceptions or bypasses. These rules will generate false positives. These rules are made available for users that wish to tune their own rules, and do not wish to use a ruleset that has been tuned for false positives.<br />
<br />
For example, if you had a application that safely used the argument "url" to accept URLs:<br />
<br />
GET /application?url=http://www.example.com/safething<br />
<br />
The normal rules would allow this, if this was known to be safe for the application. <br />
<br />
The paranoid rules, however, will NOT allow this, even if this is known to be safe for the application. They will alert, and if configured (or misconfigured) also block this as an RFI attack. These rules will alert on things that may be safe or are known to be non-malicious. This will generate a lot of false positives for most users, therefore you should not use these rules if you do not want to experience a high degree of false positives. These rules exist for paranoid users, who may want to tune the rules themselves, or may wish to know about every possible potentially malicious event, even when the event may in fact not be malicious.<br />
<br />
We do not recommend you use these rules in blocking mode, instead you should use these only in detect mode, and only if you feel that your applications are doing things in a very unsafe manner. If you do wish to use these rules, make sure that you load them from a special file so you can set the default behaviour of the rules. If you do not do this, the rules will inherit you systems default behavior, which is generally to block.<br />
<br />
Example configuration lines for the paranoid rules:<br />
<br />
<pre><br />
SecDefaultAction "log,pass,auditlog,phase:2,t:none,t:lowercase,t:replaceNulls,t:compressWhitespace"<br />
Include modsecurity.paranoid.rules.d/15_asl_paranoid_rules.conf<br />
</pre><br />
<br />
You must load these rules last.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
==== Using the paranoid rules ====<br />
<br />
If you want to use the paranoid rules because you have found a vulnerability in your application that the normal rules do not block, please let us know, we would be happy to take a look at either creating a Just In Time Patch for your vulnerability, or adjusting the tuned rules to not allow this. Remember, if you use our real time rules, we provide this service for free. One easy way to find out if you have applications that have unusual vulnerabilities is to scan the application with a web vulnerability application scanner, if you find something the normal rules dont stop just let us know. We'd be delighted to put out new rules for your applications vulnerabilities.<br />
<br />
Finally, if you do you use these rules you will need to set ATOMIC_PARANOID_MODE to 1 in your modsecurity configuration. If you do not know how to do this, we do not recommend you use these rules.<br />
<br />
'''Note: Do not use this ruleset with [[ASL]]. [[ASL]] uses intelligent defense in depth, and does need this kind of ruleset to protect you. You will get a greater level of protection from ASL, without all the false positives.'''<br />
<br />
==== Beta Rules ====<br />
<br />
==== Experimental Rules ====<br />
<br />
<br />
====70_asl_csrf_experimental.conf====<br />
<br />
These are experimental CSRF mitigation rules. The 10_asl_rules.conf rules are designed to also handle some types of CSRF attacks, however these rules are for more advanced environments.<br />
<br />
These rules work by injecting javascript code into the response, and special cookies, and must be tuned for the system to prevent false positives. If you do not understand what this means, do not use these rules.<br />
<br />
'''They are currently not supported and are experimental.'''<br />
<br />
Requires: Modsecurity 2.7.0 and up.</div>Mshinnhttps://wiki.atomicorp.com/wiki/index.php/Modsecurity_rule_familiesModsecurity rule families2023-11-09T19:15:13Z<p>Mshinn: </p>
<hr />
<div>The Atomicorp modsecurity rules are broken into families - please see the documentation for your platform as to which rulesets to load. <br />
<br />
====000000000000000000000000_asl_notconfigured.conf====<br />
<br />
'''This rule file should not be used.''' <br />
<br />
This file is a "canary" file included in the archive to prevent users from accidentally loading all the rule files at the same. This ruleset will prevent this condition by disabling the WAF and logging a warning that the installation instructions have not been followed.<br />
<br />
If you are getting any errors about this file and you are using a third party product that installs our rules, please contact the vendor for that product.<br />
<br />
====000_asl_threat_intelligence.conf====<br />
<br />
These rules use the Atomicorp Threat Intelligence system to detect if an IP is a known threat. These rules look for DOS, brute force, spam, known attackers and advanced threats.<br />
<br />
Note: Requires modsecurity 2.7.7 and up.<br />
<br />
====00_asl_x_searchengines.conf====<br />
<br />
'''This ruleset is Deprecated'''<br />
<br />
Note: this is a legacy ruleset and should only be used on platform that do not support lua, and may experience performance issues. Please use 00_asl_z_searchengines.conf instead.<br />
<br />
This ruleset tells the WAF to trust defined search engines, and to not block or shun them.<br />
<br />
<br />
Note: Requires modsecurity 2.7.7 and up.<br />
<br />
====00_asl_y_searchengines.conf ====<br />
<br />
'''This ruleset is Deprecated'''<br />
<br />
Note: this is a legacy ruleset and should only be used on platform that do not support lua, and may experience performance issues. Please use 00_asl_z_searchengines.conf instead.<br />
<br />
''(Available in ASL and the real time rules only)''<br />
<br />
This ruleset detects clients pretending to be a search engine, as well as valid search engines. You must have either [[ASL]] installed, or apache configured with "HostnameLookups Double" and a very fast local DNS server. <br />
<br />
These rules also allow you to auto-whitelist real search engines. To do this, you will need to either use [[ASL]], or you will need to manually set the variable WHITELIST_SEARCH_ENGINES to "1".<br />
<br />
'''Warning: If you do not have either [[ASL]] installed, or apache configured correctly to use these rules they will not work correctly.'''<br />
<br />
Note: If you do not have a fast local DNS server, do not use these rules. These rules perform forward and reverse lookups and require a fast local DNS server, otherwise you should expect your websites to be very slow.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
Excluded: Modsecurity 2.8.0. Because 2.8.0 has a serious bug in the @ipmatch code( https://github.com/SpiderLabs/ModSecurity/issues/706).<br />
<br />
====00_asl_z_searchengines.conf====<br />
<br />
'(Available in ASL and the real time rules only)''<br />
<br />
Note: The rules must be used with a [[Local DNS resolver]]. If you do not have a fast local DNS server (not a remote DNS server), do not use these rules. These rules perform forward and reverse lookups and require a fast local DNS server. Failure to use a local resolver will result in performance degradation, these rules may also not work at all in these cases.<br />
<br />
This ruleset detects clients pretending to be a search engine, as well as valid search engines. You must have a very fast local DNS server to use these rules. These rules also allow you to auto-whitelist real search engines. To do this, in the /etc/asl/config set WAF_LUA_00_SEARCHENGINE to "yes"<br />
<br />
For DIY installations, you must install the "advanced" subdirectory in your modsecurity rules directory. If you are manually extracting the rules archive files this should be created for you automatically, and will contain the actual .lua files this config file will load. <br />
<br />
Requires: Modsecurity 2.9.3 and up.<br />
<br />
====00_asl_zz_strict.conf====<br />
<br />
'''Note: Requires modsecurity 2.7.0 and higher.'''<br />
<br />
This enforces strict adherence to the HTTP RFCs.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====00_asl_0_global.conf====<br />
<br />
This is a global variable file, it is only used if you have modsecurity 2.5.13 and above installed. <br />
<br />
====00_asl_rbl.conf====<br />
<br />
This rule family checks an incoming host to see if its on a RBL. By default only the spamhaus XBL-SBL list is enabled which is operated by the Spamhaus project. This RBL is not operated or controlled by Atomicorp. Please contact Spamhaus if you have issues with the IPs on this RBL, or disable this option. Several other RBLs are including in this rule file and must be either enabled in ASL (ASL will generate this rule file) or if you are not running ASL you must manually enable the other RBLs.<br />
<br />
This ruleset will look up every request in the DNS to see if its on a blacklist, and will not finish serving the request until the DNS server responds. This can slow down requests if the DNS server is slow. Basically, web requests will move at the speed of the DNS servers replies.<br />
<br />
If your web server is responding slowly to requests, and you have this ruleset enabled your DNS server is too slow to meet your lookup needs. You will need to either disable this ruleset, or tune your DNS server to respond to queries more quickly.<br />
<br />
''If you use this ruleset, make sure you have a fast locally caching DNS server. This ruleset will query spamhaus for every incoming IP to see if its on a blacklist, if your DNS is slow (or non local) this will make your system seem to crawl, as the read request will be blocked by Apache until it finished the DNS lookup. If you do not have a fast and local DNS server, do not use this ruleset.''<br />
<br />
Requires: Modsecurity 2.6.0 and up.<br />
<br />
====00_asl_blacklist.conf====<br />
<br />
Allows you to blacklist hosts or CIDRs from the WAF.<br />
<br />
Requires: Modsecurity 2.9.0 and up.<br />
<br />
The format is single IPs or CIDRs per line, for example:<br />
<br />
<pre><br />
1.2.3.4<br />
5.6.7.0/24<br />
8.9.0.0/16<br />
</pre><br />
<br />
Note: You must define your own blacklist file. The default location is /etc/asl/blacklist. <br />
<br />
====00_asl_whitelist.conf====<br />
<br />
Allows you to whitelist hosts from the WAF.<br />
<br />
Requires: Modsecurity 2.9.0 and up.<br />
<br />
The format is single IPs or CIDRs per line, for example:<br />
<br />
<pre><br />
1.2.3.4<br />
5.6.7.0/24<br />
8.9.0.0/16<br />
</pre><br />
<br />
Note: You must define your own whitelist entires. The default location is /etc/asl/whitelist. '''Do not use the whitelist.txt file. It is not used for this rule. We do not provide a default whitelist for these rules.'''<br />
<br />
Note: Requires modsecurity 2.7.7 and up.<br />
<br />
====01_asl_content.conf====<br />
<br />
These rules restrict the server to known content types that the WAF can correctly decipher.<br />
<br />
Requires: Apache, and Modsecurity 2.9.2 and up.<br />
<br />
==== 01_asl_domain_blocks.conf====<br />
<br />
Optional ruleset that allows you to block connections from hosts, based on their DNS hostname and/or domain. This is a user defined list.<br />
<br />
Domains and/or hostnames are stored in this file:<br />
<br />
/etc/asl/custom-domain-blocks<br />
<br />
The format is one entry, per line, for example:<br />
<br />
<pre><br />
example.com<br />
www.hostname.some-tld<br />
</pre><br />
<br />
Note: You must have either [[ASL]] installed, or apache configured with "HostnameLookups Double" and a very fast local DNS server for these rules to work.\<br />
<br />
Note: Requires modsecurity 2.7.7 and up.<br />
<br />
====01_asl_rules_special.conf====<br />
<br />
This ruleset changes the behavior of the WAF for applications that behavior in nonstandard ways. For example, OTRS uses ";" and not "&" for argument separation. You should not use these rules if you do not have OTRS installed on your system.<br />
<br />
If you do not know what this means, you do not need this ruleset.<br />
<br />
Requires: Modsecurity 2.7.0 and up. <br />
<br />
Note: If you get an error regarding SecArgumentSeparator with these rules, your modsecurity configuration is being loaded too late in your Apache stack. Ensure that your modsecurity configuration is loaded first. This has been seen with cpanel when not using [[ASL]]. Please contact your apache vendor for assistance with this issue, or use [[ASL]] which will fix your apache configuration so this error does not occur.<br />
<br />
====03_asl_dos.conf====<br />
<br />
This ruleset protects apache from slow DOS attacks. It is only supported with Apache and requires the installation of the mod_reqtimeout module. The rule is fail safe with Apache, that is if the mod_reqtimeout module is not loaded the rules also will not load into Apache.<br />
<br />
[[ASL]] automatically ensures mod_reqtimeout is installed. If you are a rules only user please contact your Apache vendor for assistance installing this module.<br />
<br />
Note: Requires Apache and modsecurity 2.7.7 and up.<br />
<br />
====05_asl_exclude.conf====<br />
<br />
Pre-load rule exclusion list. Turns off rules that need to be disabled early in the process. ASL manages this process automatically.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====00_asl_z_antievasion.conf====<br />
<br />
This is a ruleset to detect attempts to bypass modsecurity itself, through evasion methods for example. Do not use this ruleset unless you are using 2.6.1 and up.<br />
<br />
====05_asl_scanner.conf ====<br />
<br />
Deprecated.<br />
<br />
====06_asl_honeypot.conf ====<br />
<br />
This ruleset lets you define URLs you want to specifically block, for example the URL of an application that may not be installed on the system. This can work as a honeypot of sorts, allowing the system to be configured to treat probes for non-existant applications as attacks. [[ASL]] has a more advanced system that can detect when URLs do not correspond to files on the system, which can be used in place of this ruleset or to augment it.<br />
<br />
For this ruleset to work, populate the honeypot-files.txt file in the same directory as 06_asl_honeypot.conf with one URL per line. For example:<br />
<br />
<br />
<pre><br />
/application/not/installed/on/system<br />
file_name_not_on_system.extension<br />
</pre><br />
<br />
==== 11_asl_rules.conf====<br />
<br />
This ruleset is reserved and is not currently used.<br />
<br />
====10_asl_antimalware.conf====<br />
<br />
Checks payload and RFI contents for known sources of malware and malware payloads and will block them.<br />
<br />
Requires: Modsecurity 2.6.0 and up.<br />
<br />
====09_asl_rules.conf====<br />
<br />
These are supplementation rules to the 10_asl_rules.conf, but only work on 2.6.6 and up installations. Do not use this ruleset unless you are using 2.6.6 and up.<br />
<br />
====10_asl_rules.conf ====<br />
<br />
The main rules, contains all the generic security rules to protect against classes of attacks, such as SQL injection, XSS, code injection, recursion, etc. '''These rules require modsecurity 2.9.1 and above.'''<br />
<br />
Requires: Modsecurity 2.9.1 and up.<br />
<br />
====11_asl_adv_rules.conf====<br />
<br />
These are advanced rules, and '''can only be used with modsecurity 2.7.5 and above.'''<br />
<br />
Requires: Modsecurity 2.7.5 and up.<br />
<br />
====11_asl_data_loss.conf====<br />
<br />
Experimental data leakage rules. Looks for credit card numbers and other potentially sensitive information leaking from the system.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====11_asl_brute_enhanced.conf====<br />
<br />
Requires: Modsecurity 2.9.2 and up.<br />
<br />
These rules are for platforms that do not have either [[ASL]] or Atomic Protector installed. These rules create the collections in modsecurity to block brute force attacks. The defaults are > 5 failures within 60 seconds.<br />
<br />
''Note: These rules are not necessary if the systen has ASL or Atomic Protector installed, and should not be used with ASL or AP.<br />
<br />
''Note 1: These rules will only work if the web server can write to the SecDataDir directory. That directory will contain sqllite databases that modsecurity will create and use to count events, without the collection modsecurity can not maintain state for composite events, like multiple login failures, and these rules will not work.''<br />
<br />
''Note 2: Enable this setting in /etc/asl/config to create the collections:''<br />
<br />
<br />
https://wiki.atomicorp.com/wiki/index.php/Aum_configuration#MODSEC_00_THREAT<br />
<br />
====12_asl_adv_xss_rules.conf====<br />
<br />
'''This ruleset require mod_security 2.9.0 and above.'''<br />
<br />
This is the advanced Cross Site Scripting (XSS) protection rule set. It performs deep level inspections of web requests and responses to look for potential XSS attacks.<br />
<br />
====12_asl_brute.conf====<br />
<br />
'''This ruleset is only available with [[ASL]] or the Real Time Rules.''' <br />
<br />
This ruleset detects authentication failures against all major web applications (Joomla, WordPress, MovableType, Drupal, ModX, ZenCart, OsCommerce, VBulletin, PHPBB and more).<br />
<br />
When used with [[ASL]], fast and "low and slow" brute force attacks can be detected and blocked in real time.<br />
<br />
Requires: Modsecurity 2.6.8 and up. <br />
<br />
'''Note: [[ASL]] is necessary to perform active response to brute force attacks.'''<br />
<br />
====13_asl_brute_enhanced.conf====<br />
<br />
Requires: Modsecurity 2.9.2 and up.<br />
<br />
These rules are for platforms that do not have either [ASL] or Atomic Protector installed. These rules create the collections in modsecurity to block brute force attacks. The defaults are > 10 failures within 60 seconds.<br />
<br />
''Note: These rules are not necessary if the systen has ASL or Atomic Protector installed, and should not be used with ASL or AP.<br />
<br />
Note 1: These rules will only work if the web server can write to the SecDataDir directory. That directory will contain sqllite databases that modsecurity will create and use to count events, without the collection modsecurity can not maintain state for composite events, like multiple login failures, and these rules will not work.''<br />
<br />
====20_asl_useragents.conf====<br />
<br />
Looks for malicious or suspicious user agents and known patterns of malicious activity. These rules require modsecurity 2.7.1 and up.<br />
<br />
====21_asl_useragents.conf====<br />
<br />
This alows the user to define a set of user-agents to block. These rules require modsecurity 2.9.3 and up.<br />
<br />
Requires: Modsecurity 2.9.3 and up.<br />
<br />
====30_asl_antispam.conf====<br />
<br />
Tuned antispam rules, designed to work with all known blogs, forums, guestbooks, CMS' and other web content management systems that allow users to post content.<br />
<br />
Requires: Modsecurity 2.6.8 and up.<br />
<br />
====30_asl_antispam_advanced.conf====<br />
<br />
(Not released yet) These are advanced spam rules. They require modsecurity 2.7.1 and up.<br />
<br />
Requires: Modsecurity 2.7.1 and up.<br />
<br />
====30_asl_antispam_referrer.conf====<br />
<br />
Rules to block referrer spam. Generally not needed in most environments if you protect web log generation tools from public access (which is the default for most control panels).<br />
<br />
Requires: Modsecurity 2.6.0 and up.<br />
<br />
====40_asl_apache2-rules.conf====<br />
<br />
This ruleset has been retired. mod_security 2.x does not work with Apache 1.x and this ruleset existed just for those rules that only worked with apache 2. As mod_security 2.x does not work with Apache 1.x there is no need for this ruleset.<br />
<br />
====50_asl_rootkits.conf====<br />
<br />
Detects and blocks known web based rootkits, PHP/ASP/PERL shells, spam tools and other malicious web applications from being installed, and in some cases from running on the system. These rules exist for cases where malicious software may already be installed on the system, this is a defense in depth rule set)<br />
<br />
Not: ASL can prevent all malware from running on the system, modsecurity is limited in this regard so if you are only using the rules you should not expect modsecurity to prevent malware from running. It may prevent it in some cases, but without kernel level protection such as that provided in [[ASL]] no WAF can stop all malware from running on the system itself.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====51_asl_rootkits.conf====<br />
<br />
These rules look for known malware names in filenames, and URLs.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====60_asl_recons.conf====<br />
<br />
Blocks known "google hacks" or webserver probes that look for vulnerable applications and signs of compromised systems running unauthorized shells, or unprotected applications that allow uploads which would give an attacker access to the system.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====61_asl_recons_dlp.conf====<br />
<br />
These rules detect Data Loss Search engine "hacks". These are search engine probes for sensitive files, often used by malicious parties to find sensitive information accidentally exposed on web servers.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====99_asl_a_redactor.conf====<br />
<br />
ASL only rule set. Requires modsecurity 2.6.0 and up. Part of the malicious code removal system. Automatically removes malicious code from web pages, such as hidden iframes, encoded javascript and other malicious code. '''Do not enable this ruleset if you are not using ASL. ''' <br />
<br />
====99_asl_exclude.conf====<br />
<br />
Post exclude rules.<br />
<br />
====98_asl_adv_redactor.conf====<br />
<br />
This is the new advanced malware removal system. This ruleset will remove malware "on the fly" from web pages. For example, it will remove hidden iframes, malicous javascript, and other malicious code.<br />
<br />
'''Requires: modsecurity 2.7.5 and up.'''<br />
<br />
====98_asl_jitp.conf====<br />
<br />
This is a special ruleset used by [[ASL]]. If you do not have [[ASL]] you can not use these rules.<br />
<br />
====99_asl_jitp.conf====<br />
<br />
Just in Time Patches. We publish JITPs daily if there is a new web application vulnerability that the 10_asl_rules.conf do not protect the system against. These are tuned rules for specific vulnerabilities in a web application.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====99_asl_a_redactor.conf====<br />
<br />
This ruleset is reserved, and is not currently used.<br />
<br />
====99_asl_redactor.conf====<br />
<br />
'''Note: Do not enable this ruleset unless you have been instructed to do so by support.'''<br />
<br />
Special ruleset - requires mod_sed to be loaded on the system which is included and supported in [[ASL]] - removes malicious code from web pages, such as hidden iframes, encoded javascript and other malicious code. We highly recommend you use this rule set - its fast, multithreads and will automagically remove malicious code from infected webpages, which can occur if an adversary is able to log into the system and modify the code, such as by SSH or by uploading the code via FTP. If you are not using [[ASL]] then you will need to make sure your system has mod_sed installed to use these rules, they will not load and therefore will not do anything without mod_sed installed. This ruleset is only supported with [[ASL]].<br />
<br />
====99_asl_redactor_post.conf====<br />
<br />
This ruleset detects malicious content in webpages, such as known malicious domains.<br />
<br />
====99_asl_scanner.conf====<br />
<br />
This is the same as 05_asl_scanner.conf, its provided in a form to run last. This is the recommended location for the scanner function, as the rules before this stop some attacks that the scanner also detects, but do this in a faster and less CPU intensive manner. Running the scanner last does not compromise or lower the effectiveness of the rules. This is just a performance enhancement. This ruleset is only supported with [[ASL]].<br />
<br />
====99_asl_z_adv_scanner.conf====<br />
<br />
'''Note: Requires [[ASL]] and modsecurity 2.9.0 and higher.'''<br />
<br />
This ruleset uses a fuzzy hash to identify potentially malicious files.<br />
<br />
Warning: This ruleset is not supported on non-ASL systems. Do not use this without ASL.<br />
<br />
==== Paranoid mode rules ====<br />
<br />
===== 15_asl_paranoid_rules.conf =====<br />
<br />
'''Note: Do not use these rules if you have not read this section.'''<br />
<br />
'''Please do not report false positives with these rules. If you encounter a false positive with a rule from this file, please use its duplicate in 10_asl_rules.conf instead. If you have a false positive with a rule from 10_asl_rules.conf, please report it to us.'''<br />
<br />
These are a special version of the 10_asl_rules.conf file, they use the same rule id:s as the 10_asl_rules.conf file. Therefore, you can not use these rules along with the 10_asl_rules.conf file. You can use one, or the other, but not both.<br />
<br />
These rules are a paranoid replacement for the 10_asl_rules.conf file. These rules do not contain any known safe mode application tuning exceptions or bypasses. These rules will generate false positives. These rules are made available for users that wish to tune their own rules, and do not wish to use a ruleset that has been tuned for false positives.<br />
<br />
For example, if you had a application that safely used the argument "url" to accept URLs:<br />
<br />
GET /application?url=http://www.example.com/safething<br />
<br />
The normal rules would allow this, if this was known to be safe for the application. <br />
<br />
The paranoid rules, however, will NOT allow this, even if this is known to be safe for the application. They will alert, and if configured (or misconfigured) also block this as an RFI attack. These rules will alert on things that may be safe or are known to be non-malicious. This will generate a lot of false positives for most users, therefore you should not use these rules if you do not want to experience a high degree of false positives. These rules exist for paranoid users, who may want to tune the rules themselves, or may wish to know about every possible potentially malicious event, even when the event may in fact not be malicious.<br />
<br />
We do not recommend you use these rules in blocking mode, instead you should use these only in detect mode, and only if you feel that your applications are doing things in a very unsafe manner. If you do wish to use these rules, make sure that you load them from a special file so you can set the default behaviour of the rules. If you do not do this, the rules will inherit you systems default behavior, which is generally to block.<br />
<br />
Example configuration lines for the paranoid rules:<br />
<br />
<pre><br />
SecDefaultAction "log,pass,auditlog,phase:2,t:none,t:lowercase,t:replaceNulls,t:compressWhitespace"<br />
Include modsecurity.paranoid.rules.d/15_asl_paranoid_rules.conf<br />
</pre><br />
<br />
You must load these rules last.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
==== Using the paranoid rules ====<br />
<br />
If you want to use the paranoid rules because you have found a vulnerability in your application that the normal rules do not block, please let us know, we would be happy to take a look at either creating a Just In Time Patch for your vulnerability, or adjusting the tuned rules to not allow this. Remember, if you use our real time rules, we provide this service for free. One easy way to find out if you have applications that have unusual vulnerabilities is to scan the application with a web vulnerability application scanner, if you find something the normal rules dont stop just let us know. We'd be delighted to put out new rules for your applications vulnerabilities.<br />
<br />
Finally, if you do you use these rules you will need to set ATOMIC_PARANOID_MODE to 1 in your modsecurity configuration. If you do not know how to do this, we do not recommend you use these rules.<br />
<br />
'''Note: Do not use this ruleset with [[ASL]]. [[ASL]] uses intelligent defense in depth, and does need this kind of ruleset to protect you. You will get a greater level of protection from ASL, without all the false positives.'''<br />
<br />
==== Beta Rules ====<br />
<br />
==== Experimental Rules ====<br />
<br />
<br />
====70_asl_csrf_experimental.conf====<br />
<br />
These are experimental CSRF mitigation rules. The 10_asl_rules.conf rules are designed to also handle some types of CSRF attacks, however these rules are for more advanced environments.<br />
<br />
These rules work by injecting javascript code into the response, and special cookies, and must be tuned for the system to prevent false positives. If you do not understand what this means, do not use these rules.<br />
<br />
'''They are currently not supported and are experimental.'''<br />
<br />
Requires: Modsecurity 2.7.0 and up.</div>Mshinnhttps://wiki.atomicorp.com/wiki/index.php/WAF_360151WAF 3601512023-10-05T18:15:38Z<p>Mshinn: /* Description */</p>
<hr />
<div>{{Infobox<br />
|header1 = Rule 360151<br />
|label2 = Status<br />
|data2 = Active<br />
|label3 = Alert Message<br />
|data3 = Atomicorp.com WAF Rules: PHP Injection Attack: Variable Function Call Found<br />
}}<br />
<br />
= Description =<br />
<br />
This rule detects Possible PHP injection attacks. It does this by looking for combinations of metacharacters and word/character segements encapsulated by parenthesese that may appear to be PHP variable function calls. If you have a false positive with this rule, please report it to us.<br />
<br />
= Troubleshooting =<br />
<br />
== False Positives ==<br />
<br />
If you believe this is a false positive, please report this to our security team to determine if this is a legitimate case, or if its clever attack on your system. Instructions to report false positives are detailed on the [[Reporting False Positives]] wiki page. If it is a false positive, we will fix the issue in the rules and get a release out to you promptly.<br />
<br />
== Tuning Guidance ==<br />
<br />
If you want to disable or tune this rule, please see the [[Tuning the Atomicorp WAF Rules]] page for basic information.<br />
<br />
= Additional Information =<br />
<br />
== Similar Rules ==<br />
<br />
None.<br />
<br />
== Knowledge Base Articles== <br />
<br />
None.<br />
<br />
== Outside References == <br />
<br />
None.<br />
<br />
== Notes == <br />
<br />
None.</div>Mshinnhttps://wiki.atomicorp.com/wiki/index.php/WAF_360151WAF 3601512023-10-05T18:14:37Z<p>Mshinn: Created page with "{{Infobox |header1 = Rule 360151 |label2 = Status |data2 = Active |label3 = Alert Message |data3 = Atomicorp.com WAF Rules: PHP Injection Attack: Variable Function Call Found..."</p>
<hr />
<div>{{Infobox<br />
|header1 = Rule 360151<br />
|label2 = Status<br />
|data2 = Active<br />
|label3 = Alert Message<br />
|data3 = Atomicorp.com WAF Rules: PHP Injection Attack: Variable Function Call Found<br />
}}<br />
<br />
= Description =<br />
<br />
This rule detects Possible PHP injection attacks. It does this by looking for either combinations of metacharacters and word/character segements that may appear to be PHP variable function calls. If you have a false positive with this rule, please report it to us.<br />
<br />
<br />
<br />
= Troubleshooting =<br />
<br />
== False Positives ==<br />
<br />
If you believe this is a false positive, please report this to our security team to determine if this is a legitimate case, or if its clever attack on your system. Instructions to report false positives are detailed on the [[Reporting False Positives]] wiki page. If it is a false positive, we will fix the issue in the rules and get a release out to you promptly.<br />
<br />
== Tuning Guidance ==<br />
<br />
If you want to disable or tune this rule, please see the [[Tuning the Atomicorp WAF Rules]] page for basic information.<br />
<br />
= Additional Information =<br />
<br />
== Similar Rules ==<br />
<br />
None.<br />
<br />
== Knowledge Base Articles== <br />
<br />
None.<br />
<br />
== Outside References == <br />
<br />
None.<br />
<br />
== Notes == <br />
<br />
None.</div>Mshinnhttps://wiki.atomicorp.com/wiki/index.php/Mod_securityMod security2023-09-29T21:38:21Z<p>Mshinn: /* Changing a range of rules ot be detect only by ID */</p>
<hr />
<div>=Installing modsecurity Rules =<br />
<br />
Please see this article:<br />
<br />
[[Atomic ModSecurity Rules]]<br />
<br />
=Tuning and managing modsecurity Rules=<br />
<br />
== Disabling Rules ==<br />
<br />
=== Important Notes ===<br />
<br />
==== phase:1 rules ====<br />
<br />
Note: ASL/AWP/AEO users should disable rules from the rule manager. There is no need to create custom rules, apache configuration files or other customizations when using ASL/AWP/AEO, and ASL/AWP/AEO supports disabling any rule on both a global and per domain basis.<br />
<br />
For non-ASL users, LocationMatch and Location do not work for phase:1 rules. Location and LocationMatch are not available in apache until phase:2. If you need to disable a phase:1 rule, use ASL/AWP/AEO which can disable phase:1 rules on a per domain and global basis.<br />
<br />
<br />
If you are not using ASL/AWP/AEO, and need to disable a phase:1 rule, you will need to create a custom rule to do this. This following is an example of a custom rule to do this for rule 123456.<br />
<br />
<br />
''SecRule REQUEST_HEADERS:Host "example.com$" "phase:1,id:91001,t:none,t:lowercase,pass,nolog,noauditlog,ctl:ruleRemovebyID=123456"''<br />
<br />
<br />
In the example above, "example.com" is the domain to exclude this rule. This custom rule must be loaded before the rule you want to disable. This custom rule *must be loaded before the rule you wish to disable*.<br />
<br />
If you do not know how to create this kind of custom rule, please contact support and we'll put a quote together to help develop these custom rules for you.<br />
<br />
=== Global ===<br />
<br />
==== Disabling Mod_Security Globally ====<br />
<br />
If you are using ASL, just change this setting:<br />
<br />
https://www.atomicorp.com/wiki/index.php/ASL_WAF#MODSEC_ENABLED<br />
<br />
If you are not using ASL, you will need to do this manually:<br />
<br />
Step 1) Disable config file<br />
mv /etc/httpd/conf.d/00_mod_security.conf /etc/httpd/conf.d/00_mod_security.conf.disabled<br />
<br />
Step 2) Restart Apache<br />
service httpd restart<br />
<br />
==== Disable Mod_security on a global URL ====<br />
<br />
Step 1) Create a global exclude file<br />
<br />
vim /etc/httpd/modsecurity.d/00_custom_exclude.conf<br />
<br />
Step 2) Add the LocationMatch for the url to exclude. Example: /server.php<br />
<br />
<LocationMatch /server.php><br />
<IfModule mod_security2.c><br />
SecRuleEngine Off <br />
</IfModule><br />
</LocationMatch><br />
<br />
Step 3) Restart apache<br />
<br />
service httpd restart<br />
<br />
<br />
<br />
Step 3) Restart apache<br />
<br />
service httpd restart<br />
<br />
==== Set a URL to alert only ====<br />
<br />
Step 1) Create a global exclude file<br />
<br />
vim /etc/httpd/modsecurity.d/00000_custom_exclude.conf<br />
<br />
Step 2) Add a custom rule<br />
<br />
In this example the URL is: /foo/bar<br />
<br />
Add this line to the file you created in Step 1:<br />
<br />
SecRule REQUEST_URI "/foo/bar" "phase:1,id:1000000,t:none,t:lowercase,pass,nolog,noauditlog,ctl:ruleEngine=DetectionOnly"<br />
<br />
Important Note: See the section customizing rules below to pick a unique id for your rule above. Duplicate rule ids will cause the rule to not load.<br />
<br />
Step 3) Restart apache<br />
<br />
service httpd restart<br />
<br />
=== Per domain ===<br />
<br />
==== Disabling Mod_security per domain ====<br />
<br />
Note: If you only want to disable a specific rule for a domain, please see this article:<br />
<br />
https://wiki.atomicorp.com/wiki/index.php/Mod_security#Per_application<br />
<br />
===== For Plesk Based Systems =====<br />
<br />
For Plesk and similar systems you can also disable modsecurity in the Apache configuration.<br />
<br />
Step 1) Edit the vhost/vhost_ssl.conf for the domain<br />
vim /var/www/vhosts/<DOMAINNAME>/conf/vhost.conf<br />
<br />
Step 2) Add the following<br />
<IfModule mod_security2.c><br />
SecRuleEngine Off<br />
</IfModule><br />
<br />
Then restart apache, if you are using Plesk then you will also need follow steps 3 and 4.<br />
<br />
Step 3) Add vhost.conf to domain config <br />
<br />
Plesk 9:<br />
/usr/local/psa/admin/bin/websrvmng -a<br />
<br />
Plesk 10/11:<br />
/usr/local/psa/admin/bin/httpdmng --reconfigure-domain <domain_name><br />
<br />
Step 4) Restart Apache<br />
service httpd restart<br />
<br />
===== For Cpanel based systems with EasyApache 4 =====<br />
<br />
For full information about include file path expectations, see the official cPanel documentation at [https://documentation.cpanel.net/display/EA4/Modify+Apache+Virtual+Hosts+with+Include+Files Modify Apache Virtual Hosts with Include Files]<br />
<br />
Step 1) Create the following paths, replacing <user> and <domain> with the correct values for your needs:<br />
<br />
* mkdir -p /etc/apache2/conf.d/userdata/ssl/2_4/<user>/<domain><br />
* mkdir -p /etc/apache2/conf.d/userdata/std/2_4/<user>/<domain><br />
<br />
Step 2) In each of the above paths, create a file named 'vhost.conf'<br />
<br />
Step 3) Add in the lines below to this file:<br />
<br />
<pre><br />
<IfModule mod_security2.c><br />
SecRuleEngine Off<br />
</IfModule><br />
</pre><br />
<br />
Step 4) After any addition, modification or removal of userdata files, cPanel requires both of the following scripts to be run:<br />
<br />
* /usr/local/cpanel/scripts/rebuildhttpdconf<br />
* /usr/local/cpanel/scripts/restartsrv_httpd<br />
<br />
<br />
===== For Cpanel based systems with EasyApache 3 =====<br />
<br />
Step 1) Create the custom modsecurity configuration directory for the domain<br />
<br />
For example, if the domain is example.com, you would need to create this directory:<br />
<br />
<br />
mkdir /usr/local/apache/conf/userdata/std/2/username/example.com<br />
<br />
Step 2) Create the file vhost.conf in this directory<br />
<br />
cd /usr/local/apache/conf/userdata/std/2/username/example.com<br />
<br />
touch vhost.conf<br />
<br />
Step 3) Add in the lines below to this file:<br />
<br />
<pre><br />
<IfModule mod_security2.c><br />
SecRuleEngine Off<br />
</IfModule><br />
</pre><br />
<br />
Step 4) Run the vhost includes script, for example if the domains username is "example":<br />
<br />
/scripts/ensure_vhost_includes --user=example<br />
<br />
<br />
<br />
==== Disabling Mod_security per domain for an IP address ====<br />
<br />
===== For Plesk based systems =====<br />
<br />
For Plesk and similar systems you can also disable modsecurity in the Apache configuration.<br />
<br />
Step 1) Edit the vhost/vhost_ssl.conf for the domain<br />
vim /var/www/vhosts/<DOMAINNAME>/conf/vhost.conf<br />
<br />
Step 2) Add the following<br />
<IfModule mod_security2.c><br />
SecRule REMOTE_ADDR "^1.2.3.4$" "phase:1,t:none,nolog,allow,ctl:ruleEngine=Off,ctl:auditEngine=Off,id:9999"<br />
</IfModule><br />
<br />
'''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.'''<br />
<br />
Then restart apache, if you are using Plesk then you will also need follow steps 3 and 4.<br />
<br />
Step 3) Add vhost.conf to domain config <br />
<br />
Plesk 9:<br />
/usr/local/psa/admin/bin/websrvmng -a<br />
<br />
Plesk 10/11:<br />
/usr/local/psa/admin/bin/httpdmng --reconfigure-domain <domain_name><br />
<br />
Step 4) Restart Apache<br />
service httpd restart<br />
<br />
===== For cpanel based systems =====<br />
<br />
Step 1) Create the custom modsecurity configuration directory for the domain<br />
<br />
For example, if the domain is example.com, you would need to create this directory:<br />
<br />
mkdir /usr/local/apache/conf/userdata/std/2/username/example.com<br />
<br />
Step 2) Create the file vhost.conf in this directory<br />
<br />
cd /usr/local/apache/conf/userdata/std/2/username/example.com<br />
<br />
touch vhost.conf<br />
<br />
Step 3) Add in the lines below to this file:<br />
<br />
<IfModule mod_security2.c><br />
SecRule REMOTE_ADDR "^1.2.3.4$" "phase:1,t:none,nolog,allow,ctl:ruleEngine=Off,ctl:auditEngine=Off,id:9999"<br />
</IfModule><br />
<br />
'''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.'''<br />
<br />
Step 4) Run the vhost includes script, for example if the domains username is "example":<br />
<br />
/scripts/ensure_vhost_includes –user=example<br />
<br />
==== Disable a rule for a single domain ====<br />
<br />
'''If you have ASL installed''':<br />
<br />
Method 1:<br />
<br />
Log into the ASL GUI, and click on the "ASL" tab. Then click "WAF & HIDS Rules", 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.<br />
<br />
Type in the hostname into the Text box on the left side of the options you want to exclude the rule for, then click "add".<br />
<br />
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, or a regular expression *.example.com.<br />
<br />
Note: You can use regular expressions in this field, but each end of the expression is anchored.<br />
<br />
<br />
Method 2: Run this command as root:<br />
<br />
In ASL v3.x:<br />
asl -dr RULE_ID --vhost www.example.com<br />
<br />
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:<br />
<br />
asl -dr RULE_ID --vhost www.example.com<br />
<br />
asl -dr RULE_ID --vhost ftp.example.com<br />
<br />
asl -dr RULE_ID --vhost example.com<br />
<br />
<br />
In ASL v4:<br />
asl -drv RULE_ID[,RULE_ID...] VHOST[,VHOST...]<br />
or <br />
asl --disable-rule-vhost RULE_ID[,RULE_ID...] VHOST[,VHOST...]<br />
<br />
All supplied rules will be disabled on all supplied vhosts.<br />
<br />
asl -drv 111111,222222,333333 www.example.com,ftp.example.com,example.com<br />
<br />
<br />
<br />
<br />
'''If you do not have ASL installed''' you will have to do this manually:<br />
<br />
Step 1) Edit your domains vhost.conf file (the location of this file will vary based on your control panel, contact your control panel vendor for assistance)<br />
<br />
vim vhost.conf<br />
<br />
Step 2) Add the LocationMatch for the rule to exclude. Example, ruleid 950005<br />
<LocationMatch .*><br />
<IfModule mod_security2.c><br />
SecRuleRemoveById 950005<br />
</IfModule><br />
</LocationMatch><br />
<br />
If you want to disable multiple rules:<br />
<br />
Step 2) Add the LocationMatch for the rule to exclude. Example, ruleids 950005 and 950006<br />
<LocationMatch .*><br />
<IfModule mod_security2.c><br />
SecRuleRemoveById 950005<br />
SecRuleRemoveById 950006<br />
</IfModule><br />
</LocationMatch><br />
<br />
<br />
==== Non Control Panel systems ====<br />
<br />
For nginx, or phase:1 rules rules can be disabled for a domain/FQDN by adding a custom rule before the rule you wish to disable is loaded. For example, if you wanted to disable rule 123456 for domain example.com, you would add this rule to your custom rules:<br />
<br />
SecRule REQUEST_HEADERS:Host "example.com$" "phase:1,id:91001,t:none,t:lowercase,pass,nolog,noauditlog,ctl:ruleRemovebyID=123456"<br />
<br />
This method can also be used for Apache.<br />
<br />
==== Disable a rule for all domains ====<br />
<br />
Method 1:<br />
<br />
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.<br />
<br />
Set "disabled" to yes and click update.<br />
<br />
Method 2:<br />
<br />
Use ASL utility to disable rule by ID. Example: 950005<br />
asl --disable-rule 950005<br />
<br />
Note: This requires that [[Atomic Secured Linux]] be installed.<br />
'''<br />
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:<br />
<br />
<LocationMatch .*><br />
<IfModule mod_security2.c><br />
SecRuleRemoveById 340000<br />
</IfModule><br />
</LocationMatch><br />
<br />
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.<br />
<br />
=== Per IP or network ===<br />
<br />
==== Disable Mod_security for an IP address ====<br />
<br />
In ASL, just click the "Whitelist" button.<br />
<br />
If you are not using ASL, simply add your IP address to the file:<br />
<br />
/etc/asl/whitelist<br />
<br />
And restart Apache.<br />
<br />
Note: For this rule to work, in ASL you must have the MODSEC_00_WHITELIST ruleset enabled.<br />
<br />
If you are not using ASL, then you must have the 00_asl_whitelist.conf ruleset loaded.<br />
<br />
==== Whitelist an IP ====<br />
<br />
See above, "Disable Mod_security for an IP address"<br />
<br />
==== Disable a rule by IP or network====<br />
<br />
You will need to create a custom rule, loaded after all your other rules. Lets say you wanted to exclude rule id 330039 for the network 1.2.0.0/16. You would construct a custom rule like this:<br />
<br />
<pre><br />
SecRule REMOTE_HOST "@ipmatch 1.2.0.0/16" \<br />
"id:12345,phase:2,t:none,pass,nolog,noauditlog,ctl:ruleRemovebyID=330039"<br />
</pre><br />
<br />
Note: ipmatch can also use a list, with a combination of IPs and network for example:<br />
<br />
@ipmatch 1.2.0.0/16,5.6.7.8,127.0.0.0/8<br />
<br />
Warning: If the CIDR is invalid, this may cause a segfault of the mod_security module. Check to make sure your CIDR is valid before use.<br />
<br />
=== Per application ===<br />
<br />
==== Disable modsecurity for a specific web application ====<br />
<br />
Note: this is not recommended<br />
<br />
Add a custom rule (see the section below on creating [https://www.atomicorp.com/wiki/index.php/Mod_security#Creating_custom_rules custom rules]) after all your rules have been loaded. For example, if you wanted to disable modsecurity for the application /foo/bar.cgi you would add a custom rule like this:<br />
<br />
<pre><br />
<LocationMatch /foo/bar.cgi><br />
SecRuleEngine Off<br />
<br />
</LocationMatch><br />
</pre><br />
<br />
<br />
<br />
==== Disable a rule for a specific web application ====<br />
Add a custom rule (see the section below on creating [https://www.atomicorp.com/wiki/index.php/Mod_security#Creating_custom_rules custom rules]) after all your rules have been loaded. For example, if you wanted to disable rule 950005, you would add a custom rule like this:<br />
<br />
<pre><br />
<LocationMatch /URL/path/to/application.php><br />
SecRuleRemoveById 950005<br />
<br />
</LocationMatch><br />
</pre><br />
<br />
==== Disable a rule for a single domain or FQDN ====<br />
<br />
===== For non control panel systems =====<br />
<br />
If you are using any of our GUI products, just click on the rule event, and type in the domain or hostname you want to exclude for this rule. <br />
<br />
For DIY users, you will need to create custom rules that load *before* the rule that you wish to exclude. This means you will need to add a custom rule file that loads before the rules we supply.<br />
<br />
Once you have set this up for your DIY modsecurity configuration, you will add a rule that inspects the Host: header sent by the client, which will the disable the rule(s) you wish to disable when that field is populated by that value. Keep in mind this field is completely controlled by the client, not the server. In the example below, the entire domain "example.com" is excluded for rule 123456:<br />
<br />
''SecRule REQUEST_HEADERS:Host ".example.com$" "phase:1,id:91010,t:none,t:lowercase,pass,nolog,noauditlog,ctl:ruleRemovebyID=123456"''<br />
<br />
Then restart the web server to apply this custom exclusion.<br />
<br />
===== For Plesk systems =====<br />
<br />
<br />
Step 1) Edit the virtual servers configuration for the domain for the domain<br />
<br />
Example:<br />
<br />
vim /var/www/vhosts/<DOMAINNAME>/conf/vhost.conf<br />
<br />
Step 2) Add the LocationMatch for the rule to exclude. Example, ruleid 950005<br />
<br />
<pre><br />
<LocationMatch /URL/path/to/application.php><br />
<br />
SecRuleRemoveById 950005<br />
</IfModule><br />
<br />
</pre><br />
<br />
==== Disable Mod_security rules globally for a specific application ====<br />
<br />
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.<br />
<br />
<LocationMatch /url/to/your/application><br />
<IfModule mod_security2.c><br />
SecRuleRemoveById 1234567<br />
SecRuleRemoveById 9999999<br />
</IfModule><br />
</LocationMatch><br />
<br />
Whats important to remember is that the LocationMatch variable must match the URL, not the path on the system.<br />
<br />
==== Disable Mod_security rules by domain, for a specific application, for a list of IPs ====<br />
<br />
Step 1) Edit the vhost/vhost_ssl.conf for the domain<br />
vim /var/www/vhosts/<DOMAINNAME>/conf/vhost.conf<br />
<br />
Step 2) Add the LocationMatch for the rule to exclude.<br />
<LocationMatch /foo/bar.php><br />
<IfModule mod_security2.c><br />
SecRule REMOTE_ADDR "@pmFromFile /etc/asl/whitelist" "nolog,phase:1,allow"<br />
</IfModule><br />
</LocationMatch><br />
<br />
Step 3) Add IP to /etc/asl/whitelist<br />
echo "10.11.12.13" >> /etc/asl/whitelist<br />
<br />
Or:<br />
<br />
If you want to create a special whitelist for just that application:<br />
<br />
Step 1) Edit the vhost/vhost_ssl.conf for the domain<br />
vim /var/www/vhosts/<DOMAINNAME>/conf/vhost.conf<br />
<br />
Step 2) Add the LocationMatch for the rule to exclude.<br />
<LocationMatch /foo/bar.php><br />
<IfModule mod_security2.c><br />
SecRule REMOTE_ADDR "@pmFromFile /path/to/your/custom/whitelist_for_this_application" "nolog,phase:1,allow,id:9999"<br />
</IfModule><br />
</LocationMatch><br />
<br />
'''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.'''<br />
<br />
<br />
Step 3) Create your custom whitelist and add IP to /etc/asl/whitelist<br />
echo "10.11.12.13" >> /path/to/your/custom/whitelist_for_this_application<br />
<br />
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.<br />
<br />
==== Disable rule for a specific argument for a specific application ====<br />
<br />
You can also tell modsecurity to change a rule, in some cases, without editing or forking the rule. For example, if you want to configure modsecurity to ignore a specific argument (in the argument below the argument is "foo"), for a specific application (in the example the application name is /example/application), for a specific rule (in the example below the rule if is 12345), you would create a custom rule like this:<br />
<br />
<br />
<pre><br />
SecRule REQUEST_URI "^/example/application" \<br />
"id:9999,phase:1,t:none,t:lowercase,nolog,pass,ctl:ruleRemoveTargetByID=12345;ARGS:foo"<br />
</pre><br />
<br />
As with all custom rules, this rule also needs a unique id as explained in the article above. And this type of custom rule must be loaded '''before''' the rule it modifies.<br />
<br />
Note: This does not support regular expressions for the excluded argument. At this time, they must be explicitly defined.<br />
<br />
==== Disable rule for a specific argument ====<br />
<br />
As is the example above, a rule can also be changed to exclude a specific argument, but for all applications. For example, if you want to configure modsecurity to ignore a specific argument (in the argument below the argument is "foo"), for a specific rule (in the example below the rule if is 12345), you would create a custom rule like this:<br />
<br />
<pre><br />
SecAction "phase:1,id:9999,t:none,auditlog,nolog,pass,ctl:ruleRemoveTargetById=12345;ARGS:foo"<br />
</pre><br />
<br />
As with all custom rules, this rule also needs a unique id as explained in the article above. And this type of custom rule must be loaded '''before''' the rule it modifies.<br />
<br />
Note: This does not support regular expressions for the excluded argument. At this time, they must be explicitly defined.<br />
<br />
==== Disable modsecurity for a specific argument ====<br />
<br />
As is the example above, modsecurity can also be configured to exclude a specific argument for all rules. For example, if you want to configure modsecurity to ignore a specific argument (in the argument below the argument is "foo"),you would create a custom rule like this:<br />
<br />
<pre><br />
SecAction "phase:1,id:9999,t:none,auditlog,nolog,pass,ctl:ruleRemoveTargetById=1-1000000;ARGS:foo"<br />
</pre><br />
<br />
When 1-100000 is the rule IDs you want to exclude. As with all custom rules, this rule also needs a unique id as explained in the article above. <br />
<br />
Note: This does not support regular expressions for the excluded argument. At this time, they must be explicitly defined.<br />
<br />
== Changing the action for a rule ==<br />
<br />
You can also change the default action for a rule by using the SecRuleActionById directive. <br />
<br />
=== Changing a rule to be detect only by ID===<br />
<br />
To change a rule to only detect, but not block attacks, simply change the action for the rule with the above directive. For example, to change the action for rule 12345, simply add this rule directive to your custom rules. <br />
<br />
SecRuleUpdateActionById 12345 "pass,status:200"<br />
<br />
Note 1: this directive must be added after the rule it is modifying has been loaded.<br />
<br />
Note 2: This does not work if you are using the redirect action.<br />
<br />
=== Changing a range of rules to be detect only by ID===<br />
<br />
This is similar to the method above, however you can define a range of rule IDs. For example, if you want to disable rules 1000-2000:<br />
<br />
SecRuleUpdateActionById 1000-2000 "pass,status:200"<br />
<br />
Note 1: this directive must be added after the rule it is modifying has been loaded.<br />
<br />
Note 2: This does not work if you are using the redirect action.<br />
<br />
== Disabling POST inspection for a specific URL ==<br />
<br />
Should you want to disable inspection of a POST for a specific URL, use the format below.<br />
<br />
Assuming the URL you wanted to skip POST inspection was "upload", your exclusion rule would look like this:<br />
<br />
''SecRule REQUEST_URI "^/upload" \<br />
"phase:1,id:1234567,t:none,t:lowercase,pass,nolog,ctl:requestBodyAccess=off"''<br />
<br />
Install this rule before any of your other rules. For example, in the file /etc/httpd/modsecurity.d/00_custom_exclude.conf.<br />
<br />
== Enabling rules for only specific domains ==<br />
<br />
If you wish to disable all the rules, except for specific domains, you need to copy in the two files from the subdirectory "special" where you have the rules installed. Then create this file:<br />
<br />
/etc/asl/custom_include_domains<br />
<br />
<br />
Include the domains and/or FQDNs you want the rules to apply to. Anything not on that list will cause those rules to skip all of our rules. <br />
<br />
#File must contain exactly one domain or FQDN per line. End of line markers (both LF and CRLF) will be stripped from each phrase and any whitespace trimmed from both the beginning and the end. Empty lines and comment lines (those beginning with the # character) will be ignored.<br />
#This file does not support metacharacters. (For example, * is not supported)<br />
<br />
Example:<br />
<br />
<br />
<pre><br />
www.example.com<br />
.foo.com<br />
</pre><br />
<br />
== Disabling rules using .htaccess ==<br />
<br />
This is a new feature in modsecurity 2.7.3. This capability is available if you compile modsecurity using this option:<br />
<br />
--enable-htaccess-config<br />
<br />
From there, you will be able to disable rules using .htaccess files. The format to disable a rule via .htaccess is:<br />
<br />
SecRuleRemoveById 12345<br />
<br />
Where 12345 is the rule id.<br />
<br />
'''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 and/or this option has not been enabled. <br />
<br />
Warning: Enabling this capability will allow users to disable rules, including on compromised accounts which may cause the system to become compromised. This capability was specifically disabled by default in modsecurity to prevent this from occurring. Use this option with extreme caution!<br />
<br />
=== Specific actions available in .htaccess ===<br />
<br />
<br />
* SecAction<br />
* SecRule<br />
* SecRuleRemoveByMsg<br />
* SecRuleRemoveByTag<br />
* SecRuleRemoveById<br />
* SecRuleUpdateActionById<br />
* SecRuleUpdateTargetById<br />
* SecRuleUpdateTargetByTag<br />
* SecRuleUpdateTargetByMsg<br />
<br />
'''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.<br />
<br />
Warning: Enabling this capability in modsecurity can allow an attacker to disable modsecurity rules that you may be using to protect the entire server. We do not recommend you enable this capability on a shared server.<br />
<br />
== Customizing a rule ==<br />
<br />
If you need to customize a rule do not change the asl*conf files. These files will be overwritten by updates. <br />
<br />
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.<br />
<br />
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:<br />
<br />
If you had an original rule like this:<br />
<br />
SecRule REQUEST_URI "/foo" "t:normalisePath,id:9000,rev:1,severity:2,msg:'Atomicorp.com WAF Rules: Block /foo'"<br />
<br />
<br />
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.<br />
<br />
SecRuleRemoveById 9000000<br />
SecRule REQUEST_URI "/bar" "t:normalisePath,id:9999,rev:1,severity:2,msg:'Atomicorp.com WAF Rules: Block /foo'"<br />
<br />
'''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.'''<br />
<br />
<br />
These are the reserved ranges:<br />
<br />
* 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.<br />
* 100,000-199,999; reserved for internal use of the engine, to assign to rules that do not have explicit IDs.<br />
* 200,000-299,999; reserved for rules published at modsecurity.org.<br />
* 300,000-399,999; reserved for rules published at gotroot.com.<br />
* 400,000-419,999; unused (available for reservation).<br />
* 420,000-429,999; reserved for ScallyWhack.<br />
* 430,000-699,999; unused (available for reservation).<br />
* 700,000-799,999; reserved for Ivan Ristic.<br />
* 900,000-999,999; reserved for the Core Rules project.<br />
* 1,000,000 and above; unused (available for reservation).<br />
<br />
=== For a domain ===<br />
<br />
==== Apache ====<br />
<br />
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.<br />
<br />
==== Changing the argument separator ====<br />
<br />
If you have a web application that uses the uncommon ";" argument separator, as opposed to the widely used "&" you will want to change SecArgumentSeparator value for that application. You can do this in one of two ways:<br />
<br />
1) Globally<br />
<br />
If all your applications use the older delimiter, just change the SecArgumentSeparator in the tortix_waf.conf file. Do not change this if your applications use other delimiters.<br />
<br />
''SecArgumentSeparator ";"'' <br />
<br />
2) Per Application<br />
<br />
You can also configure this per application. For example, if your web applications URL is /foo/bar.php you can create a customer rule like this:<br />
<br />
<br />
<pre><br />
<LocationMatch /foo/bar.php><br />
SecArgumentSeparator ";"<br />
</LocationMatch><br />
</pre><br />
<br />
This will only work if modsecurity is loaded before your virtual host definitions. This is the case with most control panels, but some control panels are known to load modsecurity after vhosts are defined. In which case this will fail because Apache will not know how to process this directive (it will need modsecurity loaded to understand what this means). If you get a syntax error, that means your apache configuration is loaded modsecurity after your vhosts are defined. You will need to change your apache configuration to ensure this loading occurs before vhosts are defined.<br />
<br />
[[ASL]] will automatically configure modsecurity to load first.<br />
<br />
= Creating custom rules =<br />
<br />
== Discussion ==<br />
<br />
If you need to create your own custom rules, do not change the asl*conf files. These files will be overwritten by updates. <br />
<br />
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.<br />
<br />
== Rule Ids for custom rules ==<br />
<br />
For custom rules, '''you must create your own rule ids which must be unique'''. The id: fields contain the rule ids. For custom rules you should use the local (internal) use range (see below for the reserved id ranges). '''Do not use assigned ranges.'''<br />
<br />
These are the reserved ranges:<br />
<br />
* 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.<br />
* 100,000-199,999; reserved for internal use of the engine, to assign to rules that do not have explicit IDs. (deprecated, all rules require assigned ids in 2.7.x and up)<br />
* 200,000-299,999; reserved for rules published at modsecurity.org.<br />
* 300,000-399,999; reserved for rules published by atomicorp.com<br />
* 400,000-419,999; unused (available for reservation).<br />
* 420,000-429,999; reserved for ScallyWhack.<br />
* 430,000-699,999; unused (available for reservation).<br />
* 700,000-799,999; reserved for Ivan Ristic.<br />
* 900,000-999,999; reserved for the Core Rules project.<br />
* 1,000,000 and above; unused (available for reservation).<br />
<br />
== Installing custom rules ==<br />
<br />
<br />
=== Linux ===<br />
<br />
==== Apache ====<br />
<br />
'''Step 1) Create your custom rules directory:'''<br />
<br />
''mkdir /etc/httpd/modsecurity.custom.d''<br />
<br />
'''Step 2) Create a configuration file for your custom rules in /etc/httpd/conf.d directory. For example:'''<br />
<br />
Create the file 01_modsecurity.conf and add this line to it:<br />
<br />
''Include modsecurity.custom.d/[https://www.atomicorp.com/examples/99_zzz_custom.conf 99_zzz_custom.conf]''<br />
<br />
You can download an example file from the URL below that will do this:<br />
<br />
[https://www.atomicorp.com/examples/01_modsecurity.conf 01_modsecurity.conf]<br />
<br />
And add 01_modsecurity.conf to this directory:<br />
<br />
/etc/httpd/conf.d<br />
<br />
If you have wget installed on your system, the following commands will do this automatically for you:<br />
''<br />
<br />
cd /etc/httpd/conf.d<br />
<br />
wget https://www.atomicorp.com/examples/01_modsecurity.conf''<br />
<br />
Note: 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. Please contact your control panel vendor for assistance.<br />
<br />
'''Step 3) Install your custom rules in the /etc/httpd/modsecurity.custom.d directory'''<br />
<br />
''cd /etc/httpd/modsecurity.custom.d''<br />
<br />
and edit the file 99_zzz_custom.conf and put in your custom rules.<br />
<br />
You can also download an example custom rule file by running these commands:<br />
<br />
''cd /etc/httpd/modsecurity.custom.d<br />
<br />
wget https://www.atomicorp.com/examples/99_zzz_custom.conf''<br />
<br />
'''Step 4) Test your apache configuration'''<br />
<br />
''service httpd configtest''<br />
<br />
If you have any errors, do not restart apache. You will need to correct these errors or apache will not start.<br />
<br />
'''Step 5) If your test was successful, restart apache.'''<br />
<br />
''service httpd restart''<br />
<br />
Our professional services group would be happy to help you with your custom rules needs, including developing the rules for you. If your request is something that we can safely include in the rules for all our customers, we're generally able to develop these new rules for free. Please contact us to discuss your rules needs.<br />
<br />
=== Windows ===<br />
<br />
==== IIS ====<br />
<br />
'''Step 1) Modify your modsecurity configuration file on windows and add this line to the end of your configuration. For example:'''<br />
<br />
''Include [https://www.atomicorp.com/examples/99_zzz_custom.conf 99_zzz_custom.conf]''<br />
<br />
'''Step 2) Edit the file 99_zzz_custom.conf and save it in the same directory as your modsecurity config file'''<br />
<br />
'''Step 3)Restart IIS'''<br />
<br />
<br />
Our professional services group would be happy to help you with your custom rules needs, including developing the rules for you. If your request is something that we can safely include in the rules for all our customers, we're generally able to develop these new rules for free. Please contact us to discuss your rules needs.<br />
<br />
== Modifying a rule ==<br />
<br />
If you want to modify the internal logic of a rule, you will want to "fork" or copy that rule into a custom rule. Do not modify the actual rules provided by us, your modifications will be overwritten with the next update.<br />
<br />
'''Step 1: Copy the rule you want to modify into your custom rules file.'''<br />
<br />
Copy the rule in its entirety into your custom rule file. For example, if you wanted to modify rule 390707, you would copy the entire rule into your custom rules file. For example:<br />
<br />
<pre><br />
# Restrict the maximum number of arguments in a request<br />
SecRule &ARGS "@gt 1000" \<br />
"chain,phase:2,t:none,log,auditlog,deny,status:403,msg:'Atomicorp.com WAF Rules: Too many arguments in request (max set to 1000, increase as necessary for your system)',id:'390707',severity:'4',rev:'8'"<br />
SecRule REQUEST_URI "!((?:^/(?:imaclean|massdelete)/)|^/cgi-bin/dada/mail\.cgi$|^/index\.php/mageworx/customoptions_options|^/za/|^/back-?office/|^/moderate\.php|^/backend/configdomains\.php|\.do$|^/admin[a-z0-9]+?/index\.php\?controller=adminmodules)" "t:none,t:lowercase"<br />
</pre><br />
<br />
'''Step 2: Change the rule id.''' <br />
<br />
This is absolutely required. No two rules can have the same ID. See this article for chosing a custom rule id: https://wiki.atomicorp.com/wiki/index.php/Mod_security#Rule_Ids_for_custom_rules<br />
<br />
For example:<br />
<br />
<pre><br />
# Restrict the maximum number of arguments in a request<br />
SecRule &ARGS "@gt 1000" \<br />
"chain,phase:2,t:none,log,auditlog,deny,status:403,msg:'Atomicorp.com WAF Rules: Too many arguments in request (max set to 1000, increase as necessary for your system)',id:'12345678',severity:'4',rev:'8'"<br />
SecRule REQUEST_URI "!((?:^/(?:imaclean|massdelete)/)|^/cgi-bin/dada/mail\.cgi$|^/index\.php/mageworx/customoptions_options|^/za/|^/back-?office/|^/moderate\.php|^/backend/configdomains\.php|\.do$|^/admin[a-z0-9]+?/index\.php\?controller=adminmodules)" "t:none,t:lowercase"<br />
</pre><br />
<br />
'''Step 3: Disable the original rule'''<br />
<br />
If you want your custom rule to be global, that is your modification applies to the entire system, then you will want to disable the original rule per this article:<br />
<br />
https://wiki.atomicorp.com/wiki/index.php/Mod_security#Disable_a_rule_for_all_domains<br />
<br />
If you want to disable the rule for a single application, see this article:<br />
<br />
https://wiki.atomicorp.com/wiki/index.php/Mod_security#Disable_a_rule_for_a_specific_web_application<br />
<br />
If you want to disable the rule for a specific IP or network:<br />
<br />
https://wiki.atomicorp.com/wiki/index.php/Mod_security#Disable_a_rule_by_IP_or_network<br />
<br />
If you want to disable the rule for a single domain:<br />
<br />
https://wiki.atomicorp.com/wiki/index.php/Mod_security#Disable_a_rule_for_a_single_domain<br />
<br />
'''Step 4: Set the scope of the rule.'''<br />
<br />
If you havent disabled the original rule globally, or for one or more domains, then you will need to set the scope of your custom rule. To limit your modification to a specific application, place your custom rule inside <LocationMatch> tags. For example:<br />
<br />
<pre><br />
<br />
<LocationMatch /url/to/your/custom/application><br />
# Restrict the maximum number of arguments in a request<br />
SecRule &ARGS "@gt 2048" \<br />
"chain,phase:2,t:none,log,auditlog,deny,status:403,msg:'Atomicorp.com WAF Rules: Too many arguments in request (max set to 1000, increase as necessary for your system)',id:'12345678',severity:'4',rev:'8'"<br />
SecRule REQUEST_URI "!((?:^/(?:imaclean|massdelete)/)|^/cgi-bin/dada/mail\.cgi$|^/index\.php/mageworx/customoptions_options|^/za/|^/back-?office/|^/moderate\.php|^/backend/configdomains\.php|\.do$|^/admin[a-z0-9]+?/index\.php\?controller=adminmodules)" "t:none,t:lowercase"<br />
</LocationMatch><br />
<br />
</pre><br />
<br />
= Configuring and Setting up mod_security =<br />
'''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.'''<br />
<br />
To setup and configured modsecurity, please see the [[Atomic_ModSecurity_Rules]] wiki page.</div>Mshinnhttps://wiki.atomicorp.com/wiki/index.php/Modsecurity_rule_familiesModsecurity rule families2022-10-06T21:33:16Z<p>Mshinn: /* 00_asl_y_searchengines.conf */</p>
<hr />
<div>The Atomicorp modsecurity rules are broken into families - please see the documentation for your platform as to which rulesets to load. <br />
<br />
====000000000000000000000000_asl_notconfigured.conf====<br />
<br />
'''This rule file should not be used.''' <br />
<br />
This file is a "canary" file included in the archive to prevent users from accidentally loading all the rule files at the same. This ruleset will prevent this condition by disabling the WAF and logging a warning that the installation instructions have not been followed.<br />
<br />
If you are getting any errors about this file and you are using a third party product that installs our rules, please contact the vendor for that product.<br />
<br />
====000_asl_threat_intelligence.conf====<br />
<br />
These rules use the Atomicorp Threat Intelligence system to detect if an IP is a known threat. These rules look for DOS, brute force, spam, known attackers and advanced threats.<br />
<br />
Note: Requires modsecurity 2.7.7 and up.<br />
<br />
====00_asl_x_searchengines.conf====<br />
<br />
'''This ruleset is Deprecated'''<br />
<br />
Note: this is a legacy ruleset and should only be used on platform that do not support lua, and may experience performance issues. Please use 00_asl_z_searchengines.conf instead.<br />
<br />
This ruleset tells the WAF to trust defined search engines, and to not block or shun them.<br />
<br />
<br />
Note: Requires modsecurity 2.7.7 and up.<br />
<br />
====00_asl_y_searchengines.conf ====<br />
<br />
'''This ruleset is Deprecated'''<br />
<br />
Note: this is a legacy ruleset and should only be used on platform that do not support lua, and may experience performance issues. Please use 00_asl_z_searchengines.conf instead.<br />
<br />
''(Available in ASL and the real time rules only)''<br />
<br />
This ruleset detects clients pretending to be a search engine, as well as valid search engines. You must have either [[ASL]] installed, or apache configured with "HostnameLookups Double" and a very fast local DNS server. <br />
<br />
These rules also allow you to auto-whitelist real search engines. To do this, you will need to either use [[ASL]], or you will need to manually set the variable WHITELIST_SEARCH_ENGINES to "1".<br />
<br />
'''Warning: If you do not have either [[ASL]] installed, or apache configured correctly to use these rules they will not work correctly.'''<br />
<br />
Note: If you do not have a fast local DNS server, do not use these rules. These rules perform forward and reverse lookups and require a fast local DNS server, otherwise you should expect your websites to be very slow.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
Excluded: Modsecurity 2.8.0. Because 2.8.0 has a serious bug in the @ipmatch code( https://github.com/SpiderLabs/ModSecurity/issues/706).<br />
<br />
====00_asl_z_searchengines.conf====<br />
<br />
'(Available in ASL and the real time rules only)''<br />
<br />
Note: The rules must be used with a [[Local DNS resolver]]. If you do not have a fast local DNS server (not a remote DNS server), do not use these rules. These rules perform forward and reverse lookups and require a fast local DNS server. Failure to use a local resolver will result in performance degradation, these rules may also not work at all in these cases.<br />
<br />
This ruleset detects clients pretending to be a search engine, as well as valid search engines. You must have a very fast local DNS server to use these rules. These rules also allow you to auto-whitelist real search engines. To do this, in the /etc/asl/config set WAF_LUA_00_SEARCHENGINE to "yes"<br />
<br />
For DIY installations, you must install the "advanced" subdirectory in your modsecurity rules directory. If you are manually extracting the rules archive files this should be created for you automatically, and will contain the actual .lua files this config file will load. <br />
<br />
Requires: Modsecurity 2.9.3 and up.<br />
<br />
====00_asl_zz_strict.conf====<br />
<br />
'''Note: Requires modsecurity 2.7.0 and higher.'''<br />
<br />
This enforces strict adherence to the HTTP RFCs.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====00_asl_0_global.conf====<br />
<br />
This is a global variable file, it is only used if you have modsecurity 2.5.13 and above installed. <br />
<br />
====00_asl_rbl.conf====<br />
<br />
This rule family checks an incoming host to see if its on a RBL. By default only the spamhaus XBL-SBL list is enabled which is operated by the Spamhaus project. This RBL is not operated or controlled by Atomicorp. Please contact Spamhaus if you have issues with the IPs on this RBL, or disable this option. Several other RBLs are including in this rule file and must be either enabled in ASL (ASL will generate this rule file) or if you are not running ASL you must manually enable the other RBLs.<br />
<br />
This ruleset will look up every request in the DNS to see if its on a blacklist, and will not finish serving the request until the DNS server responds. This can slow down requests if the DNS server is slow. Basically, web requests will move at the speed of the DNS servers replies.<br />
<br />
If your web server is responding slowly to requests, and you have this ruleset enabled your DNS server is too slow to meet your lookup needs. You will need to either disable this ruleset, or tune your DNS server to respond to queries more quickly.<br />
<br />
''If you use this ruleset, make sure you have a fast locally caching DNS server. This ruleset will query spamhaus for every incoming IP to see if its on a blacklist, if your DNS is slow (or non local) this will make your system seem to crawl, as the read request will be blocked by Apache until it finished the DNS lookup. If you do not have a fast and local DNS server, do not use this ruleset.''<br />
<br />
Requires: Modsecurity 2.6.0 and up.<br />
<br />
====00_asl_blacklist.conf====<br />
<br />
Allows you to blacklist hosts or CIDRs from the WAF.<br />
<br />
Requires: Modsecurity 2.9.0 and up.<br />
<br />
The format is single IPs or CIDRs per line, for example:<br />
<br />
<pre><br />
1.2.3.4<br />
5.6.7.0/24<br />
8.9.0.0/16<br />
</pre><br />
<br />
Note: You must define your own blacklist file. The default location is /etc/asl/blacklist. <br />
<br />
====00_asl_whitelist.conf====<br />
<br />
Allows you to whitelist hosts from the WAF.<br />
<br />
Requires: Modsecurity 2.9.0 and up.<br />
<br />
The format is single IPs or CIDRs per line, for example:<br />
<br />
<pre><br />
1.2.3.4<br />
5.6.7.0/24<br />
8.9.0.0/16<br />
</pre><br />
<br />
Note: You must define your own whitelist entires. The default location is /etc/asl/whitelist. '''Do not use the whitelist.txt file. It is not used for this rule. We do not provide a default whitelist for these rules.'''<br />
<br />
Note: Requires modsecurity 2.7.7 and up.<br />
<br />
====01_asl_content.conf====<br />
<br />
These rules restrict the server to known content types that the WAF can correctly decipher.<br />
<br />
Requires: Apache, and Modsecurity 2.9.2 and up.<br />
<br />
==== 01_asl_domain_blocks.conf====<br />
<br />
Optional ruleset that allows you to block connections from hosts, based on their DNS hostname and/or domain. This is a user defined list.<br />
<br />
Domains and/or hostnames are stored in this file:<br />
<br />
/etc/asl/custom-domain-blocks<br />
<br />
The format is one entry, per line, for example:<br />
<br />
<pre><br />
example.com<br />
www.hostname.some-tld<br />
</pre><br />
<br />
Note: You must have either [[ASL]] installed, or apache configured with "HostnameLookups Double" and a very fast local DNS server for these rules to work.\<br />
<br />
Note: Requires modsecurity 2.7.7 and up.<br />
<br />
====01_asl_rules_special.conf====<br />
<br />
This ruleset changes the behavior of the WAF for applications that behavior in nonstandard ways. For example, OTRS uses ";" and not "&" for argument separation. You should not use these rules if you do not have OTRS installed on your system.<br />
<br />
If you do not know what this means, you do not need this ruleset.<br />
<br />
Requires: Modsecurity 2.7.0 and up. <br />
<br />
Note: If you get an error regarding SecArgumentSeparator with these rules, your modsecurity configuration is being loaded too late in your Apache stack. Ensure that your modsecurity configuration is loaded first. This has been seen with cpanel when not using [[ASL]]. Please contact your apache vendor for assistance with this issue, or use [[ASL]] which will fix your apache configuration so this error does not occur.<br />
<br />
====03_asl_dos.conf====<br />
<br />
This ruleset protects apache from slow DOS attacks. It is only supported with Apache and requires the installation of the mod_reqtimeout module. The rule is fail safe with Apache, that is if the mod_reqtimeout module is not loaded the rules also will not load into Apache.<br />
<br />
[[ASL]] automatically ensures mod_reqtimeout is installed. If you are a rules only user please contact your Apache vendor for assistance installing this module.<br />
<br />
Note: Requires Apache and modsecurity 2.7.7 and up.<br />
<br />
====05_asl_exclude.conf====<br />
<br />
Pre-load rule exclusion list. Turns off rules that need to be disabled early in the process. ASL manages this process automatically.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====00_asl_z_antievasion.conf====<br />
<br />
This is a ruleset to detect attempts to bypass modsecurity itself, through evasion methods for example. Do not use this ruleset unless you are using 2.6.1 and up.<br />
<br />
====05_asl_scanner.conf ====<br />
<br />
Deprecated.<br />
<br />
====06_asl_honeypot.conf ====<br />
<br />
This ruleset lets you define URLs you want to specifically block, for example the URL of an application that may not be installed on the system. This can work as a honeypot of sorts, allowing the system to be configured to treat probes for non-existant applications as attacks. [[ASL]] has a more advanced system that can detect when URLs do not correspond to files on the system, which can be used in place of this ruleset or to augment it.<br />
<br />
For this ruleset to work, populate the honeypot-files.txt file in the same directory as 06_asl_honeypot.conf with one URL per line. For example:<br />
<br />
<br />
<pre><br />
/application/not/installed/on/system<br />
file_name_not_on_system.extension<br />
</pre><br />
<br />
==== 11_asl_rules.conf====<br />
<br />
This ruleset is reserved and is not currently used.<br />
<br />
====10_asl_antimalware.conf====<br />
<br />
Checks payload and RFI contents for known sources of malware and malware payloads and will block them.<br />
<br />
Requires: Modsecurity 2.6.0 and up.<br />
<br />
====09_asl_rules.conf====<br />
<br />
These are supplementation rules to the 10_asl_rules.conf, but only work on 2.6.6 and up installations. Do not use this ruleset unless you are using 2.6.6 and up.<br />
<br />
====10_asl_rules.conf ====<br />
<br />
The main rules, contains all the generic security rules to protect against classes of attacks, such as SQL injection, XSS, code injection, recursion, etc. '''These rules require modsecurity 2.9.1 and above.'''<br />
<br />
Requires: Modsecurity 2.9.1 and up.<br />
<br />
====11_asl_adv_rules.conf====<br />
<br />
These are advanced rules, and '''can only be used with modsecurity 2.7.5 and above.'''<br />
<br />
Requires: Modsecurity 2.7.5 and up.<br />
<br />
====11_asl_data_loss.conf====<br />
<br />
Experimental data leakage rules. Looks for credit card numbers and other potentially sensitive information leaking from the system.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====11_asl_brute_enhanced.conf====<br />
<br />
Requires: Modsecurity 2.9.2 and up.<br />
<br />
These rules are for platforms that do not have either [[ASL]] or Atomic Protector installed. These rules create the collections in modsecurity to block brute force attacks. The defaults are > 5 failures within 60 seconds.<br />
<br />
''Note: These rules are not necessary if the systen has ASL or Atomic Protector installed, and should not be used with ASL or AP.<br />
<br />
''Note 1: These rules will only work if the web server can write to the SecDataDir directory. That directory will contain sqllite databases that modsecurity will create and use to count events, without the collection modsecurity can not maintain state for composite events, like multiple login failures, and these rules will not work.''<br />
<br />
''Note 2: Enable this setting in /etc/asl/config to create the collections:''<br />
<br />
<br />
https://wiki.atomicorp.com/wiki/index.php/Aum_configuration#MODSEC_00_THREAT<br />
<br />
====12_asl_adv_xss_rules.conf====<br />
<br />
'''This ruleset require mod_security 2.9.0 and above.'''<br />
<br />
This is the advanced Cross Site Scripting (XSS) protection rule set. It performs deep level inspections of web requests and responses to look for potential XSS attacks.<br />
<br />
====12_asl_brute.conf====<br />
<br />
'''This ruleset is only available with [[ASL]] or the Real Time Rules.''' <br />
<br />
This ruleset detects authentication failures against all major web applications (Joomla, WordPress, MovableType, Drupal, ModX, ZenCart, OsCommerce, VBulletin, PHPBB and more).<br />
<br />
When used with [[ASL]], fast and "low and slow" brute force attacks can be detected and blocked in real time.<br />
<br />
Requires: Modsecurity 2.6.8 and up. <br />
<br />
'''Note: [[ASL]] is necessary to perform active response to brute force attacks.'''<br />
<br />
====13_asl_brute_enhanced.conf====<br />
<br />
Requires: Modsecurity 2.9.2 and up.<br />
<br />
These rules are for platforms that do not have either [ASL] or Atomic Protector installed. These rules create the collections in modsecurity to block brute force attacks. The defaults are > 10 failures within 60 seconds.<br />
<br />
''Note: These rules are not necessary if the systen has ASL or Atomic Protector installed, and should not be used with ASL or AP.<br />
<br />
Note 1: These rules will only work if the web server can write to the SecDataDir directory. That directory will contain sqllite databases that modsecurity will create and use to count events, without the collection modsecurity can not maintain state for composite events, like multiple login failures, and these rules will not work.''<br />
<br />
====20_asl_useragents.conf====<br />
<br />
Looks for malicious or suspicious user agents and known patterns of malicious activity. These rules require modsecurity 2.7.1 and up.<br />
<br />
Requires: Modsecurity 2.7.1 and up.<br />
<br />
====30_asl_antispam.conf====<br />
<br />
Tuned antispam rules, designed to work with all known blogs, forums, guestbooks, CMS' and other web content management systems that allow users to post content.<br />
<br />
Requires: Modsecurity 2.6.8 and up.<br />
<br />
====30_asl_antispam_advanced.conf====<br />
<br />
(Not released yet) These are advanced spam rules. They require modsecurity 2.7.1 and up.<br />
<br />
Requires: Modsecurity 2.7.1 and up.<br />
<br />
====30_asl_antispam_referrer.conf====<br />
<br />
Rules to block referrer spam. Generally not needed in most environments if you protect web log generation tools from public access (which is the default for most control panels).<br />
<br />
Requires: Modsecurity 2.6.0 and up.<br />
<br />
====40_asl_apache2-rules.conf====<br />
<br />
This ruleset has been retired. mod_security 2.x does not work with Apache 1.x and this ruleset existed just for those rules that only worked with apache 2. As mod_security 2.x does not work with Apache 1.x there is no need for this ruleset.<br />
<br />
====50_asl_rootkits.conf====<br />
<br />
Detects and blocks known web based rootkits, PHP/ASP/PERL shells, spam tools and other malicious web applications from being installed, and in some cases from running on the system. These rules exist for cases where malicious software may already be installed on the system, this is a defense in depth rule set)<br />
<br />
Not: ASL can prevent all malware from running on the system, modsecurity is limited in this regard so if you are only using the rules you should not expect modsecurity to prevent malware from running. It may prevent it in some cases, but without kernel level protection such as that provided in [[ASL]] no WAF can stop all malware from running on the system itself.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====51_asl_rootkits.conf====<br />
<br />
These rules look for known malware names in filenames, and URLs.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====60_asl_recons.conf====<br />
<br />
Blocks known "google hacks" or webserver probes that look for vulnerable applications and signs of compromised systems running unauthorized shells, or unprotected applications that allow uploads which would give an attacker access to the system.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====61_asl_recons_dlp.conf====<br />
<br />
These rules detect Data Loss Search engine "hacks". These are search engine probes for sensitive files, often used by malicious parties to find sensitive information accidentally exposed on web servers.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====99_asl_a_redactor.conf====<br />
<br />
ASL only rule set. Requires modsecurity 2.6.0 and up. Part of the malicious code removal system. Automatically removes malicious code from web pages, such as hidden iframes, encoded javascript and other malicious code. '''Do not enable this ruleset if you are not using ASL. ''' <br />
<br />
====99_asl_exclude.conf====<br />
<br />
Post exclude rules.<br />
<br />
====98_asl_adv_redactor.conf====<br />
<br />
This is the new advanced malware removal system. This ruleset will remove malware "on the fly" from web pages. For example, it will remove hidden iframes, malicous javascript, and other malicious code.<br />
<br />
'''Requires: modsecurity 2.7.5 and up.'''<br />
<br />
====98_asl_jitp.conf====<br />
<br />
This is a special ruleset used by [[ASL]]. If you do not have [[ASL]] you can not use these rules.<br />
<br />
====99_asl_jitp.conf====<br />
<br />
Just in Time Patches. We publish JITPs daily if there is a new web application vulnerability that the 10_asl_rules.conf do not protect the system against. These are tuned rules for specific vulnerabilities in a web application.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====99_asl_a_redactor.conf====<br />
<br />
This ruleset is reserved, and is not currently used.<br />
<br />
====99_asl_redactor.conf====<br />
<br />
'''Note: Do not enable this ruleset unless you have been instructed to do so by support.'''<br />
<br />
Special ruleset - requires mod_sed to be loaded on the system which is included and supported in [[ASL]] - removes malicious code from web pages, such as hidden iframes, encoded javascript and other malicious code. We highly recommend you use this rule set - its fast, multithreads and will automagically remove malicious code from infected webpages, which can occur if an adversary is able to log into the system and modify the code, such as by SSH or by uploading the code via FTP. If you are not using [[ASL]] then you will need to make sure your system has mod_sed installed to use these rules, they will not load and therefore will not do anything without mod_sed installed. This ruleset is only supported with [[ASL]].<br />
<br />
====99_asl_redactor_post.conf====<br />
<br />
This ruleset detects malicious content in webpages, such as known malicious domains.<br />
<br />
====99_asl_scanner.conf====<br />
<br />
This is the same as 05_asl_scanner.conf, its provided in a form to run last. This is the recommended location for the scanner function, as the rules before this stop some attacks that the scanner also detects, but do this in a faster and less CPU intensive manner. Running the scanner last does not compromise or lower the effectiveness of the rules. This is just a performance enhancement. This ruleset is only supported with [[ASL]].<br />
<br />
====99_asl_z_adv_scanner.conf====<br />
<br />
'''Note: Requires [[ASL]] and modsecurity 2.9.0 and higher.'''<br />
<br />
This ruleset uses a fuzzy hash to identify potentially malicious files.<br />
<br />
Warning: This ruleset is not supported on non-ASL systems. Do not use this without ASL.<br />
<br />
==== Paranoid mode rules ====<br />
<br />
===== 15_asl_paranoid_rules.conf =====<br />
<br />
'''Note: Do not use these rules if you have not read this section.'''<br />
<br />
'''Please do not report false positives with these rules. If you encounter a false positive with a rule from this file, please use its duplicate in 10_asl_rules.conf instead. If you have a false positive with a rule from 10_asl_rules.conf, please report it to us.'''<br />
<br />
These are a special version of the 10_asl_rules.conf file, they use the same rule id:s as the 10_asl_rules.conf file. Therefore, you can not use these rules along with the 10_asl_rules.conf file. You can use one, or the other, but not both.<br />
<br />
These rules are a paranoid replacement for the 10_asl_rules.conf file. These rules do not contain any known safe mode application tuning exceptions or bypasses. These rules will generate false positives. These rules are made available for users that wish to tune their own rules, and do not wish to use a ruleset that has been tuned for false positives.<br />
<br />
For example, if you had a application that safely used the argument "url" to accept URLs:<br />
<br />
GET /application?url=http://www.example.com/safething<br />
<br />
The normal rules would allow this, if this was known to be safe for the application. <br />
<br />
The paranoid rules, however, will NOT allow this, even if this is known to be safe for the application. They will alert, and if configured (or misconfigured) also block this as an RFI attack. These rules will alert on things that may be safe or are known to be non-malicious. This will generate a lot of false positives for most users, therefore you should not use these rules if you do not want to experience a high degree of false positives. These rules exist for paranoid users, who may want to tune the rules themselves, or may wish to know about every possible potentially malicious event, even when the event may in fact not be malicious.<br />
<br />
We do not recommend you use these rules in blocking mode, instead you should use these only in detect mode, and only if you feel that your applications are doing things in a very unsafe manner. If you do wish to use these rules, make sure that you load them from a special file so you can set the default behaviour of the rules. If you do not do this, the rules will inherit you systems default behavior, which is generally to block.<br />
<br />
Example configuration lines for the paranoid rules:<br />
<br />
<pre><br />
SecDefaultAction "log,pass,auditlog,phase:2,t:none,t:lowercase,t:replaceNulls,t:compressWhitespace"<br />
Include modsecurity.paranoid.rules.d/15_asl_paranoid_rules.conf<br />
</pre><br />
<br />
You must load these rules last.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
==== Using the paranoid rules ====<br />
<br />
If you want to use the paranoid rules because you have found a vulnerability in your application that the normal rules do not block, please let us know, we would be happy to take a look at either creating a Just In Time Patch for your vulnerability, or adjusting the tuned rules to not allow this. Remember, if you use our real time rules, we provide this service for free. One easy way to find out if you have applications that have unusual vulnerabilities is to scan the application with a web vulnerability application scanner, if you find something the normal rules dont stop just let us know. We'd be delighted to put out new rules for your applications vulnerabilities.<br />
<br />
Finally, if you do you use these rules you will need to set ATOMIC_PARANOID_MODE to 1 in your modsecurity configuration. If you do not know how to do this, we do not recommend you use these rules.<br />
<br />
'''Note: Do not use this ruleset with [[ASL]]. [[ASL]] uses intelligent defense in depth, and does need this kind of ruleset to protect you. You will get a greater level of protection from ASL, without all the false positives.'''<br />
<br />
==== Beta Rules ====<br />
<br />
==== Experimental Rules ====<br />
<br />
<br />
====70_asl_csrf_experimental.conf====<br />
<br />
These are experimental CSRF mitigation rules. The 10_asl_rules.conf rules are designed to also handle some types of CSRF attacks, however these rules are for more advanced environments.<br />
<br />
These rules work by injecting javascript code into the response, and special cookies, and must be tuned for the system to prevent false positives. If you do not understand what this means, do not use these rules.<br />
<br />
'''They are currently not supported and are experimental.'''<br />
<br />
Requires: Modsecurity 2.7.0 and up.</div>Mshinnhttps://wiki.atomicorp.com/wiki/index.php/Modsecurity_rule_familiesModsecurity rule families2022-10-06T21:32:48Z<p>Mshinn: /* 00_asl_x_searchengines.conf */</p>
<hr />
<div>The Atomicorp modsecurity rules are broken into families - please see the documentation for your platform as to which rulesets to load. <br />
<br />
====000000000000000000000000_asl_notconfigured.conf====<br />
<br />
'''This rule file should not be used.''' <br />
<br />
This file is a "canary" file included in the archive to prevent users from accidentally loading all the rule files at the same. This ruleset will prevent this condition by disabling the WAF and logging a warning that the installation instructions have not been followed.<br />
<br />
If you are getting any errors about this file and you are using a third party product that installs our rules, please contact the vendor for that product.<br />
<br />
====000_asl_threat_intelligence.conf====<br />
<br />
These rules use the Atomicorp Threat Intelligence system to detect if an IP is a known threat. These rules look for DOS, brute force, spam, known attackers and advanced threats.<br />
<br />
Note: Requires modsecurity 2.7.7 and up.<br />
<br />
====00_asl_x_searchengines.conf====<br />
<br />
'''This ruleset is Deprecated'''<br />
<br />
Note: this is a legacy ruleset and should only be used on platform that do not support lua, and may experience performance issues. Please use 00_asl_z_searchengines.conf instead.<br />
<br />
This ruleset tells the WAF to trust defined search engines, and to not block or shun them.<br />
<br />
<br />
Note: Requires modsecurity 2.7.7 and up.<br />
<br />
====00_asl_y_searchengines.conf ====<br />
<br />
'''This ruleset is Deprecated'''<br />
<br />
Note: this is a legacy ruleset and should only be used on platform that do not support lua, and may experience performance issues. Please use 00_asl_z_searchengines.conf instead.<br />
<br />
''(Available in ASL and the real time rules only)''<br />
<br />
This ruleset detects clients pretending to be a search engine, as well as valid search engines. You must have either [[ASL]] installed, or apache configured with "HostnameLookups Double" and a very fast local DNS server. <br />
<br />
These rules also allow you to auto-whitelist real search engines. To do this, you will need to either use [[ASL]], or you will need to manually set the variable WHITELIST_SEARCH_ENGINES to "1".<br />
<br />
'''Warning: If you do not have either [[ASL]] installed, or apache configured correctly to use these rules they will not work correctly.'''<br />
<br />
Note: If you do not have a fast local DNS server, do not use these rules. These rules perform forward and reverse lookups and require a fast local DNS server, otherwise you should expect your websites to be very slow.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
Excluded: Modsecurity 2.8.0. Because 2.8.0 has a serious bug in the @ipmatch code( https://github.com/SpiderLabs/ModSecurity/issues/706).<br />
<br />
====00_asl_zz_strict.conf====<br />
<br />
'''Note: Requires modsecurity 2.7.0 and higher.'''<br />
<br />
This enforces strict adherence to the HTTP RFCs.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====00_asl_0_global.conf====<br />
<br />
This is a global variable file, it is only used if you have modsecurity 2.5.13 and above installed. <br />
<br />
====00_asl_rbl.conf====<br />
<br />
This rule family checks an incoming host to see if its on a RBL. By default only the spamhaus XBL-SBL list is enabled which is operated by the Spamhaus project. This RBL is not operated or controlled by Atomicorp. Please contact Spamhaus if you have issues with the IPs on this RBL, or disable this option. Several other RBLs are including in this rule file and must be either enabled in ASL (ASL will generate this rule file) or if you are not running ASL you must manually enable the other RBLs.<br />
<br />
This ruleset will look up every request in the DNS to see if its on a blacklist, and will not finish serving the request until the DNS server responds. This can slow down requests if the DNS server is slow. Basically, web requests will move at the speed of the DNS servers replies.<br />
<br />
If your web server is responding slowly to requests, and you have this ruleset enabled your DNS server is too slow to meet your lookup needs. You will need to either disable this ruleset, or tune your DNS server to respond to queries more quickly.<br />
<br />
''If you use this ruleset, make sure you have a fast locally caching DNS server. This ruleset will query spamhaus for every incoming IP to see if its on a blacklist, if your DNS is slow (or non local) this will make your system seem to crawl, as the read request will be blocked by Apache until it finished the DNS lookup. If you do not have a fast and local DNS server, do not use this ruleset.''<br />
<br />
Requires: Modsecurity 2.6.0 and up.<br />
<br />
====00_asl_blacklist.conf====<br />
<br />
Allows you to blacklist hosts or CIDRs from the WAF.<br />
<br />
Requires: Modsecurity 2.9.0 and up.<br />
<br />
The format is single IPs or CIDRs per line, for example:<br />
<br />
<pre><br />
1.2.3.4<br />
5.6.7.0/24<br />
8.9.0.0/16<br />
</pre><br />
<br />
Note: You must define your own blacklist file. The default location is /etc/asl/blacklist. <br />
<br />
====00_asl_whitelist.conf====<br />
<br />
Allows you to whitelist hosts from the WAF.<br />
<br />
Requires: Modsecurity 2.9.0 and up.<br />
<br />
The format is single IPs or CIDRs per line, for example:<br />
<br />
<pre><br />
1.2.3.4<br />
5.6.7.0/24<br />
8.9.0.0/16<br />
</pre><br />
<br />
Note: You must define your own whitelist entires. The default location is /etc/asl/whitelist. '''Do not use the whitelist.txt file. It is not used for this rule. We do not provide a default whitelist for these rules.'''<br />
<br />
Note: Requires modsecurity 2.7.7 and up.<br />
<br />
====01_asl_content.conf====<br />
<br />
These rules restrict the server to known content types that the WAF can correctly decipher.<br />
<br />
Requires: Apache, and Modsecurity 2.9.2 and up.<br />
<br />
==== 01_asl_domain_blocks.conf====<br />
<br />
Optional ruleset that allows you to block connections from hosts, based on their DNS hostname and/or domain. This is a user defined list.<br />
<br />
Domains and/or hostnames are stored in this file:<br />
<br />
/etc/asl/custom-domain-blocks<br />
<br />
The format is one entry, per line, for example:<br />
<br />
<pre><br />
example.com<br />
www.hostname.some-tld<br />
</pre><br />
<br />
Note: You must have either [[ASL]] installed, or apache configured with "HostnameLookups Double" and a very fast local DNS server for these rules to work.\<br />
<br />
Note: Requires modsecurity 2.7.7 and up.<br />
<br />
====01_asl_rules_special.conf====<br />
<br />
This ruleset changes the behavior of the WAF for applications that behavior in nonstandard ways. For example, OTRS uses ";" and not "&" for argument separation. You should not use these rules if you do not have OTRS installed on your system.<br />
<br />
If you do not know what this means, you do not need this ruleset.<br />
<br />
Requires: Modsecurity 2.7.0 and up. <br />
<br />
Note: If you get an error regarding SecArgumentSeparator with these rules, your modsecurity configuration is being loaded too late in your Apache stack. Ensure that your modsecurity configuration is loaded first. This has been seen with cpanel when not using [[ASL]]. Please contact your apache vendor for assistance with this issue, or use [[ASL]] which will fix your apache configuration so this error does not occur.<br />
<br />
====03_asl_dos.conf====<br />
<br />
This ruleset protects apache from slow DOS attacks. It is only supported with Apache and requires the installation of the mod_reqtimeout module. The rule is fail safe with Apache, that is if the mod_reqtimeout module is not loaded the rules also will not load into Apache.<br />
<br />
[[ASL]] automatically ensures mod_reqtimeout is installed. If you are a rules only user please contact your Apache vendor for assistance installing this module.<br />
<br />
Note: Requires Apache and modsecurity 2.7.7 and up.<br />
<br />
====05_asl_exclude.conf====<br />
<br />
Pre-load rule exclusion list. Turns off rules that need to be disabled early in the process. ASL manages this process automatically.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====00_asl_z_antievasion.conf====<br />
<br />
This is a ruleset to detect attempts to bypass modsecurity itself, through evasion methods for example. Do not use this ruleset unless you are using 2.6.1 and up.<br />
<br />
====05_asl_scanner.conf ====<br />
<br />
Deprecated.<br />
<br />
====06_asl_honeypot.conf ====<br />
<br />
This ruleset lets you define URLs you want to specifically block, for example the URL of an application that may not be installed on the system. This can work as a honeypot of sorts, allowing the system to be configured to treat probes for non-existant applications as attacks. [[ASL]] has a more advanced system that can detect when URLs do not correspond to files on the system, which can be used in place of this ruleset or to augment it.<br />
<br />
For this ruleset to work, populate the honeypot-files.txt file in the same directory as 06_asl_honeypot.conf with one URL per line. For example:<br />
<br />
<br />
<pre><br />
/application/not/installed/on/system<br />
file_name_not_on_system.extension<br />
</pre><br />
<br />
==== 11_asl_rules.conf====<br />
<br />
This ruleset is reserved and is not currently used.<br />
<br />
====10_asl_antimalware.conf====<br />
<br />
Checks payload and RFI contents for known sources of malware and malware payloads and will block them.<br />
<br />
Requires: Modsecurity 2.6.0 and up.<br />
<br />
====09_asl_rules.conf====<br />
<br />
These are supplementation rules to the 10_asl_rules.conf, but only work on 2.6.6 and up installations. Do not use this ruleset unless you are using 2.6.6 and up.<br />
<br />
====10_asl_rules.conf ====<br />
<br />
The main rules, contains all the generic security rules to protect against classes of attacks, such as SQL injection, XSS, code injection, recursion, etc. '''These rules require modsecurity 2.9.1 and above.'''<br />
<br />
Requires: Modsecurity 2.9.1 and up.<br />
<br />
====11_asl_adv_rules.conf====<br />
<br />
These are advanced rules, and '''can only be used with modsecurity 2.7.5 and above.'''<br />
<br />
Requires: Modsecurity 2.7.5 and up.<br />
<br />
====11_asl_data_loss.conf====<br />
<br />
Experimental data leakage rules. Looks for credit card numbers and other potentially sensitive information leaking from the system.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====11_asl_brute_enhanced.conf====<br />
<br />
Requires: Modsecurity 2.9.2 and up.<br />
<br />
These rules are for platforms that do not have either [[ASL]] or Atomic Protector installed. These rules create the collections in modsecurity to block brute force attacks. The defaults are > 5 failures within 60 seconds.<br />
<br />
''Note: These rules are not necessary if the systen has ASL or Atomic Protector installed, and should not be used with ASL or AP.<br />
<br />
''Note 1: These rules will only work if the web server can write to the SecDataDir directory. That directory will contain sqllite databases that modsecurity will create and use to count events, without the collection modsecurity can not maintain state for composite events, like multiple login failures, and these rules will not work.''<br />
<br />
''Note 2: Enable this setting in /etc/asl/config to create the collections:''<br />
<br />
<br />
https://wiki.atomicorp.com/wiki/index.php/Aum_configuration#MODSEC_00_THREAT<br />
<br />
====12_asl_adv_xss_rules.conf====<br />
<br />
'''This ruleset require mod_security 2.9.0 and above.'''<br />
<br />
This is the advanced Cross Site Scripting (XSS) protection rule set. It performs deep level inspections of web requests and responses to look for potential XSS attacks.<br />
<br />
====12_asl_brute.conf====<br />
<br />
'''This ruleset is only available with [[ASL]] or the Real Time Rules.''' <br />
<br />
This ruleset detects authentication failures against all major web applications (Joomla, WordPress, MovableType, Drupal, ModX, ZenCart, OsCommerce, VBulletin, PHPBB and more).<br />
<br />
When used with [[ASL]], fast and "low and slow" brute force attacks can be detected and blocked in real time.<br />
<br />
Requires: Modsecurity 2.6.8 and up. <br />
<br />
'''Note: [[ASL]] is necessary to perform active response to brute force attacks.'''<br />
<br />
====13_asl_brute_enhanced.conf====<br />
<br />
Requires: Modsecurity 2.9.2 and up.<br />
<br />
These rules are for platforms that do not have either [ASL] or Atomic Protector installed. These rules create the collections in modsecurity to block brute force attacks. The defaults are > 10 failures within 60 seconds.<br />
<br />
''Note: These rules are not necessary if the systen has ASL or Atomic Protector installed, and should not be used with ASL or AP.<br />
<br />
Note 1: These rules will only work if the web server can write to the SecDataDir directory. That directory will contain sqllite databases that modsecurity will create and use to count events, without the collection modsecurity can not maintain state for composite events, like multiple login failures, and these rules will not work.''<br />
<br />
====20_asl_useragents.conf====<br />
<br />
Looks for malicious or suspicious user agents and known patterns of malicious activity. These rules require modsecurity 2.7.1 and up.<br />
<br />
Requires: Modsecurity 2.7.1 and up.<br />
<br />
====30_asl_antispam.conf====<br />
<br />
Tuned antispam rules, designed to work with all known blogs, forums, guestbooks, CMS' and other web content management systems that allow users to post content.<br />
<br />
Requires: Modsecurity 2.6.8 and up.<br />
<br />
====30_asl_antispam_advanced.conf====<br />
<br />
(Not released yet) These are advanced spam rules. They require modsecurity 2.7.1 and up.<br />
<br />
Requires: Modsecurity 2.7.1 and up.<br />
<br />
====30_asl_antispam_referrer.conf====<br />
<br />
Rules to block referrer spam. Generally not needed in most environments if you protect web log generation tools from public access (which is the default for most control panels).<br />
<br />
Requires: Modsecurity 2.6.0 and up.<br />
<br />
====40_asl_apache2-rules.conf====<br />
<br />
This ruleset has been retired. mod_security 2.x does not work with Apache 1.x and this ruleset existed just for those rules that only worked with apache 2. As mod_security 2.x does not work with Apache 1.x there is no need for this ruleset.<br />
<br />
====50_asl_rootkits.conf====<br />
<br />
Detects and blocks known web based rootkits, PHP/ASP/PERL shells, spam tools and other malicious web applications from being installed, and in some cases from running on the system. These rules exist for cases where malicious software may already be installed on the system, this is a defense in depth rule set)<br />
<br />
Not: ASL can prevent all malware from running on the system, modsecurity is limited in this regard so if you are only using the rules you should not expect modsecurity to prevent malware from running. It may prevent it in some cases, but without kernel level protection such as that provided in [[ASL]] no WAF can stop all malware from running on the system itself.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====51_asl_rootkits.conf====<br />
<br />
These rules look for known malware names in filenames, and URLs.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====60_asl_recons.conf====<br />
<br />
Blocks known "google hacks" or webserver probes that look for vulnerable applications and signs of compromised systems running unauthorized shells, or unprotected applications that allow uploads which would give an attacker access to the system.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====61_asl_recons_dlp.conf====<br />
<br />
These rules detect Data Loss Search engine "hacks". These are search engine probes for sensitive files, often used by malicious parties to find sensitive information accidentally exposed on web servers.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====99_asl_a_redactor.conf====<br />
<br />
ASL only rule set. Requires modsecurity 2.6.0 and up. Part of the malicious code removal system. Automatically removes malicious code from web pages, such as hidden iframes, encoded javascript and other malicious code. '''Do not enable this ruleset if you are not using ASL. ''' <br />
<br />
====99_asl_exclude.conf====<br />
<br />
Post exclude rules.<br />
<br />
====98_asl_adv_redactor.conf====<br />
<br />
This is the new advanced malware removal system. This ruleset will remove malware "on the fly" from web pages. For example, it will remove hidden iframes, malicous javascript, and other malicious code.<br />
<br />
'''Requires: modsecurity 2.7.5 and up.'''<br />
<br />
====98_asl_jitp.conf====<br />
<br />
This is a special ruleset used by [[ASL]]. If you do not have [[ASL]] you can not use these rules.<br />
<br />
====99_asl_jitp.conf====<br />
<br />
Just in Time Patches. We publish JITPs daily if there is a new web application vulnerability that the 10_asl_rules.conf do not protect the system against. These are tuned rules for specific vulnerabilities in a web application.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====99_asl_a_redactor.conf====<br />
<br />
This ruleset is reserved, and is not currently used.<br />
<br />
====99_asl_redactor.conf====<br />
<br />
'''Note: Do not enable this ruleset unless you have been instructed to do so by support.'''<br />
<br />
Special ruleset - requires mod_sed to be loaded on the system which is included and supported in [[ASL]] - removes malicious code from web pages, such as hidden iframes, encoded javascript and other malicious code. We highly recommend you use this rule set - its fast, multithreads and will automagically remove malicious code from infected webpages, which can occur if an adversary is able to log into the system and modify the code, such as by SSH or by uploading the code via FTP. If you are not using [[ASL]] then you will need to make sure your system has mod_sed installed to use these rules, they will not load and therefore will not do anything without mod_sed installed. This ruleset is only supported with [[ASL]].<br />
<br />
====99_asl_redactor_post.conf====<br />
<br />
This ruleset detects malicious content in webpages, such as known malicious domains.<br />
<br />
====99_asl_scanner.conf====<br />
<br />
This is the same as 05_asl_scanner.conf, its provided in a form to run last. This is the recommended location for the scanner function, as the rules before this stop some attacks that the scanner also detects, but do this in a faster and less CPU intensive manner. Running the scanner last does not compromise or lower the effectiveness of the rules. This is just a performance enhancement. This ruleset is only supported with [[ASL]].<br />
<br />
====99_asl_z_adv_scanner.conf====<br />
<br />
'''Note: Requires [[ASL]] and modsecurity 2.9.0 and higher.'''<br />
<br />
This ruleset uses a fuzzy hash to identify potentially malicious files.<br />
<br />
Warning: This ruleset is not supported on non-ASL systems. Do not use this without ASL.<br />
<br />
==== Paranoid mode rules ====<br />
<br />
===== 15_asl_paranoid_rules.conf =====<br />
<br />
'''Note: Do not use these rules if you have not read this section.'''<br />
<br />
'''Please do not report false positives with these rules. If you encounter a false positive with a rule from this file, please use its duplicate in 10_asl_rules.conf instead. If you have a false positive with a rule from 10_asl_rules.conf, please report it to us.'''<br />
<br />
These are a special version of the 10_asl_rules.conf file, they use the same rule id:s as the 10_asl_rules.conf file. Therefore, you can not use these rules along with the 10_asl_rules.conf file. You can use one, or the other, but not both.<br />
<br />
These rules are a paranoid replacement for the 10_asl_rules.conf file. These rules do not contain any known safe mode application tuning exceptions or bypasses. These rules will generate false positives. These rules are made available for users that wish to tune their own rules, and do not wish to use a ruleset that has been tuned for false positives.<br />
<br />
For example, if you had a application that safely used the argument "url" to accept URLs:<br />
<br />
GET /application?url=http://www.example.com/safething<br />
<br />
The normal rules would allow this, if this was known to be safe for the application. <br />
<br />
The paranoid rules, however, will NOT allow this, even if this is known to be safe for the application. They will alert, and if configured (or misconfigured) also block this as an RFI attack. These rules will alert on things that may be safe or are known to be non-malicious. This will generate a lot of false positives for most users, therefore you should not use these rules if you do not want to experience a high degree of false positives. These rules exist for paranoid users, who may want to tune the rules themselves, or may wish to know about every possible potentially malicious event, even when the event may in fact not be malicious.<br />
<br />
We do not recommend you use these rules in blocking mode, instead you should use these only in detect mode, and only if you feel that your applications are doing things in a very unsafe manner. If you do wish to use these rules, make sure that you load them from a special file so you can set the default behaviour of the rules. If you do not do this, the rules will inherit you systems default behavior, which is generally to block.<br />
<br />
Example configuration lines for the paranoid rules:<br />
<br />
<pre><br />
SecDefaultAction "log,pass,auditlog,phase:2,t:none,t:lowercase,t:replaceNulls,t:compressWhitespace"<br />
Include modsecurity.paranoid.rules.d/15_asl_paranoid_rules.conf<br />
</pre><br />
<br />
You must load these rules last.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
==== Using the paranoid rules ====<br />
<br />
If you want to use the paranoid rules because you have found a vulnerability in your application that the normal rules do not block, please let us know, we would be happy to take a look at either creating a Just In Time Patch for your vulnerability, or adjusting the tuned rules to not allow this. Remember, if you use our real time rules, we provide this service for free. One easy way to find out if you have applications that have unusual vulnerabilities is to scan the application with a web vulnerability application scanner, if you find something the normal rules dont stop just let us know. We'd be delighted to put out new rules for your applications vulnerabilities.<br />
<br />
Finally, if you do you use these rules you will need to set ATOMIC_PARANOID_MODE to 1 in your modsecurity configuration. If you do not know how to do this, we do not recommend you use these rules.<br />
<br />
'''Note: Do not use this ruleset with [[ASL]]. [[ASL]] uses intelligent defense in depth, and does need this kind of ruleset to protect you. You will get a greater level of protection from ASL, without all the false positives.'''<br />
<br />
==== Beta Rules ====<br />
<br />
==== Experimental Rules ====<br />
<br />
<br />
====70_asl_csrf_experimental.conf====<br />
<br />
These are experimental CSRF mitigation rules. The 10_asl_rules.conf rules are designed to also handle some types of CSRF attacks, however these rules are for more advanced environments.<br />
<br />
These rules work by injecting javascript code into the response, and special cookies, and must be tuned for the system to prevent false positives. If you do not understand what this means, do not use these rules.<br />
<br />
'''They are currently not supported and are experimental.'''<br />
<br />
Requires: Modsecurity 2.7.0 and up.</div>Mshinnhttps://wiki.atomicorp.com/wiki/index.php/Modsecurity_rule_familiesModsecurity rule families2022-10-06T21:32:05Z<p>Mshinn: /* 00_asl_y_searchengines.conf */</p>
<hr />
<div>The Atomicorp modsecurity rules are broken into families - please see the documentation for your platform as to which rulesets to load. <br />
<br />
====000000000000000000000000_asl_notconfigured.conf====<br />
<br />
'''This rule file should not be used.''' <br />
<br />
This file is a "canary" file included in the archive to prevent users from accidentally loading all the rule files at the same. This ruleset will prevent this condition by disabling the WAF and logging a warning that the installation instructions have not been followed.<br />
<br />
If you are getting any errors about this file and you are using a third party product that installs our rules, please contact the vendor for that product.<br />
<br />
====000_asl_threat_intelligence.conf====<br />
<br />
These rules use the Atomicorp Threat Intelligence system to detect if an IP is a known threat. These rules look for DOS, brute force, spam, known attackers and advanced threats.<br />
<br />
Note: Requires modsecurity 2.7.7 and up.<br />
<br />
====00_asl_x_searchengines.conf====<br />
<br />
This ruleset tells the WAF to trust defined search engines, and to not block or shun them.<br />
<br />
<br />
Note: Requires Apache and modsecurity 2.7.7 and up.<br />
<br />
====00_asl_y_searchengines.conf ====<br />
<br />
'''This ruleset is Deprecated'''<br />
<br />
Note: this is a legacy ruleset and should only be used on platform that do not support lua, and may experience performance issues. Please use 00_asl_z_searchengines.conf instead.<br />
<br />
''(Available in ASL and the real time rules only)''<br />
<br />
This ruleset detects clients pretending to be a search engine, as well as valid search engines. You must have either [[ASL]] installed, or apache configured with "HostnameLookups Double" and a very fast local DNS server. <br />
<br />
These rules also allow you to auto-whitelist real search engines. To do this, you will need to either use [[ASL]], or you will need to manually set the variable WHITELIST_SEARCH_ENGINES to "1".<br />
<br />
'''Warning: If you do not have either [[ASL]] installed, or apache configured correctly to use these rules they will not work correctly.'''<br />
<br />
Note: If you do not have a fast local DNS server, do not use these rules. These rules perform forward and reverse lookups and require a fast local DNS server, otherwise you should expect your websites to be very slow.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
Excluded: Modsecurity 2.8.0. Because 2.8.0 has a serious bug in the @ipmatch code( https://github.com/SpiderLabs/ModSecurity/issues/706).<br />
<br />
====00_asl_zz_strict.conf====<br />
<br />
'''Note: Requires modsecurity 2.7.0 and higher.'''<br />
<br />
This enforces strict adherence to the HTTP RFCs.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====00_asl_0_global.conf====<br />
<br />
This is a global variable file, it is only used if you have modsecurity 2.5.13 and above installed. <br />
<br />
====00_asl_rbl.conf====<br />
<br />
This rule family checks an incoming host to see if its on a RBL. By default only the spamhaus XBL-SBL list is enabled which is operated by the Spamhaus project. This RBL is not operated or controlled by Atomicorp. Please contact Spamhaus if you have issues with the IPs on this RBL, or disable this option. Several other RBLs are including in this rule file and must be either enabled in ASL (ASL will generate this rule file) or if you are not running ASL you must manually enable the other RBLs.<br />
<br />
This ruleset will look up every request in the DNS to see if its on a blacklist, and will not finish serving the request until the DNS server responds. This can slow down requests if the DNS server is slow. Basically, web requests will move at the speed of the DNS servers replies.<br />
<br />
If your web server is responding slowly to requests, and you have this ruleset enabled your DNS server is too slow to meet your lookup needs. You will need to either disable this ruleset, or tune your DNS server to respond to queries more quickly.<br />
<br />
''If you use this ruleset, make sure you have a fast locally caching DNS server. This ruleset will query spamhaus for every incoming IP to see if its on a blacklist, if your DNS is slow (or non local) this will make your system seem to crawl, as the read request will be blocked by Apache until it finished the DNS lookup. If you do not have a fast and local DNS server, do not use this ruleset.''<br />
<br />
Requires: Modsecurity 2.6.0 and up.<br />
<br />
====00_asl_blacklist.conf====<br />
<br />
Allows you to blacklist hosts or CIDRs from the WAF.<br />
<br />
Requires: Modsecurity 2.9.0 and up.<br />
<br />
The format is single IPs or CIDRs per line, for example:<br />
<br />
<pre><br />
1.2.3.4<br />
5.6.7.0/24<br />
8.9.0.0/16<br />
</pre><br />
<br />
Note: You must define your own blacklist file. The default location is /etc/asl/blacklist. <br />
<br />
====00_asl_whitelist.conf====<br />
<br />
Allows you to whitelist hosts from the WAF.<br />
<br />
Requires: Modsecurity 2.9.0 and up.<br />
<br />
The format is single IPs or CIDRs per line, for example:<br />
<br />
<pre><br />
1.2.3.4<br />
5.6.7.0/24<br />
8.9.0.0/16<br />
</pre><br />
<br />
Note: You must define your own whitelist entires. The default location is /etc/asl/whitelist. '''Do not use the whitelist.txt file. It is not used for this rule. We do not provide a default whitelist for these rules.'''<br />
<br />
Note: Requires modsecurity 2.7.7 and up.<br />
<br />
====01_asl_content.conf====<br />
<br />
These rules restrict the server to known content types that the WAF can correctly decipher.<br />
<br />
Requires: Apache, and Modsecurity 2.9.2 and up.<br />
<br />
==== 01_asl_domain_blocks.conf====<br />
<br />
Optional ruleset that allows you to block connections from hosts, based on their DNS hostname and/or domain. This is a user defined list.<br />
<br />
Domains and/or hostnames are stored in this file:<br />
<br />
/etc/asl/custom-domain-blocks<br />
<br />
The format is one entry, per line, for example:<br />
<br />
<pre><br />
example.com<br />
www.hostname.some-tld<br />
</pre><br />
<br />
Note: You must have either [[ASL]] installed, or apache configured with "HostnameLookups Double" and a very fast local DNS server for these rules to work.\<br />
<br />
Note: Requires modsecurity 2.7.7 and up.<br />
<br />
====01_asl_rules_special.conf====<br />
<br />
This ruleset changes the behavior of the WAF for applications that behavior in nonstandard ways. For example, OTRS uses ";" and not "&" for argument separation. You should not use these rules if you do not have OTRS installed on your system.<br />
<br />
If you do not know what this means, you do not need this ruleset.<br />
<br />
Requires: Modsecurity 2.7.0 and up. <br />
<br />
Note: If you get an error regarding SecArgumentSeparator with these rules, your modsecurity configuration is being loaded too late in your Apache stack. Ensure that your modsecurity configuration is loaded first. This has been seen with cpanel when not using [[ASL]]. Please contact your apache vendor for assistance with this issue, or use [[ASL]] which will fix your apache configuration so this error does not occur.<br />
<br />
====03_asl_dos.conf====<br />
<br />
This ruleset protects apache from slow DOS attacks. It is only supported with Apache and requires the installation of the mod_reqtimeout module. The rule is fail safe with Apache, that is if the mod_reqtimeout module is not loaded the rules also will not load into Apache.<br />
<br />
[[ASL]] automatically ensures mod_reqtimeout is installed. If you are a rules only user please contact your Apache vendor for assistance installing this module.<br />
<br />
Note: Requires Apache and modsecurity 2.7.7 and up.<br />
<br />
====05_asl_exclude.conf====<br />
<br />
Pre-load rule exclusion list. Turns off rules that need to be disabled early in the process. ASL manages this process automatically.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====00_asl_z_antievasion.conf====<br />
<br />
This is a ruleset to detect attempts to bypass modsecurity itself, through evasion methods for example. Do not use this ruleset unless you are using 2.6.1 and up.<br />
<br />
====05_asl_scanner.conf ====<br />
<br />
Deprecated.<br />
<br />
====06_asl_honeypot.conf ====<br />
<br />
This ruleset lets you define URLs you want to specifically block, for example the URL of an application that may not be installed on the system. This can work as a honeypot of sorts, allowing the system to be configured to treat probes for non-existant applications as attacks. [[ASL]] has a more advanced system that can detect when URLs do not correspond to files on the system, which can be used in place of this ruleset or to augment it.<br />
<br />
For this ruleset to work, populate the honeypot-files.txt file in the same directory as 06_asl_honeypot.conf with one URL per line. For example:<br />
<br />
<br />
<pre><br />
/application/not/installed/on/system<br />
file_name_not_on_system.extension<br />
</pre><br />
<br />
==== 11_asl_rules.conf====<br />
<br />
This ruleset is reserved and is not currently used.<br />
<br />
====10_asl_antimalware.conf====<br />
<br />
Checks payload and RFI contents for known sources of malware and malware payloads and will block them.<br />
<br />
Requires: Modsecurity 2.6.0 and up.<br />
<br />
====09_asl_rules.conf====<br />
<br />
These are supplementation rules to the 10_asl_rules.conf, but only work on 2.6.6 and up installations. Do not use this ruleset unless you are using 2.6.6 and up.<br />
<br />
====10_asl_rules.conf ====<br />
<br />
The main rules, contains all the generic security rules to protect against classes of attacks, such as SQL injection, XSS, code injection, recursion, etc. '''These rules require modsecurity 2.9.1 and above.'''<br />
<br />
Requires: Modsecurity 2.9.1 and up.<br />
<br />
====11_asl_adv_rules.conf====<br />
<br />
These are advanced rules, and '''can only be used with modsecurity 2.7.5 and above.'''<br />
<br />
Requires: Modsecurity 2.7.5 and up.<br />
<br />
====11_asl_data_loss.conf====<br />
<br />
Experimental data leakage rules. Looks for credit card numbers and other potentially sensitive information leaking from the system.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====11_asl_brute_enhanced.conf====<br />
<br />
Requires: Modsecurity 2.9.2 and up.<br />
<br />
These rules are for platforms that do not have either [[ASL]] or Atomic Protector installed. These rules create the collections in modsecurity to block brute force attacks. The defaults are > 5 failures within 60 seconds.<br />
<br />
''Note: These rules are not necessary if the systen has ASL or Atomic Protector installed, and should not be used with ASL or AP.<br />
<br />
''Note 1: These rules will only work if the web server can write to the SecDataDir directory. That directory will contain sqllite databases that modsecurity will create and use to count events, without the collection modsecurity can not maintain state for composite events, like multiple login failures, and these rules will not work.''<br />
<br />
''Note 2: Enable this setting in /etc/asl/config to create the collections:''<br />
<br />
<br />
https://wiki.atomicorp.com/wiki/index.php/Aum_configuration#MODSEC_00_THREAT<br />
<br />
====12_asl_adv_xss_rules.conf====<br />
<br />
'''This ruleset require mod_security 2.9.0 and above.'''<br />
<br />
This is the advanced Cross Site Scripting (XSS) protection rule set. It performs deep level inspections of web requests and responses to look for potential XSS attacks.<br />
<br />
====12_asl_brute.conf====<br />
<br />
'''This ruleset is only available with [[ASL]] or the Real Time Rules.''' <br />
<br />
This ruleset detects authentication failures against all major web applications (Joomla, WordPress, MovableType, Drupal, ModX, ZenCart, OsCommerce, VBulletin, PHPBB and more).<br />
<br />
When used with [[ASL]], fast and "low and slow" brute force attacks can be detected and blocked in real time.<br />
<br />
Requires: Modsecurity 2.6.8 and up. <br />
<br />
'''Note: [[ASL]] is necessary to perform active response to brute force attacks.'''<br />
<br />
====13_asl_brute_enhanced.conf====<br />
<br />
Requires: Modsecurity 2.9.2 and up.<br />
<br />
These rules are for platforms that do not have either [ASL] or Atomic Protector installed. These rules create the collections in modsecurity to block brute force attacks. The defaults are > 10 failures within 60 seconds.<br />
<br />
''Note: These rules are not necessary if the systen has ASL or Atomic Protector installed, and should not be used with ASL or AP.<br />
<br />
Note 1: These rules will only work if the web server can write to the SecDataDir directory. That directory will contain sqllite databases that modsecurity will create and use to count events, without the collection modsecurity can not maintain state for composite events, like multiple login failures, and these rules will not work.''<br />
<br />
====20_asl_useragents.conf====<br />
<br />
Looks for malicious or suspicious user agents and known patterns of malicious activity. These rules require modsecurity 2.7.1 and up.<br />
<br />
Requires: Modsecurity 2.7.1 and up.<br />
<br />
====30_asl_antispam.conf====<br />
<br />
Tuned antispam rules, designed to work with all known blogs, forums, guestbooks, CMS' and other web content management systems that allow users to post content.<br />
<br />
Requires: Modsecurity 2.6.8 and up.<br />
<br />
====30_asl_antispam_advanced.conf====<br />
<br />
(Not released yet) These are advanced spam rules. They require modsecurity 2.7.1 and up.<br />
<br />
Requires: Modsecurity 2.7.1 and up.<br />
<br />
====30_asl_antispam_referrer.conf====<br />
<br />
Rules to block referrer spam. Generally not needed in most environments if you protect web log generation tools from public access (which is the default for most control panels).<br />
<br />
Requires: Modsecurity 2.6.0 and up.<br />
<br />
====40_asl_apache2-rules.conf====<br />
<br />
This ruleset has been retired. mod_security 2.x does not work with Apache 1.x and this ruleset existed just for those rules that only worked with apache 2. As mod_security 2.x does not work with Apache 1.x there is no need for this ruleset.<br />
<br />
====50_asl_rootkits.conf====<br />
<br />
Detects and blocks known web based rootkits, PHP/ASP/PERL shells, spam tools and other malicious web applications from being installed, and in some cases from running on the system. These rules exist for cases where malicious software may already be installed on the system, this is a defense in depth rule set)<br />
<br />
Not: ASL can prevent all malware from running on the system, modsecurity is limited in this regard so if you are only using the rules you should not expect modsecurity to prevent malware from running. It may prevent it in some cases, but without kernel level protection such as that provided in [[ASL]] no WAF can stop all malware from running on the system itself.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====51_asl_rootkits.conf====<br />
<br />
These rules look for known malware names in filenames, and URLs.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====60_asl_recons.conf====<br />
<br />
Blocks known "google hacks" or webserver probes that look for vulnerable applications and signs of compromised systems running unauthorized shells, or unprotected applications that allow uploads which would give an attacker access to the system.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====61_asl_recons_dlp.conf====<br />
<br />
These rules detect Data Loss Search engine "hacks". These are search engine probes for sensitive files, often used by malicious parties to find sensitive information accidentally exposed on web servers.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====99_asl_a_redactor.conf====<br />
<br />
ASL only rule set. Requires modsecurity 2.6.0 and up. Part of the malicious code removal system. Automatically removes malicious code from web pages, such as hidden iframes, encoded javascript and other malicious code. '''Do not enable this ruleset if you are not using ASL. ''' <br />
<br />
====99_asl_exclude.conf====<br />
<br />
Post exclude rules.<br />
<br />
====98_asl_adv_redactor.conf====<br />
<br />
This is the new advanced malware removal system. This ruleset will remove malware "on the fly" from web pages. For example, it will remove hidden iframes, malicous javascript, and other malicious code.<br />
<br />
'''Requires: modsecurity 2.7.5 and up.'''<br />
<br />
====98_asl_jitp.conf====<br />
<br />
This is a special ruleset used by [[ASL]]. If you do not have [[ASL]] you can not use these rules.<br />
<br />
====99_asl_jitp.conf====<br />
<br />
Just in Time Patches. We publish JITPs daily if there is a new web application vulnerability that the 10_asl_rules.conf do not protect the system against. These are tuned rules for specific vulnerabilities in a web application.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====99_asl_a_redactor.conf====<br />
<br />
This ruleset is reserved, and is not currently used.<br />
<br />
====99_asl_redactor.conf====<br />
<br />
'''Note: Do not enable this ruleset unless you have been instructed to do so by support.'''<br />
<br />
Special ruleset - requires mod_sed to be loaded on the system which is included and supported in [[ASL]] - removes malicious code from web pages, such as hidden iframes, encoded javascript and other malicious code. We highly recommend you use this rule set - its fast, multithreads and will automagically remove malicious code from infected webpages, which can occur if an adversary is able to log into the system and modify the code, such as by SSH or by uploading the code via FTP. If you are not using [[ASL]] then you will need to make sure your system has mod_sed installed to use these rules, they will not load and therefore will not do anything without mod_sed installed. This ruleset is only supported with [[ASL]].<br />
<br />
====99_asl_redactor_post.conf====<br />
<br />
This ruleset detects malicious content in webpages, such as known malicious domains.<br />
<br />
====99_asl_scanner.conf====<br />
<br />
This is the same as 05_asl_scanner.conf, its provided in a form to run last. This is the recommended location for the scanner function, as the rules before this stop some attacks that the scanner also detects, but do this in a faster and less CPU intensive manner. Running the scanner last does not compromise or lower the effectiveness of the rules. This is just a performance enhancement. This ruleset is only supported with [[ASL]].<br />
<br />
====99_asl_z_adv_scanner.conf====<br />
<br />
'''Note: Requires [[ASL]] and modsecurity 2.9.0 and higher.'''<br />
<br />
This ruleset uses a fuzzy hash to identify potentially malicious files.<br />
<br />
Warning: This ruleset is not supported on non-ASL systems. Do not use this without ASL.<br />
<br />
==== Paranoid mode rules ====<br />
<br />
===== 15_asl_paranoid_rules.conf =====<br />
<br />
'''Note: Do not use these rules if you have not read this section.'''<br />
<br />
'''Please do not report false positives with these rules. If you encounter a false positive with a rule from this file, please use its duplicate in 10_asl_rules.conf instead. If you have a false positive with a rule from 10_asl_rules.conf, please report it to us.'''<br />
<br />
These are a special version of the 10_asl_rules.conf file, they use the same rule id:s as the 10_asl_rules.conf file. Therefore, you can not use these rules along with the 10_asl_rules.conf file. You can use one, or the other, but not both.<br />
<br />
These rules are a paranoid replacement for the 10_asl_rules.conf file. These rules do not contain any known safe mode application tuning exceptions or bypasses. These rules will generate false positives. These rules are made available for users that wish to tune their own rules, and do not wish to use a ruleset that has been tuned for false positives.<br />
<br />
For example, if you had a application that safely used the argument "url" to accept URLs:<br />
<br />
GET /application?url=http://www.example.com/safething<br />
<br />
The normal rules would allow this, if this was known to be safe for the application. <br />
<br />
The paranoid rules, however, will NOT allow this, even if this is known to be safe for the application. They will alert, and if configured (or misconfigured) also block this as an RFI attack. These rules will alert on things that may be safe or are known to be non-malicious. This will generate a lot of false positives for most users, therefore you should not use these rules if you do not want to experience a high degree of false positives. These rules exist for paranoid users, who may want to tune the rules themselves, or may wish to know about every possible potentially malicious event, even when the event may in fact not be malicious.<br />
<br />
We do not recommend you use these rules in blocking mode, instead you should use these only in detect mode, and only if you feel that your applications are doing things in a very unsafe manner. If you do wish to use these rules, make sure that you load them from a special file so you can set the default behaviour of the rules. If you do not do this, the rules will inherit you systems default behavior, which is generally to block.<br />
<br />
Example configuration lines for the paranoid rules:<br />
<br />
<pre><br />
SecDefaultAction "log,pass,auditlog,phase:2,t:none,t:lowercase,t:replaceNulls,t:compressWhitespace"<br />
Include modsecurity.paranoid.rules.d/15_asl_paranoid_rules.conf<br />
</pre><br />
<br />
You must load these rules last.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
==== Using the paranoid rules ====<br />
<br />
If you want to use the paranoid rules because you have found a vulnerability in your application that the normal rules do not block, please let us know, we would be happy to take a look at either creating a Just In Time Patch for your vulnerability, or adjusting the tuned rules to not allow this. Remember, if you use our real time rules, we provide this service for free. One easy way to find out if you have applications that have unusual vulnerabilities is to scan the application with a web vulnerability application scanner, if you find something the normal rules dont stop just let us know. We'd be delighted to put out new rules for your applications vulnerabilities.<br />
<br />
Finally, if you do you use these rules you will need to set ATOMIC_PARANOID_MODE to 1 in your modsecurity configuration. If you do not know how to do this, we do not recommend you use these rules.<br />
<br />
'''Note: Do not use this ruleset with [[ASL]]. [[ASL]] uses intelligent defense in depth, and does need this kind of ruleset to protect you. You will get a greater level of protection from ASL, without all the false positives.'''<br />
<br />
==== Beta Rules ====<br />
<br />
==== Experimental Rules ====<br />
<br />
<br />
====70_asl_csrf_experimental.conf====<br />
<br />
These are experimental CSRF mitigation rules. The 10_asl_rules.conf rules are designed to also handle some types of CSRF attacks, however these rules are for more advanced environments.<br />
<br />
These rules work by injecting javascript code into the response, and special cookies, and must be tuned for the system to prevent false positives. If you do not understand what this means, do not use these rules.<br />
<br />
'''They are currently not supported and are experimental.'''<br />
<br />
Requires: Modsecurity 2.7.0 and up.</div>Mshinnhttps://wiki.atomicorp.com/wiki/index.php/Atomic_ModSecurity_RulesAtomic ModSecurity Rules2022-10-06T21:30:55Z<p>Mshinn: /* litespeed */</p>
<hr />
<div>[[Atomic Secured Linux]] includes modsecurity, and the Real Time GotRoot.com/Atomicorp Modsecurity Rules. These docs are for users that do not have [[ASL]].<br />
<br />
'''ASL will install and configure modsecurity, and provides a powerful and easy use to GUI to manage all of this for you. If you don't have ASL, [https://www.atomicorp.com/amember/cart/index/index?c=1 upgrade to ASL today!]'''<br />
<br />
= '''About the rules''' =<br />
<br />
The gotroot.com rules are written by us - we are the gotroot guys. Same great rules, same team, ten years of writing modsecurity rules and still going strong! GotRoot is our Information Assurance lab and [http://www.atomicorp.com Atomicorp] is the product arm of [http://www.progllc.com Prometheus Global] (the parent company for both). So when you get the gotroot.com rules from atomicorp.com or gotroot.com - you're getting the same rules from the same people that created, write and maintain them. In the future we will be merging the gotroot.com, atomicrocketturtle and atomicorp websites into the atomicorp.com website.<br />
<br />
We publish two versions of the rules:<br />
<br />
'''RealTime Rules:''' The latest and greatest version of the rules, with all the performance enhancements, new security features and bug fixes released by us on a daily basis. These rules are fully supported and are recommended for production use.<br />
<br />
'''Free/Delayed Rules:''' A delayed subset of the Advanced rules.<br />
<br />
Installation of the rules assumes a certain level of comfort with configuring apache. If you are not comfortable with configuring apache, you should contact someone that is, or use our [[Atomic Secured Linux]] product which does this automatically for you, and does not require you to configure apache.<br />
<br />
== Getting the rules ==<br />
<br />
[https://www.atomicorp.com/amember/cart/index/index?c=6 Click here] to get the Atomicorp ModSecurity Rules.<br />
<br />
== '''Atomic ModSecurity Rules Frequently Asked Questions''' ==<br />
<br />
Please see the [[Atomic ModSecurity Rules FAQ]] wiki page.<br />
<br />
== '''Real Time Rule Support''' ==<br />
<br />
If you have a subscription to the real time rules, you can request email support by sending an email to:<br />
<br />
support@atomicorp.com<br />
<br />
The Customer Support Forums are located here:<br />
<br />
[http://www.atomicorp.com/forums Customer Support Forums]<br />
<br />
And the Custom Support Portal is located here (you can submit bug reports and open cases through the portal):<br />
<br />
[https://www.atomicorp.com/portal Customer Support Portal]<br />
<br />
== '''Licenses''' ==<br />
<br />
The Real Time Atomic ModSecurity Rules are licensed by the server. You can order licenses from the online store at the link below:<br />
<br />
[https://www.atomicorp.com/amember/cart/index/index?c=6 Online Store]<br />
<br />
If you require additional licenses please log into the [https://www.atomicorp.com/support/license-manager.html AtomiCorp License Manager]. You can add additional systems there, you can control your payment methods and you can also sign up to become an affiliate.<br />
<br />
=== License Terms and Conditions ===<br />
<br />
Purchase of an Atomicorp ModSecurity rule license entitles the purchaser to access and download from the Atomicorp Repository to a single IP address within the time period of the license. A separate license is required for each dedicated server/host or VPS that the rule set is installed upon or is protecting.<br />
<br />
Atomicorp ModSecurity rules installed upon a Reverse Proxy WAF appliance/server requires a separate license. Please contact Atomicorp support for details.<br />
<br />
The rule set cannot be copied, mirrored, or reproduced under protection of US and International copyright laws.<br />
<br />
Use of the rule set is limited to the time period of the license. If the license period of a rule set expires, it must must removed from its installed server and no longer used. Atomicorp reserves the right to track and enforce license compliance of the Atomicorp Modsecurity rule sets.<br />
<br />
Agreement to these terms and conditions and the Atomicorp [https://atomicorp.com/eula.html End User License Agreement] is required to download and use the Atomicorp ModSecurity rules.<br />
<br />
== Important Information about the Rules ==<br />
<br />
=== Minimum Version of Modsecurity Required to use the rules ===<br />
<br />
The rules are supported with the following versions of Modsecurity:<br />
<br />
<br />
* 2.9.3<br />
<br />
We recommend customers use our modsecurity builds, as they are tested to ensure all features work correctly. Third party builds may not include the correct libraries, may cause problems with your web server, including crashes and may disable or incorrectly enable features in modsecurity that can cause unpredictable behavior or failure of rules to process correctly.<br />
<br />
If you need a solution to keep the rules and modsecurity up to date and in sync with your version of modsecurity automatically, please use [[aum]] or [[ASL]] which will do this for you automatically.<br />
<br />
==== What versions of modsecurity do the rules work with ====<br />
<br />
They work with both modsecurity 2.9.x, and modsecurity 3.x.<br />
<br />
=== What does each rule family do? ===<br />
<br />
Please see the [[modsecurity_rule_families]] documents.<br />
<br />
= Installation =<br />
<br />
== Easy One Step Installation ==<br />
<br />
<br />
<br />
===== Full Management Suite =====<br />
<br />
Install [[ASL]]. This installs everything: modsecurity, all the rules, the GUI, rule manager and all ASL components, plus it includes the subscription to the real time rules.<br />
<br />
ASL will automatically download and keep your rules up to date, and will ensure that modsecurity stays up to date so your system can support the latest rules. ASL also provides you with a full security management suite, which will allow you to manage, edit and configure your rules through a web console. It will also protect you from uploaded malware, brute force attacks, DOS attacks, rootkits and many other threats that a WAF can not protect you from.<br />
<br />
A full list of ASLs features is available at the URL below:<br />
<br />
https://www.atomicorp.com/products/asl.html<br />
<br />
===== Just a downloader =====<br />
<br />
We also provide an automated rule updater and modsecurity installation tool, called [[aum]]. You can read more about it on the [[aum]] page. You can install it by running these commands as root:<br />
<br />
Step 1) Install [[aum]]<br />
<br />
''wget -q -O - https://updates.atomicorp.com/installers/aum |bash''<br />
<br />
Step 2) Configure [[aum]]<br />
<br />
''aum configure''<br />
<br />
Step 3) Tell [[aum]] to install the rules<br />
<br />
''aum upgrade''<br />
<br />
You can read more about aum on the [[aum]] documentation page.<br />
<br />
Note: This capability is included in [[ASL]]. ASL users do not need to install aum, its already included.<br />
<br />
== (Optional) Do It Yourself Installation ==<br />
<br />
Note: A manual installation is not necessary if you have [[ASL]] installed. ASL will configure and install modsecurity, and the rules, automatically. This is also not necessary if you are using our new AUM software to handle rule download and installation.<br />
<br />
=== Linux ===<br />
<br />
==== Step 1: Download ModSecurity ====<br />
<br />
Binaries:<br />
<br />
[http://updates.atomicorp.com/channels/atomic/ Install modsecurity from the Atomicorp software repository]<br />
<br />
Source Code:<br />
<br />
[http://updates.atomicorp.com/channels/atomic/ Install modsecurity from the Atomicorp software repository]<br />
<br />
Please note that the rules are only supported with the version of modsecurity [http://wiki.atomicorp.com/wiki/index.php/Atomic_ModSecurity_Rules#Minimum_Version_of_Modsecurity_Required_to_use_the_rules identified in this section of the wiki.]<br />
<br />
Note: Please contact us before using a third party or source build of modsecurity. Its critical modsecurity be built correctly to work with the rules.<br />
<br />
==== Step 2: Set up and configure directories ====<br />
<br />
Create the following directories as root:<br />
<br />
mkdir /etc/httpd/modsecurity.d<br />
mkdir /var/asl<br />
mkdir /var/asl/tmp<br />
mkdir /var/asl/data<br />
mkdir /var/asl/data/msa<br />
mkdir /var/asl/data/audit<br />
mkdir /var/asl/data/suspicious<br />
<br />
==== Step 3: Set permissions for directories ====<br />
<br />
Set the following permissions on the directories you just created. In this example these directories are set to be owned by "apache" and the group "apache", which is standard on a normal Centos or RHEL system. However some control panels configure apache to run as a different user, such as nobody, or http. <br />
<br />
To determine what user this is, check your system to see what user your webserver uses. You can use this command to find the user:<br />
<br />
ps auxwww | grep httpd<br />
<br />
The output will look similar to this:<br />
<br />
(RHEL/Centos example with or without Plesk)<br />
<br />
root 26755 0.0 4.3 430752 86432 ? Ss 04:30 0:01 /usr/sbin/httpd<br />
'''apache''' 26908 0.0 3.7 300564 75076 ? S 04:30 0:00 /usr/sbin/httpd<br />
'''apache''' 26909 0.1 5.5 495812 112084 ? S 04:30 0:37 /usr/sbin/httpd<br />
'''apache''' 26910 0.0 5.3 495424 106672 ? S 04:30 0:23 /usr/sbin/httpd<br />
'''apache''' 26911 0.1 5.7 495892 114368 ? S 04:30 0:57 /usr/sbin/httpd<br />
'''apache''' 26912 0.1 5.7 496056 114440 ? S 04:30 0:52 /usr/sbin/httpd<br />
'''apache''' 26913 0.1 5.5 496604 110692 ? S 04:30 0:57 /usr/sbin/httpd<br />
'''apache''' 26914 0.0 5.7 499324 116236 ? S 04:30 0:16 /usr/sbin/httpd<br />
'''apache''' 26915 0.2 5.5 493600 112192 ? S 04:30 1:09 /usr/sbin/httpd<br />
'''apache''' 26916 0.1 6.4 513760 129992 ? S 04:30 0:30 /usr/sbin/httpd<br />
<br />
In this example the user in bold is "apache" (this may be different for your system). This is the user you will want to set the directory permissions to (as in the example below):<br />
<br />
chown apache.apache /var/asl/data/msa<br />
chown apache.apache /var/asl/data/audit<br />
chown apache.apache /var/asl/data/suspicious<br />
chmod o-rx -R /var/asl/data/*<br />
chmod ug+rwx -R /var/asl/data/*<br />
<br />
(RHEL/Centos example with Cpanel)<br />
<br />
root 20594 86.8 3.1 255148 181232 ? Ss 11:39 0:04 /usr/local/apache/bin/httpd -k restart<br />
root 20611 0.0 3.1 255060 179596 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20612 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20613 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20614 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20615 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20616 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
<br />
In this example from a Centos system running Cpanel the user is "nobody", so you would want to use these commands:<br />
<br />
chown nobody.nobody /var/asl/data/msa<br />
chown nobody.nobody /var/asl/data/audit<br />
chown nobody.nobody /var/asl/data/suspicious<br />
chmod o-rx -R /var/asl/data/*<br />
chmod ug+rwx -R /var/asl/data/*<br />
<br />
==== Step 4: (Optional) Create rule updater directories ====<br />
These directories must as be created if you use optional rules updater. Create these directories as root and they only need to be accessed by root:<br />
<br />
mkdir /var/asl/updates<br />
mkdir /var/asl/rules/<br />
mkdir /var/asl/rules/clamav<br />
<br />
==== Step 5: Create the whitelist file ====<br />
<br />
Create this file:<br />
<br />
touch /etc/asl/whitelist<br />
<br />
This file contains a list of IPs you want to exclude from ALL rules. That means those IPs can do anything to your system - so be very very careful about what IPs you add to this list. This is a dangerous thing to do. The format of the file is a single IP, per line. <br />
<br />
Cpanel users should skip to the notes at the bottom of this page for special additional actions for cpanel systems. All other users should continue with these instructions.<br />
<br />
==== Step 6: Configure your webserver ====<br />
<br />
===== nginx =====<br />
<br />
===== Step 6a: configure nginx to load modsecurity =====<br />
<br />
====== nginx proxying to a backend ======<br />
<br />
If you are using nginx as a frontend to another webserver, then add the following directives to your nginx.conf file.<br />
<br />
<pre><br />
location / {<br />
ModSecurityEnabled on;<br />
ModSecurityConfig modsecurity.conf;<br />
proxy_pass http://localhost:8080;<br />
proxy_read_timeout 180s;<br />
}<br />
<br />
</pre><br />
<br />
Change "localhost:8011" to the server you are proxying nginx to, and change 8080 to the portnumber for that server. For example, if you are running apache on port 8088 on localhost the line would be:<br />
<br />
proxy_pass http://localhost:8088;<br />
<br />
====== nginx standalone ======<br />
<br />
If you are only using nginx, and not using it as a frontend to another web server then you want to use this configuration:<br />
<br />
<pre><br />
location / {<br />
ModSecurityEnabled on;<br />
ModSecurityConfig modsecurity.conf;<br />
}<br />
</pre><br />
<br />
===== Apache =====<br />
<br />
===== Step 6a: configure apache to load modsecurity =====<br />
<br />
You then need to tell apache to load modsecurity. Depending on your apache configuration, apache should be configured to include configuration files. If you have a setting like this in your apache config:<br />
<br />
Include conf.d/*.conf<br />
<br />
Then you are setup to load external configuration files. If you do not have this setup, its highly recommend you add this. This installation guide is written for this type of configuration. Loading mod_security occurs by including a modsecurity configuration file in that directory. We recommend you name the name 00_modsecurity.conf to ensure it runs first. Its vitally important that modsecurity load before other modules, otherwise attacks can occur before modsecurity scans them and some attacks can be missed.<br />
<br />
An example 00_modsecurity.conf file that works with our files is included here:<br />
<br />
LoadModule security2_module modules/mod_security2.so<br />
LoadModule unique_id_module modules/mod_unique_id.so<br />
<IfModule mod_security2.c><br />
Include modsecurity.d/tortix_waf.conf<br />
</IfModule><br />
<br />
Install this file in your conf.d directory. On a standard RHEL or Centos system that directory is located here:<br />
<br />
/etc/httpd/conf.d/<br />
<br />
=== Step 7: Configure modsecurity ===<br />
<br />
You then need to configure modsecurity. This is done via the an apache configuration file. In this example, we will create the file "tortix_waf.conf". Here is an example file that works with our rules:<br />
<br />
SecRuleEngine On<br />
SecRequestBodyAccess On<br />
SecResponseBodyAccess On<br />
SecResponseBodyMimeType (null) text/html text/plain text/xml<br />
SecResponseBodyLimit 2621440<br />
SecServerSignature Apache<br />
SecComponentSignature 200911012341<br />
SecUploadDir /var/asl/data/suspicious<br />
SecUploadKeepFiles Off<br />
SecAuditEngine RelevantOnly<br />
SecAuditLogRelevantStatus "^(?:5|4(?!04))"<br />
SecAuditLogType Concurrent<br />
SecAuditLog logs/audit_log<br />
[[SecAuditLogParts]] ABIFHZ<br />
SecArgumentSeparator "&" <br />
SecCookieFormat 0<br />
SecRequestBodyInMemoryLimit 131072<br />
SecDataDir /var/asl/data/msa<br />
SecTmpDir /tmp<br />
SecAuditLogStorageDir /var/asl/data/audit<br />
SecResponseBodyLimitAction ProcessPartial<br />
SecAuditLogDirMode 0770<br />
SecPcreMatchLimit 250000 <br />
SecPcreMatchLimitRecursion 250000<br />
<br />
You will want to install this file in your modsecurity.d directory, which is located here if you follow the instructions above:<br />
<br />
/etc/httpd/modsecurity.d<br />
<br />
==== tortix_waf.conf ====<br />
<br />
You can also download an example version of the modsecurity configuration file from here:<br />
<br />
https://www.atomicorp.com/installer/tortix_waf.conf<br />
<br />
[[ASL]] will automatically generate this file depending on your needs. If you are not using ASL, you will need to modify this configuration file to suit your system and modsecurity requirements.<br />
<br />
==== Step 8: Download the ModSecurity Rules ====<br />
<br />
See the [[Downloading Rules]] page.<br />
<br />
==== Step 9: Install the rules ====<br />
<br />
==== Remove any previous installations of rules ====<br />
<br />
If you have installed our delayed rules, you will need to make sure you have deleted them. You will not want to have any older versions of the rules installed.<br />
<br />
Also, if you have installed any third party modsecurity rules, you will want to make sure they are using rule id's that are assigned to them. The modsecurity project assigns ranges to the rule id's modsecurity uses. Modsecurity requires a unique id for each rule, otherwise you will get an error like this:<br />
<br />
ModSecurity: Found another rule with the same id<br />
<br />
This means either that someone else is using the same rule id's assigned to our ruleset by the modsecurity project (our official range is 300000-399999), or you have loaded our rules twice.<br />
<br />
==== Installation ====<br />
<br />
Download the rules to a temporary directory using your favorite download tool. Extract the rules:<br />
<br />
tar zxvf /var/asl/updates/modsec-200911012341.tar.gz<br />
<br />
Then copy each of the ASL rule files you wish to use into /etc/httpd/modsecurity.d. Do not copy all of the rule files, you will need to select rule files that are appropriate for your system. Or simply use [[aum]] or [[ASL]] to do this for you automatically.<br />
<br />
If you are using cpanel, please see the notes at the bottom of this page, cpanel does not use the standard locations for apache configuration files.<br />
<br />
Finally, load the rules. '''Make sure you specify only those rule files that are appropriate for your system.''' For example:<br />
<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/99_asl_jitp.conf<br />
<br />
'''Warning: You should NOT include all the rules. There are rulesets, documented above, that replace other rulesets and are incompatible with each other.'''<br />
<br />
===== Recommend minimum rulesets =====<br />
<br />
====== apache ======<br />
<br />
The recommended ''minimum ruleset'' to load is:<br />
<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_0_global.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_antimalware.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/11_asl_adv_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/20_asl_useragents.conf<br />
Include /full/path/to/your/rules/modsecurity.d/30_asl_antispam.conf<br />
Include /full/path/to/your/rules/modsecurity.d/50_asl_rootkits.conf<br />
Include /full/path/to/your/rules/modsecurity.d/60_asl_recons.conf<br />
Include /full/path/to/your/rules/modsecurity.d/61_asl_recons_dlp.conf<br />
Include /full/path/to/your/rules/modsecurity.d/99_asl_jitp.conf<br />
<br />
If you have modsecurity 2.9.0 and up installed, you should also load additional rule files and should use this ruleset:<br />
<br />
Include /full/path/to/your/rules/modsecurity.d/000_asl_threat_intelligence.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_zz_strict.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_0_global.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_z_antievasion.conf<br />
Include /full/path/to/your/rules/modsecurity.d/01_asl_content.conf<br />
Include /full/path/to/your/rules/modsecurity.d/01_asl_content_z.conf<br />
Include /full/path/to/your/rules/modsecurity.d/03_asl_dos.conf<br />
Include /full/path/to/your/rules/modsecurity.d/09_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_antimalware.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/11_asl_adv_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/11_asl_data_loss.conf<br />
Include /full/path/to/your/rules/modsecurity.d/12_asl_adv_xss_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/20_asl_useragents.conf<br />
Include /full/path/to/your/rules/modsecurity.d/30_asl_antispam.conf<br />
Include /full/path/to/your/rules/modsecurity.d/50_asl_rootkits.conf<br />
Include /full/path/to/your/rules/modsecurity.d/51_asl_rootkits.conf<br />
Include /full/path/to/your/rules/modsecurity.d/60_asl_recons.conf<br />
Include /full/path/to/your/rules/modsecurity.d/61_asl_recons_dlp.conf<br />
Include /full/path/to/your/rules/modsecurity.d/99_asl_jitp.conf<br />
Include /full/path/to/your/rules/modsecurity.d/98_asl_adv_redactor.conf<br />
<br />
If you have a [[Local DNS resolver]] setup and properly configured on your system, and you are using modsecurity 2.9.0 and up we also recommend these additional rulesets:<br />
<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_z_searchengines.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_z_aa_threat_intelligence.conf<br />
Include /full/path/to/your/rules/modsecurity.d/99_asl_zzzz_threat_intelligence.conf<br />
<br />
Note: Some of these rulesets are designed to work with advanced security management systems such as [[ASL]] and may not work completely without an advanced management system.<br />
<br />
====== nginx ======<br />
<br />
The same rulesets as apache will work with nginx.<br />
<br />
====== litespeed ======<br />
<br />
[[Litespeed]] has a proprietary implementation of mod_security. It does not support all the features that mod_security with apache, IIS and nginx does. Therefore, you can not use all the rulesets with Litespeed, as Litespeed does not support those features of mod_security. The following rulesets are recommended with Litespeed:<br />
<br />
The recommended ''minimum ruleset'' to load is:<br />
<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_0_global.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_antimalware.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/11_asl_adv_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/20_asl_useragents.conf<br />
Include /full/path/to/your/rules/modsecurity.d/30_asl_antispam.conf<br />
Include /full/path/to/your/rules/modsecurity.d/50_asl_rootkits.conf<br />
Include /full/path/to/your/rules/modsecurity.d/60_asl_recons.conf<br />
Include /full/path/to/your/rules/modsecurity.d/61_asl_recons_dlp.conf<br />
Include /full/path/to/your/rules/modsecurity.d/99_asl_jitp.conf<br />
<br />
If you require more advanced protection, you should also load additional rule files and should use this ruleset:<br />
<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_zz_strict.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_z_searchengines.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_0_global.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_z_antievasion.conf<br />
Include /full/path/to/your/rules/modsecurity.d/01_asl_content.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_zz_strict.conf<br />
Include /full/path/to/your/rules/modsecurity.d/03_asl_dos.conf<br />
Include /full/path/to/your/rules/modsecurity.d/09_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_antimalware.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/11_asl_adv_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/11_asl_data_loss.conf<br />
Include /full/path/to/your/rules/modsecurity.d/12_asl_adv_xss_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/20_asl_useragents.conf<br />
Include /full/path/to/your/rules/modsecurity.d/30_asl_antispam.conf<br />
Include /full/path/to/your/rules/modsecurity.d/50_asl_rootkits.conf<br />
Include /full/path/to/your/rules/modsecurity.d/51_asl_rootkits.conf<br />
Include /full/path/to/your/rules/modsecurity.d/60_asl_recons.conf<br />
Include /full/path/to/your/rules/modsecurity.d/61_asl_recons_dlp.conf<br />
Include /full/path/to/your/rules/modsecurity.d/99_asl_jitp.conf<br />
<br />
<br />
Note: [[Litespeed]] does not support content inspection (outbound rules), or lua based rules. Therefore, the following rulesets Litespeed does not support, and loading them will have no effect on the system:<br />
<br />
<br />
00_asl_z_searchengines.conf<br />
00_asl_z_aa_threat_intelligence.conf<br />
12_asl_brute.conf<br />
98_asl_adv_redactor.conf<br />
99_asl_zzzz_threat_intelligence.conf<br />
<br />
Note: Some of these rulesets are designed to work with advanced security management systems such as [[ASL]] and may not work completely without an advanced management system.<br />
<br />
===== Notes on Scanner ruleset =====<br />
<br />
NOTE: If you use this file:<br />
<br />
05_asl_scanner.conf<br />
<br />
Or this file:<br />
<br />
99_asl_scanner.conf<br />
<br />
[[ASL]] includes malware upload scanning, rules subscriptions do not.<br />
<br />
If you wish to use this ruleset, and you are not using [[ASL]], then you will need to create a script to pass the files to clamd and read the result. Make sure you have clamd installed and configured correctly to list on a TCP port, or if you use a socket, make sure apache can read/write to this socket or as a last resort, run clamd as root. Using this file will force all web uploads on your system to go thru clamav to look for malware, viruses, etc. If you dont need that, then you can leave this config file out. <br />
<br />
Real time malware upload protection is included in [[ASL]] and uses a faster method than the older style modsecurity scripting method above. So if you need realtime malware upload protection (for web, FTP, or even realtime), then upgrade to [[ASL]] which includes highspeed malware upload protection, full support, automatic and hassle free installation. ASL also protects against any form of upload of malware, including HTTP, HTTPS, SSH and FTP uploads and includes our real-time malware detection and prevention system which will detect and block any malicious software running on the system in realtime. This is just one of the many many features of [[ASL]].<br />
<br />
==== Step 10: Test your web server ====<br />
===== Test nginx =====<br />
<br />
nginx -t -c <NGINX_CONFIG_FILE><br />
<br />
Where NGINX_CONFIG_FILE is your nginx.conf file.<br />
<br />
===== Test Apache =====<br />
<br />
Before restarting apache we recommend you test your configuration by running apache with the "configtest" command. On a standard system you can do this by calling your apache init file like this:<br />
<br />
/etc/init.d/httpd configtest<br />
<br />
If you get errors, check to see that you don't have some extraneous configuration files installed.<br />
<br />
===== Testing to see if the rules are loaded =====<br />
'''<br />
Step 1)''' (for non [[ASL]] systems)<br />
<br />
Make sure you have the rules installed exactly as described on this page. This test may not work if you have not followed these instructions. (If you used ASL to setup your WAF, and you have not installed any third party tools that configure, install or manage modsecurity then your rules are installed correctly and you do not need to review the instructions on this page. If you have manually altered your modsecurity configuration then you will need to review this entire article. Manual modifications of ASL modsecurity configurations are not supported.)<br />
<br />
'''Step 2) Make sure all rules are enabled'''<br />
<br />
'''Ensure that you do not have any of our rules disabled.''' This test assumes you do not have any rules disabled, that you are not whitelisting the source of this test and that your have the Atomicorp rules loaded.<br />
<br />
'''Step 3) Test from a non-whitelisted system''' <br />
<br />
Make sure you do not have the system you are performing this from is whitelisted<br />
<br />
For example, cpanels default modsecurity configuration will configure modsecurity to ignore everything from 127.0.0.1, or from the system itself. So if you perform the test above from the server itself, and you have not removed this cpanel whitelist, then this test will not work.<br />
<br />
'''Step 4) Run the test'''<br />
<br />
On the system where the rules are installed run this command (this assumes you have wget installed, '''127.0.0.1 is NOT whitelisted''' and a web server is listening on 127.0.0.1):<br />
<br />
''wget http://localhost/foo.php?foo=http://www.example.com''<br />
<br />
If the test worked, should get a 403 error if the rules are loaded, which will look similar to this:<br />
<br />
<pre><br />
--2010-05-27 20:12:25-- http://localhost/foo.php?foo=http://www.example.com<br />
Resolving localhost... 127.0.0.1<br />
Connecting to localhost|127.0.0.1|:80... connected.<br />
HTTP request sent, awaiting response... 403 Forbidden<br />
2010-05-27 20:12:25 ERROR 403: Forbidden.<br />
</pre><br />
<br />
If you do not get a 403 error, the test did not work.<br />
<br />
You can also use your browser to test the rules by going to a URL similar to this:<br />
<br />
http://YOUR_HOST/foo.php?foo=http://www.example.com<br />
<br />
Remember to replace YOUR_HOST with the actual HOSTNAME or IP of the server.<br />
<br />
If the rules are properly loaded, you should get a 403 error, if you do not get a 403 error, the rules are not loaded correctly and you need to check your configuration to ensure that you have followed the instructions above correctly.<br />
<br />
If you get a 403 error from the command line and a 404 error from the browser, check to make sure the computer you are testing the browser from is not whitelisted on the server.<br />
<br />
Note: If you do not have wget installed, then you will need to install it or a similar tool to run this test from a Linux or UNIX based system. If you are using Windows, you can use a similar tool or your browser.<br />
<br />
====== What to do if you do not get a 403 error ======<br />
<br />
If you get a different error, such as a 404 error or a 5xx series error check your configuration. The following are common causes of this:<br />
<br />
'''1) You have rules disabled'''<br />
<br />
Make sure you do not have any rules disabled.<br />
<br />
'''2) Your IP is whitelisted'''<br />
<br />
There is a rule whitelisting the system you are conducting this test from. Whitelisting tells the WAF to ignore everything from that source.<br />
<br />
For example, cpanels default modsecurity configuration will configure modsecurity to ignore everything from 127.0.0.1, or from the system itself. So if you perform the test above from the server itself, and you have not removed this cpanel whitelist, then you will not get a 403 error. More than likely you will get a 404 error. The solution is to remove any whitelists from your system.<br />
<br />
Note: Whitelisting the server itself can open a hole in your security. You should not whitelist localhost or the servers own IP address, particularly if you have multi users on the system. This is both unnecessary, and doing so will allow any users on the system to carry out attacks on other domains on the system unimpeded. Make sure you do not have any rules like that, this opens a very large hole in your system.<br />
<br />
'''3) Local error message is different'''<br />
<br />
You or someone else may have configured your system to use a different error message. Check your configuration, and make sure it exactly matches the ones on this wiki. IF you are using kind of plugin that does not return a 403 when a connection is rejected, and you must use this, then you will need to manually check your mod_security logs to see if your test is being rejected by modsecurity. If it is, then your rules are working correctly and you can ignore the error code.<br />
<br />
'''4) Third party addons''' <br />
<br />
You have third party rules or addons installed with your modsecurity configuration that are changing the responses. Remove all third party addons, and make sure your configuration exactly matches the instructions on this page<br />
<br />
'''5) Insecurely configured apache'''<br />
<br />
Some control panels are known to disable modsecurity on localhost, and on the systems IP addresses. These highly insecure control panels essentially disable modsecurity if an attacker connects to the systems IP address. This of course leaves your system wide open to attack, and if you are unlucky enough to be using one of these control panels we recommend you report this to your control panel vendor as a serious vulnerability. If they are unwilling to fix it, then we recommend you find a more security concious control panel vendor.<br />
<br />
Example:<br />
<br />
We have seen some control panels that configure modsecurity to be disabled in the /etc/httpd/conf/httpd.conf file for all the local IPs on the system. <br />
<br />
<pre><br />
<VirtualHost <LOCAL IP ADDRESS>:80 127.0.0.1:80 *><br />
<IfModule mod_security2.c><br />
SecRuleEngine Off<br />
</IfModule><br />
</pre><br />
<br />
If your control panel has this vulnerability, you can remove this, but its very possible the control panel will simply open this hole in your system again. We highly recommend you report this vulnerability to your control panel vendor, and if they are unwilling to fix this vulnerability that you find a more security concious control panel vendor.<br />
<br />
'''6) You arent loading the rules'''<br />
<br />
This is common with custom configurations. Check to make sure your webserver is configured to load the rules. Keep mind that modsecurity will still generate generic messages even though the rules are not loaded. For example, if all you see are events like this:<br />
<br />
<pre><br />
--70c19f31-A--<br />
[01/Jan/2013:11:19:13 --0300] roiKIi6Ni3EKFZSKpSUs2iEb 1.2.3.4 34978 5.6.7.8 80<br />
--70c19f31-B--<br />
HEAD / HTTP/1.1<br />
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) <br />
<br />
Accept: */*<br />
<br />
--70c19f31-F--<br />
HTTP/1.1 403 Forbidden<br />
X-Powered-By: PHP/5.4.20<br />
Expires: Thu, 19 Jan 2001 02:12:00 GMT<br />
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0<br />
Pragma: no-cache<br />
Connection: close<br />
Content-Type: text/html<br />
<br />
--70c19f31-H--<br />
Stopwatch: 1383338363503919 358184 (- - -)<br />
Stopwatch2: 1383338363503919 358184; combined=2144, p1=37, p2=2053, p3=0, p4=0, p5=53, sr=0, sw=1, l=0, gc=0<br />
Producer: ModSecurity for Apache/2.7.5 ( http://www.modsecurity.org/).<br />
Server: Apache<br />
Engine-Mode: "ENABLED"<br />
<br />
--70c19f31-Z--<br />
</pre><br />
<br />
In this example, no rule is being triggered, but modsecurity is logging a basic 403 error. It will do this if the modsecurity configuration is loaded, but not the rules. So if you see this happening on your system, and you have ruled out all other issues in this list, it means your custom configuration isnt loading the rules.<br />
<br />
[[ASL]] will automatically configure modsecurity correctly. So if you are having problems configuring modsecurity yourself, then we recommend you use [[ASL]] to setup modsecurity for you.<br />
<br />
=== Windows ===<br />
<br />
Please see the [[modsecurity iis]] page.<br />
<br />
== Automated rules updates ==<br />
<br />
Please see the [[ASL]] page for installation instructions.<br />
<br />
= Tuning the Rules/Disabling Rules =<br />
<br />
== Disabling Rules ==<br />
<br />
See the [[mod_security]] page for details.<br />
<br />
== Tuning the Rules ==<br />
<br />
See the [[mod_security]] page for details.<br />
<br />
== Troubleshoot the Rules ==<br />
<br />
See the [[Atomicorp WAF Rules Troubleshooting]] page for details.<br />
<br />
== Reporting False Positives ==<br />
<br />
See the [[Reporting False Positives]] page for details.<br />
<br />
= Notes =<br />
<br />
== Special notes for CPANEL users not using ASL ==<br />
<br />
The Atomicorp Modsecurity rules work great with Cpanel, right out of the box. To use them with Cpanel either install [[ASL]], or manually install modsecurity and make a few changes to the mod_security configuration that comes with cpanel and then you are all set!<br />
<br />
=== Installing modsecurity in cpanel ===<br />
<br />
'''Option 1) Simplest and most powerful solution'''<br />
<br />
Install [[ASL]]. This will install modsecurity, configure it and will install the rule and event management GUI available in [[ASL]]<br />
<br />
Option 2) Install just the rules<br />
<br />
=== Manually Configuring modsecurity with cpanel ===<br />
<br />
These are additional considerations for installing modsecurity with cpanel. Please read this entire page, as well as this section if you are installing modsecurity with cpanel (even if you already have modsecurity install with cpanel).<br />
<br />
We recommend if you are using cPanel that you follow this advice, as cpanel includes a very minimal configuration for modsecurity that does not include all of the required and optimal settings documented here. Our settings will make your server faster, and more importantly more secure. If you use mod_security with Cpanel you must add these additional settings to experience the full feature set of mod_security.<br />
<br />
==== Step 1 ====<br />
<br />
Make sure you have read this entire document and have setup all the require directories details above.<br />
<br />
==== Step 2: Configure directory permissions ====<br />
<br />
Certain versions of Cpanel do not run apache as a standard user (such as apache) but as the older non-privileged user "nobody". You will need to determine what use cpanel uses for the httpd processes, and that the modsecurity work directories are owned by the user that Cpanel runs apache as. To find this out you can run this command as root:<br />
<br />
ps auxwww | grep httpd<br />
<br />
root 20594 86.8 3.1 255148 181232 ? Ss 11:39 0:04 /usr/local/apache/bin/httpd -k restart<br />
root 20611 0.0 3.1 255060 179596 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20612 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20613 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20614 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20615 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20616 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
<br />
In this example from a Centos system running Cpanel the user is "nobody", so you would want to use these commands to configure the modsecurity work directories for a system where apache is running as "nobody": <br />
<br />
mkdir /var/asl<br />
mkdir /var/asl/data/<br />
mkdir /var/asl/data/msa<br />
mkdir /var/asl/data/audit<br />
mkdir /var/asl/data/suspicious<br />
chown nobody.nobody /var/asl/data/msa<br />
chown nobody.nobody /var/asl/data/audit<br />
chown nobody.nobody /var/asl/data/suspicious<br />
chmod o-rx -R /var/asl/data/*<br />
chmod ug+rwx -R /var/asl/data/*<br />
<br />
==== Step 3: Install modsecurity ====<br />
<br />
Please see the current minimum version required at the link below:<br />
<br />
https://www.atomicorp.com/wiki/index.php/Atomic_ModSecurity_Rules#Minimum_Version_of_Modsecurity_Required_to_use_the_rules<br />
<br />
==== Step 4: Install mod_uniqueid ====<br />
<br />
Cpanel users will need to manually verify that the mod_unique_id module is loaded by cpanel's apache. It should be loaded by default, but check your cpanel configuration to be sure.<br />
<br />
==== Step 5: Configure cpanel ====<br />
<br />
A typical cpanel modsec2.conf configuration file looks like this:<br />
<br />
LoadFile /opt/xml2/lib/libxml2.so<br />
LoadFile /opt/lua/lib/liblua.so<br />
LoadModule security2_module modules/mod_security2.so<br />
<IfModule mod_security2.c><br />
SecRuleEngine On<br />
# See http://www.modsecurity.org/documentation/ModSecurity-Migration-Matrix.pdf<br />
# "Add the rules that will do exactly the same as the directives"<br />
# SecFilterCheckURLEncoding On<br />
# SecFilterForceByteRange 0 255<br />
SecAuditEngine RelevantOnly<br />
SecAuditLog logs/modsec_audit.log<br />
SecDebugLog logs/modsec_debug_log<br />
SecDebugLogLevel 0<br />
SecDefaultAction "phase:2,deny,log,status:403"<br />
Include "/usr/local/apache/conf/modsec2.user.conf"<br />
</IfModule><br />
<br />
Because cpanel will overwrite this configuration, you need to modify your user configuration file. You will want to setup your user configuration file (/usr/local/apache/conf/modsec2.user.conf) as in the examples below depending on the type of license you have purchased (remote rules vs downloadable rules).<br />
<br />
==== Step 5a: Remote Rules ====<br />
<br />
If you have a remote rules license, simply add these two lines to the /usr/local/apache/conf/modsec2.user.conf file, replacing <API Key> with the value in your license signup email:<br />
<br />
''SecRemoteRulesFailAction Warn<br />
<br />
SecRemoteRules <API Key> https://waf.atomicorp.com/rules/srr.php''<br />
<br />
Additional rule classes can be specified as follows<br />
<br />
''SecRemoteRules <API Key> https://waf.atomicorp.com/rules/srr.php?antispam,recons''<br />
<br />
A full list of rule classes is available at [https://docs.atomicorp.com/gotrootModsec/remoterules.html].<br />
<br />
==== Step 5a: Downloadable Rules ====<br />
<br />
If you have a license for the downloadable rules, this is the recommended configuration and the '''minimum''' recommended rule sets that are designed to work with cpanel without [[ASL]] installed. Please be sure to read this entire page for information about additional rules that you may also want to use with cpanel.<br />
<br />
SecRequestBodyAccess On<br />
SecAuditLogType Concurrent<br />
SecResponseBodyAccess On<br />
SecResponseBodyMimeType (null) text/html text/plain text/xml<br />
SecResponseBodyLimit 2621440<br />
SecAuditLogRelevantStatus "^(?:5|4(?!04))"<br />
SecServerSignature Apache<br />
SecUploadDir /var/asl/data/suspicious<br />
SecUploadKeepFiles Off<br />
SecAuditLogParts ABIFHZ<br />
SecArgumentSeparator "&"<br />
SecCookieFormat 0<br />
SecRequestBodyInMemoryLimit 131072<br />
SecDataDir /var/asl/data/msa<br />
SecTmpDir /tmp<br />
SecAuditLogStorageDir /var/asl/data/audit<br />
SecResponseBodyLimitAction ProcessPartial<br />
<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_z_antievasion.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_zz_strict.conf<br />
Include /full/path/to/your/rules/modsecurity.d/09_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_antimalware.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/11_asl_adv_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/20_asl_useragents.conf<br />
Include /full/path/to/your/rules/modsecurity.d/30_asl_antispam.conf<br />
Include /full/path/to/your/rules/modsecurity.d/50_asl_rootkits.conf<br />
Include /full/path/to/your/rules/modsecurity.d/60_asl_recons.conf<br />
Include /full/path/to/your/rules/modsecurity.d/61_asl_recons_dlp.conf<br />
Include /full/path/to/your/rules/modsecurity.d/99_asl_jitp.conf<br />
<br />
If you want to load just some of the rules, make sure you specify only those rule files. The default list above is the recommended and supported rulesets with cpanel. Do not use the other asl rulesets with cpanel, those other rules either use other apache modules (such as mod_sed) or ASL specific features that require [[ASL]].<br />
<br />
Then run this command as root to install the rules:<br />
<br />
[[aum]] -u<br />
<br />
Or if you want to install the rules files manually, please see the [https://www.atomicorp.com/wiki/index.php/Atomic_ModSecurity_Rules#Step_8:_Download_the_ModSecurity_Rules Downloading rules] section above.<br />
<br />
==== Step 7: Restart Apache ====<br />
<br />
Restart apache, enjoy your new secure web server!<br />
<br />
<br />
<br />
==== Optional Steps ====<br />
<br />
===== Malware Scanner =====<br />
<br />
The malware scanner is included in [[ASL]], it is not included in the rules or rule subscriptions. Therefore, if you use this file:<br />
<br />
05_asl_scanner.conf<br />
<br />
Or this:<br />
<br />
99_asl_scanner.conf<br />
<br />
You will need to include your own scanner, and will need to make sure you have clamd installed and configured correctly to listen on a TCP port, or if you use a socket, make sure apache can read/write to this socket or as a last resort, run clamd as root. Using this file forces all web uploads on your system to go thru clamav to look for malware, viruses, etc. If you dont need that, then you can leave this config file out.<br />
<br />
<br />
==== Cpanel Error Messages ====<br />
<br />
==== modsecparse.pl ====<br />
<br />
'''This is a third party tool not provided by, or supported by Atomicorp.''' If you use this tool, it apparently does not work with the new fast concurrent logging system in modsecurity. The concurrent logging system is much faster, will speed up apache and is less resource intensive that the older serial method. <br />
<br />
However, if you use this tool you must use the slower serial logging method, as it does not support the faster concurrent method. To use this tool, change the SecAuditLogType setting from "Concurrent" to "Serial":<br />
<br />
SecAuditLogType Serial<br />
<br />
'''Keep in mind that this logging method is much slower, may slow down apache and is not supported.''' This performance impact is not caused by the rules. Serial logging is much slower than concurrent logging. Therefore we do not recommend you use this logging method or any tools that require it. There are lots of modsecurity log readers that can use the concurrent logging method, such as [[ASL]] and we encourage you to explore using one of those modern tools instead.<br />
<br />
==== Serial logging ====<br />
<br />
===== Discussion =====<br />
<br />
Serial logging is the older slower depreacted logging method modsecurity original used many years ago. This logging method would log the entire event in a single file. As a result, it would slow apache down because each event needed to wait for the previous event to finish writing before it could write to the log file. Events stack up and slow apache down. This incurs a significant performance penalty on apache, and of course a better method was devised for modsecurity to address this performance issue. The solution is the concurrent logging method. This generates a unique event file for each log event, logging the events data to that file instead of trying to jam tons of data into a single file, and thereby slowing down apache. All modern modsecurity log viewing tools support the concurrent method.<br />
<br />
The concurrent logging system is much faster, will speed up apache and is less resource intensive that the older serial method. This method is highly recommended over the slow serial logging method.<br />
<br />
===== Configuration =====<br />
<br />
====== aum ======<br />
<br />
If you want to use the old slower serial logging method, and you are using aum, change this setting in /etc/asl/config:<br />
<br />
MODSEC_LOGTYPE="Concurrent"<br />
<br />
<br />
To:<br />
<br />
MODSEC_LOGTYPE="Serial"<br />
<br />
<br />
And then run:<br />
<br />
aum -uf<br />
<br />
====== non-aum systems ======<br />
<br />
If you want to use the old slower serial logging method change the SecAuditLogType setting from "Concurrent" to "Serial":<br />
<br />
SecAuditLogType Serial<br />
<br />
'''Warning: Serial logging is much slower than concurrent logging and will slow down apache.''' Any performance impact is not caused by the rules. <br />
<br />
Therefore we do not recommend you use this logging method or any tools that require it. There are lots of modsecurity log readers that can use the fast concurrent logging method, such as [[ASL]] and we encourage you to explore using one of those modern tools instead of a tool that requires the slower and performance degrading serial logging method.<br />
<br />
If you change your system to the slower Serial method, you may also want to change the logfile name you are using for your modsecurity logs. You can do that by changing this option in your configuration:<br />
<br />
SecAuditLog logs/audit_log</div>Mshinnhttps://wiki.atomicorp.com/wiki/index.php/Local_DNS_resolverLocal DNS resolver2022-10-06T21:30:14Z<p>Mshinn: /* Discussion */</p>
<hr />
<div>= Introduction =<br />
<br />
A local DNS resolver is standard piece of software installed on the server performing DNS lookups that can lookup the Fully Qualified Domain Name (FQDN) for any IP address. This software is available from the OS vendors of all OSes supported with our products and is normally installed on most Linux systems, and by all known control panels. If you are not sure if your system has a local resolver, please ask your OS or control panel vendor to confirm.<br />
<br />
= Examples =<br />
<br />
Examples of this include:<br />
<br />
# Local caching DNS server<br />
# Local installation of the Berkeley Internet Name Domain (BIND) DNS (Domain Name System) server<br />
<br />
In both of these examples, the DNS servers need to be configured with the ability to lookup any zone on the Internet, and not just locally served zones. This is generally the standard configuration of a DNS server, however you should check to make sure this is the case. DNS servers that can only look up locally served zones are not resolvers, they rely on remote DNS servers sometimes referred to as forwarders to do resolution for them.<br />
<br />
For example, if a server wants to know what the FQDN for 1.2.3.4 is, a local resolver would look this up via DNS by connecting '''directly''' to the root DNS servers to find the authoritative DNS server for that zone. A forwarder, which is not a local resolver, would only request the FQDN from another DNS server, and that server would connect to the root DNS servers. The use of remote resolvers adds multiple steps to the process, which causes the lookups to take longer, which causes the lookups to be considerably slower than a local resolver. This slowness is compounded when remote resolvers are shared by multiple systems as the remote resolver must handle other requests from other systems simutaneously. This will add additional delays as the remote resolver works to service these other requests. And finally, because this process occurs entirely over the network (even for requests that could be cached locally, but are not because the DNS server is remote and local), this adds even more delays to process.<br />
<br />
= Discussion =<br />
<br />
A Local resolver is different from a remote resolver in that:<br />
<br />
# all the software necessary to perform the lookup and to manage and present the response is installed on the server requesting the lookup<br />
# the local resolver will "talk" directly to the Internets root DNS servers. This reduces the number of steps needed to do the lookup, which is orders of magnitude faster than remote resolvers<br />
# the local resolver is only serving requests for itself, which will have less of a work backlog than a shared DNS server which decreases response times<br />
# the local resolver also has the advantage of caching responses locally. Once an address is resolved once, remote queries are not necessary for that address (until the answer expires from the cache). Which means the second and subsequent request occurs instantly.<br />
# applications on the server are not adversely effected by network delays communicating with a remoter resolver as they only need to communicate with the local resolver on the same server, which occurs effectively instantly<br />
<br />
== How to tell if your system is setup with a local resolver ==<br />
<br />
A quick way to see if you have a local resolver setup on your system is to run these two tests:<br />
<br />
Step 1)<br />
<br />
Run this command as root:<br />
<br />
grep 127.0.0.1 /etc/resolv.conf<br />
<br />
If you do not see a line like this in the first position:<br />
<br />
nameserver 127.0.0.1<br />
<br />
Then you do not have a local resolver setup on your system. <br />
<br />
Step 2) Check to make sure your local resolver is setup as your primary resolver<br />
<br />
The file /etc/resolv.conf contains information your system uses to resolve domain and host names. Your OS, if configured correctly, will look at this file to get a list of DNS servers to query. It will query these servers in order, and if it doesnt get a response from the first DNS server, it will move on the the next, and the next in the /etc/resolv.conf file. <br />
<br />
For example, this file lists the local resolver first, and remote resolver last. This example does have a local DNS resolved configured for the system.<br />
<br />
<pre><br />
nameserver 127.0.0.1<br />
nameserver 192.168.1.1<br />
nameserver 192.168.1.251<br />
</pre><br />
<br />
The example below lists a remote resolver first, and the local resolver last. '''This example does not have a local DNS resolver configured for the system.'''<br />
<br />
<pre><br />
nameserver 192.168.1.1<br />
nameserver 192.168.1.251<br />
nameserver 127.0.0.1<br />
</pre><br />
<br />
If your system is not configured with the 127.0.0.1 resolver first, then you should not use any DNS based rules. Your system will not use the local resolver unless the remote resolver fails. This will result in a very slow resolution and is not recommended. A local resolver should always be in the first position.<br />
<br />
Step 3) If you do have "nameserver 127.0.0.1" in the first line of your /etc/resolv.conf file<br />
<br />
Run this command as root:<br />
<br />
nslookup www.atomicorp.com<br />
<br />
If your system can actually use your local resolver, you will see the 127.0.0.1 resolver return the answer to the DNS query. For example, this system has a working local resolver:<br />
<br />
<pre><br />
Server: 127.0.0.1<br />
Address: 127.0.0.1#53<br />
<br />
Non-authoritative answer:<br />
www.atomicorp.com canonical name = atomicorp.com.<br />
Name: atomicorp.com<br />
Address: 198.71.51.132<br />
</pre><br />
<br />
'''The system below does not have a local working resolver:'''<br />
<br />
<pre><br />
Server: 192.168.1.1<br />
Address: 192.168.1.1#53<br />
<br />
Non-authoritative answer:<br />
www.atomicorp.com canonical name = atomicorp.com.<br />
Name: atomicorp.com<br />
Address: 198.71.51.132<br />
</pre><br />
<br />
The key difference is that the 127.0.0.1 server is not returning the IP address for the www.atomicorp.com FQDN. Another non-local server is. This proves that the local resolver is not working correctly.<br />
<br />
= Outside articles =<br />
<br />
[http://www.faqs.org/docs/linux_network/x-087-2-resolv.howdnsworks.html How DNS works]</div>Mshinnhttps://wiki.atomicorp.com/wiki/index.php/Local_DNS_resolverLocal DNS resolver2022-10-06T21:30:02Z<p>Mshinn: /* Discussion */</p>
<hr />
<div>= Introduction =<br />
<br />
A local DNS resolver is standard piece of software installed on the server performing DNS lookups that can lookup the Fully Qualified Domain Name (FQDN) for any IP address. This software is available from the OS vendors of all OSes supported with our products and is normally installed on most Linux systems, and by all known control panels. If you are not sure if your system has a local resolver, please ask your OS or control panel vendor to confirm.<br />
<br />
= Examples =<br />
<br />
Examples of this include:<br />
<br />
# Local caching DNS server<br />
# Local installation of the Berkeley Internet Name Domain (BIND) DNS (Domain Name System) server<br />
<br />
In both of these examples, the DNS servers need to be configured with the ability to lookup any zone on the Internet, and not just locally served zones. This is generally the standard configuration of a DNS server, however you should check to make sure this is the case. DNS servers that can only look up locally served zones are not resolvers, they rely on remote DNS servers sometimes referred to as forwarders to do resolution for them.<br />
<br />
For example, if a server wants to know what the FQDN for 1.2.3.4 is, a local resolver would look this up via DNS by connecting '''directly''' to the root DNS servers to find the authoritative DNS server for that zone. A forwarder, which is not a local resolver, would only request the FQDN from another DNS server, and that server would connect to the root DNS servers. The use of remote resolvers adds multiple steps to the process, which causes the lookups to take longer, which causes the lookups to be considerably slower than a local resolver. This slowness is compounded when remote resolvers are shared by multiple systems as the remote resolver must handle other requests from other systems simutaneously. This will add additional delays as the remote resolver works to service these other requests. And finally, because this process occurs entirely over the network (even for requests that could be cached locally, but are not because the DNS server is remote and local), this adds even more delays to process.<br />
<br />
= Discussion =<br />
<br />
A Local resolver is different from a remote resolver in that:<br />
<br />
# all the software necessary to perform the lookup and to manage and present the response is installed on the server requesting the lookup<br />
# the local resolver will "talk" directly to the Internets root DNS servers. This reduces the number of steps needed to do the lookup, which is orders of magnitude faster than remote resolvers<br />
# the local resolver is only serving requests for itself, which will have less of a work backlog than a shared DNS server which decreases response times<br />
# the local resolver also has the advantage of caching responses locally. Once an address is resolved once, remote queries are not necessary for that address (until the answer expires from the cache). Which means the second and subsequent request occurs instantly.<br />
# applications on the server are not adversely effected by network delays communicating with a remoter resolver as they only need to communicate with the local resolver on the same server, which occurrs effectively instantly<br />
<br />
== How to tell if your system is setup with a local resolver ==<br />
<br />
A quick way to see if you have a local resolver setup on your system is to run these two tests:<br />
<br />
Step 1)<br />
<br />
Run this command as root:<br />
<br />
grep 127.0.0.1 /etc/resolv.conf<br />
<br />
If you do not see a line like this in the first position:<br />
<br />
nameserver 127.0.0.1<br />
<br />
Then you do not have a local resolver setup on your system. <br />
<br />
Step 2) Check to make sure your local resolver is setup as your primary resolver<br />
<br />
The file /etc/resolv.conf contains information your system uses to resolve domain and host names. Your OS, if configured correctly, will look at this file to get a list of DNS servers to query. It will query these servers in order, and if it doesnt get a response from the first DNS server, it will move on the the next, and the next in the /etc/resolv.conf file. <br />
<br />
For example, this file lists the local resolver first, and remote resolver last. This example does have a local DNS resolved configured for the system.<br />
<br />
<pre><br />
nameserver 127.0.0.1<br />
nameserver 192.168.1.1<br />
nameserver 192.168.1.251<br />
</pre><br />
<br />
The example below lists a remote resolver first, and the local resolver last. '''This example does not have a local DNS resolver configured for the system.'''<br />
<br />
<pre><br />
nameserver 192.168.1.1<br />
nameserver 192.168.1.251<br />
nameserver 127.0.0.1<br />
</pre><br />
<br />
If your system is not configured with the 127.0.0.1 resolver first, then you should not use any DNS based rules. Your system will not use the local resolver unless the remote resolver fails. This will result in a very slow resolution and is not recommended. A local resolver should always be in the first position.<br />
<br />
Step 3) If you do have "nameserver 127.0.0.1" in the first line of your /etc/resolv.conf file<br />
<br />
Run this command as root:<br />
<br />
nslookup www.atomicorp.com<br />
<br />
If your system can actually use your local resolver, you will see the 127.0.0.1 resolver return the answer to the DNS query. For example, this system has a working local resolver:<br />
<br />
<pre><br />
Server: 127.0.0.1<br />
Address: 127.0.0.1#53<br />
<br />
Non-authoritative answer:<br />
www.atomicorp.com canonical name = atomicorp.com.<br />
Name: atomicorp.com<br />
Address: 198.71.51.132<br />
</pre><br />
<br />
'''The system below does not have a local working resolver:'''<br />
<br />
<pre><br />
Server: 192.168.1.1<br />
Address: 192.168.1.1#53<br />
<br />
Non-authoritative answer:<br />
www.atomicorp.com canonical name = atomicorp.com.<br />
Name: atomicorp.com<br />
Address: 198.71.51.132<br />
</pre><br />
<br />
The key difference is that the 127.0.0.1 server is not returning the IP address for the www.atomicorp.com FQDN. Another non-local server is. This proves that the local resolver is not working correctly.<br />
<br />
= Outside articles =<br />
<br />
[http://www.faqs.org/docs/linux_network/x-087-2-resolv.howdnsworks.html How DNS works]</div>Mshinnhttps://wiki.atomicorp.com/wiki/index.php/Local_DNS_resolverLocal DNS resolver2022-10-06T21:28:04Z<p>Mshinn: /* Discussion */</p>
<hr />
<div>= Introduction =<br />
<br />
A local DNS resolver is standard piece of software installed on the server performing DNS lookups that can lookup the Fully Qualified Domain Name (FQDN) for any IP address. This software is available from the OS vendors of all OSes supported with our products and is normally installed on most Linux systems, and by all known control panels. If you are not sure if your system has a local resolver, please ask your OS or control panel vendor to confirm.<br />
<br />
= Examples =<br />
<br />
Examples of this include:<br />
<br />
# Local caching DNS server<br />
# Local installation of the Berkeley Internet Name Domain (BIND) DNS (Domain Name System) server<br />
<br />
In both of these examples, the DNS servers need to be configured with the ability to lookup any zone on the Internet, and not just locally served zones. This is generally the standard configuration of a DNS server, however you should check to make sure this is the case. DNS servers that can only look up locally served zones are not resolvers, they rely on remote DNS servers sometimes referred to as forwarders to do resolution for them.<br />
<br />
For example, if a server wants to know what the FQDN for 1.2.3.4 is, a local resolver would look this up via DNS by connecting '''directly''' to the root DNS servers to find the authoritative DNS server for that zone. A forwarder, which is not a local resolver, would only request the FQDN from another DNS server, and that server would connect to the root DNS servers. The use of remote resolvers adds multiple steps to the process, which causes the lookups to take longer, which causes the lookups to be considerably slower than a local resolver. This slowness is compounded when remote resolvers are shared by multiple systems as the remote resolver must handle other requests from other systems simutaneously. This will add additional delays as the remote resolver works to service these other requests. And finally, because this process occurs entirely over the network (even for requests that could be cached locally, but are not because the DNS server is remote and local), this adds even more delays to process.<br />
<br />
= Discussion =<br />
<br />
A Local resolver is different from a remote resolver in that:<br />
<br />
# all the software necessary to perform the lookup and to manage and present the response is installed on the server requesting the lookup<br />
# the local resolver will "talk" directly to the Internets root DNS servers. This reduces the number of steps needed to do the lookup, which is orders of magnitude faster than remote resolvers<br />
# the local resolver is only serving requests for its server, reducing the work load and decreasing response teimes<br />
# the local resolver also has the advantage of caching responses locally. So if an address is resolved, remote queries are not necessary for that address until the answer expires from the cache. This causes future lookups to occur instantly.<br />
# applications on the server are not adversely effected by network delays communicating with a remoter resolver as they only need to communicate with the local resolver on the same server<br />
<br />
== How to tell if your system is setup with a local resolver ==<br />
<br />
A quick way to see if you have a local resolver setup on your system is to run these two tests:<br />
<br />
Step 1)<br />
<br />
Run this command as root:<br />
<br />
grep 127.0.0.1 /etc/resolv.conf<br />
<br />
If you do not see a line like this in the first position:<br />
<br />
nameserver 127.0.0.1<br />
<br />
Then you do not have a local resolver setup on your system. <br />
<br />
Step 2) Check to make sure your local resolver is setup as your primary resolver<br />
<br />
The file /etc/resolv.conf contains information your system uses to resolve domain and host names. Your OS, if configured correctly, will look at this file to get a list of DNS servers to query. It will query these servers in order, and if it doesnt get a response from the first DNS server, it will move on the the next, and the next in the /etc/resolv.conf file. <br />
<br />
For example, this file lists the local resolver first, and remote resolver last. This example does have a local DNS resolved configured for the system.<br />
<br />
<pre><br />
nameserver 127.0.0.1<br />
nameserver 192.168.1.1<br />
nameserver 192.168.1.251<br />
</pre><br />
<br />
The example below lists a remote resolver first, and the local resolver last. '''This example does not have a local DNS resolver configured for the system.'''<br />
<br />
<pre><br />
nameserver 192.168.1.1<br />
nameserver 192.168.1.251<br />
nameserver 127.0.0.1<br />
</pre><br />
<br />
If your system is not configured with the 127.0.0.1 resolver first, then you should not use any DNS based rules. Your system will not use the local resolver unless the remote resolver fails. This will result in a very slow resolution and is not recommended. A local resolver should always be in the first position.<br />
<br />
Step 3) If you do have "nameserver 127.0.0.1" in the first line of your /etc/resolv.conf file<br />
<br />
Run this command as root:<br />
<br />
nslookup www.atomicorp.com<br />
<br />
If your system can actually use your local resolver, you will see the 127.0.0.1 resolver return the answer to the DNS query. For example, this system has a working local resolver:<br />
<br />
<pre><br />
Server: 127.0.0.1<br />
Address: 127.0.0.1#53<br />
<br />
Non-authoritative answer:<br />
www.atomicorp.com canonical name = atomicorp.com.<br />
Name: atomicorp.com<br />
Address: 198.71.51.132<br />
</pre><br />
<br />
'''The system below does not have a local working resolver:'''<br />
<br />
<pre><br />
Server: 192.168.1.1<br />
Address: 192.168.1.1#53<br />
<br />
Non-authoritative answer:<br />
www.atomicorp.com canonical name = atomicorp.com.<br />
Name: atomicorp.com<br />
Address: 198.71.51.132<br />
</pre><br />
<br />
The key difference is that the 127.0.0.1 server is not returning the IP address for the www.atomicorp.com FQDN. Another non-local server is. This proves that the local resolver is not working correctly.<br />
<br />
= Outside articles =<br />
<br />
[http://www.faqs.org/docs/linux_network/x-087-2-resolv.howdnsworks.html How DNS works]</div>Mshinnhttps://wiki.atomicorp.com/wiki/index.php/Local_DNS_resolverLocal DNS resolver2022-10-06T21:27:44Z<p>Mshinn: /* Examples */</p>
<hr />
<div>= Introduction =<br />
<br />
A local DNS resolver is standard piece of software installed on the server performing DNS lookups that can lookup the Fully Qualified Domain Name (FQDN) for any IP address. This software is available from the OS vendors of all OSes supported with our products and is normally installed on most Linux systems, and by all known control panels. If you are not sure if your system has a local resolver, please ask your OS or control panel vendor to confirm.<br />
<br />
= Examples =<br />
<br />
Examples of this include:<br />
<br />
# Local caching DNS server<br />
# Local installation of the Berkeley Internet Name Domain (BIND) DNS (Domain Name System) server<br />
<br />
In both of these examples, the DNS servers need to be configured with the ability to lookup any zone on the Internet, and not just locally served zones. This is generally the standard configuration of a DNS server, however you should check to make sure this is the case. DNS servers that can only look up locally served zones are not resolvers, they rely on remote DNS servers sometimes referred to as forwarders to do resolution for them.<br />
<br />
For example, if a server wants to know what the FQDN for 1.2.3.4 is, a local resolver would look this up via DNS by connecting '''directly''' to the root DNS servers to find the authoritative DNS server for that zone. A forwarder, which is not a local resolver, would only request the FQDN from another DNS server, and that server would connect to the root DNS servers. The use of remote resolvers adds multiple steps to the process, which causes the lookups to take longer, which causes the lookups to be considerably slower than a local resolver. This slowness is compounded when remote resolvers are shared by multiple systems as the remote resolver must handle other requests from other systems simutaneously. This will add additional delays as the remote resolver works to service these other requests. And finally, because this process occurs entirely over the network (even for requests that could be cached locally, but are not because the DNS server is remote and local), this adds even more delays to process.<br />
<br />
= Discussion =<br />
<br />
A Local resolver is different from a remote resolver in that:<br />
<br />
# all the software necessary to perform the lookup and to manage and present the response is installed on the server performing the lookup<br />
# the local resolver will "talk" directly to the Internets root DNS servers. This reduces the number of steps needed to do the lookup, which is orders of magnitude faster than remote resolvers<br />
# the local resolver is only serving requests for its server, reducing the work load and decreasing response teimes<br />
# the local resolver also has the advantage of caching responses locally. So if an address is resolved, remote queries are not necessary for that address until the answer expires from the cache. This causes future lookups to occur instantly.<br />
# applications on the server are not adversely effected by network delays communicating with a remoter resolver as they only need to communicate with the local resolver on the same server<br />
<br />
== How to tell if your system is setup with a local resolver ==<br />
<br />
A quick way to see if you have a local resolver setup on your system is to run these two tests:<br />
<br />
Step 1)<br />
<br />
Run this command as root:<br />
<br />
grep 127.0.0.1 /etc/resolv.conf<br />
<br />
If you do not see a line like this in the first position:<br />
<br />
nameserver 127.0.0.1<br />
<br />
Then you do not have a local resolver setup on your system. <br />
<br />
Step 2) Check to make sure your local resolver is setup as your primary resolver<br />
<br />
The file /etc/resolv.conf contains information your system uses to resolve domain and host names. Your OS, if configured correctly, will look at this file to get a list of DNS servers to query. It will query these servers in order, and if it doesnt get a response from the first DNS server, it will move on the the next, and the next in the /etc/resolv.conf file. <br />
<br />
For example, this file lists the local resolver first, and remote resolver last. This example does have a local DNS resolved configured for the system.<br />
<br />
<pre><br />
nameserver 127.0.0.1<br />
nameserver 192.168.1.1<br />
nameserver 192.168.1.251<br />
</pre><br />
<br />
The example below lists a remote resolver first, and the local resolver last. '''This example does not have a local DNS resolver configured for the system.'''<br />
<br />
<pre><br />
nameserver 192.168.1.1<br />
nameserver 192.168.1.251<br />
nameserver 127.0.0.1<br />
</pre><br />
<br />
If your system is not configured with the 127.0.0.1 resolver first, then you should not use any DNS based rules. Your system will not use the local resolver unless the remote resolver fails. This will result in a very slow resolution and is not recommended. A local resolver should always be in the first position.<br />
<br />
Step 3) If you do have "nameserver 127.0.0.1" in the first line of your /etc/resolv.conf file<br />
<br />
Run this command as root:<br />
<br />
nslookup www.atomicorp.com<br />
<br />
If your system can actually use your local resolver, you will see the 127.0.0.1 resolver return the answer to the DNS query. For example, this system has a working local resolver:<br />
<br />
<pre><br />
Server: 127.0.0.1<br />
Address: 127.0.0.1#53<br />
<br />
Non-authoritative answer:<br />
www.atomicorp.com canonical name = atomicorp.com.<br />
Name: atomicorp.com<br />
Address: 198.71.51.132<br />
</pre><br />
<br />
'''The system below does not have a local working resolver:'''<br />
<br />
<pre><br />
Server: 192.168.1.1<br />
Address: 192.168.1.1#53<br />
<br />
Non-authoritative answer:<br />
www.atomicorp.com canonical name = atomicorp.com.<br />
Name: atomicorp.com<br />
Address: 198.71.51.132<br />
</pre><br />
<br />
The key difference is that the 127.0.0.1 server is not returning the IP address for the www.atomicorp.com FQDN. Another non-local server is. This proves that the local resolver is not working correctly.<br />
<br />
= Outside articles =<br />
<br />
[http://www.faqs.org/docs/linux_network/x-087-2-resolv.howdnsworks.html How DNS works]</div>Mshinnhttps://wiki.atomicorp.com/wiki/index.php/Local_DNS_resolverLocal DNS resolver2022-10-06T21:24:21Z<p>Mshinn: /* Introduction */</p>
<hr />
<div>= Introduction =<br />
<br />
A local DNS resolver is standard piece of software installed on the server performing DNS lookups that can lookup the Fully Qualified Domain Name (FQDN) for any IP address. This software is available from the OS vendors of all OSes supported with our products and is normally installed on most Linux systems, and by all known control panels. If you are not sure if your system has a local resolver, please ask your OS or control panel vendor to confirm.<br />
<br />
= Examples =<br />
<br />
Examples of this include:<br />
<br />
# Local caching DNS server<br />
# Local installation of the Berkeley Internet Name Domain (BIND) DNS (Domain Name System) server<br />
<br />
In both of these examples, the DNS servers need to be configured with the ability to lookup any zone on the Internet, and not just locally served zones. This is generally the standard configuration of a DNS server, however you should check to make sure this is the case. DNS servers that can only look up locally served zones are not resolvers, they rely on remote DNS servers sometimes referred to as forwarders to do resolution for them.<br />
<br />
For example, if a server wants to know what the FQDN for 1.2.3.4 is, a local resolver would look this up via DNS by connecting '''directly''' to the root DNS servers to find the authoritative DNS server for that zone. A forwarder, which is not a local resolver, would only request the FQDN from another DNS server, and that server would connect to the root DNS servers. The use of remote resolvers adds multiple steps to the process, which causes the lookups to be considerably slower. This slowness is compounded when remote resolvers are shared by multiple systems as the remote resolver must handle other requests from other system. This will add additional delays as the remote resolver works to service requests from multiple systems. And finally, because this process occurs over the network, this adds additional delays to process.<br />
<br />
= Discussion =<br />
<br />
A Local resolver is different from a remote resolver in that:<br />
<br />
# all the software necessary to perform the lookup and to manage and present the response is installed on the server performing the lookup<br />
# the local resolver will "talk" directly to the Internets root DNS servers. This reduces the number of steps needed to do the lookup, which is orders of magnitude faster than remote resolvers<br />
# the local resolver is only serving requests for its server, reducing the work load and decreasing response teimes<br />
# the local resolver also has the advantage of caching responses locally. So if an address is resolved, remote queries are not necessary for that address until the answer expires from the cache. This causes future lookups to occur instantly.<br />
# applications on the server are not adversely effected by network delays communicating with a remoter resolver as they only need to communicate with the local resolver on the same server<br />
<br />
== How to tell if your system is setup with a local resolver ==<br />
<br />
A quick way to see if you have a local resolver setup on your system is to run these two tests:<br />
<br />
Step 1)<br />
<br />
Run this command as root:<br />
<br />
grep 127.0.0.1 /etc/resolv.conf<br />
<br />
If you do not see a line like this in the first position:<br />
<br />
nameserver 127.0.0.1<br />
<br />
Then you do not have a local resolver setup on your system. <br />
<br />
Step 2) Check to make sure your local resolver is setup as your primary resolver<br />
<br />
The file /etc/resolv.conf contains information your system uses to resolve domain and host names. Your OS, if configured correctly, will look at this file to get a list of DNS servers to query. It will query these servers in order, and if it doesnt get a response from the first DNS server, it will move on the the next, and the next in the /etc/resolv.conf file. <br />
<br />
For example, this file lists the local resolver first, and remote resolver last. This example does have a local DNS resolved configured for the system.<br />
<br />
<pre><br />
nameserver 127.0.0.1<br />
nameserver 192.168.1.1<br />
nameserver 192.168.1.251<br />
</pre><br />
<br />
The example below lists a remote resolver first, and the local resolver last. '''This example does not have a local DNS resolver configured for the system.'''<br />
<br />
<pre><br />
nameserver 192.168.1.1<br />
nameserver 192.168.1.251<br />
nameserver 127.0.0.1<br />
</pre><br />
<br />
If your system is not configured with the 127.0.0.1 resolver first, then you should not use any DNS based rules. Your system will not use the local resolver unless the remote resolver fails. This will result in a very slow resolution and is not recommended. A local resolver should always be in the first position.<br />
<br />
Step 3) If you do have "nameserver 127.0.0.1" in the first line of your /etc/resolv.conf file<br />
<br />
Run this command as root:<br />
<br />
nslookup www.atomicorp.com<br />
<br />
If your system can actually use your local resolver, you will see the 127.0.0.1 resolver return the answer to the DNS query. For example, this system has a working local resolver:<br />
<br />
<pre><br />
Server: 127.0.0.1<br />
Address: 127.0.0.1#53<br />
<br />
Non-authoritative answer:<br />
www.atomicorp.com canonical name = atomicorp.com.<br />
Name: atomicorp.com<br />
Address: 198.71.51.132<br />
</pre><br />
<br />
'''The system below does not have a local working resolver:'''<br />
<br />
<pre><br />
Server: 192.168.1.1<br />
Address: 192.168.1.1#53<br />
<br />
Non-authoritative answer:<br />
www.atomicorp.com canonical name = atomicorp.com.<br />
Name: atomicorp.com<br />
Address: 198.71.51.132<br />
</pre><br />
<br />
The key difference is that the 127.0.0.1 server is not returning the IP address for the www.atomicorp.com FQDN. Another non-local server is. This proves that the local resolver is not working correctly.<br />
<br />
= Outside articles =<br />
<br />
[http://www.faqs.org/docs/linux_network/x-087-2-resolv.howdnsworks.html How DNS works]</div>Mshinnhttps://wiki.atomicorp.com/wiki/index.php/WAF_rule_familiesWAF rule families2022-10-06T21:23:34Z<p>Mshinn: /* 00_asl_rbl.conf */</p>
<hr />
<div>The Atomicorp/Gotroot rules are broken into families - we recommend you load all the rule families. They work well together, and its safe to use all the rules on a box. We run every rule on our boxes and have been since we first started publishing them over ten years ago.<br />
<br />
====000000000000000000000000_asl_notconfigured.conf====<br />
<br />
'''This rule file should not be used.''' <br />
<br />
This file is a "canary" file included in the archive to prevent users from accidentally loading all the rule files at the same. This ruleset will prevent this condition by disabling the WAF and logging a warning that the installation instructions have not been followed.<br />
<br />
If you are getting any errors about this file and you are using a third party product that installs our rules, please contact the vendor for that product.<br />
<br />
====000_asl_threat_intelligence.conf====<br />
<br />
These rules use the Atomicorp Threat Intelligence system to detect if an IP is a known threat. These rules look for DOS, brute force, spam, known attackers and advanced threats.<br />
<br />
Note: Requires modsecurity 2.7.7 and up.<br />
<br />
====00_asl_x_searchengines.conf====<br />
<br />
'''This ruleset is Deprecated'''<br />
<br />
Note: this is a legacy ruleset and should only be used on platform that do not support lua, and may experience performance issues. Please use 00_asl_z_searchengines.conf instead.<br />
<br />
This ruleset tells the WAF to trust defined search engines, and to not block or shun them.<br />
<br />
<br />
Note: Requires modsecurity 2.7.7 and up.<br />
<br />
====00_asl_y_searchengines.conf ====<br />
<br />
'''This ruleset is Deprecated'''<br />
<br />
Note: this is a legacy ruleset and should only be used on platform that do not support lua, and may experience performance issues. Please use 00_asl_z_searchengines.conf instead.<br />
<br />
''(Available in ASL and the real time rules only)''<br />
<br />
This ruleset detects clients pretending to be a search engine, as well as valid search engines. You must have either [[ASL]] installed, or apache configured with "HostnameLookups Double" and a very fast local DNS server. <br />
<br />
These rules also allow you to auto-whitelist real search engines. To do this, you will need to either use [[ASL]], or you will need to manually set the variable WHITELIST_SEARCH_ENGINES to "1".<br />
<br />
'''Warning: If you do not have either [[ASL]] installed, or apache configured correctly to use these rules they will not work correctly.'''<br />
<br />
Note: If you do not have a fast local DNS server, do not use these rules. These rules perform forward and reverse lookups and require a fast local DNS server, otherwise you should expect your websites to be very slow.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
Excluded: Modsecurity 2.8.0. Because 2.8.0 has a serious bug in the @ipmatch code( https://github.com/SpiderLabs/ModSecurity/issues/706).<br />
<br />
====00_asl_z_searchengines.conf====<br />
<br />
'(Available in ASL and the real time rules only)''<br />
<br />
Note: The rules must be used with a [[Local DNS resolver]]. If you do not have a fast local DNS server (not a remote DNS server), do not use these rules. These rules perform forward and reverse lookups and require a fast local DNS server. Failure to use a local resolver will result in performance degradation, these rules may also not work at all in these cases.<br />
<br />
This ruleset detects clients pretending to be a search engine, as well as valid search engines. You must have a very fast local DNS server to use these rules. These rules also allow you to auto-whitelist real search engines. To do this, in the /etc/asl/config set WAF_LUA_00_SEARCHENGINE to "yes"<br />
<br />
For DIY installations, you must install the "advanced" subdirectory in your modsecurity rules directory. If you are manually extracting the rules archive files this should be created for you automatically, and will contain the actual .lua files this config file will load. <br />
<br />
Requires: Modsecurity 2.9.3 and up.<br />
<br />
====00_asl_zz_strict.conf====<br />
<br />
'''Note: Requires modsecurity 2.7.0 and higher.'''<br />
<br />
This enforces strict adherence to the HTTP RFCs.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====00_asl_0_global.conf====<br />
<br />
This is a global variable file, it is only used if you have modsecurity 2.5.13 and above installed. <br />
<br />
====00_asl_rbl.conf====<br />
<br />
This rule family checks an incoming host to see if its on a third party RBL. By default only the third party spamhaus XBL-SBL list is enabled which is operated by the Spamhaus project. This RBL is not operated or controlled by Atomicorp. Please contact Spamhaus if you have issues with the IPs on this RBL, or disable this option. Several other RBLs are including in this rule file and must be either enabled in ASL (ASL will generate this rule file) or if you are not running ASL you must manually enable the other RBLs.<br />
<br />
This ruleset will look up every request in the DNS to see if its on a blacklist, and will not finish serving the request until the DNS server responds. This can slow down requests if the DNS server is slow. Basically, web requests will move at the speed of the DNS servers replies.<br />
<br />
If your web server is responding slowly to requests, and you have this ruleset enabled your DNS server is too slow to meet your lookup needs. You will need to either disable this ruleset, or tune your DNS server to respond to queries more quickly.<br />
<br />
''If you use this ruleset, make sure you have a fast locally caching DNS server. This ruleset will query spamhaus for every incoming IP to see if its on a blacklist, if your DNS is slow (or non local) this will make your system seem to crawl, as the read request will be blocked by Apache until it finished the DNS lookup. If you do not have a fast and local DNS server, do not use this ruleset.''<br />
<br />
Requires: Modsecurity 2.6.0 and up.<br />
<br />
====00_asl_blacklist.conf====<br />
<br />
Allows you to blacklist hosts or CIDRs from the WAF.<br />
<br />
Requires: Modsecurity 2.9.0 and up.<br />
<br />
The format is single IPs or CIDRs per line, for example:<br />
<br />
<pre><br />
1.2.3.4<br />
5.6.7.0/24<br />
8.9.0.0/16<br />
</pre><br />
<br />
Note: You must define your own blacklist file. The default location is /etc/asl/blacklist. <br />
<br />
====00_asl_whitelist.conf====<br />
<br />
Allows you to whitelist hosts from the WAF.<br />
<br />
Requires: Modsecurity 2.9.0 and up.<br />
<br />
The format is single IPs or CIDRs per line, for example:<br />
<br />
<pre><br />
1.2.3.4<br />
5.6.7.0/24<br />
8.9.0.0/16<br />
</pre><br />
<br />
Note: You must define your own whitelist entires. The default location is /etc/asl/whitelist. '''Do not use the whitelist.txt file. It is not used for this rule. We do not provide a default whitelist for these rules.'''<br />
<br />
Note: Requires modsecurity 2.7.7 and up.<br />
<br />
====01_asl_content.conf====<br />
<br />
These rules restrict the server to known content types that the WAF can correctly decipher.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
==== 01_asl_domain_blocks.conf====<br />
<br />
Optional ruleset that allows you to block connections from hosts, based on their DNS hostname and/or domain. This is a user defined list.<br />
<br />
Domains and/or hostnames are stored in this file:<br />
<br />
/etc/asl/custom-domain-blocks<br />
<br />
The format is one entry, per line, for example:<br />
<br />
<pre><br />
example.com<br />
www.hostname.some-tld<br />
</pre><br />
<br />
Note: You must have either [[ASL]] installed, or apache configured with "HostnameLookups Double" and a very fast local DNS server for these rules to work.\<br />
<br />
Note: Requires modsecurity 2.7.7 and up.<br />
<br />
====01_asl_rules_special.conf====<br />
<br />
This ruleset changes the behavior of the WAF for applications that behavior in nonstandard ways. For example, OTRS uses ";" and not "&" for argument separation. You should not use these rules if you do not have OTRS installed on your system.<br />
<br />
If you do not know what this means, you do not need this ruleset.<br />
<br />
Requires: Modsecurity 2.7.0 and up. <br />
<br />
Note: If you get an error regarding SecArgumentSeparator with these rules, your modsecurity configuration is being loaded too late in your Apache stack. Ensure that your modsecurity configuration is loaded first. This has been seen with cpanel when not using [[ASL]]. Please contact your apache vendor for assistance with this issue, or use [[ASL]] which will fix your apache configuration so this error does not occur.<br />
<br />
====03_asl_dos.conf====<br />
<br />
This ruleset protects apache from slow DOS attacks. It is only supported with Apache and requires the installation of the mod_reqtimeout module. The rule is fail safe with Apache, that is if the mod_reqtimeout module is not loaded the rules also will not load into Apache.<br />
<br />
[[ASL]] automatically ensures mod_reqtimeout is installed. If you are a rules only user please contact your Apache vendor for assistance installing this module.<br />
<br />
Note: Requires modsecurity 2.7.7 and up.<br />
<br />
====05_asl_exclude.conf====<br />
<br />
Pre-load rule exclusion list. Turns off rules that need to be disabled early in the process. ASL manages this process automatically.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====00_asl_z_antievasion.conf====<br />
<br />
This is a ruleset to detect attempts to bypass modsecurity itself, through evasion methods for example. Do not use this ruleset unless you are using 2.6.1 and up.<br />
<br />
====05_asl_scanner.conf ====<br />
<br />
Deprecated.<br />
<br />
====06_asl_honeypot.conf ====<br />
<br />
This ruleset lets you define URLs you want to specifically block, for example the URL of an application that may not be installed on the system. This can work as a honeypot of sorts, allowing the system to be configured to treat probes for non-existant applications as attacks. [[ASL]] has a more advanced system that can detect when URLs do not correspond to files on the system, which can be used in place of this ruleset or to augment it.<br />
<br />
For this ruleset to work, populate the honeypot-files.txt file in the same directory as 06_asl_honeypot.conf with one URL per line. For example:<br />
<br />
<br />
<pre><br />
/application/not/installed/on/system<br />
file_name_not_on_system.extension<br />
</pre><br />
<br />
==== 11_asl_rules.conf====<br />
<br />
This ruleset is reserved and is not currently used.<br />
<br />
====10_asl_antimalware.conf====<br />
<br />
Checks payload and RFI contents for known sources of malware and malware payloads and will block them.<br />
<br />
Requires: Modsecurity 2.6.0 and up.<br />
<br />
====09_asl_rules.conf====<br />
<br />
These are supplementation rules to the 10_asl_rules.conf, but only work on 2.6.6 and up installations. Do not use this ruleset unless you are using 2.6.6 and up.<br />
<br />
====10_asl_rules.conf ====<br />
<br />
The main rules, contains all the generic security rules to protect against classes of attacks, such as SQL injection, XSS, code injection, recursion, etc. '''These rules require modsecurity 2.9.1 and above.'''<br />
<br />
Requires: Modsecurity 2.9.1 and up.<br />
<br />
====11_asl_adv_rules.conf====<br />
<br />
These are advanced rules, and '''can only be used with modsecurity 2.7.5 and above.'''<br />
<br />
Requires: Modsecurity 2.7.5 and up.<br />
<br />
====11_asl_data_loss.conf====<br />
<br />
Experimental data leakage rules. Looks for credit card numbers and other potentially sensitive information leaking from the system.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====11_asl_brute_enhanced.conf====<br />
<br />
Requires: Modsecurity 2.9.2 and up.<br />
<br />
These rules are for platforms that do not have either [[ASL]] or Atomic Protector installed. These rules create the collections in modsecurity to block brute force attacks. The defaults are > 5 failures within 60 seconds.<br />
<br />
''Note: These rules are not necessary if the systen has ASL or Atomic Protector installed, and should not be used with ASL or AP.<br />
<br />
''Note 1: These rules will only work if the web server can write to the SecDataDir directory. That directory will contain sqllite databases that modsecurity will create and use to count events, without the collection modsecurity can not maintain state for composite events, like multiple login failures, and these rules will not work.''<br />
<br />
''Note 2: Enable this setting in /etc/asl/config to create the collections:''<br />
<br />
<br />
https://wiki.atomicorp.com/wiki/index.php/Aum_configuration#MODSEC_00_THREAT<br />
<br />
====12_asl_adv_xss_rules.conf====<br />
<br />
'''This ruleset require mod_security 2.9.0 and above.'''<br />
<br />
This is the advanced Cross Site Scripting (XSS) protection rule set. It performs deep level inspections of web requests and responses to look for potential XSS attacks.<br />
<br />
====12_asl_brute.conf====<br />
<br />
'''This ruleset is only available with [[ASL]] or the Real Time Rules.''' <br />
<br />
This ruleset detects authentication failures against all major web applications (Joomla, WordPress, MovableType, Drupal, ModX, ZenCart, OsCommerce, VBulletin, PHPBB and more).<br />
<br />
When used with [[ASL]], fast and "low and slow" brute force attacks can be detected and blocked in real time.<br />
<br />
Requires: Modsecurity 2.6.8 and up. <br />
<br />
'''Note: [[ASL]] is necessary to perform active response to brute force attacks.'''<br />
<br />
====13_asl_brute_enhanced.conf====<br />
<br />
Requires: Modsecurity 2.9.2 and up.<br />
<br />
These rules are for platforms that do not have either [ASL] or Atomic Protector installed. These rules create the collections in modsecurity to block brute force attacks. The defaults are > 10 failures within 60 seconds.<br />
<br />
''Note: These rules are not necessary if the systen has ASL or Atomic Protector installed, and should not be used with ASL or AP.<br />
<br />
Note 1: These rules will only work if the web server can write to the SecDataDir directory. That directory will contain sqllite databases that modsecurity will create and use to count events, without the collection modsecurity can not maintain state for composite events, like multiple login failures, and these rules will not work.''<br />
<br />
====20_asl_useragents.conf====<br />
<br />
Looks for malicious or suspicious user agents and known patterns of malicious activity. These rules require modsecurity 2.7.1 and up.<br />
<br />
Requires: Modsecurity 2.7.1 and up.<br />
<br />
====30_asl_antispam.conf====<br />
<br />
Tuned antispam rules, designed to work with all known blogs, forums, guestbooks, CMS' and other web content management systems that allow users to post content.<br />
<br />
Requires: Modsecurity 2.6.8 and up.<br />
<br />
====30_asl_antispam_advanced.conf====<br />
<br />
(Not released yet) These are advanced spam rules. They require modsecurity 2.7.1 and up.<br />
<br />
Requires: Modsecurity 2.7.1 and up.<br />
<br />
====30_asl_antispam_referrer.conf====<br />
<br />
Rules to block referrer spam. Generally not needed in most environments if you protect web log generation tools from public access (which is the default for most control panels).<br />
<br />
Requires: Modsecurity 2.6.0 and up.<br />
<br />
====40_asl_apache2-rules.conf====<br />
<br />
This ruleset has been retired. mod_security 2.x does not work with Apache 1.x and this ruleset existed just for those rules that only worked with apache 2. As mod_security 2.x does not work with Apache 1.x there is no need for this ruleset.<br />
<br />
====50_asl_rootkits.conf====<br />
<br />
Detects and blocks known web based rootkits, PHP/ASP/PERL shells, spam tools and other malicious web applications from being installed, and in some cases from running on the system. These rules exist for cases where malicious software may already be installed on the system, this is a defense in depth rule set)<br />
<br />
Not: ASL can prevent all malware from running on the system, modsecurity is limited in this regard so if you are only using the rules you should not expect modsecurity to prevent malware from running. It may prevent it in some cases, but without kernel level protection such as that provided in [[ASL]] no WAF can stop all malware from running on the system itself.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====51_asl_rootkits.conf====<br />
<br />
These rules look for known malware names in filenames, and URLs.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====60_asl_recons.conf====<br />
<br />
Blocks known "google hacks" or webserver probes that look for vulnerable applications and signs of compromised systems running unauthorized shells, or unprotected applications that allow uploads which would give an attacker access to the system.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====61_asl_recons_dlp.conf====<br />
<br />
These rules detect Data Loss Search engine "hacks". These are search engine probes for sensitive files, often used by malicious parties to find sensitive information accidentally exposed on web servers.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====99_asl_a_redactor.conf====<br />
<br />
ASL only rule set. Requires modsecurity 2.6.0 and up. Part of the malicious code removal system. Automatically removes malicious code from web pages, such as hidden iframes, encoded javascript and other malicious code. '''Do not enable this ruleset if you are not using ASL. ''' <br />
<br />
====99_asl_exclude.conf====<br />
<br />
Post exclude rules.<br />
<br />
====98_asl_adv_redactor.conf====<br />
<br />
This is the new advanced malware removal system. This ruleset will remove malware "on the fly" from web pages. For example, it will remove hidden iframes, malicous javascript, and other malicious code.<br />
<br />
'''Requires: modsecurity 2.7.5 and up.'''<br />
<br />
====98_asl_jitp.conf====<br />
<br />
This is a special ruleset used by [[ASL]]. If you do not have [[ASL]] you can not use these rules.<br />
<br />
====99_asl_jitp.conf====<br />
<br />
Just in Time Patches. We publish JITPs daily if there is a new web application vulnerability that the 10_asl_rules.conf do not protect the system against. These are tuned rules for specific vulnerabilities in a web application.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====99_asl_a_redactor.conf====<br />
<br />
This ruleset is reserved, and is not currently used.<br />
<br />
====99_asl_redactor.conf====<br />
<br />
'''Note: Do not enable this ruleset unless you have been instructed to do so by support.'''<br />
<br />
Special ruleset - requires mod_sed to be loaded on the system which is included and supported in [[ASL]] - removes malicious code from web pages, such as hidden iframes, encoded javascript and other malicious code. We highly recommend you use this rule set - its fast, multithreads and will automagically remove malicious code from infected webpages, which can occur if an adversary is able to log into the system and modify the code, such as by SSH or by uploading the code via FTP. If you are not using [[ASL]] then you will need to make sure your system has mod_sed installed to use these rules, they will not load and therefore will not do anything without mod_sed installed. This ruleset is only supported with [[ASL]].<br />
<br />
====99_asl_redactor_post.conf====<br />
<br />
This ruleset detects malicious content in webpages, such as known malicious domains.<br />
<br />
====99_asl_scanner.conf====<br />
<br />
This is the same as 05_asl_scanner.conf, its provided in a form to run last. This is the recommended location for the scanner function, as the rules before this stop some attacks that the scanner also detects, but do this in a faster and less CPU intensive manner. Running the scanner last does not compromise or lower the effectiveness of the rules. This is just a performance enhancement. This ruleset is only supported with [[ASL]].<br />
<br />
====99_asl_z_adv_scanner.conf====<br />
<br />
'''Note: Requires [[ASL]] and modsecurity 2.9.0 and higher.'''<br />
<br />
This ruleset uses a fuzzy hash to identify potentially malicious files.<br />
<br />
Warning: This ruleset is not supported on non-ASL systems. Do not use this without ASL.<br />
<br />
==== Paranoid mode rules ====<br />
<br />
===== 15_asl_paranoid_rules.conf =====<br />
<br />
'''Note: Do not use these rules if you have not read this section.'''<br />
<br />
'''Please do not report false positives with these rules. If you encounter a false positive with a rule from this file, please use its duplicate in 10_asl_rules.conf instead. If you have a false positive with a rule from 10_asl_rules.conf, please report it to us.'''<br />
<br />
These are a special version of the 10_asl_rules.conf file, they use the same rule id:s as the 10_asl_rules.conf file. Therefore, you can not use these rules along with the 10_asl_rules.conf file. You can use one, or the other, but not both.<br />
<br />
These rules are a paranoid replacement for the 10_asl_rules.conf file. These rules do not contain any known safe mode application tuning exceptions or bypasses. These rules will generate false positives. These rules are made available for users that wish to tune their own rules, and do not wish to use a ruleset that has been tuned for false positives.<br />
<br />
For example, if you had a application that safely used the argument "url" to accept URLs:<br />
<br />
GET /application?url=http://www.example.com/safething<br />
<br />
The normal rules would allow this, if this was known to be safe for the application. <br />
<br />
The paranoid rules, however, will NOT allow this, even if this is known to be safe for the application. They will alert, and if configured (or misconfigured) also block this as an RFI attack. These rules will alert on things that may be safe or are known to be non-malicious. This will generate a lot of false positives for most users, therefore you should not use these rules if you do not want to experience a high degree of false positives. These rules exist for paranoid users, who may want to tune the rules themselves, or may wish to know about every possible potentially malicious event, even when the event may in fact not be malicious.<br />
<br />
We do not recommend you use these rules in blocking mode, instead you should use these only in detect mode, and only if you feel that your applications are doing things in a very unsafe manner. If you do wish to use these rules, make sure that you load them from a special file so you can set the default behaviour of the rules. If you do not do this, the rules will inherit you systems default behavior, which is generally to block.<br />
<br />
Example configuration lines for the paranoid rules:<br />
<br />
<pre><br />
SecDefaultAction "log,pass,auditlog,phase:2,t:none,t:lowercase,t:replaceNulls,t:compressWhitespace"<br />
Include modsecurity.paranoid.rules.d/15_asl_paranoid_rules.conf<br />
</pre><br />
<br />
You must load these rules last.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
==== Using the paranoid rules ====<br />
<br />
If you want to use the paranoid rules because you have found a vulnerability in your application that the normal rules do not block, please let us know, we would be happy to take a look at either creating a Just In Time Patch for your vulnerability, or adjusting the tuned rules to not allow this. Remember, if you use our real time rules, we provide this service for free. One easy way to find out if you have applications that have unusual vulnerabilities is to scan the application with a web vulnerability application scanner, if you find something the normal rules dont stop just let us know. We'd be delighted to put out new rules for your applications vulnerabilities.<br />
<br />
Finally, if you do you use these rules you will need to set ATOMIC_PARANOID_MODE to 1 in your modsecurity configuration. If you do not know how to do this, we do not recommend you use these rules.<br />
<br />
'''Note: Do not use this ruleset with [[ASL]]. [[ASL]] uses intelligent defense in depth, and does need this kind of ruleset to protect you. You will get a greater level of protection from ASL, without all the false positives.'''<br />
<br />
==== Beta Rules ====<br />
<br />
==== Experimental Rules ====<br />
<br />
<br />
====70_asl_csrf_experimental.conf====<br />
<br />
These are experimental CSRF mitigation rules. The 10_asl_rules.conf rules are designed to also handle some types of CSRF attacks, however these rules are for more advanced environments.<br />
<br />
These rules work by injecting javascript code into the response, and special cookies, and must be tuned for the system to prevent false positives. If you do not understand what this means, do not use these rules.<br />
<br />
'''They are currently not supported and are experimental.'''<br />
<br />
Requires: Modsecurity 2.7.0 and up.</div>Mshinnhttps://wiki.atomicorp.com/wiki/index.php/WAF_rule_familiesWAF rule families2022-10-06T21:22:09Z<p>Mshinn: /* 00_asl_z_searchengines.conf */</p>
<hr />
<div>The Atomicorp/Gotroot rules are broken into families - we recommend you load all the rule families. They work well together, and its safe to use all the rules on a box. We run every rule on our boxes and have been since we first started publishing them over ten years ago.<br />
<br />
====000000000000000000000000_asl_notconfigured.conf====<br />
<br />
'''This rule file should not be used.''' <br />
<br />
This file is a "canary" file included in the archive to prevent users from accidentally loading all the rule files at the same. This ruleset will prevent this condition by disabling the WAF and logging a warning that the installation instructions have not been followed.<br />
<br />
If you are getting any errors about this file and you are using a third party product that installs our rules, please contact the vendor for that product.<br />
<br />
====000_asl_threat_intelligence.conf====<br />
<br />
These rules use the Atomicorp Threat Intelligence system to detect if an IP is a known threat. These rules look for DOS, brute force, spam, known attackers and advanced threats.<br />
<br />
Note: Requires modsecurity 2.7.7 and up.<br />
<br />
====00_asl_x_searchengines.conf====<br />
<br />
'''This ruleset is Deprecated'''<br />
<br />
Note: this is a legacy ruleset and should only be used on platform that do not support lua, and may experience performance issues. Please use 00_asl_z_searchengines.conf instead.<br />
<br />
This ruleset tells the WAF to trust defined search engines, and to not block or shun them.<br />
<br />
<br />
Note: Requires modsecurity 2.7.7 and up.<br />
<br />
====00_asl_y_searchengines.conf ====<br />
<br />
'''This ruleset is Deprecated'''<br />
<br />
Note: this is a legacy ruleset and should only be used on platform that do not support lua, and may experience performance issues. Please use 00_asl_z_searchengines.conf instead.<br />
<br />
''(Available in ASL and the real time rules only)''<br />
<br />
This ruleset detects clients pretending to be a search engine, as well as valid search engines. You must have either [[ASL]] installed, or apache configured with "HostnameLookups Double" and a very fast local DNS server. <br />
<br />
These rules also allow you to auto-whitelist real search engines. To do this, you will need to either use [[ASL]], or you will need to manually set the variable WHITELIST_SEARCH_ENGINES to "1".<br />
<br />
'''Warning: If you do not have either [[ASL]] installed, or apache configured correctly to use these rules they will not work correctly.'''<br />
<br />
Note: If you do not have a fast local DNS server, do not use these rules. These rules perform forward and reverse lookups and require a fast local DNS server, otherwise you should expect your websites to be very slow.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
Excluded: Modsecurity 2.8.0. Because 2.8.0 has a serious bug in the @ipmatch code( https://github.com/SpiderLabs/ModSecurity/issues/706).<br />
<br />
====00_asl_z_searchengines.conf====<br />
<br />
'(Available in ASL and the real time rules only)''<br />
<br />
Note: The rules must be used with a [[Local DNS resolver]]. If you do not have a fast local DNS server (not a remote DNS server), do not use these rules. These rules perform forward and reverse lookups and require a fast local DNS server. Failure to use a local resolver will result in performance degradation, these rules may also not work at all in these cases.<br />
<br />
This ruleset detects clients pretending to be a search engine, as well as valid search engines. You must have a very fast local DNS server to use these rules. These rules also allow you to auto-whitelist real search engines. To do this, in the /etc/asl/config set WAF_LUA_00_SEARCHENGINE to "yes"<br />
<br />
For DIY installations, you must install the "advanced" subdirectory in your modsecurity rules directory. If you are manually extracting the rules archive files this should be created for you automatically, and will contain the actual .lua files this config file will load. <br />
<br />
Requires: Modsecurity 2.9.3 and up.<br />
<br />
====00_asl_zz_strict.conf====<br />
<br />
'''Note: Requires modsecurity 2.7.0 and higher.'''<br />
<br />
This enforces strict adherence to the HTTP RFCs.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====00_asl_0_global.conf====<br />
<br />
This is a global variable file, it is only used if you have modsecurity 2.5.13 and above installed. <br />
<br />
====00_asl_rbl.conf====<br />
<br />
This rule family checks an incoming host to see if its on a RBL. By default only the spamhaus XBL-SBL list is enabled which is operated by the Spamhaus project. This RBL is not operated or controlled by Atomicorp. Please contact Spamhaus if you have issues with the IPs on this RBL, or disable this option. Several other RBLs are including in this rule file and must be either enabled in ASL (ASL will generate this rule file) or if you are not running ASL you must manually enable the other RBLs.<br />
<br />
This ruleset will look up every request in the DNS to see if its on a blacklist, and will not finish serving the request until the DNS server responds. This can slow down requests if the DNS server is slow. Basically, web requests will move at the speed of the DNS servers replies.<br />
<br />
If your web server is responding slowly to requests, and you have this ruleset enabled your DNS server is too slow to meet your lookup needs. You will need to either disable this ruleset, or tune your DNS server to respond to queries more quickly.<br />
<br />
''If you use this ruleset, make sure you have a fast locally caching DNS server. This ruleset will query spamhaus for every incoming IP to see if its on a blacklist, if your DNS is slow (or non local) this will make your system seem to crawl, as the read request will be blocked by Apache until it finished the DNS lookup. If you do not have a fast and local DNS server, do not use this ruleset.''<br />
<br />
Requires: Modsecurity 2.6.0 and up.<br />
<br />
====00_asl_blacklist.conf====<br />
<br />
Allows you to blacklist hosts or CIDRs from the WAF.<br />
<br />
Requires: Modsecurity 2.9.0 and up.<br />
<br />
The format is single IPs or CIDRs per line, for example:<br />
<br />
<pre><br />
1.2.3.4<br />
5.6.7.0/24<br />
8.9.0.0/16<br />
</pre><br />
<br />
Note: You must define your own blacklist file. The default location is /etc/asl/blacklist. <br />
<br />
====00_asl_whitelist.conf====<br />
<br />
Allows you to whitelist hosts from the WAF.<br />
<br />
Requires: Modsecurity 2.9.0 and up.<br />
<br />
The format is single IPs or CIDRs per line, for example:<br />
<br />
<pre><br />
1.2.3.4<br />
5.6.7.0/24<br />
8.9.0.0/16<br />
</pre><br />
<br />
Note: You must define your own whitelist entires. The default location is /etc/asl/whitelist. '''Do not use the whitelist.txt file. It is not used for this rule. We do not provide a default whitelist for these rules.'''<br />
<br />
Note: Requires modsecurity 2.7.7 and up.<br />
<br />
====01_asl_content.conf====<br />
<br />
These rules restrict the server to known content types that the WAF can correctly decipher.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
==== 01_asl_domain_blocks.conf====<br />
<br />
Optional ruleset that allows you to block connections from hosts, based on their DNS hostname and/or domain. This is a user defined list.<br />
<br />
Domains and/or hostnames are stored in this file:<br />
<br />
/etc/asl/custom-domain-blocks<br />
<br />
The format is one entry, per line, for example:<br />
<br />
<pre><br />
example.com<br />
www.hostname.some-tld<br />
</pre><br />
<br />
Note: You must have either [[ASL]] installed, or apache configured with "HostnameLookups Double" and a very fast local DNS server for these rules to work.\<br />
<br />
Note: Requires modsecurity 2.7.7 and up.<br />
<br />
====01_asl_rules_special.conf====<br />
<br />
This ruleset changes the behavior of the WAF for applications that behavior in nonstandard ways. For example, OTRS uses ";" and not "&" for argument separation. You should not use these rules if you do not have OTRS installed on your system.<br />
<br />
If you do not know what this means, you do not need this ruleset.<br />
<br />
Requires: Modsecurity 2.7.0 and up. <br />
<br />
Note: If you get an error regarding SecArgumentSeparator with these rules, your modsecurity configuration is being loaded too late in your Apache stack. Ensure that your modsecurity configuration is loaded first. This has been seen with cpanel when not using [[ASL]]. Please contact your apache vendor for assistance with this issue, or use [[ASL]] which will fix your apache configuration so this error does not occur.<br />
<br />
====03_asl_dos.conf====<br />
<br />
This ruleset protects apache from slow DOS attacks. It is only supported with Apache and requires the installation of the mod_reqtimeout module. The rule is fail safe with Apache, that is if the mod_reqtimeout module is not loaded the rules also will not load into Apache.<br />
<br />
[[ASL]] automatically ensures mod_reqtimeout is installed. If you are a rules only user please contact your Apache vendor for assistance installing this module.<br />
<br />
Note: Requires modsecurity 2.7.7 and up.<br />
<br />
====05_asl_exclude.conf====<br />
<br />
Pre-load rule exclusion list. Turns off rules that need to be disabled early in the process. ASL manages this process automatically.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====00_asl_z_antievasion.conf====<br />
<br />
This is a ruleset to detect attempts to bypass modsecurity itself, through evasion methods for example. Do not use this ruleset unless you are using 2.6.1 and up.<br />
<br />
====05_asl_scanner.conf ====<br />
<br />
Deprecated.<br />
<br />
====06_asl_honeypot.conf ====<br />
<br />
This ruleset lets you define URLs you want to specifically block, for example the URL of an application that may not be installed on the system. This can work as a honeypot of sorts, allowing the system to be configured to treat probes for non-existant applications as attacks. [[ASL]] has a more advanced system that can detect when URLs do not correspond to files on the system, which can be used in place of this ruleset or to augment it.<br />
<br />
For this ruleset to work, populate the honeypot-files.txt file in the same directory as 06_asl_honeypot.conf with one URL per line. For example:<br />
<br />
<br />
<pre><br />
/application/not/installed/on/system<br />
file_name_not_on_system.extension<br />
</pre><br />
<br />
==== 11_asl_rules.conf====<br />
<br />
This ruleset is reserved and is not currently used.<br />
<br />
====10_asl_antimalware.conf====<br />
<br />
Checks payload and RFI contents for known sources of malware and malware payloads and will block them.<br />
<br />
Requires: Modsecurity 2.6.0 and up.<br />
<br />
====09_asl_rules.conf====<br />
<br />
These are supplementation rules to the 10_asl_rules.conf, but only work on 2.6.6 and up installations. Do not use this ruleset unless you are using 2.6.6 and up.<br />
<br />
====10_asl_rules.conf ====<br />
<br />
The main rules, contains all the generic security rules to protect against classes of attacks, such as SQL injection, XSS, code injection, recursion, etc. '''These rules require modsecurity 2.9.1 and above.'''<br />
<br />
Requires: Modsecurity 2.9.1 and up.<br />
<br />
====11_asl_adv_rules.conf====<br />
<br />
These are advanced rules, and '''can only be used with modsecurity 2.7.5 and above.'''<br />
<br />
Requires: Modsecurity 2.7.5 and up.<br />
<br />
====11_asl_data_loss.conf====<br />
<br />
Experimental data leakage rules. Looks for credit card numbers and other potentially sensitive information leaking from the system.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====11_asl_brute_enhanced.conf====<br />
<br />
Requires: Modsecurity 2.9.2 and up.<br />
<br />
These rules are for platforms that do not have either [[ASL]] or Atomic Protector installed. These rules create the collections in modsecurity to block brute force attacks. The defaults are > 5 failures within 60 seconds.<br />
<br />
''Note: These rules are not necessary if the systen has ASL or Atomic Protector installed, and should not be used with ASL or AP.<br />
<br />
''Note 1: These rules will only work if the web server can write to the SecDataDir directory. That directory will contain sqllite databases that modsecurity will create and use to count events, without the collection modsecurity can not maintain state for composite events, like multiple login failures, and these rules will not work.''<br />
<br />
''Note 2: Enable this setting in /etc/asl/config to create the collections:''<br />
<br />
<br />
https://wiki.atomicorp.com/wiki/index.php/Aum_configuration#MODSEC_00_THREAT<br />
<br />
====12_asl_adv_xss_rules.conf====<br />
<br />
'''This ruleset require mod_security 2.9.0 and above.'''<br />
<br />
This is the advanced Cross Site Scripting (XSS) protection rule set. It performs deep level inspections of web requests and responses to look for potential XSS attacks.<br />
<br />
====12_asl_brute.conf====<br />
<br />
'''This ruleset is only available with [[ASL]] or the Real Time Rules.''' <br />
<br />
This ruleset detects authentication failures against all major web applications (Joomla, WordPress, MovableType, Drupal, ModX, ZenCart, OsCommerce, VBulletin, PHPBB and more).<br />
<br />
When used with [[ASL]], fast and "low and slow" brute force attacks can be detected and blocked in real time.<br />
<br />
Requires: Modsecurity 2.6.8 and up. <br />
<br />
'''Note: [[ASL]] is necessary to perform active response to brute force attacks.'''<br />
<br />
====13_asl_brute_enhanced.conf====<br />
<br />
Requires: Modsecurity 2.9.2 and up.<br />
<br />
These rules are for platforms that do not have either [ASL] or Atomic Protector installed. These rules create the collections in modsecurity to block brute force attacks. The defaults are > 10 failures within 60 seconds.<br />
<br />
''Note: These rules are not necessary if the systen has ASL or Atomic Protector installed, and should not be used with ASL or AP.<br />
<br />
Note 1: These rules will only work if the web server can write to the SecDataDir directory. That directory will contain sqllite databases that modsecurity will create and use to count events, without the collection modsecurity can not maintain state for composite events, like multiple login failures, and these rules will not work.''<br />
<br />
====20_asl_useragents.conf====<br />
<br />
Looks for malicious or suspicious user agents and known patterns of malicious activity. These rules require modsecurity 2.7.1 and up.<br />
<br />
Requires: Modsecurity 2.7.1 and up.<br />
<br />
====30_asl_antispam.conf====<br />
<br />
Tuned antispam rules, designed to work with all known blogs, forums, guestbooks, CMS' and other web content management systems that allow users to post content.<br />
<br />
Requires: Modsecurity 2.6.8 and up.<br />
<br />
====30_asl_antispam_advanced.conf====<br />
<br />
(Not released yet) These are advanced spam rules. They require modsecurity 2.7.1 and up.<br />
<br />
Requires: Modsecurity 2.7.1 and up.<br />
<br />
====30_asl_antispam_referrer.conf====<br />
<br />
Rules to block referrer spam. Generally not needed in most environments if you protect web log generation tools from public access (which is the default for most control panels).<br />
<br />
Requires: Modsecurity 2.6.0 and up.<br />
<br />
====40_asl_apache2-rules.conf====<br />
<br />
This ruleset has been retired. mod_security 2.x does not work with Apache 1.x and this ruleset existed just for those rules that only worked with apache 2. As mod_security 2.x does not work with Apache 1.x there is no need for this ruleset.<br />
<br />
====50_asl_rootkits.conf====<br />
<br />
Detects and blocks known web based rootkits, PHP/ASP/PERL shells, spam tools and other malicious web applications from being installed, and in some cases from running on the system. These rules exist for cases where malicious software may already be installed on the system, this is a defense in depth rule set)<br />
<br />
Not: ASL can prevent all malware from running on the system, modsecurity is limited in this regard so if you are only using the rules you should not expect modsecurity to prevent malware from running. It may prevent it in some cases, but without kernel level protection such as that provided in [[ASL]] no WAF can stop all malware from running on the system itself.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====51_asl_rootkits.conf====<br />
<br />
These rules look for known malware names in filenames, and URLs.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====60_asl_recons.conf====<br />
<br />
Blocks known "google hacks" or webserver probes that look for vulnerable applications and signs of compromised systems running unauthorized shells, or unprotected applications that allow uploads which would give an attacker access to the system.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====61_asl_recons_dlp.conf====<br />
<br />
These rules detect Data Loss Search engine "hacks". These are search engine probes for sensitive files, often used by malicious parties to find sensitive information accidentally exposed on web servers.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====99_asl_a_redactor.conf====<br />
<br />
ASL only rule set. Requires modsecurity 2.6.0 and up. Part of the malicious code removal system. Automatically removes malicious code from web pages, such as hidden iframes, encoded javascript and other malicious code. '''Do not enable this ruleset if you are not using ASL. ''' <br />
<br />
====99_asl_exclude.conf====<br />
<br />
Post exclude rules.<br />
<br />
====98_asl_adv_redactor.conf====<br />
<br />
This is the new advanced malware removal system. This ruleset will remove malware "on the fly" from web pages. For example, it will remove hidden iframes, malicous javascript, and other malicious code.<br />
<br />
'''Requires: modsecurity 2.7.5 and up.'''<br />
<br />
====98_asl_jitp.conf====<br />
<br />
This is a special ruleset used by [[ASL]]. If you do not have [[ASL]] you can not use these rules.<br />
<br />
====99_asl_jitp.conf====<br />
<br />
Just in Time Patches. We publish JITPs daily if there is a new web application vulnerability that the 10_asl_rules.conf do not protect the system against. These are tuned rules for specific vulnerabilities in a web application.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====99_asl_a_redactor.conf====<br />
<br />
This ruleset is reserved, and is not currently used.<br />
<br />
====99_asl_redactor.conf====<br />
<br />
'''Note: Do not enable this ruleset unless you have been instructed to do so by support.'''<br />
<br />
Special ruleset - requires mod_sed to be loaded on the system which is included and supported in [[ASL]] - removes malicious code from web pages, such as hidden iframes, encoded javascript and other malicious code. We highly recommend you use this rule set - its fast, multithreads and will automagically remove malicious code from infected webpages, which can occur if an adversary is able to log into the system and modify the code, such as by SSH or by uploading the code via FTP. If you are not using [[ASL]] then you will need to make sure your system has mod_sed installed to use these rules, they will not load and therefore will not do anything without mod_sed installed. This ruleset is only supported with [[ASL]].<br />
<br />
====99_asl_redactor_post.conf====<br />
<br />
This ruleset detects malicious content in webpages, such as known malicious domains.<br />
<br />
====99_asl_scanner.conf====<br />
<br />
This is the same as 05_asl_scanner.conf, its provided in a form to run last. This is the recommended location for the scanner function, as the rules before this stop some attacks that the scanner also detects, but do this in a faster and less CPU intensive manner. Running the scanner last does not compromise or lower the effectiveness of the rules. This is just a performance enhancement. This ruleset is only supported with [[ASL]].<br />
<br />
====99_asl_z_adv_scanner.conf====<br />
<br />
'''Note: Requires [[ASL]] and modsecurity 2.9.0 and higher.'''<br />
<br />
This ruleset uses a fuzzy hash to identify potentially malicious files.<br />
<br />
Warning: This ruleset is not supported on non-ASL systems. Do not use this without ASL.<br />
<br />
==== Paranoid mode rules ====<br />
<br />
===== 15_asl_paranoid_rules.conf =====<br />
<br />
'''Note: Do not use these rules if you have not read this section.'''<br />
<br />
'''Please do not report false positives with these rules. If you encounter a false positive with a rule from this file, please use its duplicate in 10_asl_rules.conf instead. If you have a false positive with a rule from 10_asl_rules.conf, please report it to us.'''<br />
<br />
These are a special version of the 10_asl_rules.conf file, they use the same rule id:s as the 10_asl_rules.conf file. Therefore, you can not use these rules along with the 10_asl_rules.conf file. You can use one, or the other, but not both.<br />
<br />
These rules are a paranoid replacement for the 10_asl_rules.conf file. These rules do not contain any known safe mode application tuning exceptions or bypasses. These rules will generate false positives. These rules are made available for users that wish to tune their own rules, and do not wish to use a ruleset that has been tuned for false positives.<br />
<br />
For example, if you had a application that safely used the argument "url" to accept URLs:<br />
<br />
GET /application?url=http://www.example.com/safething<br />
<br />
The normal rules would allow this, if this was known to be safe for the application. <br />
<br />
The paranoid rules, however, will NOT allow this, even if this is known to be safe for the application. They will alert, and if configured (or misconfigured) also block this as an RFI attack. These rules will alert on things that may be safe or are known to be non-malicious. This will generate a lot of false positives for most users, therefore you should not use these rules if you do not want to experience a high degree of false positives. These rules exist for paranoid users, who may want to tune the rules themselves, or may wish to know about every possible potentially malicious event, even when the event may in fact not be malicious.<br />
<br />
We do not recommend you use these rules in blocking mode, instead you should use these only in detect mode, and only if you feel that your applications are doing things in a very unsafe manner. If you do wish to use these rules, make sure that you load them from a special file so you can set the default behaviour of the rules. If you do not do this, the rules will inherit you systems default behavior, which is generally to block.<br />
<br />
Example configuration lines for the paranoid rules:<br />
<br />
<pre><br />
SecDefaultAction "log,pass,auditlog,phase:2,t:none,t:lowercase,t:replaceNulls,t:compressWhitespace"<br />
Include modsecurity.paranoid.rules.d/15_asl_paranoid_rules.conf<br />
</pre><br />
<br />
You must load these rules last.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
==== Using the paranoid rules ====<br />
<br />
If you want to use the paranoid rules because you have found a vulnerability in your application that the normal rules do not block, please let us know, we would be happy to take a look at either creating a Just In Time Patch for your vulnerability, or adjusting the tuned rules to not allow this. Remember, if you use our real time rules, we provide this service for free. One easy way to find out if you have applications that have unusual vulnerabilities is to scan the application with a web vulnerability application scanner, if you find something the normal rules dont stop just let us know. We'd be delighted to put out new rules for your applications vulnerabilities.<br />
<br />
Finally, if you do you use these rules you will need to set ATOMIC_PARANOID_MODE to 1 in your modsecurity configuration. If you do not know how to do this, we do not recommend you use these rules.<br />
<br />
'''Note: Do not use this ruleset with [[ASL]]. [[ASL]] uses intelligent defense in depth, and does need this kind of ruleset to protect you. You will get a greater level of protection from ASL, without all the false positives.'''<br />
<br />
==== Beta Rules ====<br />
<br />
==== Experimental Rules ====<br />
<br />
<br />
====70_asl_csrf_experimental.conf====<br />
<br />
These are experimental CSRF mitigation rules. The 10_asl_rules.conf rules are designed to also handle some types of CSRF attacks, however these rules are for more advanced environments.<br />
<br />
These rules work by injecting javascript code into the response, and special cookies, and must be tuned for the system to prevent false positives. If you do not understand what this means, do not use these rules.<br />
<br />
'''They are currently not supported and are experimental.'''<br />
<br />
Requires: Modsecurity 2.7.0 and up.</div>Mshinnhttps://wiki.atomicorp.com/wiki/index.php/WAF_rule_familiesWAF rule families2022-10-06T21:21:19Z<p>Mshinn: /* 00_asl_z_searchengines.conf */</p>
<hr />
<div>The Atomicorp/Gotroot rules are broken into families - we recommend you load all the rule families. They work well together, and its safe to use all the rules on a box. We run every rule on our boxes and have been since we first started publishing them over ten years ago.<br />
<br />
====000000000000000000000000_asl_notconfigured.conf====<br />
<br />
'''This rule file should not be used.''' <br />
<br />
This file is a "canary" file included in the archive to prevent users from accidentally loading all the rule files at the same. This ruleset will prevent this condition by disabling the WAF and logging a warning that the installation instructions have not been followed.<br />
<br />
If you are getting any errors about this file and you are using a third party product that installs our rules, please contact the vendor for that product.<br />
<br />
====000_asl_threat_intelligence.conf====<br />
<br />
These rules use the Atomicorp Threat Intelligence system to detect if an IP is a known threat. These rules look for DOS, brute force, spam, known attackers and advanced threats.<br />
<br />
Note: Requires modsecurity 2.7.7 and up.<br />
<br />
====00_asl_x_searchengines.conf====<br />
<br />
'''This ruleset is Deprecated'''<br />
<br />
Note: this is a legacy ruleset and should only be used on platform that do not support lua, and may experience performance issues. Please use 00_asl_z_searchengines.conf instead.<br />
<br />
This ruleset tells the WAF to trust defined search engines, and to not block or shun them.<br />
<br />
<br />
Note: Requires modsecurity 2.7.7 and up.<br />
<br />
====00_asl_y_searchengines.conf ====<br />
<br />
'''This ruleset is Deprecated'''<br />
<br />
Note: this is a legacy ruleset and should only be used on platform that do not support lua, and may experience performance issues. Please use 00_asl_z_searchengines.conf instead.<br />
<br />
''(Available in ASL and the real time rules only)''<br />
<br />
This ruleset detects clients pretending to be a search engine, as well as valid search engines. You must have either [[ASL]] installed, or apache configured with "HostnameLookups Double" and a very fast local DNS server. <br />
<br />
These rules also allow you to auto-whitelist real search engines. To do this, you will need to either use [[ASL]], or you will need to manually set the variable WHITELIST_SEARCH_ENGINES to "1".<br />
<br />
'''Warning: If you do not have either [[ASL]] installed, or apache configured correctly to use these rules they will not work correctly.'''<br />
<br />
Note: If you do not have a fast local DNS server, do not use these rules. These rules perform forward and reverse lookups and require a fast local DNS server, otherwise you should expect your websites to be very slow.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
Excluded: Modsecurity 2.8.0. Because 2.8.0 has a serious bug in the @ipmatch code( https://github.com/SpiderLabs/ModSecurity/issues/706).<br />
<br />
====00_asl_z_searchengines.conf====<br />
<br />
'(Available in ASL and the real time rules only)''<br />
<br />
Note: The rules must be used with a [[Local DNS resolver]]. If you do not have a fast local DNS server, do not use these rules. These rules perform forward and reverse lookups and require a fast local DNS server. Failure to use a local resolver will result in performance degradation, and these may not work.<br />
<br />
This ruleset detects clients pretending to be a search engine, as well as valid search engines. You must have a very fast local DNS server to use these rules. These rules also allow you to auto-whitelist real search engines. To do this, in the /etc/asl/config set WAF_LUA_00_SEARCHENGINE to "yes"<br />
<br />
For DIY installations, you must install the "advanced" subdirectory in your modsecurity rules directory. If you are manually extracting the rules archive files this should be created for you automatically, and will contain the actual .lua files this config file will load. <br />
<br />
Requires: Modsecurity 2.9.3 and up.<br />
<br />
====00_asl_zz_strict.conf====<br />
<br />
'''Note: Requires modsecurity 2.7.0 and higher.'''<br />
<br />
This enforces strict adherence to the HTTP RFCs.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====00_asl_0_global.conf====<br />
<br />
This is a global variable file, it is only used if you have modsecurity 2.5.13 and above installed. <br />
<br />
====00_asl_rbl.conf====<br />
<br />
This rule family checks an incoming host to see if its on a RBL. By default only the spamhaus XBL-SBL list is enabled which is operated by the Spamhaus project. This RBL is not operated or controlled by Atomicorp. Please contact Spamhaus if you have issues with the IPs on this RBL, or disable this option. Several other RBLs are including in this rule file and must be either enabled in ASL (ASL will generate this rule file) or if you are not running ASL you must manually enable the other RBLs.<br />
<br />
This ruleset will look up every request in the DNS to see if its on a blacklist, and will not finish serving the request until the DNS server responds. This can slow down requests if the DNS server is slow. Basically, web requests will move at the speed of the DNS servers replies.<br />
<br />
If your web server is responding slowly to requests, and you have this ruleset enabled your DNS server is too slow to meet your lookup needs. You will need to either disable this ruleset, or tune your DNS server to respond to queries more quickly.<br />
<br />
''If you use this ruleset, make sure you have a fast locally caching DNS server. This ruleset will query spamhaus for every incoming IP to see if its on a blacklist, if your DNS is slow (or non local) this will make your system seem to crawl, as the read request will be blocked by Apache until it finished the DNS lookup. If you do not have a fast and local DNS server, do not use this ruleset.''<br />
<br />
Requires: Modsecurity 2.6.0 and up.<br />
<br />
====00_asl_blacklist.conf====<br />
<br />
Allows you to blacklist hosts or CIDRs from the WAF.<br />
<br />
Requires: Modsecurity 2.9.0 and up.<br />
<br />
The format is single IPs or CIDRs per line, for example:<br />
<br />
<pre><br />
1.2.3.4<br />
5.6.7.0/24<br />
8.9.0.0/16<br />
</pre><br />
<br />
Note: You must define your own blacklist file. The default location is /etc/asl/blacklist. <br />
<br />
====00_asl_whitelist.conf====<br />
<br />
Allows you to whitelist hosts from the WAF.<br />
<br />
Requires: Modsecurity 2.9.0 and up.<br />
<br />
The format is single IPs or CIDRs per line, for example:<br />
<br />
<pre><br />
1.2.3.4<br />
5.6.7.0/24<br />
8.9.0.0/16<br />
</pre><br />
<br />
Note: You must define your own whitelist entires. The default location is /etc/asl/whitelist. '''Do not use the whitelist.txt file. It is not used for this rule. We do not provide a default whitelist for these rules.'''<br />
<br />
Note: Requires modsecurity 2.7.7 and up.<br />
<br />
====01_asl_content.conf====<br />
<br />
These rules restrict the server to known content types that the WAF can correctly decipher.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
==== 01_asl_domain_blocks.conf====<br />
<br />
Optional ruleset that allows you to block connections from hosts, based on their DNS hostname and/or domain. This is a user defined list.<br />
<br />
Domains and/or hostnames are stored in this file:<br />
<br />
/etc/asl/custom-domain-blocks<br />
<br />
The format is one entry, per line, for example:<br />
<br />
<pre><br />
example.com<br />
www.hostname.some-tld<br />
</pre><br />
<br />
Note: You must have either [[ASL]] installed, or apache configured with "HostnameLookups Double" and a very fast local DNS server for these rules to work.\<br />
<br />
Note: Requires modsecurity 2.7.7 and up.<br />
<br />
====01_asl_rules_special.conf====<br />
<br />
This ruleset changes the behavior of the WAF for applications that behavior in nonstandard ways. For example, OTRS uses ";" and not "&" for argument separation. You should not use these rules if you do not have OTRS installed on your system.<br />
<br />
If you do not know what this means, you do not need this ruleset.<br />
<br />
Requires: Modsecurity 2.7.0 and up. <br />
<br />
Note: If you get an error regarding SecArgumentSeparator with these rules, your modsecurity configuration is being loaded too late in your Apache stack. Ensure that your modsecurity configuration is loaded first. This has been seen with cpanel when not using [[ASL]]. Please contact your apache vendor for assistance with this issue, or use [[ASL]] which will fix your apache configuration so this error does not occur.<br />
<br />
====03_asl_dos.conf====<br />
<br />
This ruleset protects apache from slow DOS attacks. It is only supported with Apache and requires the installation of the mod_reqtimeout module. The rule is fail safe with Apache, that is if the mod_reqtimeout module is not loaded the rules also will not load into Apache.<br />
<br />
[[ASL]] automatically ensures mod_reqtimeout is installed. If you are a rules only user please contact your Apache vendor for assistance installing this module.<br />
<br />
Note: Requires modsecurity 2.7.7 and up.<br />
<br />
====05_asl_exclude.conf====<br />
<br />
Pre-load rule exclusion list. Turns off rules that need to be disabled early in the process. ASL manages this process automatically.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====00_asl_z_antievasion.conf====<br />
<br />
This is a ruleset to detect attempts to bypass modsecurity itself, through evasion methods for example. Do not use this ruleset unless you are using 2.6.1 and up.<br />
<br />
====05_asl_scanner.conf ====<br />
<br />
Deprecated.<br />
<br />
====06_asl_honeypot.conf ====<br />
<br />
This ruleset lets you define URLs you want to specifically block, for example the URL of an application that may not be installed on the system. This can work as a honeypot of sorts, allowing the system to be configured to treat probes for non-existant applications as attacks. [[ASL]] has a more advanced system that can detect when URLs do not correspond to files on the system, which can be used in place of this ruleset or to augment it.<br />
<br />
For this ruleset to work, populate the honeypot-files.txt file in the same directory as 06_asl_honeypot.conf with one URL per line. For example:<br />
<br />
<br />
<pre><br />
/application/not/installed/on/system<br />
file_name_not_on_system.extension<br />
</pre><br />
<br />
==== 11_asl_rules.conf====<br />
<br />
This ruleset is reserved and is not currently used.<br />
<br />
====10_asl_antimalware.conf====<br />
<br />
Checks payload and RFI contents for known sources of malware and malware payloads and will block them.<br />
<br />
Requires: Modsecurity 2.6.0 and up.<br />
<br />
====09_asl_rules.conf====<br />
<br />
These are supplementation rules to the 10_asl_rules.conf, but only work on 2.6.6 and up installations. Do not use this ruleset unless you are using 2.6.6 and up.<br />
<br />
====10_asl_rules.conf ====<br />
<br />
The main rules, contains all the generic security rules to protect against classes of attacks, such as SQL injection, XSS, code injection, recursion, etc. '''These rules require modsecurity 2.9.1 and above.'''<br />
<br />
Requires: Modsecurity 2.9.1 and up.<br />
<br />
====11_asl_adv_rules.conf====<br />
<br />
These are advanced rules, and '''can only be used with modsecurity 2.7.5 and above.'''<br />
<br />
Requires: Modsecurity 2.7.5 and up.<br />
<br />
====11_asl_data_loss.conf====<br />
<br />
Experimental data leakage rules. Looks for credit card numbers and other potentially sensitive information leaking from the system.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====11_asl_brute_enhanced.conf====<br />
<br />
Requires: Modsecurity 2.9.2 and up.<br />
<br />
These rules are for platforms that do not have either [[ASL]] or Atomic Protector installed. These rules create the collections in modsecurity to block brute force attacks. The defaults are > 5 failures within 60 seconds.<br />
<br />
''Note: These rules are not necessary if the systen has ASL or Atomic Protector installed, and should not be used with ASL or AP.<br />
<br />
''Note 1: These rules will only work if the web server can write to the SecDataDir directory. That directory will contain sqllite databases that modsecurity will create and use to count events, without the collection modsecurity can not maintain state for composite events, like multiple login failures, and these rules will not work.''<br />
<br />
''Note 2: Enable this setting in /etc/asl/config to create the collections:''<br />
<br />
<br />
https://wiki.atomicorp.com/wiki/index.php/Aum_configuration#MODSEC_00_THREAT<br />
<br />
====12_asl_adv_xss_rules.conf====<br />
<br />
'''This ruleset require mod_security 2.9.0 and above.'''<br />
<br />
This is the advanced Cross Site Scripting (XSS) protection rule set. It performs deep level inspections of web requests and responses to look for potential XSS attacks.<br />
<br />
====12_asl_brute.conf====<br />
<br />
'''This ruleset is only available with [[ASL]] or the Real Time Rules.''' <br />
<br />
This ruleset detects authentication failures against all major web applications (Joomla, WordPress, MovableType, Drupal, ModX, ZenCart, OsCommerce, VBulletin, PHPBB and more).<br />
<br />
When used with [[ASL]], fast and "low and slow" brute force attacks can be detected and blocked in real time.<br />
<br />
Requires: Modsecurity 2.6.8 and up. <br />
<br />
'''Note: [[ASL]] is necessary to perform active response to brute force attacks.'''<br />
<br />
====13_asl_brute_enhanced.conf====<br />
<br />
Requires: Modsecurity 2.9.2 and up.<br />
<br />
These rules are for platforms that do not have either [ASL] or Atomic Protector installed. These rules create the collections in modsecurity to block brute force attacks. The defaults are > 10 failures within 60 seconds.<br />
<br />
''Note: These rules are not necessary if the systen has ASL or Atomic Protector installed, and should not be used with ASL or AP.<br />
<br />
Note 1: These rules will only work if the web server can write to the SecDataDir directory. That directory will contain sqllite databases that modsecurity will create and use to count events, without the collection modsecurity can not maintain state for composite events, like multiple login failures, and these rules will not work.''<br />
<br />
====20_asl_useragents.conf====<br />
<br />
Looks for malicious or suspicious user agents and known patterns of malicious activity. These rules require modsecurity 2.7.1 and up.<br />
<br />
Requires: Modsecurity 2.7.1 and up.<br />
<br />
====30_asl_antispam.conf====<br />
<br />
Tuned antispam rules, designed to work with all known blogs, forums, guestbooks, CMS' and other web content management systems that allow users to post content.<br />
<br />
Requires: Modsecurity 2.6.8 and up.<br />
<br />
====30_asl_antispam_advanced.conf====<br />
<br />
(Not released yet) These are advanced spam rules. They require modsecurity 2.7.1 and up.<br />
<br />
Requires: Modsecurity 2.7.1 and up.<br />
<br />
====30_asl_antispam_referrer.conf====<br />
<br />
Rules to block referrer spam. Generally not needed in most environments if you protect web log generation tools from public access (which is the default for most control panels).<br />
<br />
Requires: Modsecurity 2.6.0 and up.<br />
<br />
====40_asl_apache2-rules.conf====<br />
<br />
This ruleset has been retired. mod_security 2.x does not work with Apache 1.x and this ruleset existed just for those rules that only worked with apache 2. As mod_security 2.x does not work with Apache 1.x there is no need for this ruleset.<br />
<br />
====50_asl_rootkits.conf====<br />
<br />
Detects and blocks known web based rootkits, PHP/ASP/PERL shells, spam tools and other malicious web applications from being installed, and in some cases from running on the system. These rules exist for cases where malicious software may already be installed on the system, this is a defense in depth rule set)<br />
<br />
Not: ASL can prevent all malware from running on the system, modsecurity is limited in this regard so if you are only using the rules you should not expect modsecurity to prevent malware from running. It may prevent it in some cases, but without kernel level protection such as that provided in [[ASL]] no WAF can stop all malware from running on the system itself.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====51_asl_rootkits.conf====<br />
<br />
These rules look for known malware names in filenames, and URLs.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====60_asl_recons.conf====<br />
<br />
Blocks known "google hacks" or webserver probes that look for vulnerable applications and signs of compromised systems running unauthorized shells, or unprotected applications that allow uploads which would give an attacker access to the system.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====61_asl_recons_dlp.conf====<br />
<br />
These rules detect Data Loss Search engine "hacks". These are search engine probes for sensitive files, often used by malicious parties to find sensitive information accidentally exposed on web servers.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====99_asl_a_redactor.conf====<br />
<br />
ASL only rule set. Requires modsecurity 2.6.0 and up. Part of the malicious code removal system. Automatically removes malicious code from web pages, such as hidden iframes, encoded javascript and other malicious code. '''Do not enable this ruleset if you are not using ASL. ''' <br />
<br />
====99_asl_exclude.conf====<br />
<br />
Post exclude rules.<br />
<br />
====98_asl_adv_redactor.conf====<br />
<br />
This is the new advanced malware removal system. This ruleset will remove malware "on the fly" from web pages. For example, it will remove hidden iframes, malicous javascript, and other malicious code.<br />
<br />
'''Requires: modsecurity 2.7.5 and up.'''<br />
<br />
====98_asl_jitp.conf====<br />
<br />
This is a special ruleset used by [[ASL]]. If you do not have [[ASL]] you can not use these rules.<br />
<br />
====99_asl_jitp.conf====<br />
<br />
Just in Time Patches. We publish JITPs daily if there is a new web application vulnerability that the 10_asl_rules.conf do not protect the system against. These are tuned rules for specific vulnerabilities in a web application.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====99_asl_a_redactor.conf====<br />
<br />
This ruleset is reserved, and is not currently used.<br />
<br />
====99_asl_redactor.conf====<br />
<br />
'''Note: Do not enable this ruleset unless you have been instructed to do so by support.'''<br />
<br />
Special ruleset - requires mod_sed to be loaded on the system which is included and supported in [[ASL]] - removes malicious code from web pages, such as hidden iframes, encoded javascript and other malicious code. We highly recommend you use this rule set - its fast, multithreads and will automagically remove malicious code from infected webpages, which can occur if an adversary is able to log into the system and modify the code, such as by SSH or by uploading the code via FTP. If you are not using [[ASL]] then you will need to make sure your system has mod_sed installed to use these rules, they will not load and therefore will not do anything without mod_sed installed. This ruleset is only supported with [[ASL]].<br />
<br />
====99_asl_redactor_post.conf====<br />
<br />
This ruleset detects malicious content in webpages, such as known malicious domains.<br />
<br />
====99_asl_scanner.conf====<br />
<br />
This is the same as 05_asl_scanner.conf, its provided in a form to run last. This is the recommended location for the scanner function, as the rules before this stop some attacks that the scanner also detects, but do this in a faster and less CPU intensive manner. Running the scanner last does not compromise or lower the effectiveness of the rules. This is just a performance enhancement. This ruleset is only supported with [[ASL]].<br />
<br />
====99_asl_z_adv_scanner.conf====<br />
<br />
'''Note: Requires [[ASL]] and modsecurity 2.9.0 and higher.'''<br />
<br />
This ruleset uses a fuzzy hash to identify potentially malicious files.<br />
<br />
Warning: This ruleset is not supported on non-ASL systems. Do not use this without ASL.<br />
<br />
==== Paranoid mode rules ====<br />
<br />
===== 15_asl_paranoid_rules.conf =====<br />
<br />
'''Note: Do not use these rules if you have not read this section.'''<br />
<br />
'''Please do not report false positives with these rules. If you encounter a false positive with a rule from this file, please use its duplicate in 10_asl_rules.conf instead. If you have a false positive with a rule from 10_asl_rules.conf, please report it to us.'''<br />
<br />
These are a special version of the 10_asl_rules.conf file, they use the same rule id:s as the 10_asl_rules.conf file. Therefore, you can not use these rules along with the 10_asl_rules.conf file. You can use one, or the other, but not both.<br />
<br />
These rules are a paranoid replacement for the 10_asl_rules.conf file. These rules do not contain any known safe mode application tuning exceptions or bypasses. These rules will generate false positives. These rules are made available for users that wish to tune their own rules, and do not wish to use a ruleset that has been tuned for false positives.<br />
<br />
For example, if you had a application that safely used the argument "url" to accept URLs:<br />
<br />
GET /application?url=http://www.example.com/safething<br />
<br />
The normal rules would allow this, if this was known to be safe for the application. <br />
<br />
The paranoid rules, however, will NOT allow this, even if this is known to be safe for the application. They will alert, and if configured (or misconfigured) also block this as an RFI attack. These rules will alert on things that may be safe or are known to be non-malicious. This will generate a lot of false positives for most users, therefore you should not use these rules if you do not want to experience a high degree of false positives. These rules exist for paranoid users, who may want to tune the rules themselves, or may wish to know about every possible potentially malicious event, even when the event may in fact not be malicious.<br />
<br />
We do not recommend you use these rules in blocking mode, instead you should use these only in detect mode, and only if you feel that your applications are doing things in a very unsafe manner. If you do wish to use these rules, make sure that you load them from a special file so you can set the default behaviour of the rules. If you do not do this, the rules will inherit you systems default behavior, which is generally to block.<br />
<br />
Example configuration lines for the paranoid rules:<br />
<br />
<pre><br />
SecDefaultAction "log,pass,auditlog,phase:2,t:none,t:lowercase,t:replaceNulls,t:compressWhitespace"<br />
Include modsecurity.paranoid.rules.d/15_asl_paranoid_rules.conf<br />
</pre><br />
<br />
You must load these rules last.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
==== Using the paranoid rules ====<br />
<br />
If you want to use the paranoid rules because you have found a vulnerability in your application that the normal rules do not block, please let us know, we would be happy to take a look at either creating a Just In Time Patch for your vulnerability, or adjusting the tuned rules to not allow this. Remember, if you use our real time rules, we provide this service for free. One easy way to find out if you have applications that have unusual vulnerabilities is to scan the application with a web vulnerability application scanner, if you find something the normal rules dont stop just let us know. We'd be delighted to put out new rules for your applications vulnerabilities.<br />
<br />
Finally, if you do you use these rules you will need to set ATOMIC_PARANOID_MODE to 1 in your modsecurity configuration. If you do not know how to do this, we do not recommend you use these rules.<br />
<br />
'''Note: Do not use this ruleset with [[ASL]]. [[ASL]] uses intelligent defense in depth, and does need this kind of ruleset to protect you. You will get a greater level of protection from ASL, without all the false positives.'''<br />
<br />
==== Beta Rules ====<br />
<br />
==== Experimental Rules ====<br />
<br />
<br />
====70_asl_csrf_experimental.conf====<br />
<br />
These are experimental CSRF mitigation rules. The 10_asl_rules.conf rules are designed to also handle some types of CSRF attacks, however these rules are for more advanced environments.<br />
<br />
These rules work by injecting javascript code into the response, and special cookies, and must be tuned for the system to prevent false positives. If you do not understand what this means, do not use these rules.<br />
<br />
'''They are currently not supported and are experimental.'''<br />
<br />
Requires: Modsecurity 2.7.0 and up.</div>Mshinnhttps://wiki.atomicorp.com/wiki/index.php/WAF_rule_familiesWAF rule families2022-10-06T21:19:09Z<p>Mshinn: /* 00_asl_z_searchengines.conf */</p>
<hr />
<div>The Atomicorp/Gotroot rules are broken into families - we recommend you load all the rule families. They work well together, and its safe to use all the rules on a box. We run every rule on our boxes and have been since we first started publishing them over ten years ago.<br />
<br />
====000000000000000000000000_asl_notconfigured.conf====<br />
<br />
'''This rule file should not be used.''' <br />
<br />
This file is a "canary" file included in the archive to prevent users from accidentally loading all the rule files at the same. This ruleset will prevent this condition by disabling the WAF and logging a warning that the installation instructions have not been followed.<br />
<br />
If you are getting any errors about this file and you are using a third party product that installs our rules, please contact the vendor for that product.<br />
<br />
====000_asl_threat_intelligence.conf====<br />
<br />
These rules use the Atomicorp Threat Intelligence system to detect if an IP is a known threat. These rules look for DOS, brute force, spam, known attackers and advanced threats.<br />
<br />
Note: Requires modsecurity 2.7.7 and up.<br />
<br />
====00_asl_x_searchengines.conf====<br />
<br />
'''This ruleset is Deprecated'''<br />
<br />
Note: this is a legacy ruleset and should only be used on platform that do not support lua, and may experience performance issues. Please use 00_asl_z_searchengines.conf instead.<br />
<br />
This ruleset tells the WAF to trust defined search engines, and to not block or shun them.<br />
<br />
<br />
Note: Requires modsecurity 2.7.7 and up.<br />
<br />
====00_asl_y_searchengines.conf ====<br />
<br />
'''This ruleset is Deprecated'''<br />
<br />
Note: this is a legacy ruleset and should only be used on platform that do not support lua, and may experience performance issues. Please use 00_asl_z_searchengines.conf instead.<br />
<br />
''(Available in ASL and the real time rules only)''<br />
<br />
This ruleset detects clients pretending to be a search engine, as well as valid search engines. You must have either [[ASL]] installed, or apache configured with "HostnameLookups Double" and a very fast local DNS server. <br />
<br />
These rules also allow you to auto-whitelist real search engines. To do this, you will need to either use [[ASL]], or you will need to manually set the variable WHITELIST_SEARCH_ENGINES to "1".<br />
<br />
'''Warning: If you do not have either [[ASL]] installed, or apache configured correctly to use these rules they will not work correctly.'''<br />
<br />
Note: If you do not have a fast local DNS server, do not use these rules. These rules perform forward and reverse lookups and require a fast local DNS server, otherwise you should expect your websites to be very slow.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
Excluded: Modsecurity 2.8.0. Because 2.8.0 has a serious bug in the @ipmatch code( https://github.com/SpiderLabs/ModSecurity/issues/706).<br />
<br />
====00_asl_z_searchengines.conf====<br />
<br />
'(Available in ASL and the real time rules only)''<br />
<br />
Note: The rules must be used with a [Local DNS resolver]. If you do not have a fast local DNS server, do not use these rules. These rules perform forward and reverse lookups and require a fast local DNS server. Failure to use a local resolver will result in performance degradation, and these may not work.<br />
<br />
This ruleset detects clients pretending to be a search engine, as well as valid search engines. You must have a very fast local DNS server to use these rules. These rules also allow you to auto-whitelist real search engines. To do this, in the /etc/asl/config set WAF_LUA_00_SEARCHENGINE to "yes"<br />
<br />
For DIY installations, you must install the "advanced" subdirectory in your modsecurity rules directory. If you are manually extracting the rules archive files this should be created for you automatically, and will contain the actual .lua files this config file will load. <br />
<br />
Requires: Modsecurity 2.9.3 and up.<br />
<br />
====00_asl_zz_strict.conf====<br />
<br />
'''Note: Requires modsecurity 2.7.0 and higher.'''<br />
<br />
This enforces strict adherence to the HTTP RFCs.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====00_asl_0_global.conf====<br />
<br />
This is a global variable file, it is only used if you have modsecurity 2.5.13 and above installed. <br />
<br />
====00_asl_rbl.conf====<br />
<br />
This rule family checks an incoming host to see if its on a RBL. By default only the spamhaus XBL-SBL list is enabled which is operated by the Spamhaus project. This RBL is not operated or controlled by Atomicorp. Please contact Spamhaus if you have issues with the IPs on this RBL, or disable this option. Several other RBLs are including in this rule file and must be either enabled in ASL (ASL will generate this rule file) or if you are not running ASL you must manually enable the other RBLs.<br />
<br />
This ruleset will look up every request in the DNS to see if its on a blacklist, and will not finish serving the request until the DNS server responds. This can slow down requests if the DNS server is slow. Basically, web requests will move at the speed of the DNS servers replies.<br />
<br />
If your web server is responding slowly to requests, and you have this ruleset enabled your DNS server is too slow to meet your lookup needs. You will need to either disable this ruleset, or tune your DNS server to respond to queries more quickly.<br />
<br />
''If you use this ruleset, make sure you have a fast locally caching DNS server. This ruleset will query spamhaus for every incoming IP to see if its on a blacklist, if your DNS is slow (or non local) this will make your system seem to crawl, as the read request will be blocked by Apache until it finished the DNS lookup. If you do not have a fast and local DNS server, do not use this ruleset.''<br />
<br />
Requires: Modsecurity 2.6.0 and up.<br />
<br />
====00_asl_blacklist.conf====<br />
<br />
Allows you to blacklist hosts or CIDRs from the WAF.<br />
<br />
Requires: Modsecurity 2.9.0 and up.<br />
<br />
The format is single IPs or CIDRs per line, for example:<br />
<br />
<pre><br />
1.2.3.4<br />
5.6.7.0/24<br />
8.9.0.0/16<br />
</pre><br />
<br />
Note: You must define your own blacklist file. The default location is /etc/asl/blacklist. <br />
<br />
====00_asl_whitelist.conf====<br />
<br />
Allows you to whitelist hosts from the WAF.<br />
<br />
Requires: Modsecurity 2.9.0 and up.<br />
<br />
The format is single IPs or CIDRs per line, for example:<br />
<br />
<pre><br />
1.2.3.4<br />
5.6.7.0/24<br />
8.9.0.0/16<br />
</pre><br />
<br />
Note: You must define your own whitelist entires. The default location is /etc/asl/whitelist. '''Do not use the whitelist.txt file. It is not used for this rule. We do not provide a default whitelist for these rules.'''<br />
<br />
Note: Requires modsecurity 2.7.7 and up.<br />
<br />
====01_asl_content.conf====<br />
<br />
These rules restrict the server to known content types that the WAF can correctly decipher.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
==== 01_asl_domain_blocks.conf====<br />
<br />
Optional ruleset that allows you to block connections from hosts, based on their DNS hostname and/or domain. This is a user defined list.<br />
<br />
Domains and/or hostnames are stored in this file:<br />
<br />
/etc/asl/custom-domain-blocks<br />
<br />
The format is one entry, per line, for example:<br />
<br />
<pre><br />
example.com<br />
www.hostname.some-tld<br />
</pre><br />
<br />
Note: You must have either [[ASL]] installed, or apache configured with "HostnameLookups Double" and a very fast local DNS server for these rules to work.\<br />
<br />
Note: Requires modsecurity 2.7.7 and up.<br />
<br />
====01_asl_rules_special.conf====<br />
<br />
This ruleset changes the behavior of the WAF for applications that behavior in nonstandard ways. For example, OTRS uses ";" and not "&" for argument separation. You should not use these rules if you do not have OTRS installed on your system.<br />
<br />
If you do not know what this means, you do not need this ruleset.<br />
<br />
Requires: Modsecurity 2.7.0 and up. <br />
<br />
Note: If you get an error regarding SecArgumentSeparator with these rules, your modsecurity configuration is being loaded too late in your Apache stack. Ensure that your modsecurity configuration is loaded first. This has been seen with cpanel when not using [[ASL]]. Please contact your apache vendor for assistance with this issue, or use [[ASL]] which will fix your apache configuration so this error does not occur.<br />
<br />
====03_asl_dos.conf====<br />
<br />
This ruleset protects apache from slow DOS attacks. It is only supported with Apache and requires the installation of the mod_reqtimeout module. The rule is fail safe with Apache, that is if the mod_reqtimeout module is not loaded the rules also will not load into Apache.<br />
<br />
[[ASL]] automatically ensures mod_reqtimeout is installed. If you are a rules only user please contact your Apache vendor for assistance installing this module.<br />
<br />
Note: Requires modsecurity 2.7.7 and up.<br />
<br />
====05_asl_exclude.conf====<br />
<br />
Pre-load rule exclusion list. Turns off rules that need to be disabled early in the process. ASL manages this process automatically.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====00_asl_z_antievasion.conf====<br />
<br />
This is a ruleset to detect attempts to bypass modsecurity itself, through evasion methods for example. Do not use this ruleset unless you are using 2.6.1 and up.<br />
<br />
====05_asl_scanner.conf ====<br />
<br />
Deprecated.<br />
<br />
====06_asl_honeypot.conf ====<br />
<br />
This ruleset lets you define URLs you want to specifically block, for example the URL of an application that may not be installed on the system. This can work as a honeypot of sorts, allowing the system to be configured to treat probes for non-existant applications as attacks. [[ASL]] has a more advanced system that can detect when URLs do not correspond to files on the system, which can be used in place of this ruleset or to augment it.<br />
<br />
For this ruleset to work, populate the honeypot-files.txt file in the same directory as 06_asl_honeypot.conf with one URL per line. For example:<br />
<br />
<br />
<pre><br />
/application/not/installed/on/system<br />
file_name_not_on_system.extension<br />
</pre><br />
<br />
==== 11_asl_rules.conf====<br />
<br />
This ruleset is reserved and is not currently used.<br />
<br />
====10_asl_antimalware.conf====<br />
<br />
Checks payload and RFI contents for known sources of malware and malware payloads and will block them.<br />
<br />
Requires: Modsecurity 2.6.0 and up.<br />
<br />
====09_asl_rules.conf====<br />
<br />
These are supplementation rules to the 10_asl_rules.conf, but only work on 2.6.6 and up installations. Do not use this ruleset unless you are using 2.6.6 and up.<br />
<br />
====10_asl_rules.conf ====<br />
<br />
The main rules, contains all the generic security rules to protect against classes of attacks, such as SQL injection, XSS, code injection, recursion, etc. '''These rules require modsecurity 2.9.1 and above.'''<br />
<br />
Requires: Modsecurity 2.9.1 and up.<br />
<br />
====11_asl_adv_rules.conf====<br />
<br />
These are advanced rules, and '''can only be used with modsecurity 2.7.5 and above.'''<br />
<br />
Requires: Modsecurity 2.7.5 and up.<br />
<br />
====11_asl_data_loss.conf====<br />
<br />
Experimental data leakage rules. Looks for credit card numbers and other potentially sensitive information leaking from the system.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====11_asl_brute_enhanced.conf====<br />
<br />
Requires: Modsecurity 2.9.2 and up.<br />
<br />
These rules are for platforms that do not have either [[ASL]] or Atomic Protector installed. These rules create the collections in modsecurity to block brute force attacks. The defaults are > 5 failures within 60 seconds.<br />
<br />
''Note: These rules are not necessary if the systen has ASL or Atomic Protector installed, and should not be used with ASL or AP.<br />
<br />
''Note 1: These rules will only work if the web server can write to the SecDataDir directory. That directory will contain sqllite databases that modsecurity will create and use to count events, without the collection modsecurity can not maintain state for composite events, like multiple login failures, and these rules will not work.''<br />
<br />
''Note 2: Enable this setting in /etc/asl/config to create the collections:''<br />
<br />
<br />
https://wiki.atomicorp.com/wiki/index.php/Aum_configuration#MODSEC_00_THREAT<br />
<br />
====12_asl_adv_xss_rules.conf====<br />
<br />
'''This ruleset require mod_security 2.9.0 and above.'''<br />
<br />
This is the advanced Cross Site Scripting (XSS) protection rule set. It performs deep level inspections of web requests and responses to look for potential XSS attacks.<br />
<br />
====12_asl_brute.conf====<br />
<br />
'''This ruleset is only available with [[ASL]] or the Real Time Rules.''' <br />
<br />
This ruleset detects authentication failures against all major web applications (Joomla, WordPress, MovableType, Drupal, ModX, ZenCart, OsCommerce, VBulletin, PHPBB and more).<br />
<br />
When used with [[ASL]], fast and "low and slow" brute force attacks can be detected and blocked in real time.<br />
<br />
Requires: Modsecurity 2.6.8 and up. <br />
<br />
'''Note: [[ASL]] is necessary to perform active response to brute force attacks.'''<br />
<br />
====13_asl_brute_enhanced.conf====<br />
<br />
Requires: Modsecurity 2.9.2 and up.<br />
<br />
These rules are for platforms that do not have either [ASL] or Atomic Protector installed. These rules create the collections in modsecurity to block brute force attacks. The defaults are > 10 failures within 60 seconds.<br />
<br />
''Note: These rules are not necessary if the systen has ASL or Atomic Protector installed, and should not be used with ASL or AP.<br />
<br />
Note 1: These rules will only work if the web server can write to the SecDataDir directory. That directory will contain sqllite databases that modsecurity will create and use to count events, without the collection modsecurity can not maintain state for composite events, like multiple login failures, and these rules will not work.''<br />
<br />
====20_asl_useragents.conf====<br />
<br />
Looks for malicious or suspicious user agents and known patterns of malicious activity. These rules require modsecurity 2.7.1 and up.<br />
<br />
Requires: Modsecurity 2.7.1 and up.<br />
<br />
====30_asl_antispam.conf====<br />
<br />
Tuned antispam rules, designed to work with all known blogs, forums, guestbooks, CMS' and other web content management systems that allow users to post content.<br />
<br />
Requires: Modsecurity 2.6.8 and up.<br />
<br />
====30_asl_antispam_advanced.conf====<br />
<br />
(Not released yet) These are advanced spam rules. They require modsecurity 2.7.1 and up.<br />
<br />
Requires: Modsecurity 2.7.1 and up.<br />
<br />
====30_asl_antispam_referrer.conf====<br />
<br />
Rules to block referrer spam. Generally not needed in most environments if you protect web log generation tools from public access (which is the default for most control panels).<br />
<br />
Requires: Modsecurity 2.6.0 and up.<br />
<br />
====40_asl_apache2-rules.conf====<br />
<br />
This ruleset has been retired. mod_security 2.x does not work with Apache 1.x and this ruleset existed just for those rules that only worked with apache 2. As mod_security 2.x does not work with Apache 1.x there is no need for this ruleset.<br />
<br />
====50_asl_rootkits.conf====<br />
<br />
Detects and blocks known web based rootkits, PHP/ASP/PERL shells, spam tools and other malicious web applications from being installed, and in some cases from running on the system. These rules exist for cases where malicious software may already be installed on the system, this is a defense in depth rule set)<br />
<br />
Not: ASL can prevent all malware from running on the system, modsecurity is limited in this regard so if you are only using the rules you should not expect modsecurity to prevent malware from running. It may prevent it in some cases, but without kernel level protection such as that provided in [[ASL]] no WAF can stop all malware from running on the system itself.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====51_asl_rootkits.conf====<br />
<br />
These rules look for known malware names in filenames, and URLs.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====60_asl_recons.conf====<br />
<br />
Blocks known "google hacks" or webserver probes that look for vulnerable applications and signs of compromised systems running unauthorized shells, or unprotected applications that allow uploads which would give an attacker access to the system.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====61_asl_recons_dlp.conf====<br />
<br />
These rules detect Data Loss Search engine "hacks". These are search engine probes for sensitive files, often used by malicious parties to find sensitive information accidentally exposed on web servers.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====99_asl_a_redactor.conf====<br />
<br />
ASL only rule set. Requires modsecurity 2.6.0 and up. Part of the malicious code removal system. Automatically removes malicious code from web pages, such as hidden iframes, encoded javascript and other malicious code. '''Do not enable this ruleset if you are not using ASL. ''' <br />
<br />
====99_asl_exclude.conf====<br />
<br />
Post exclude rules.<br />
<br />
====98_asl_adv_redactor.conf====<br />
<br />
This is the new advanced malware removal system. This ruleset will remove malware "on the fly" from web pages. For example, it will remove hidden iframes, malicous javascript, and other malicious code.<br />
<br />
'''Requires: modsecurity 2.7.5 and up.'''<br />
<br />
====98_asl_jitp.conf====<br />
<br />
This is a special ruleset used by [[ASL]]. If you do not have [[ASL]] you can not use these rules.<br />
<br />
====99_asl_jitp.conf====<br />
<br />
Just in Time Patches. We publish JITPs daily if there is a new web application vulnerability that the 10_asl_rules.conf do not protect the system against. These are tuned rules for specific vulnerabilities in a web application.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====99_asl_a_redactor.conf====<br />
<br />
This ruleset is reserved, and is not currently used.<br />
<br />
====99_asl_redactor.conf====<br />
<br />
'''Note: Do not enable this ruleset unless you have been instructed to do so by support.'''<br />
<br />
Special ruleset - requires mod_sed to be loaded on the system which is included and supported in [[ASL]] - removes malicious code from web pages, such as hidden iframes, encoded javascript and other malicious code. We highly recommend you use this rule set - its fast, multithreads and will automagically remove malicious code from infected webpages, which can occur if an adversary is able to log into the system and modify the code, such as by SSH or by uploading the code via FTP. If you are not using [[ASL]] then you will need to make sure your system has mod_sed installed to use these rules, they will not load and therefore will not do anything without mod_sed installed. This ruleset is only supported with [[ASL]].<br />
<br />
====99_asl_redactor_post.conf====<br />
<br />
This ruleset detects malicious content in webpages, such as known malicious domains.<br />
<br />
====99_asl_scanner.conf====<br />
<br />
This is the same as 05_asl_scanner.conf, its provided in a form to run last. This is the recommended location for the scanner function, as the rules before this stop some attacks that the scanner also detects, but do this in a faster and less CPU intensive manner. Running the scanner last does not compromise or lower the effectiveness of the rules. This is just a performance enhancement. This ruleset is only supported with [[ASL]].<br />
<br />
====99_asl_z_adv_scanner.conf====<br />
<br />
'''Note: Requires [[ASL]] and modsecurity 2.9.0 and higher.'''<br />
<br />
This ruleset uses a fuzzy hash to identify potentially malicious files.<br />
<br />
Warning: This ruleset is not supported on non-ASL systems. Do not use this without ASL.<br />
<br />
==== Paranoid mode rules ====<br />
<br />
===== 15_asl_paranoid_rules.conf =====<br />
<br />
'''Note: Do not use these rules if you have not read this section.'''<br />
<br />
'''Please do not report false positives with these rules. If you encounter a false positive with a rule from this file, please use its duplicate in 10_asl_rules.conf instead. If you have a false positive with a rule from 10_asl_rules.conf, please report it to us.'''<br />
<br />
These are a special version of the 10_asl_rules.conf file, they use the same rule id:s as the 10_asl_rules.conf file. Therefore, you can not use these rules along with the 10_asl_rules.conf file. You can use one, or the other, but not both.<br />
<br />
These rules are a paranoid replacement for the 10_asl_rules.conf file. These rules do not contain any known safe mode application tuning exceptions or bypasses. These rules will generate false positives. These rules are made available for users that wish to tune their own rules, and do not wish to use a ruleset that has been tuned for false positives.<br />
<br />
For example, if you had a application that safely used the argument "url" to accept URLs:<br />
<br />
GET /application?url=http://www.example.com/safething<br />
<br />
The normal rules would allow this, if this was known to be safe for the application. <br />
<br />
The paranoid rules, however, will NOT allow this, even if this is known to be safe for the application. They will alert, and if configured (or misconfigured) also block this as an RFI attack. These rules will alert on things that may be safe or are known to be non-malicious. This will generate a lot of false positives for most users, therefore you should not use these rules if you do not want to experience a high degree of false positives. These rules exist for paranoid users, who may want to tune the rules themselves, or may wish to know about every possible potentially malicious event, even when the event may in fact not be malicious.<br />
<br />
We do not recommend you use these rules in blocking mode, instead you should use these only in detect mode, and only if you feel that your applications are doing things in a very unsafe manner. If you do wish to use these rules, make sure that you load them from a special file so you can set the default behaviour of the rules. If you do not do this, the rules will inherit you systems default behavior, which is generally to block.<br />
<br />
Example configuration lines for the paranoid rules:<br />
<br />
<pre><br />
SecDefaultAction "log,pass,auditlog,phase:2,t:none,t:lowercase,t:replaceNulls,t:compressWhitespace"<br />
Include modsecurity.paranoid.rules.d/15_asl_paranoid_rules.conf<br />
</pre><br />
<br />
You must load these rules last.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
==== Using the paranoid rules ====<br />
<br />
If you want to use the paranoid rules because you have found a vulnerability in your application that the normal rules do not block, please let us know, we would be happy to take a look at either creating a Just In Time Patch for your vulnerability, or adjusting the tuned rules to not allow this. Remember, if you use our real time rules, we provide this service for free. One easy way to find out if you have applications that have unusual vulnerabilities is to scan the application with a web vulnerability application scanner, if you find something the normal rules dont stop just let us know. We'd be delighted to put out new rules for your applications vulnerabilities.<br />
<br />
Finally, if you do you use these rules you will need to set ATOMIC_PARANOID_MODE to 1 in your modsecurity configuration. If you do not know how to do this, we do not recommend you use these rules.<br />
<br />
'''Note: Do not use this ruleset with [[ASL]]. [[ASL]] uses intelligent defense in depth, and does need this kind of ruleset to protect you. You will get a greater level of protection from ASL, without all the false positives.'''<br />
<br />
==== Beta Rules ====<br />
<br />
==== Experimental Rules ====<br />
<br />
<br />
====70_asl_csrf_experimental.conf====<br />
<br />
These are experimental CSRF mitigation rules. The 10_asl_rules.conf rules are designed to also handle some types of CSRF attacks, however these rules are for more advanced environments.<br />
<br />
These rules work by injecting javascript code into the response, and special cookies, and must be tuned for the system to prevent false positives. If you do not understand what this means, do not use these rules.<br />
<br />
'''They are currently not supported and are experimental.'''<br />
<br />
Requires: Modsecurity 2.7.0 and up.</div>Mshinnhttps://wiki.atomicorp.com/wiki/index.php/WAF_rule_familiesWAF rule families2022-10-06T21:17:55Z<p>Mshinn: /* 00_asl_z_searchengines.conf */</p>
<hr />
<div>The Atomicorp/Gotroot rules are broken into families - we recommend you load all the rule families. They work well together, and its safe to use all the rules on a box. We run every rule on our boxes and have been since we first started publishing them over ten years ago.<br />
<br />
====000000000000000000000000_asl_notconfigured.conf====<br />
<br />
'''This rule file should not be used.''' <br />
<br />
This file is a "canary" file included in the archive to prevent users from accidentally loading all the rule files at the same. This ruleset will prevent this condition by disabling the WAF and logging a warning that the installation instructions have not been followed.<br />
<br />
If you are getting any errors about this file and you are using a third party product that installs our rules, please contact the vendor for that product.<br />
<br />
====000_asl_threat_intelligence.conf====<br />
<br />
These rules use the Atomicorp Threat Intelligence system to detect if an IP is a known threat. These rules look for DOS, brute force, spam, known attackers and advanced threats.<br />
<br />
Note: Requires modsecurity 2.7.7 and up.<br />
<br />
====00_asl_x_searchengines.conf====<br />
<br />
'''This ruleset is Deprecated'''<br />
<br />
Note: this is a legacy ruleset and should only be used on platform that do not support lua, and may experience performance issues. Please use 00_asl_z_searchengines.conf instead.<br />
<br />
This ruleset tells the WAF to trust defined search engines, and to not block or shun them.<br />
<br />
<br />
Note: Requires modsecurity 2.7.7 and up.<br />
<br />
====00_asl_y_searchengines.conf ====<br />
<br />
'''This ruleset is Deprecated'''<br />
<br />
Note: this is a legacy ruleset and should only be used on platform that do not support lua, and may experience performance issues. Please use 00_asl_z_searchengines.conf instead.<br />
<br />
''(Available in ASL and the real time rules only)''<br />
<br />
This ruleset detects clients pretending to be a search engine, as well as valid search engines. You must have either [[ASL]] installed, or apache configured with "HostnameLookups Double" and a very fast local DNS server. <br />
<br />
These rules also allow you to auto-whitelist real search engines. To do this, you will need to either use [[ASL]], or you will need to manually set the variable WHITELIST_SEARCH_ENGINES to "1".<br />
<br />
'''Warning: If you do not have either [[ASL]] installed, or apache configured correctly to use these rules they will not work correctly.'''<br />
<br />
Note: If you do not have a fast local DNS server, do not use these rules. These rules perform forward and reverse lookups and require a fast local DNS server, otherwise you should expect your websites to be very slow.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
Excluded: Modsecurity 2.8.0. Because 2.8.0 has a serious bug in the @ipmatch code( https://github.com/SpiderLabs/ModSecurity/issues/706).<br />
<br />
====00_asl_z_searchengines.conf====<br />
<br />
'(Available in ASL and the real time rules only)''<br />
<br />
Note: If you do not have a fast local DNS server, do not use these rules. These rules perform forward and reverse lookups and require a fast local DNS server, otherwise you should expect your websites to be very slow.<br />
<br />
This ruleset detects clients pretending to be a search engine, as well as valid search engines. You must have a very fast local DNS server to use these rules. These rules also allow you to auto-whitelist real search engines. To do this, in the /etc/asl/config set WAF_LUA_00_SEARCHENGINE to "yes"<br />
<br />
For DIY installations, you must install the "advanced" subdirectory in your modsecurity rules directory. If you are manually extracting the rules archive files this should be created for you automatically, and will contain the actual .lua files this config file will load. <br />
<br />
Requires: Modsecurity 2.9.3 and up.<br />
<br />
====00_asl_zz_strict.conf====<br />
<br />
'''Note: Requires modsecurity 2.7.0 and higher.'''<br />
<br />
This enforces strict adherence to the HTTP RFCs.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====00_asl_0_global.conf====<br />
<br />
This is a global variable file, it is only used if you have modsecurity 2.5.13 and above installed. <br />
<br />
====00_asl_rbl.conf====<br />
<br />
This rule family checks an incoming host to see if its on a RBL. By default only the spamhaus XBL-SBL list is enabled which is operated by the Spamhaus project. This RBL is not operated or controlled by Atomicorp. Please contact Spamhaus if you have issues with the IPs on this RBL, or disable this option. Several other RBLs are including in this rule file and must be either enabled in ASL (ASL will generate this rule file) or if you are not running ASL you must manually enable the other RBLs.<br />
<br />
This ruleset will look up every request in the DNS to see if its on a blacklist, and will not finish serving the request until the DNS server responds. This can slow down requests if the DNS server is slow. Basically, web requests will move at the speed of the DNS servers replies.<br />
<br />
If your web server is responding slowly to requests, and you have this ruleset enabled your DNS server is too slow to meet your lookup needs. You will need to either disable this ruleset, or tune your DNS server to respond to queries more quickly.<br />
<br />
''If you use this ruleset, make sure you have a fast locally caching DNS server. This ruleset will query spamhaus for every incoming IP to see if its on a blacklist, if your DNS is slow (or non local) this will make your system seem to crawl, as the read request will be blocked by Apache until it finished the DNS lookup. If you do not have a fast and local DNS server, do not use this ruleset.''<br />
<br />
Requires: Modsecurity 2.6.0 and up.<br />
<br />
====00_asl_blacklist.conf====<br />
<br />
Allows you to blacklist hosts or CIDRs from the WAF.<br />
<br />
Requires: Modsecurity 2.9.0 and up.<br />
<br />
The format is single IPs or CIDRs per line, for example:<br />
<br />
<pre><br />
1.2.3.4<br />
5.6.7.0/24<br />
8.9.0.0/16<br />
</pre><br />
<br />
Note: You must define your own blacklist file. The default location is /etc/asl/blacklist. <br />
<br />
====00_asl_whitelist.conf====<br />
<br />
Allows you to whitelist hosts from the WAF.<br />
<br />
Requires: Modsecurity 2.9.0 and up.<br />
<br />
The format is single IPs or CIDRs per line, for example:<br />
<br />
<pre><br />
1.2.3.4<br />
5.6.7.0/24<br />
8.9.0.0/16<br />
</pre><br />
<br />
Note: You must define your own whitelist entires. The default location is /etc/asl/whitelist. '''Do not use the whitelist.txt file. It is not used for this rule. We do not provide a default whitelist for these rules.'''<br />
<br />
Note: Requires modsecurity 2.7.7 and up.<br />
<br />
====01_asl_content.conf====<br />
<br />
These rules restrict the server to known content types that the WAF can correctly decipher.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
==== 01_asl_domain_blocks.conf====<br />
<br />
Optional ruleset that allows you to block connections from hosts, based on their DNS hostname and/or domain. This is a user defined list.<br />
<br />
Domains and/or hostnames are stored in this file:<br />
<br />
/etc/asl/custom-domain-blocks<br />
<br />
The format is one entry, per line, for example:<br />
<br />
<pre><br />
example.com<br />
www.hostname.some-tld<br />
</pre><br />
<br />
Note: You must have either [[ASL]] installed, or apache configured with "HostnameLookups Double" and a very fast local DNS server for these rules to work.\<br />
<br />
Note: Requires modsecurity 2.7.7 and up.<br />
<br />
====01_asl_rules_special.conf====<br />
<br />
This ruleset changes the behavior of the WAF for applications that behavior in nonstandard ways. For example, OTRS uses ";" and not "&" for argument separation. You should not use these rules if you do not have OTRS installed on your system.<br />
<br />
If you do not know what this means, you do not need this ruleset.<br />
<br />
Requires: Modsecurity 2.7.0 and up. <br />
<br />
Note: If you get an error regarding SecArgumentSeparator with these rules, your modsecurity configuration is being loaded too late in your Apache stack. Ensure that your modsecurity configuration is loaded first. This has been seen with cpanel when not using [[ASL]]. Please contact your apache vendor for assistance with this issue, or use [[ASL]] which will fix your apache configuration so this error does not occur.<br />
<br />
====03_asl_dos.conf====<br />
<br />
This ruleset protects apache from slow DOS attacks. It is only supported with Apache and requires the installation of the mod_reqtimeout module. The rule is fail safe with Apache, that is if the mod_reqtimeout module is not loaded the rules also will not load into Apache.<br />
<br />
[[ASL]] automatically ensures mod_reqtimeout is installed. If you are a rules only user please contact your Apache vendor for assistance installing this module.<br />
<br />
Note: Requires modsecurity 2.7.7 and up.<br />
<br />
====05_asl_exclude.conf====<br />
<br />
Pre-load rule exclusion list. Turns off rules that need to be disabled early in the process. ASL manages this process automatically.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====00_asl_z_antievasion.conf====<br />
<br />
This is a ruleset to detect attempts to bypass modsecurity itself, through evasion methods for example. Do not use this ruleset unless you are using 2.6.1 and up.<br />
<br />
====05_asl_scanner.conf ====<br />
<br />
Deprecated.<br />
<br />
====06_asl_honeypot.conf ====<br />
<br />
This ruleset lets you define URLs you want to specifically block, for example the URL of an application that may not be installed on the system. This can work as a honeypot of sorts, allowing the system to be configured to treat probes for non-existant applications as attacks. [[ASL]] has a more advanced system that can detect when URLs do not correspond to files on the system, which can be used in place of this ruleset or to augment it.<br />
<br />
For this ruleset to work, populate the honeypot-files.txt file in the same directory as 06_asl_honeypot.conf with one URL per line. For example:<br />
<br />
<br />
<pre><br />
/application/not/installed/on/system<br />
file_name_not_on_system.extension<br />
</pre><br />
<br />
==== 11_asl_rules.conf====<br />
<br />
This ruleset is reserved and is not currently used.<br />
<br />
====10_asl_antimalware.conf====<br />
<br />
Checks payload and RFI contents for known sources of malware and malware payloads and will block them.<br />
<br />
Requires: Modsecurity 2.6.0 and up.<br />
<br />
====09_asl_rules.conf====<br />
<br />
These are supplementation rules to the 10_asl_rules.conf, but only work on 2.6.6 and up installations. Do not use this ruleset unless you are using 2.6.6 and up.<br />
<br />
====10_asl_rules.conf ====<br />
<br />
The main rules, contains all the generic security rules to protect against classes of attacks, such as SQL injection, XSS, code injection, recursion, etc. '''These rules require modsecurity 2.9.1 and above.'''<br />
<br />
Requires: Modsecurity 2.9.1 and up.<br />
<br />
====11_asl_adv_rules.conf====<br />
<br />
These are advanced rules, and '''can only be used with modsecurity 2.7.5 and above.'''<br />
<br />
Requires: Modsecurity 2.7.5 and up.<br />
<br />
====11_asl_data_loss.conf====<br />
<br />
Experimental data leakage rules. Looks for credit card numbers and other potentially sensitive information leaking from the system.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====11_asl_brute_enhanced.conf====<br />
<br />
Requires: Modsecurity 2.9.2 and up.<br />
<br />
These rules are for platforms that do not have either [[ASL]] or Atomic Protector installed. These rules create the collections in modsecurity to block brute force attacks. The defaults are > 5 failures within 60 seconds.<br />
<br />
''Note: These rules are not necessary if the systen has ASL or Atomic Protector installed, and should not be used with ASL or AP.<br />
<br />
''Note 1: These rules will only work if the web server can write to the SecDataDir directory. That directory will contain sqllite databases that modsecurity will create and use to count events, without the collection modsecurity can not maintain state for composite events, like multiple login failures, and these rules will not work.''<br />
<br />
''Note 2: Enable this setting in /etc/asl/config to create the collections:''<br />
<br />
<br />
https://wiki.atomicorp.com/wiki/index.php/Aum_configuration#MODSEC_00_THREAT<br />
<br />
====12_asl_adv_xss_rules.conf====<br />
<br />
'''This ruleset require mod_security 2.9.0 and above.'''<br />
<br />
This is the advanced Cross Site Scripting (XSS) protection rule set. It performs deep level inspections of web requests and responses to look for potential XSS attacks.<br />
<br />
====12_asl_brute.conf====<br />
<br />
'''This ruleset is only available with [[ASL]] or the Real Time Rules.''' <br />
<br />
This ruleset detects authentication failures against all major web applications (Joomla, WordPress, MovableType, Drupal, ModX, ZenCart, OsCommerce, VBulletin, PHPBB and more).<br />
<br />
When used with [[ASL]], fast and "low and slow" brute force attacks can be detected and blocked in real time.<br />
<br />
Requires: Modsecurity 2.6.8 and up. <br />
<br />
'''Note: [[ASL]] is necessary to perform active response to brute force attacks.'''<br />
<br />
====13_asl_brute_enhanced.conf====<br />
<br />
Requires: Modsecurity 2.9.2 and up.<br />
<br />
These rules are for platforms that do not have either [ASL] or Atomic Protector installed. These rules create the collections in modsecurity to block brute force attacks. The defaults are > 10 failures within 60 seconds.<br />
<br />
''Note: These rules are not necessary if the systen has ASL or Atomic Protector installed, and should not be used with ASL or AP.<br />
<br />
Note 1: These rules will only work if the web server can write to the SecDataDir directory. That directory will contain sqllite databases that modsecurity will create and use to count events, without the collection modsecurity can not maintain state for composite events, like multiple login failures, and these rules will not work.''<br />
<br />
====20_asl_useragents.conf====<br />
<br />
Looks for malicious or suspicious user agents and known patterns of malicious activity. These rules require modsecurity 2.7.1 and up.<br />
<br />
Requires: Modsecurity 2.7.1 and up.<br />
<br />
====30_asl_antispam.conf====<br />
<br />
Tuned antispam rules, designed to work with all known blogs, forums, guestbooks, CMS' and other web content management systems that allow users to post content.<br />
<br />
Requires: Modsecurity 2.6.8 and up.<br />
<br />
====30_asl_antispam_advanced.conf====<br />
<br />
(Not released yet) These are advanced spam rules. They require modsecurity 2.7.1 and up.<br />
<br />
Requires: Modsecurity 2.7.1 and up.<br />
<br />
====30_asl_antispam_referrer.conf====<br />
<br />
Rules to block referrer spam. Generally not needed in most environments if you protect web log generation tools from public access (which is the default for most control panels).<br />
<br />
Requires: Modsecurity 2.6.0 and up.<br />
<br />
====40_asl_apache2-rules.conf====<br />
<br />
This ruleset has been retired. mod_security 2.x does not work with Apache 1.x and this ruleset existed just for those rules that only worked with apache 2. As mod_security 2.x does not work with Apache 1.x there is no need for this ruleset.<br />
<br />
====50_asl_rootkits.conf====<br />
<br />
Detects and blocks known web based rootkits, PHP/ASP/PERL shells, spam tools and other malicious web applications from being installed, and in some cases from running on the system. These rules exist for cases where malicious software may already be installed on the system, this is a defense in depth rule set)<br />
<br />
Not: ASL can prevent all malware from running on the system, modsecurity is limited in this regard so if you are only using the rules you should not expect modsecurity to prevent malware from running. It may prevent it in some cases, but without kernel level protection such as that provided in [[ASL]] no WAF can stop all malware from running on the system itself.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====51_asl_rootkits.conf====<br />
<br />
These rules look for known malware names in filenames, and URLs.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====60_asl_recons.conf====<br />
<br />
Blocks known "google hacks" or webserver probes that look for vulnerable applications and signs of compromised systems running unauthorized shells, or unprotected applications that allow uploads which would give an attacker access to the system.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====61_asl_recons_dlp.conf====<br />
<br />
These rules detect Data Loss Search engine "hacks". These are search engine probes for sensitive files, often used by malicious parties to find sensitive information accidentally exposed on web servers.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====99_asl_a_redactor.conf====<br />
<br />
ASL only rule set. Requires modsecurity 2.6.0 and up. Part of the malicious code removal system. Automatically removes malicious code from web pages, such as hidden iframes, encoded javascript and other malicious code. '''Do not enable this ruleset if you are not using ASL. ''' <br />
<br />
====99_asl_exclude.conf====<br />
<br />
Post exclude rules.<br />
<br />
====98_asl_adv_redactor.conf====<br />
<br />
This is the new advanced malware removal system. This ruleset will remove malware "on the fly" from web pages. For example, it will remove hidden iframes, malicous javascript, and other malicious code.<br />
<br />
'''Requires: modsecurity 2.7.5 and up.'''<br />
<br />
====98_asl_jitp.conf====<br />
<br />
This is a special ruleset used by [[ASL]]. If you do not have [[ASL]] you can not use these rules.<br />
<br />
====99_asl_jitp.conf====<br />
<br />
Just in Time Patches. We publish JITPs daily if there is a new web application vulnerability that the 10_asl_rules.conf do not protect the system against. These are tuned rules for specific vulnerabilities in a web application.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====99_asl_a_redactor.conf====<br />
<br />
This ruleset is reserved, and is not currently used.<br />
<br />
====99_asl_redactor.conf====<br />
<br />
'''Note: Do not enable this ruleset unless you have been instructed to do so by support.'''<br />
<br />
Special ruleset - requires mod_sed to be loaded on the system which is included and supported in [[ASL]] - removes malicious code from web pages, such as hidden iframes, encoded javascript and other malicious code. We highly recommend you use this rule set - its fast, multithreads and will automagically remove malicious code from infected webpages, which can occur if an adversary is able to log into the system and modify the code, such as by SSH or by uploading the code via FTP. If you are not using [[ASL]] then you will need to make sure your system has mod_sed installed to use these rules, they will not load and therefore will not do anything without mod_sed installed. This ruleset is only supported with [[ASL]].<br />
<br />
====99_asl_redactor_post.conf====<br />
<br />
This ruleset detects malicious content in webpages, such as known malicious domains.<br />
<br />
====99_asl_scanner.conf====<br />
<br />
This is the same as 05_asl_scanner.conf, its provided in a form to run last. This is the recommended location for the scanner function, as the rules before this stop some attacks that the scanner also detects, but do this in a faster and less CPU intensive manner. Running the scanner last does not compromise or lower the effectiveness of the rules. This is just a performance enhancement. This ruleset is only supported with [[ASL]].<br />
<br />
====99_asl_z_adv_scanner.conf====<br />
<br />
'''Note: Requires [[ASL]] and modsecurity 2.9.0 and higher.'''<br />
<br />
This ruleset uses a fuzzy hash to identify potentially malicious files.<br />
<br />
Warning: This ruleset is not supported on non-ASL systems. Do not use this without ASL.<br />
<br />
==== Paranoid mode rules ====<br />
<br />
===== 15_asl_paranoid_rules.conf =====<br />
<br />
'''Note: Do not use these rules if you have not read this section.'''<br />
<br />
'''Please do not report false positives with these rules. If you encounter a false positive with a rule from this file, please use its duplicate in 10_asl_rules.conf instead. If you have a false positive with a rule from 10_asl_rules.conf, please report it to us.'''<br />
<br />
These are a special version of the 10_asl_rules.conf file, they use the same rule id:s as the 10_asl_rules.conf file. Therefore, you can not use these rules along with the 10_asl_rules.conf file. You can use one, or the other, but not both.<br />
<br />
These rules are a paranoid replacement for the 10_asl_rules.conf file. These rules do not contain any known safe mode application tuning exceptions or bypasses. These rules will generate false positives. These rules are made available for users that wish to tune their own rules, and do not wish to use a ruleset that has been tuned for false positives.<br />
<br />
For example, if you had a application that safely used the argument "url" to accept URLs:<br />
<br />
GET /application?url=http://www.example.com/safething<br />
<br />
The normal rules would allow this, if this was known to be safe for the application. <br />
<br />
The paranoid rules, however, will NOT allow this, even if this is known to be safe for the application. They will alert, and if configured (or misconfigured) also block this as an RFI attack. These rules will alert on things that may be safe or are known to be non-malicious. This will generate a lot of false positives for most users, therefore you should not use these rules if you do not want to experience a high degree of false positives. These rules exist for paranoid users, who may want to tune the rules themselves, or may wish to know about every possible potentially malicious event, even when the event may in fact not be malicious.<br />
<br />
We do not recommend you use these rules in blocking mode, instead you should use these only in detect mode, and only if you feel that your applications are doing things in a very unsafe manner. If you do wish to use these rules, make sure that you load them from a special file so you can set the default behaviour of the rules. If you do not do this, the rules will inherit you systems default behavior, which is generally to block.<br />
<br />
Example configuration lines for the paranoid rules:<br />
<br />
<pre><br />
SecDefaultAction "log,pass,auditlog,phase:2,t:none,t:lowercase,t:replaceNulls,t:compressWhitespace"<br />
Include modsecurity.paranoid.rules.d/15_asl_paranoid_rules.conf<br />
</pre><br />
<br />
You must load these rules last.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
==== Using the paranoid rules ====<br />
<br />
If you want to use the paranoid rules because you have found a vulnerability in your application that the normal rules do not block, please let us know, we would be happy to take a look at either creating a Just In Time Patch for your vulnerability, or adjusting the tuned rules to not allow this. Remember, if you use our real time rules, we provide this service for free. One easy way to find out if you have applications that have unusual vulnerabilities is to scan the application with a web vulnerability application scanner, if you find something the normal rules dont stop just let us know. We'd be delighted to put out new rules for your applications vulnerabilities.<br />
<br />
Finally, if you do you use these rules you will need to set ATOMIC_PARANOID_MODE to 1 in your modsecurity configuration. If you do not know how to do this, we do not recommend you use these rules.<br />
<br />
'''Note: Do not use this ruleset with [[ASL]]. [[ASL]] uses intelligent defense in depth, and does need this kind of ruleset to protect you. You will get a greater level of protection from ASL, without all the false positives.'''<br />
<br />
==== Beta Rules ====<br />
<br />
==== Experimental Rules ====<br />
<br />
<br />
====70_asl_csrf_experimental.conf====<br />
<br />
These are experimental CSRF mitigation rules. The 10_asl_rules.conf rules are designed to also handle some types of CSRF attacks, however these rules are for more advanced environments.<br />
<br />
These rules work by injecting javascript code into the response, and special cookies, and must be tuned for the system to prevent false positives. If you do not understand what this means, do not use these rules.<br />
<br />
'''They are currently not supported and are experimental.'''<br />
<br />
Requires: Modsecurity 2.7.0 and up.</div>Mshinnhttps://wiki.atomicorp.com/wiki/index.php/WAF_rule_familiesWAF rule families2022-10-06T21:13:52Z<p>Mshinn: /* 00_asl_x_searchengines.conf */</p>
<hr />
<div>The Atomicorp/Gotroot rules are broken into families - we recommend you load all the rule families. They work well together, and its safe to use all the rules on a box. We run every rule on our boxes and have been since we first started publishing them over ten years ago.<br />
<br />
====000000000000000000000000_asl_notconfigured.conf====<br />
<br />
'''This rule file should not be used.''' <br />
<br />
This file is a "canary" file included in the archive to prevent users from accidentally loading all the rule files at the same. This ruleset will prevent this condition by disabling the WAF and logging a warning that the installation instructions have not been followed.<br />
<br />
If you are getting any errors about this file and you are using a third party product that installs our rules, please contact the vendor for that product.<br />
<br />
====000_asl_threat_intelligence.conf====<br />
<br />
These rules use the Atomicorp Threat Intelligence system to detect if an IP is a known threat. These rules look for DOS, brute force, spam, known attackers and advanced threats.<br />
<br />
Note: Requires modsecurity 2.7.7 and up.<br />
<br />
====00_asl_x_searchengines.conf====<br />
<br />
'''This ruleset is Deprecated'''<br />
<br />
Note: this is a legacy ruleset and should only be used on platform that do not support lua, and may experience performance issues. Please use 00_asl_z_searchengines.conf instead.<br />
<br />
This ruleset tells the WAF to trust defined search engines, and to not block or shun them.<br />
<br />
<br />
Note: Requires modsecurity 2.7.7 and up.<br />
<br />
====00_asl_y_searchengines.conf ====<br />
<br />
'''This ruleset is Deprecated'''<br />
<br />
Note: this is a legacy ruleset and should only be used on platform that do not support lua, and may experience performance issues. Please use 00_asl_z_searchengines.conf instead.<br />
<br />
''(Available in ASL and the real time rules only)''<br />
<br />
This ruleset detects clients pretending to be a search engine, as well as valid search engines. You must have either [[ASL]] installed, or apache configured with "HostnameLookups Double" and a very fast local DNS server. <br />
<br />
These rules also allow you to auto-whitelist real search engines. To do this, you will need to either use [[ASL]], or you will need to manually set the variable WHITELIST_SEARCH_ENGINES to "1".<br />
<br />
'''Warning: If you do not have either [[ASL]] installed, or apache configured correctly to use these rules they will not work correctly.'''<br />
<br />
Note: If you do not have a fast local DNS server, do not use these rules. These rules perform forward and reverse lookups and require a fast local DNS server, otherwise you should expect your websites to be very slow.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
Excluded: Modsecurity 2.8.0. Because 2.8.0 has a serious bug in the @ipmatch code( https://github.com/SpiderLabs/ModSecurity/issues/706).<br />
<br />
====00_asl_z_searchengines.conf====<br />
<br />
'(Available in ASL and the real time rules only)''<br />
<br />
This ruleset detects clients pretending to be a search engine, as well as valid search engines. You must have either [[ASL]] installed, or apache configured with "HostnameLookups Double" and a very fast local DNS server. <br />
<br />
These rules also allow you to auto-whitelist real search engines. To do this, you will need to either use [[ASL]], or you will need to manually set the variable WHITELIST_SEARCH_ENGINES to "1".<br />
<br />
'''Warning: If you do not have either [[ASL]] installed, or apache configured correctly to use these rules they will not work correctly.'''<br />
<br />
Note: If you do not have a fast local DNS server, do not use these rules. These rules perform forward and reverse lookups and require a fast local DNS server, otherwise you should expect your websites to be very slow.<br />
<br />
Requires: Modsecurity 2.9.3 and up.<br />
<br />
====00_asl_zz_strict.conf====<br />
<br />
'''Note: Requires modsecurity 2.7.0 and higher.'''<br />
<br />
This enforces strict adherence to the HTTP RFCs.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====00_asl_0_global.conf====<br />
<br />
This is a global variable file, it is only used if you have modsecurity 2.5.13 and above installed. <br />
<br />
====00_asl_rbl.conf====<br />
<br />
This rule family checks an incoming host to see if its on a RBL. By default only the spamhaus XBL-SBL list is enabled which is operated by the Spamhaus project. This RBL is not operated or controlled by Atomicorp. Please contact Spamhaus if you have issues with the IPs on this RBL, or disable this option. Several other RBLs are including in this rule file and must be either enabled in ASL (ASL will generate this rule file) or if you are not running ASL you must manually enable the other RBLs.<br />
<br />
This ruleset will look up every request in the DNS to see if its on a blacklist, and will not finish serving the request until the DNS server responds. This can slow down requests if the DNS server is slow. Basically, web requests will move at the speed of the DNS servers replies.<br />
<br />
If your web server is responding slowly to requests, and you have this ruleset enabled your DNS server is too slow to meet your lookup needs. You will need to either disable this ruleset, or tune your DNS server to respond to queries more quickly.<br />
<br />
''If you use this ruleset, make sure you have a fast locally caching DNS server. This ruleset will query spamhaus for every incoming IP to see if its on a blacklist, if your DNS is slow (or non local) this will make your system seem to crawl, as the read request will be blocked by Apache until it finished the DNS lookup. If you do not have a fast and local DNS server, do not use this ruleset.''<br />
<br />
Requires: Modsecurity 2.6.0 and up.<br />
<br />
====00_asl_blacklist.conf====<br />
<br />
Allows you to blacklist hosts or CIDRs from the WAF.<br />
<br />
Requires: Modsecurity 2.9.0 and up.<br />
<br />
The format is single IPs or CIDRs per line, for example:<br />
<br />
<pre><br />
1.2.3.4<br />
5.6.7.0/24<br />
8.9.0.0/16<br />
</pre><br />
<br />
Note: You must define your own blacklist file. The default location is /etc/asl/blacklist. <br />
<br />
====00_asl_whitelist.conf====<br />
<br />
Allows you to whitelist hosts from the WAF.<br />
<br />
Requires: Modsecurity 2.9.0 and up.<br />
<br />
The format is single IPs or CIDRs per line, for example:<br />
<br />
<pre><br />
1.2.3.4<br />
5.6.7.0/24<br />
8.9.0.0/16<br />
</pre><br />
<br />
Note: You must define your own whitelist entires. The default location is /etc/asl/whitelist. '''Do not use the whitelist.txt file. It is not used for this rule. We do not provide a default whitelist for these rules.'''<br />
<br />
Note: Requires modsecurity 2.7.7 and up.<br />
<br />
====01_asl_content.conf====<br />
<br />
These rules restrict the server to known content types that the WAF can correctly decipher.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
==== 01_asl_domain_blocks.conf====<br />
<br />
Optional ruleset that allows you to block connections from hosts, based on their DNS hostname and/or domain. This is a user defined list.<br />
<br />
Domains and/or hostnames are stored in this file:<br />
<br />
/etc/asl/custom-domain-blocks<br />
<br />
The format is one entry, per line, for example:<br />
<br />
<pre><br />
example.com<br />
www.hostname.some-tld<br />
</pre><br />
<br />
Note: You must have either [[ASL]] installed, or apache configured with "HostnameLookups Double" and a very fast local DNS server for these rules to work.\<br />
<br />
Note: Requires modsecurity 2.7.7 and up.<br />
<br />
====01_asl_rules_special.conf====<br />
<br />
This ruleset changes the behavior of the WAF for applications that behavior in nonstandard ways. For example, OTRS uses ";" and not "&" for argument separation. You should not use these rules if you do not have OTRS installed on your system.<br />
<br />
If you do not know what this means, you do not need this ruleset.<br />
<br />
Requires: Modsecurity 2.7.0 and up. <br />
<br />
Note: If you get an error regarding SecArgumentSeparator with these rules, your modsecurity configuration is being loaded too late in your Apache stack. Ensure that your modsecurity configuration is loaded first. This has been seen with cpanel when not using [[ASL]]. Please contact your apache vendor for assistance with this issue, or use [[ASL]] which will fix your apache configuration so this error does not occur.<br />
<br />
====03_asl_dos.conf====<br />
<br />
This ruleset protects apache from slow DOS attacks. It is only supported with Apache and requires the installation of the mod_reqtimeout module. The rule is fail safe with Apache, that is if the mod_reqtimeout module is not loaded the rules also will not load into Apache.<br />
<br />
[[ASL]] automatically ensures mod_reqtimeout is installed. If you are a rules only user please contact your Apache vendor for assistance installing this module.<br />
<br />
Note: Requires modsecurity 2.7.7 and up.<br />
<br />
====05_asl_exclude.conf====<br />
<br />
Pre-load rule exclusion list. Turns off rules that need to be disabled early in the process. ASL manages this process automatically.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====00_asl_z_antievasion.conf====<br />
<br />
This is a ruleset to detect attempts to bypass modsecurity itself, through evasion methods for example. Do not use this ruleset unless you are using 2.6.1 and up.<br />
<br />
====05_asl_scanner.conf ====<br />
<br />
Deprecated.<br />
<br />
====06_asl_honeypot.conf ====<br />
<br />
This ruleset lets you define URLs you want to specifically block, for example the URL of an application that may not be installed on the system. This can work as a honeypot of sorts, allowing the system to be configured to treat probes for non-existant applications as attacks. [[ASL]] has a more advanced system that can detect when URLs do not correspond to files on the system, which can be used in place of this ruleset or to augment it.<br />
<br />
For this ruleset to work, populate the honeypot-files.txt file in the same directory as 06_asl_honeypot.conf with one URL per line. For example:<br />
<br />
<br />
<pre><br />
/application/not/installed/on/system<br />
file_name_not_on_system.extension<br />
</pre><br />
<br />
==== 11_asl_rules.conf====<br />
<br />
This ruleset is reserved and is not currently used.<br />
<br />
====10_asl_antimalware.conf====<br />
<br />
Checks payload and RFI contents for known sources of malware and malware payloads and will block them.<br />
<br />
Requires: Modsecurity 2.6.0 and up.<br />
<br />
====09_asl_rules.conf====<br />
<br />
These are supplementation rules to the 10_asl_rules.conf, but only work on 2.6.6 and up installations. Do not use this ruleset unless you are using 2.6.6 and up.<br />
<br />
====10_asl_rules.conf ====<br />
<br />
The main rules, contains all the generic security rules to protect against classes of attacks, such as SQL injection, XSS, code injection, recursion, etc. '''These rules require modsecurity 2.9.1 and above.'''<br />
<br />
Requires: Modsecurity 2.9.1 and up.<br />
<br />
====11_asl_adv_rules.conf====<br />
<br />
These are advanced rules, and '''can only be used with modsecurity 2.7.5 and above.'''<br />
<br />
Requires: Modsecurity 2.7.5 and up.<br />
<br />
====11_asl_data_loss.conf====<br />
<br />
Experimental data leakage rules. Looks for credit card numbers and other potentially sensitive information leaking from the system.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====11_asl_brute_enhanced.conf====<br />
<br />
Requires: Modsecurity 2.9.2 and up.<br />
<br />
These rules are for platforms that do not have either [[ASL]] or Atomic Protector installed. These rules create the collections in modsecurity to block brute force attacks. The defaults are > 5 failures within 60 seconds.<br />
<br />
''Note: These rules are not necessary if the systen has ASL or Atomic Protector installed, and should not be used with ASL or AP.<br />
<br />
''Note 1: These rules will only work if the web server can write to the SecDataDir directory. That directory will contain sqllite databases that modsecurity will create and use to count events, without the collection modsecurity can not maintain state for composite events, like multiple login failures, and these rules will not work.''<br />
<br />
''Note 2: Enable this setting in /etc/asl/config to create the collections:''<br />
<br />
<br />
https://wiki.atomicorp.com/wiki/index.php/Aum_configuration#MODSEC_00_THREAT<br />
<br />
====12_asl_adv_xss_rules.conf====<br />
<br />
'''This ruleset require mod_security 2.9.0 and above.'''<br />
<br />
This is the advanced Cross Site Scripting (XSS) protection rule set. It performs deep level inspections of web requests and responses to look for potential XSS attacks.<br />
<br />
====12_asl_brute.conf====<br />
<br />
'''This ruleset is only available with [[ASL]] or the Real Time Rules.''' <br />
<br />
This ruleset detects authentication failures against all major web applications (Joomla, WordPress, MovableType, Drupal, ModX, ZenCart, OsCommerce, VBulletin, PHPBB and more).<br />
<br />
When used with [[ASL]], fast and "low and slow" brute force attacks can be detected and blocked in real time.<br />
<br />
Requires: Modsecurity 2.6.8 and up. <br />
<br />
'''Note: [[ASL]] is necessary to perform active response to brute force attacks.'''<br />
<br />
====13_asl_brute_enhanced.conf====<br />
<br />
Requires: Modsecurity 2.9.2 and up.<br />
<br />
These rules are for platforms that do not have either [ASL] or Atomic Protector installed. These rules create the collections in modsecurity to block brute force attacks. The defaults are > 10 failures within 60 seconds.<br />
<br />
''Note: These rules are not necessary if the systen has ASL or Atomic Protector installed, and should not be used with ASL or AP.<br />
<br />
Note 1: These rules will only work if the web server can write to the SecDataDir directory. That directory will contain sqllite databases that modsecurity will create and use to count events, without the collection modsecurity can not maintain state for composite events, like multiple login failures, and these rules will not work.''<br />
<br />
====20_asl_useragents.conf====<br />
<br />
Looks for malicious or suspicious user agents and known patterns of malicious activity. These rules require modsecurity 2.7.1 and up.<br />
<br />
Requires: Modsecurity 2.7.1 and up.<br />
<br />
====30_asl_antispam.conf====<br />
<br />
Tuned antispam rules, designed to work with all known blogs, forums, guestbooks, CMS' and other web content management systems that allow users to post content.<br />
<br />
Requires: Modsecurity 2.6.8 and up.<br />
<br />
====30_asl_antispam_advanced.conf====<br />
<br />
(Not released yet) These are advanced spam rules. They require modsecurity 2.7.1 and up.<br />
<br />
Requires: Modsecurity 2.7.1 and up.<br />
<br />
====30_asl_antispam_referrer.conf====<br />
<br />
Rules to block referrer spam. Generally not needed in most environments if you protect web log generation tools from public access (which is the default for most control panels).<br />
<br />
Requires: Modsecurity 2.6.0 and up.<br />
<br />
====40_asl_apache2-rules.conf====<br />
<br />
This ruleset has been retired. mod_security 2.x does not work with Apache 1.x and this ruleset existed just for those rules that only worked with apache 2. As mod_security 2.x does not work with Apache 1.x there is no need for this ruleset.<br />
<br />
====50_asl_rootkits.conf====<br />
<br />
Detects and blocks known web based rootkits, PHP/ASP/PERL shells, spam tools and other malicious web applications from being installed, and in some cases from running on the system. These rules exist for cases where malicious software may already be installed on the system, this is a defense in depth rule set)<br />
<br />
Not: ASL can prevent all malware from running on the system, modsecurity is limited in this regard so if you are only using the rules you should not expect modsecurity to prevent malware from running. It may prevent it in some cases, but without kernel level protection such as that provided in [[ASL]] no WAF can stop all malware from running on the system itself.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====51_asl_rootkits.conf====<br />
<br />
These rules look for known malware names in filenames, and URLs.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====60_asl_recons.conf====<br />
<br />
Blocks known "google hacks" or webserver probes that look for vulnerable applications and signs of compromised systems running unauthorized shells, or unprotected applications that allow uploads which would give an attacker access to the system.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====61_asl_recons_dlp.conf====<br />
<br />
These rules detect Data Loss Search engine "hacks". These are search engine probes for sensitive files, often used by malicious parties to find sensitive information accidentally exposed on web servers.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====99_asl_a_redactor.conf====<br />
<br />
ASL only rule set. Requires modsecurity 2.6.0 and up. Part of the malicious code removal system. Automatically removes malicious code from web pages, such as hidden iframes, encoded javascript and other malicious code. '''Do not enable this ruleset if you are not using ASL. ''' <br />
<br />
====99_asl_exclude.conf====<br />
<br />
Post exclude rules.<br />
<br />
====98_asl_adv_redactor.conf====<br />
<br />
This is the new advanced malware removal system. This ruleset will remove malware "on the fly" from web pages. For example, it will remove hidden iframes, malicous javascript, and other malicious code.<br />
<br />
'''Requires: modsecurity 2.7.5 and up.'''<br />
<br />
====98_asl_jitp.conf====<br />
<br />
This is a special ruleset used by [[ASL]]. If you do not have [[ASL]] you can not use these rules.<br />
<br />
====99_asl_jitp.conf====<br />
<br />
Just in Time Patches. We publish JITPs daily if there is a new web application vulnerability that the 10_asl_rules.conf do not protect the system against. These are tuned rules for specific vulnerabilities in a web application.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====99_asl_a_redactor.conf====<br />
<br />
This ruleset is reserved, and is not currently used.<br />
<br />
====99_asl_redactor.conf====<br />
<br />
'''Note: Do not enable this ruleset unless you have been instructed to do so by support.'''<br />
<br />
Special ruleset - requires mod_sed to be loaded on the system which is included and supported in [[ASL]] - removes malicious code from web pages, such as hidden iframes, encoded javascript and other malicious code. We highly recommend you use this rule set - its fast, multithreads and will automagically remove malicious code from infected webpages, which can occur if an adversary is able to log into the system and modify the code, such as by SSH or by uploading the code via FTP. If you are not using [[ASL]] then you will need to make sure your system has mod_sed installed to use these rules, they will not load and therefore will not do anything without mod_sed installed. This ruleset is only supported with [[ASL]].<br />
<br />
====99_asl_redactor_post.conf====<br />
<br />
This ruleset detects malicious content in webpages, such as known malicious domains.<br />
<br />
====99_asl_scanner.conf====<br />
<br />
This is the same as 05_asl_scanner.conf, its provided in a form to run last. This is the recommended location for the scanner function, as the rules before this stop some attacks that the scanner also detects, but do this in a faster and less CPU intensive manner. Running the scanner last does not compromise or lower the effectiveness of the rules. This is just a performance enhancement. This ruleset is only supported with [[ASL]].<br />
<br />
====99_asl_z_adv_scanner.conf====<br />
<br />
'''Note: Requires [[ASL]] and modsecurity 2.9.0 and higher.'''<br />
<br />
This ruleset uses a fuzzy hash to identify potentially malicious files.<br />
<br />
Warning: This ruleset is not supported on non-ASL systems. Do not use this without ASL.<br />
<br />
==== Paranoid mode rules ====<br />
<br />
===== 15_asl_paranoid_rules.conf =====<br />
<br />
'''Note: Do not use these rules if you have not read this section.'''<br />
<br />
'''Please do not report false positives with these rules. If you encounter a false positive with a rule from this file, please use its duplicate in 10_asl_rules.conf instead. If you have a false positive with a rule from 10_asl_rules.conf, please report it to us.'''<br />
<br />
These are a special version of the 10_asl_rules.conf file, they use the same rule id:s as the 10_asl_rules.conf file. Therefore, you can not use these rules along with the 10_asl_rules.conf file. You can use one, or the other, but not both.<br />
<br />
These rules are a paranoid replacement for the 10_asl_rules.conf file. These rules do not contain any known safe mode application tuning exceptions or bypasses. These rules will generate false positives. These rules are made available for users that wish to tune their own rules, and do not wish to use a ruleset that has been tuned for false positives.<br />
<br />
For example, if you had a application that safely used the argument "url" to accept URLs:<br />
<br />
GET /application?url=http://www.example.com/safething<br />
<br />
The normal rules would allow this, if this was known to be safe for the application. <br />
<br />
The paranoid rules, however, will NOT allow this, even if this is known to be safe for the application. They will alert, and if configured (or misconfigured) also block this as an RFI attack. These rules will alert on things that may be safe or are known to be non-malicious. This will generate a lot of false positives for most users, therefore you should not use these rules if you do not want to experience a high degree of false positives. These rules exist for paranoid users, who may want to tune the rules themselves, or may wish to know about every possible potentially malicious event, even when the event may in fact not be malicious.<br />
<br />
We do not recommend you use these rules in blocking mode, instead you should use these only in detect mode, and only if you feel that your applications are doing things in a very unsafe manner. If you do wish to use these rules, make sure that you load them from a special file so you can set the default behaviour of the rules. If you do not do this, the rules will inherit you systems default behavior, which is generally to block.<br />
<br />
Example configuration lines for the paranoid rules:<br />
<br />
<pre><br />
SecDefaultAction "log,pass,auditlog,phase:2,t:none,t:lowercase,t:replaceNulls,t:compressWhitespace"<br />
Include modsecurity.paranoid.rules.d/15_asl_paranoid_rules.conf<br />
</pre><br />
<br />
You must load these rules last.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
==== Using the paranoid rules ====<br />
<br />
If you want to use the paranoid rules because you have found a vulnerability in your application that the normal rules do not block, please let us know, we would be happy to take a look at either creating a Just In Time Patch for your vulnerability, or adjusting the tuned rules to not allow this. Remember, if you use our real time rules, we provide this service for free. One easy way to find out if you have applications that have unusual vulnerabilities is to scan the application with a web vulnerability application scanner, if you find something the normal rules dont stop just let us know. We'd be delighted to put out new rules for your applications vulnerabilities.<br />
<br />
Finally, if you do you use these rules you will need to set ATOMIC_PARANOID_MODE to 1 in your modsecurity configuration. If you do not know how to do this, we do not recommend you use these rules.<br />
<br />
'''Note: Do not use this ruleset with [[ASL]]. [[ASL]] uses intelligent defense in depth, and does need this kind of ruleset to protect you. You will get a greater level of protection from ASL, without all the false positives.'''<br />
<br />
==== Beta Rules ====<br />
<br />
==== Experimental Rules ====<br />
<br />
<br />
====70_asl_csrf_experimental.conf====<br />
<br />
These are experimental CSRF mitigation rules. The 10_asl_rules.conf rules are designed to also handle some types of CSRF attacks, however these rules are for more advanced environments.<br />
<br />
These rules work by injecting javascript code into the response, and special cookies, and must be tuned for the system to prevent false positives. If you do not understand what this means, do not use these rules.<br />
<br />
'''They are currently not supported and are experimental.'''<br />
<br />
Requires: Modsecurity 2.7.0 and up.</div>Mshinnhttps://wiki.atomicorp.com/wiki/index.php/WAF_rule_familiesWAF rule families2022-10-06T21:13:39Z<p>Mshinn: /* 00_asl_y_searchengines.conf */</p>
<hr />
<div>The Atomicorp/Gotroot rules are broken into families - we recommend you load all the rule families. They work well together, and its safe to use all the rules on a box. We run every rule on our boxes and have been since we first started publishing them over ten years ago.<br />
<br />
====000000000000000000000000_asl_notconfigured.conf====<br />
<br />
'''This rule file should not be used.''' <br />
<br />
This file is a "canary" file included in the archive to prevent users from accidentally loading all the rule files at the same. This ruleset will prevent this condition by disabling the WAF and logging a warning that the installation instructions have not been followed.<br />
<br />
If you are getting any errors about this file and you are using a third party product that installs our rules, please contact the vendor for that product.<br />
<br />
====000_asl_threat_intelligence.conf====<br />
<br />
These rules use the Atomicorp Threat Intelligence system to detect if an IP is a known threat. These rules look for DOS, brute force, spam, known attackers and advanced threats.<br />
<br />
Note: Requires modsecurity 2.7.7 and up.<br />
<br />
====00_asl_x_searchengines.conf====<br />
<br />
This ruleset tells the WAF to trust defined search engines, and to not block or shun them.<br />
<br />
<br />
Note: Requires modsecurity 2.7.7 and up.<br />
<br />
====00_asl_y_searchengines.conf ====<br />
<br />
'''This ruleset is Deprecated'''<br />
<br />
Note: this is a legacy ruleset and should only be used on platform that do not support lua, and may experience performance issues. Please use 00_asl_z_searchengines.conf instead.<br />
<br />
''(Available in ASL and the real time rules only)''<br />
<br />
This ruleset detects clients pretending to be a search engine, as well as valid search engines. You must have either [[ASL]] installed, or apache configured with "HostnameLookups Double" and a very fast local DNS server. <br />
<br />
These rules also allow you to auto-whitelist real search engines. To do this, you will need to either use [[ASL]], or you will need to manually set the variable WHITELIST_SEARCH_ENGINES to "1".<br />
<br />
'''Warning: If you do not have either [[ASL]] installed, or apache configured correctly to use these rules they will not work correctly.'''<br />
<br />
Note: If you do not have a fast local DNS server, do not use these rules. These rules perform forward and reverse lookups and require a fast local DNS server, otherwise you should expect your websites to be very slow.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
Excluded: Modsecurity 2.8.0. Because 2.8.0 has a serious bug in the @ipmatch code( https://github.com/SpiderLabs/ModSecurity/issues/706).<br />
<br />
====00_asl_z_searchengines.conf====<br />
<br />
'(Available in ASL and the real time rules only)''<br />
<br />
This ruleset detects clients pretending to be a search engine, as well as valid search engines. You must have either [[ASL]] installed, or apache configured with "HostnameLookups Double" and a very fast local DNS server. <br />
<br />
These rules also allow you to auto-whitelist real search engines. To do this, you will need to either use [[ASL]], or you will need to manually set the variable WHITELIST_SEARCH_ENGINES to "1".<br />
<br />
'''Warning: If you do not have either [[ASL]] installed, or apache configured correctly to use these rules they will not work correctly.'''<br />
<br />
Note: If you do not have a fast local DNS server, do not use these rules. These rules perform forward and reverse lookups and require a fast local DNS server, otherwise you should expect your websites to be very slow.<br />
<br />
Requires: Modsecurity 2.9.3 and up.<br />
<br />
====00_asl_zz_strict.conf====<br />
<br />
'''Note: Requires modsecurity 2.7.0 and higher.'''<br />
<br />
This enforces strict adherence to the HTTP RFCs.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====00_asl_0_global.conf====<br />
<br />
This is a global variable file, it is only used if you have modsecurity 2.5.13 and above installed. <br />
<br />
====00_asl_rbl.conf====<br />
<br />
This rule family checks an incoming host to see if its on a RBL. By default only the spamhaus XBL-SBL list is enabled which is operated by the Spamhaus project. This RBL is not operated or controlled by Atomicorp. Please contact Spamhaus if you have issues with the IPs on this RBL, or disable this option. Several other RBLs are including in this rule file and must be either enabled in ASL (ASL will generate this rule file) or if you are not running ASL you must manually enable the other RBLs.<br />
<br />
This ruleset will look up every request in the DNS to see if its on a blacklist, and will not finish serving the request until the DNS server responds. This can slow down requests if the DNS server is slow. Basically, web requests will move at the speed of the DNS servers replies.<br />
<br />
If your web server is responding slowly to requests, and you have this ruleset enabled your DNS server is too slow to meet your lookup needs. You will need to either disable this ruleset, or tune your DNS server to respond to queries more quickly.<br />
<br />
''If you use this ruleset, make sure you have a fast locally caching DNS server. This ruleset will query spamhaus for every incoming IP to see if its on a blacklist, if your DNS is slow (or non local) this will make your system seem to crawl, as the read request will be blocked by Apache until it finished the DNS lookup. If you do not have a fast and local DNS server, do not use this ruleset.''<br />
<br />
Requires: Modsecurity 2.6.0 and up.<br />
<br />
====00_asl_blacklist.conf====<br />
<br />
Allows you to blacklist hosts or CIDRs from the WAF.<br />
<br />
Requires: Modsecurity 2.9.0 and up.<br />
<br />
The format is single IPs or CIDRs per line, for example:<br />
<br />
<pre><br />
1.2.3.4<br />
5.6.7.0/24<br />
8.9.0.0/16<br />
</pre><br />
<br />
Note: You must define your own blacklist file. The default location is /etc/asl/blacklist. <br />
<br />
====00_asl_whitelist.conf====<br />
<br />
Allows you to whitelist hosts from the WAF.<br />
<br />
Requires: Modsecurity 2.9.0 and up.<br />
<br />
The format is single IPs or CIDRs per line, for example:<br />
<br />
<pre><br />
1.2.3.4<br />
5.6.7.0/24<br />
8.9.0.0/16<br />
</pre><br />
<br />
Note: You must define your own whitelist entires. The default location is /etc/asl/whitelist. '''Do not use the whitelist.txt file. It is not used for this rule. We do not provide a default whitelist for these rules.'''<br />
<br />
Note: Requires modsecurity 2.7.7 and up.<br />
<br />
====01_asl_content.conf====<br />
<br />
These rules restrict the server to known content types that the WAF can correctly decipher.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
==== 01_asl_domain_blocks.conf====<br />
<br />
Optional ruleset that allows you to block connections from hosts, based on their DNS hostname and/or domain. This is a user defined list.<br />
<br />
Domains and/or hostnames are stored in this file:<br />
<br />
/etc/asl/custom-domain-blocks<br />
<br />
The format is one entry, per line, for example:<br />
<br />
<pre><br />
example.com<br />
www.hostname.some-tld<br />
</pre><br />
<br />
Note: You must have either [[ASL]] installed, or apache configured with "HostnameLookups Double" and a very fast local DNS server for these rules to work.\<br />
<br />
Note: Requires modsecurity 2.7.7 and up.<br />
<br />
====01_asl_rules_special.conf====<br />
<br />
This ruleset changes the behavior of the WAF for applications that behavior in nonstandard ways. For example, OTRS uses ";" and not "&" for argument separation. You should not use these rules if you do not have OTRS installed on your system.<br />
<br />
If you do not know what this means, you do not need this ruleset.<br />
<br />
Requires: Modsecurity 2.7.0 and up. <br />
<br />
Note: If you get an error regarding SecArgumentSeparator with these rules, your modsecurity configuration is being loaded too late in your Apache stack. Ensure that your modsecurity configuration is loaded first. This has been seen with cpanel when not using [[ASL]]. Please contact your apache vendor for assistance with this issue, or use [[ASL]] which will fix your apache configuration so this error does not occur.<br />
<br />
====03_asl_dos.conf====<br />
<br />
This ruleset protects apache from slow DOS attacks. It is only supported with Apache and requires the installation of the mod_reqtimeout module. The rule is fail safe with Apache, that is if the mod_reqtimeout module is not loaded the rules also will not load into Apache.<br />
<br />
[[ASL]] automatically ensures mod_reqtimeout is installed. If you are a rules only user please contact your Apache vendor for assistance installing this module.<br />
<br />
Note: Requires modsecurity 2.7.7 and up.<br />
<br />
====05_asl_exclude.conf====<br />
<br />
Pre-load rule exclusion list. Turns off rules that need to be disabled early in the process. ASL manages this process automatically.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====00_asl_z_antievasion.conf====<br />
<br />
This is a ruleset to detect attempts to bypass modsecurity itself, through evasion methods for example. Do not use this ruleset unless you are using 2.6.1 and up.<br />
<br />
====05_asl_scanner.conf ====<br />
<br />
Deprecated.<br />
<br />
====06_asl_honeypot.conf ====<br />
<br />
This ruleset lets you define URLs you want to specifically block, for example the URL of an application that may not be installed on the system. This can work as a honeypot of sorts, allowing the system to be configured to treat probes for non-existant applications as attacks. [[ASL]] has a more advanced system that can detect when URLs do not correspond to files on the system, which can be used in place of this ruleset or to augment it.<br />
<br />
For this ruleset to work, populate the honeypot-files.txt file in the same directory as 06_asl_honeypot.conf with one URL per line. For example:<br />
<br />
<br />
<pre><br />
/application/not/installed/on/system<br />
file_name_not_on_system.extension<br />
</pre><br />
<br />
==== 11_asl_rules.conf====<br />
<br />
This ruleset is reserved and is not currently used.<br />
<br />
====10_asl_antimalware.conf====<br />
<br />
Checks payload and RFI contents for known sources of malware and malware payloads and will block them.<br />
<br />
Requires: Modsecurity 2.6.0 and up.<br />
<br />
====09_asl_rules.conf====<br />
<br />
These are supplementation rules to the 10_asl_rules.conf, but only work on 2.6.6 and up installations. Do not use this ruleset unless you are using 2.6.6 and up.<br />
<br />
====10_asl_rules.conf ====<br />
<br />
The main rules, contains all the generic security rules to protect against classes of attacks, such as SQL injection, XSS, code injection, recursion, etc. '''These rules require modsecurity 2.9.1 and above.'''<br />
<br />
Requires: Modsecurity 2.9.1 and up.<br />
<br />
====11_asl_adv_rules.conf====<br />
<br />
These are advanced rules, and '''can only be used with modsecurity 2.7.5 and above.'''<br />
<br />
Requires: Modsecurity 2.7.5 and up.<br />
<br />
====11_asl_data_loss.conf====<br />
<br />
Experimental data leakage rules. Looks for credit card numbers and other potentially sensitive information leaking from the system.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====11_asl_brute_enhanced.conf====<br />
<br />
Requires: Modsecurity 2.9.2 and up.<br />
<br />
These rules are for platforms that do not have either [[ASL]] or Atomic Protector installed. These rules create the collections in modsecurity to block brute force attacks. The defaults are > 5 failures within 60 seconds.<br />
<br />
''Note: These rules are not necessary if the systen has ASL or Atomic Protector installed, and should not be used with ASL or AP.<br />
<br />
''Note 1: These rules will only work if the web server can write to the SecDataDir directory. That directory will contain sqllite databases that modsecurity will create and use to count events, without the collection modsecurity can not maintain state for composite events, like multiple login failures, and these rules will not work.''<br />
<br />
''Note 2: Enable this setting in /etc/asl/config to create the collections:''<br />
<br />
<br />
https://wiki.atomicorp.com/wiki/index.php/Aum_configuration#MODSEC_00_THREAT<br />
<br />
====12_asl_adv_xss_rules.conf====<br />
<br />
'''This ruleset require mod_security 2.9.0 and above.'''<br />
<br />
This is the advanced Cross Site Scripting (XSS) protection rule set. It performs deep level inspections of web requests and responses to look for potential XSS attacks.<br />
<br />
====12_asl_brute.conf====<br />
<br />
'''This ruleset is only available with [[ASL]] or the Real Time Rules.''' <br />
<br />
This ruleset detects authentication failures against all major web applications (Joomla, WordPress, MovableType, Drupal, ModX, ZenCart, OsCommerce, VBulletin, PHPBB and more).<br />
<br />
When used with [[ASL]], fast and "low and slow" brute force attacks can be detected and blocked in real time.<br />
<br />
Requires: Modsecurity 2.6.8 and up. <br />
<br />
'''Note: [[ASL]] is necessary to perform active response to brute force attacks.'''<br />
<br />
====13_asl_brute_enhanced.conf====<br />
<br />
Requires: Modsecurity 2.9.2 and up.<br />
<br />
These rules are for platforms that do not have either [ASL] or Atomic Protector installed. These rules create the collections in modsecurity to block brute force attacks. The defaults are > 10 failures within 60 seconds.<br />
<br />
''Note: These rules are not necessary if the systen has ASL or Atomic Protector installed, and should not be used with ASL or AP.<br />
<br />
Note 1: These rules will only work if the web server can write to the SecDataDir directory. That directory will contain sqllite databases that modsecurity will create and use to count events, without the collection modsecurity can not maintain state for composite events, like multiple login failures, and these rules will not work.''<br />
<br />
====20_asl_useragents.conf====<br />
<br />
Looks for malicious or suspicious user agents and known patterns of malicious activity. These rules require modsecurity 2.7.1 and up.<br />
<br />
Requires: Modsecurity 2.7.1 and up.<br />
<br />
====30_asl_antispam.conf====<br />
<br />
Tuned antispam rules, designed to work with all known blogs, forums, guestbooks, CMS' and other web content management systems that allow users to post content.<br />
<br />
Requires: Modsecurity 2.6.8 and up.<br />
<br />
====30_asl_antispam_advanced.conf====<br />
<br />
(Not released yet) These are advanced spam rules. They require modsecurity 2.7.1 and up.<br />
<br />
Requires: Modsecurity 2.7.1 and up.<br />
<br />
====30_asl_antispam_referrer.conf====<br />
<br />
Rules to block referrer spam. Generally not needed in most environments if you protect web log generation tools from public access (which is the default for most control panels).<br />
<br />
Requires: Modsecurity 2.6.0 and up.<br />
<br />
====40_asl_apache2-rules.conf====<br />
<br />
This ruleset has been retired. mod_security 2.x does not work with Apache 1.x and this ruleset existed just for those rules that only worked with apache 2. As mod_security 2.x does not work with Apache 1.x there is no need for this ruleset.<br />
<br />
====50_asl_rootkits.conf====<br />
<br />
Detects and blocks known web based rootkits, PHP/ASP/PERL shells, spam tools and other malicious web applications from being installed, and in some cases from running on the system. These rules exist for cases where malicious software may already be installed on the system, this is a defense in depth rule set)<br />
<br />
Not: ASL can prevent all malware from running on the system, modsecurity is limited in this regard so if you are only using the rules you should not expect modsecurity to prevent malware from running. It may prevent it in some cases, but without kernel level protection such as that provided in [[ASL]] no WAF can stop all malware from running on the system itself.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====51_asl_rootkits.conf====<br />
<br />
These rules look for known malware names in filenames, and URLs.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====60_asl_recons.conf====<br />
<br />
Blocks known "google hacks" or webserver probes that look for vulnerable applications and signs of compromised systems running unauthorized shells, or unprotected applications that allow uploads which would give an attacker access to the system.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====61_asl_recons_dlp.conf====<br />
<br />
These rules detect Data Loss Search engine "hacks". These are search engine probes for sensitive files, often used by malicious parties to find sensitive information accidentally exposed on web servers.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====99_asl_a_redactor.conf====<br />
<br />
ASL only rule set. Requires modsecurity 2.6.0 and up. Part of the malicious code removal system. Automatically removes malicious code from web pages, such as hidden iframes, encoded javascript and other malicious code. '''Do not enable this ruleset if you are not using ASL. ''' <br />
<br />
====99_asl_exclude.conf====<br />
<br />
Post exclude rules.<br />
<br />
====98_asl_adv_redactor.conf====<br />
<br />
This is the new advanced malware removal system. This ruleset will remove malware "on the fly" from web pages. For example, it will remove hidden iframes, malicous javascript, and other malicious code.<br />
<br />
'''Requires: modsecurity 2.7.5 and up.'''<br />
<br />
====98_asl_jitp.conf====<br />
<br />
This is a special ruleset used by [[ASL]]. If you do not have [[ASL]] you can not use these rules.<br />
<br />
====99_asl_jitp.conf====<br />
<br />
Just in Time Patches. We publish JITPs daily if there is a new web application vulnerability that the 10_asl_rules.conf do not protect the system against. These are tuned rules for specific vulnerabilities in a web application.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
====99_asl_a_redactor.conf====<br />
<br />
This ruleset is reserved, and is not currently used.<br />
<br />
====99_asl_redactor.conf====<br />
<br />
'''Note: Do not enable this ruleset unless you have been instructed to do so by support.'''<br />
<br />
Special ruleset - requires mod_sed to be loaded on the system which is included and supported in [[ASL]] - removes malicious code from web pages, such as hidden iframes, encoded javascript and other malicious code. We highly recommend you use this rule set - its fast, multithreads and will automagically remove malicious code from infected webpages, which can occur if an adversary is able to log into the system and modify the code, such as by SSH or by uploading the code via FTP. If you are not using [[ASL]] then you will need to make sure your system has mod_sed installed to use these rules, they will not load and therefore will not do anything without mod_sed installed. This ruleset is only supported with [[ASL]].<br />
<br />
====99_asl_redactor_post.conf====<br />
<br />
This ruleset detects malicious content in webpages, such as known malicious domains.<br />
<br />
====99_asl_scanner.conf====<br />
<br />
This is the same as 05_asl_scanner.conf, its provided in a form to run last. This is the recommended location for the scanner function, as the rules before this stop some attacks that the scanner also detects, but do this in a faster and less CPU intensive manner. Running the scanner last does not compromise or lower the effectiveness of the rules. This is just a performance enhancement. This ruleset is only supported with [[ASL]].<br />
<br />
====99_asl_z_adv_scanner.conf====<br />
<br />
'''Note: Requires [[ASL]] and modsecurity 2.9.0 and higher.'''<br />
<br />
This ruleset uses a fuzzy hash to identify potentially malicious files.<br />
<br />
Warning: This ruleset is not supported on non-ASL systems. Do not use this without ASL.<br />
<br />
==== Paranoid mode rules ====<br />
<br />
===== 15_asl_paranoid_rules.conf =====<br />
<br />
'''Note: Do not use these rules if you have not read this section.'''<br />
<br />
'''Please do not report false positives with these rules. If you encounter a false positive with a rule from this file, please use its duplicate in 10_asl_rules.conf instead. If you have a false positive with a rule from 10_asl_rules.conf, please report it to us.'''<br />
<br />
These are a special version of the 10_asl_rules.conf file, they use the same rule id:s as the 10_asl_rules.conf file. Therefore, you can not use these rules along with the 10_asl_rules.conf file. You can use one, or the other, but not both.<br />
<br />
These rules are a paranoid replacement for the 10_asl_rules.conf file. These rules do not contain any known safe mode application tuning exceptions or bypasses. These rules will generate false positives. These rules are made available for users that wish to tune their own rules, and do not wish to use a ruleset that has been tuned for false positives.<br />
<br />
For example, if you had a application that safely used the argument "url" to accept URLs:<br />
<br />
GET /application?url=http://www.example.com/safething<br />
<br />
The normal rules would allow this, if this was known to be safe for the application. <br />
<br />
The paranoid rules, however, will NOT allow this, even if this is known to be safe for the application. They will alert, and if configured (or misconfigured) also block this as an RFI attack. These rules will alert on things that may be safe or are known to be non-malicious. This will generate a lot of false positives for most users, therefore you should not use these rules if you do not want to experience a high degree of false positives. These rules exist for paranoid users, who may want to tune the rules themselves, or may wish to know about every possible potentially malicious event, even when the event may in fact not be malicious.<br />
<br />
We do not recommend you use these rules in blocking mode, instead you should use these only in detect mode, and only if you feel that your applications are doing things in a very unsafe manner. If you do wish to use these rules, make sure that you load them from a special file so you can set the default behaviour of the rules. If you do not do this, the rules will inherit you systems default behavior, which is generally to block.<br />
<br />
Example configuration lines for the paranoid rules:<br />
<br />
<pre><br />
SecDefaultAction "log,pass,auditlog,phase:2,t:none,t:lowercase,t:replaceNulls,t:compressWhitespace"<br />
Include modsecurity.paranoid.rules.d/15_asl_paranoid_rules.conf<br />
</pre><br />
<br />
You must load these rules last.<br />
<br />
Requires: Modsecurity 2.7.0 and up.<br />
<br />
==== Using the paranoid rules ====<br />
<br />
If you want to use the paranoid rules because you have found a vulnerability in your application that the normal rules do not block, please let us know, we would be happy to take a look at either creating a Just In Time Patch for your vulnerability, or adjusting the tuned rules to not allow this. Remember, if you use our real time rules, we provide this service for free. One easy way to find out if you have applications that have unusual vulnerabilities is to scan the application with a web vulnerability application scanner, if you find something the normal rules dont stop just let us know. We'd be delighted to put out new rules for your applications vulnerabilities.<br />
<br />
Finally, if you do you use these rules you will need to set ATOMIC_PARANOID_MODE to 1 in your modsecurity configuration. If you do not know how to do this, we do not recommend you use these rules.<br />
<br />
'''Note: Do not use this ruleset with [[ASL]]. [[ASL]] uses intelligent defense in depth, and does need this kind of ruleset to protect you. You will get a greater level of protection from ASL, without all the false positives.'''<br />
<br />
==== Beta Rules ====<br />
<br />
==== Experimental Rules ====<br />
<br />
<br />
====70_asl_csrf_experimental.conf====<br />
<br />
These are experimental CSRF mitigation rules. The 10_asl_rules.conf rules are designed to also handle some types of CSRF attacks, however these rules are for more advanced environments.<br />
<br />
These rules work by injecting javascript code into the response, and special cookies, and must be tuned for the system to prevent false positives. If you do not understand what this means, do not use these rules.<br />
<br />
'''They are currently not supported and are experimental.'''<br />
<br />
Requires: Modsecurity 2.7.0 and up.</div>Mshinnhttps://wiki.atomicorp.com/wiki/index.php/Atomic_ModSecurity_RulesAtomic ModSecurity Rules2022-09-27T17:22:15Z<p>Mshinn: /* Step 5a: Remote Rules */</p>
<hr />
<div>[[Atomic Secured Linux]] includes modsecurity, and the Real Time GotRoot.com/Atomicorp Modsecurity Rules. These docs are for users that do not have [[ASL]].<br />
<br />
'''ASL will install and configure modsecurity, and provides a powerful and easy use to GUI to manage all of this for you. If you don't have ASL, [https://www.atomicorp.com/amember/cart/index/index?c=1 upgrade to ASL today!]'''<br />
<br />
= '''About the rules''' =<br />
<br />
The gotroot.com rules are written by us - we are the gotroot guys. Same great rules, same team, ten years of writing modsecurity rules and still going strong! GotRoot is our Information Assurance lab and [http://www.atomicorp.com Atomicorp] is the product arm of [http://www.progllc.com Prometheus Global] (the parent company for both). So when you get the gotroot.com rules from atomicorp.com or gotroot.com - you're getting the same rules from the same people that created, write and maintain them. In the future we will be merging the gotroot.com, atomicrocketturtle and atomicorp websites into the atomicorp.com website.<br />
<br />
We publish two versions of the rules:<br />
<br />
'''RealTime Rules:''' The latest and greatest version of the rules, with all the performance enhancements, new security features and bug fixes released by us on a daily basis. These rules are fully supported and are recommended for production use.<br />
<br />
'''Free/Delayed Rules:''' A delayed subset of the Advanced rules.<br />
<br />
Installation of the rules assumes a certain level of comfort with configuring apache. If you are not comfortable with configuring apache, you should contact someone that is, or use our [[Atomic Secured Linux]] product which does this automatically for you, and does not require you to configure apache.<br />
<br />
== Getting the rules ==<br />
<br />
[https://www.atomicorp.com/amember/cart/index/index?c=6 Click here] to get the Atomicorp ModSecurity Rules.<br />
<br />
== '''Atomic ModSecurity Rules Frequently Asked Questions''' ==<br />
<br />
Please see the [[Atomic ModSecurity Rules FAQ]] wiki page.<br />
<br />
== '''Real Time Rule Support''' ==<br />
<br />
If you have a subscription to the real time rules, you can request email support by sending an email to:<br />
<br />
support@atomicorp.com<br />
<br />
The Customer Support Forums are located here:<br />
<br />
[http://www.atomicorp.com/forums Customer Support Forums]<br />
<br />
And the Custom Support Portal is located here (you can submit bug reports and open cases through the portal):<br />
<br />
[https://www.atomicorp.com/portal Customer Support Portal]<br />
<br />
== '''Licenses''' ==<br />
<br />
The Real Time Atomic ModSecurity Rules are licensed by the server. You can order licenses from the online store at the link below:<br />
<br />
[https://www.atomicorp.com/amember/cart/index/index?c=6 Online Store]<br />
<br />
If you require additional licenses please log into the [https://www.atomicorp.com/support/license-manager.html AtomiCorp License Manager]. You can add additional systems there, you can control your payment methods and you can also sign up to become an affiliate.<br />
<br />
=== License Terms and Conditions ===<br />
<br />
Purchase of an Atomicorp ModSecurity rule license entitles the purchaser to access and download from the Atomicorp Repository to a single IP address within the time period of the license. A separate license is required for each dedicated server/host or VPS that the rule set is installed upon or is protecting.<br />
<br />
Atomicorp ModSecurity rules installed upon a Reverse Proxy WAF appliance/server requires a separate license. Please contact Atomicorp support for details.<br />
<br />
The rule set cannot be copied, mirrored, or reproduced under protection of US and International copyright laws.<br />
<br />
Use of the rule set is limited to the time period of the license. If the license period of a rule set expires, it must must removed from its installed server and no longer used. Atomicorp reserves the right to track and enforce license compliance of the Atomicorp Modsecurity rule sets.<br />
<br />
Agreement to these terms and conditions and the Atomicorp [https://atomicorp.com/eula.html End User License Agreement] is required to download and use the Atomicorp ModSecurity rules.<br />
<br />
== Important Information about the Rules ==<br />
<br />
=== Minimum Version of Modsecurity Required to use the rules ===<br />
<br />
The rules are supported with the following versions of Modsecurity:<br />
<br />
<br />
* 2.9.3<br />
<br />
We recommend customers use our modsecurity builds, as they are tested to ensure all features work correctly. Third party builds may not include the correct libraries, may cause problems with your web server, including crashes and may disable or incorrectly enable features in modsecurity that can cause unpredictable behavior or failure of rules to process correctly.<br />
<br />
If you need a solution to keep the rules and modsecurity up to date and in sync with your version of modsecurity automatically, please use [[aum]] or [[ASL]] which will do this for you automatically.<br />
<br />
==== What versions of modsecurity do the rules work with ====<br />
<br />
They work with both modsecurity 2.9.x, and modsecurity 3.x.<br />
<br />
=== What does each rule family do? ===<br />
<br />
Please see the [[modsecurity_rule_families]] documents.<br />
<br />
= Installation =<br />
<br />
== Easy One Step Installation ==<br />
<br />
<br />
<br />
===== Full Management Suite =====<br />
<br />
Install [[ASL]]. This installs everything: modsecurity, all the rules, the GUI, rule manager and all ASL components, plus it includes the subscription to the real time rules.<br />
<br />
ASL will automatically download and keep your rules up to date, and will ensure that modsecurity stays up to date so your system can support the latest rules. ASL also provides you with a full security management suite, which will allow you to manage, edit and configure your rules through a web console. It will also protect you from uploaded malware, brute force attacks, DOS attacks, rootkits and many other threats that a WAF can not protect you from.<br />
<br />
A full list of ASLs features is available at the URL below:<br />
<br />
https://www.atomicorp.com/products/asl.html<br />
<br />
===== Just a downloader =====<br />
<br />
We also provide an automated rule updater and modsecurity installation tool, called [[aum]]. You can read more about it on the [[aum]] page. You can install it by running these commands as root:<br />
<br />
Step 1) Install [[aum]]<br />
<br />
''wget -q -O - https://updates.atomicorp.com/installers/aum |bash''<br />
<br />
Step 2) Configure [[aum]]<br />
<br />
''aum configure''<br />
<br />
Step 3) Tell [[aum]] to install the rules<br />
<br />
''aum upgrade''<br />
<br />
You can read more about aum on the [[aum]] documentation page.<br />
<br />
Note: This capability is included in [[ASL]]. ASL users do not need to install aum, its already included.<br />
<br />
== (Optional) Do It Yourself Installation ==<br />
<br />
Note: A manual installation is not necessary if you have [[ASL]] installed. ASL will configure and install modsecurity, and the rules, automatically. This is also not necessary if you are using our new AUM software to handle rule download and installation.<br />
<br />
=== Linux ===<br />
<br />
==== Step 1: Download ModSecurity ====<br />
<br />
Binaries:<br />
<br />
[http://updates.atomicorp.com/channels/atomic/ Install modsecurity from the Atomicorp software repository]<br />
<br />
Source Code:<br />
<br />
[http://updates.atomicorp.com/channels/atomic/ Install modsecurity from the Atomicorp software repository]<br />
<br />
Please note that the rules are only supported with the version of modsecurity [http://wiki.atomicorp.com/wiki/index.php/Atomic_ModSecurity_Rules#Minimum_Version_of_Modsecurity_Required_to_use_the_rules identified in this section of the wiki.]<br />
<br />
Note: Please contact us before using a third party or source build of modsecurity. Its critical modsecurity be built correctly to work with the rules.<br />
<br />
==== Step 2: Set up and configure directories ====<br />
<br />
Create the following directories as root:<br />
<br />
mkdir /etc/httpd/modsecurity.d<br />
mkdir /var/asl<br />
mkdir /var/asl/tmp<br />
mkdir /var/asl/data<br />
mkdir /var/asl/data/msa<br />
mkdir /var/asl/data/audit<br />
mkdir /var/asl/data/suspicious<br />
<br />
==== Step 3: Set permissions for directories ====<br />
<br />
Set the following permissions on the directories you just created. In this example these directories are set to be owned by "apache" and the group "apache", which is standard on a normal Centos or RHEL system. However some control panels configure apache to run as a different user, such as nobody, or http. <br />
<br />
To determine what user this is, check your system to see what user your webserver uses. You can use this command to find the user:<br />
<br />
ps auxwww | grep httpd<br />
<br />
The output will look similar to this:<br />
<br />
(RHEL/Centos example with or without Plesk)<br />
<br />
root 26755 0.0 4.3 430752 86432 ? Ss 04:30 0:01 /usr/sbin/httpd<br />
'''apache''' 26908 0.0 3.7 300564 75076 ? S 04:30 0:00 /usr/sbin/httpd<br />
'''apache''' 26909 0.1 5.5 495812 112084 ? S 04:30 0:37 /usr/sbin/httpd<br />
'''apache''' 26910 0.0 5.3 495424 106672 ? S 04:30 0:23 /usr/sbin/httpd<br />
'''apache''' 26911 0.1 5.7 495892 114368 ? S 04:30 0:57 /usr/sbin/httpd<br />
'''apache''' 26912 0.1 5.7 496056 114440 ? S 04:30 0:52 /usr/sbin/httpd<br />
'''apache''' 26913 0.1 5.5 496604 110692 ? S 04:30 0:57 /usr/sbin/httpd<br />
'''apache''' 26914 0.0 5.7 499324 116236 ? S 04:30 0:16 /usr/sbin/httpd<br />
'''apache''' 26915 0.2 5.5 493600 112192 ? S 04:30 1:09 /usr/sbin/httpd<br />
'''apache''' 26916 0.1 6.4 513760 129992 ? S 04:30 0:30 /usr/sbin/httpd<br />
<br />
In this example the user in bold is "apache" (this may be different for your system). This is the user you will want to set the directory permissions to (as in the example below):<br />
<br />
chown apache.apache /var/asl/data/msa<br />
chown apache.apache /var/asl/data/audit<br />
chown apache.apache /var/asl/data/suspicious<br />
chmod o-rx -R /var/asl/data/*<br />
chmod ug+rwx -R /var/asl/data/*<br />
<br />
(RHEL/Centos example with Cpanel)<br />
<br />
root 20594 86.8 3.1 255148 181232 ? Ss 11:39 0:04 /usr/local/apache/bin/httpd -k restart<br />
root 20611 0.0 3.1 255060 179596 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20612 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20613 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20614 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20615 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20616 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
<br />
In this example from a Centos system running Cpanel the user is "nobody", so you would want to use these commands:<br />
<br />
chown nobody.nobody /var/asl/data/msa<br />
chown nobody.nobody /var/asl/data/audit<br />
chown nobody.nobody /var/asl/data/suspicious<br />
chmod o-rx -R /var/asl/data/*<br />
chmod ug+rwx -R /var/asl/data/*<br />
<br />
==== Step 4: (Optional) Create rule updater directories ====<br />
These directories must as be created if you use optional rules updater. Create these directories as root and they only need to be accessed by root:<br />
<br />
mkdir /var/asl/updates<br />
mkdir /var/asl/rules/<br />
mkdir /var/asl/rules/clamav<br />
<br />
==== Step 5: Create the whitelist file ====<br />
<br />
Create this file:<br />
<br />
touch /etc/asl/whitelist<br />
<br />
This file contains a list of IPs you want to exclude from ALL rules. That means those IPs can do anything to your system - so be very very careful about what IPs you add to this list. This is a dangerous thing to do. The format of the file is a single IP, per line. <br />
<br />
Cpanel users should skip to the notes at the bottom of this page for special additional actions for cpanel systems. All other users should continue with these instructions.<br />
<br />
==== Step 6: Configure your webserver ====<br />
<br />
===== nginx =====<br />
<br />
===== Step 6a: configure nginx to load modsecurity =====<br />
<br />
====== nginx proxying to a backend ======<br />
<br />
If you are using nginx as a frontend to another webserver, then add the following directives to your nginx.conf file.<br />
<br />
<pre><br />
location / {<br />
ModSecurityEnabled on;<br />
ModSecurityConfig modsecurity.conf;<br />
proxy_pass http://localhost:8080;<br />
proxy_read_timeout 180s;<br />
}<br />
<br />
</pre><br />
<br />
Change "localhost:8011" to the server you are proxying nginx to, and change 8080 to the portnumber for that server. For example, if you are running apache on port 8088 on localhost the line would be:<br />
<br />
proxy_pass http://localhost:8088;<br />
<br />
====== nginx standalone ======<br />
<br />
If you are only using nginx, and not using it as a frontend to another web server then you want to use this configuration:<br />
<br />
<pre><br />
location / {<br />
ModSecurityEnabled on;<br />
ModSecurityConfig modsecurity.conf;<br />
}<br />
</pre><br />
<br />
===== Apache =====<br />
<br />
===== Step 6a: configure apache to load modsecurity =====<br />
<br />
You then need to tell apache to load modsecurity. Depending on your apache configuration, apache should be configured to include configuration files. If you have a setting like this in your apache config:<br />
<br />
Include conf.d/*.conf<br />
<br />
Then you are setup to load external configuration files. If you do not have this setup, its highly recommend you add this. This installation guide is written for this type of configuration. Loading mod_security occurs by including a modsecurity configuration file in that directory. We recommend you name the name 00_modsecurity.conf to ensure it runs first. Its vitally important that modsecurity load before other modules, otherwise attacks can occur before modsecurity scans them and some attacks can be missed.<br />
<br />
An example 00_modsecurity.conf file that works with our files is included here:<br />
<br />
LoadModule security2_module modules/mod_security2.so<br />
LoadModule unique_id_module modules/mod_unique_id.so<br />
<IfModule mod_security2.c><br />
Include modsecurity.d/tortix_waf.conf<br />
</IfModule><br />
<br />
Install this file in your conf.d directory. On a standard RHEL or Centos system that directory is located here:<br />
<br />
/etc/httpd/conf.d/<br />
<br />
=== Step 7: Configure modsecurity ===<br />
<br />
You then need to configure modsecurity. This is done via the an apache configuration file. In this example, we will create the file "tortix_waf.conf". Here is an example file that works with our rules:<br />
<br />
SecRuleEngine On<br />
SecRequestBodyAccess On<br />
SecResponseBodyAccess On<br />
SecResponseBodyMimeType (null) text/html text/plain text/xml<br />
SecResponseBodyLimit 2621440<br />
SecServerSignature Apache<br />
SecComponentSignature 200911012341<br />
SecUploadDir /var/asl/data/suspicious<br />
SecUploadKeepFiles Off<br />
SecAuditEngine RelevantOnly<br />
SecAuditLogRelevantStatus "^(?:5|4(?!04))"<br />
SecAuditLogType Concurrent<br />
SecAuditLog logs/audit_log<br />
[[SecAuditLogParts]] ABIFHZ<br />
SecArgumentSeparator "&" <br />
SecCookieFormat 0<br />
SecRequestBodyInMemoryLimit 131072<br />
SecDataDir /var/asl/data/msa<br />
SecTmpDir /tmp<br />
SecAuditLogStorageDir /var/asl/data/audit<br />
SecResponseBodyLimitAction ProcessPartial<br />
SecAuditLogDirMode 0770<br />
SecPcreMatchLimit 250000 <br />
SecPcreMatchLimitRecursion 250000<br />
<br />
You will want to install this file in your modsecurity.d directory, which is located here if you follow the instructions above:<br />
<br />
/etc/httpd/modsecurity.d<br />
<br />
==== tortix_waf.conf ====<br />
<br />
You can also download an example version of the modsecurity configuration file from here:<br />
<br />
https://www.atomicorp.com/installer/tortix_waf.conf<br />
<br />
[[ASL]] will automatically generate this file depending on your needs. If you are not using ASL, you will need to modify this configuration file to suit your system and modsecurity requirements.<br />
<br />
==== Step 8: Download the ModSecurity Rules ====<br />
<br />
See the [[Downloading Rules]] page.<br />
<br />
==== Step 9: Install the rules ====<br />
<br />
==== Remove any previous installations of rules ====<br />
<br />
If you have installed our delayed rules, you will need to make sure you have deleted them. You will not want to have any older versions of the rules installed.<br />
<br />
Also, if you have installed any third party modsecurity rules, you will want to make sure they are using rule id's that are assigned to them. The modsecurity project assigns ranges to the rule id's modsecurity uses. Modsecurity requires a unique id for each rule, otherwise you will get an error like this:<br />
<br />
ModSecurity: Found another rule with the same id<br />
<br />
This means either that someone else is using the same rule id's assigned to our ruleset by the modsecurity project (our official range is 300000-399999), or you have loaded our rules twice.<br />
<br />
==== Installation ====<br />
<br />
Download the rules to a temporary directory using your favorite download tool. Extract the rules:<br />
<br />
tar zxvf /var/asl/updates/modsec-200911012341.tar.gz<br />
<br />
Then copy each of the ASL rule files you wish to use into /etc/httpd/modsecurity.d. Do not copy all of the rule files, you will need to select rule files that are appropriate for your system. Or simply use [[aum]] or [[ASL]] to do this for you automatically.<br />
<br />
If you are using cpanel, please see the notes at the bottom of this page, cpanel does not use the standard locations for apache configuration files.<br />
<br />
Finally, load the rules. '''Make sure you specify only those rule files that are appropriate for your system.''' For example:<br />
<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/99_asl_jitp.conf<br />
<br />
'''Warning: You should NOT include all the rules. There are rulesets, documented above, that replace other rulesets and are incompatible with each other.'''<br />
<br />
===== Recommend minimum rulesets =====<br />
<br />
====== apache ======<br />
<br />
The recommended ''minimum ruleset'' to load is:<br />
<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_0_global.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_antimalware.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/11_asl_adv_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/20_asl_useragents.conf<br />
Include /full/path/to/your/rules/modsecurity.d/30_asl_antispam.conf<br />
Include /full/path/to/your/rules/modsecurity.d/50_asl_rootkits.conf<br />
Include /full/path/to/your/rules/modsecurity.d/60_asl_recons.conf<br />
Include /full/path/to/your/rules/modsecurity.d/61_asl_recons_dlp.conf<br />
Include /full/path/to/your/rules/modsecurity.d/99_asl_jitp.conf<br />
<br />
If you have modsecurity 2.9.0 and up installed, you should also load additional rule files and should use this ruleset:<br />
<br />
Include /full/path/to/your/rules/modsecurity.d/000_asl_threat_intelligence.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_zz_strict.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_0_global.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_z_antievasion.conf<br />
Include /full/path/to/your/rules/modsecurity.d/01_asl_content.conf<br />
Include /full/path/to/your/rules/modsecurity.d/01_asl_content_z.conf<br />
Include /full/path/to/your/rules/modsecurity.d/03_asl_dos.conf<br />
Include /full/path/to/your/rules/modsecurity.d/09_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_antimalware.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/11_asl_adv_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/11_asl_data_loss.conf<br />
Include /full/path/to/your/rules/modsecurity.d/12_asl_adv_xss_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/20_asl_useragents.conf<br />
Include /full/path/to/your/rules/modsecurity.d/30_asl_antispam.conf<br />
Include /full/path/to/your/rules/modsecurity.d/50_asl_rootkits.conf<br />
Include /full/path/to/your/rules/modsecurity.d/51_asl_rootkits.conf<br />
Include /full/path/to/your/rules/modsecurity.d/60_asl_recons.conf<br />
Include /full/path/to/your/rules/modsecurity.d/61_asl_recons_dlp.conf<br />
Include /full/path/to/your/rules/modsecurity.d/99_asl_jitp.conf<br />
Include /full/path/to/your/rules/modsecurity.d/98_asl_adv_redactor.conf<br />
<br />
If you have a [[Local DNS resolver]] setup and properly configured on your system, and you are using modsecurity 2.9.0 and up we also recommend these additional rulesets:<br />
<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_z_searchengines.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_z_aa_threat_intelligence.conf<br />
Include /full/path/to/your/rules/modsecurity.d/99_asl_zzzz_threat_intelligence.conf<br />
<br />
Note: Some of these rulesets are designed to work with advanced security management systems such as [[ASL]] and may not work completely without an advanced management system.<br />
<br />
====== nginx ======<br />
<br />
The same rulesets as apache will work with nginx.<br />
<br />
====== litespeed ======<br />
<br />
[[Litespeed]] has a proprietary implementation of mod_security. It does not support all the features that mod_security with apache, IIS and nginx does. Therefore, you can not use all the rulesets with Litespeed, as Litespeed does not support those features of mod_security. The following rulesets are recommended with Litespeed:<br />
<br />
The recommended ''minimum ruleset'' to load is:<br />
<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_0_global.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_antimalware.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/11_asl_adv_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/20_asl_useragents.conf<br />
Include /full/path/to/your/rules/modsecurity.d/30_asl_antispam.conf<br />
Include /full/path/to/your/rules/modsecurity.d/50_asl_rootkits.conf<br />
Include /full/path/to/your/rules/modsecurity.d/60_asl_recons.conf<br />
Include /full/path/to/your/rules/modsecurity.d/61_asl_recons_dlp.conf<br />
Include /full/path/to/your/rules/modsecurity.d/99_asl_jitp.conf<br />
<br />
If you require more advanced protection, you should also load additional rule files and should use this ruleset:<br />
<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_zz_strict.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_x_searchengines.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_y_searchengines.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_0_global.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_z_antievasion.conf<br />
Include /full/path/to/your/rules/modsecurity.d/01_asl_content.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_zz_strict.conf<br />
Include /full/path/to/your/rules/modsecurity.d/03_asl_dos.conf<br />
Include /full/path/to/your/rules/modsecurity.d/09_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_antimalware.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/11_asl_adv_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/11_asl_data_loss.conf<br />
Include /full/path/to/your/rules/modsecurity.d/12_asl_adv_xss_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/20_asl_useragents.conf<br />
Include /full/path/to/your/rules/modsecurity.d/30_asl_antispam.conf<br />
Include /full/path/to/your/rules/modsecurity.d/50_asl_rootkits.conf<br />
Include /full/path/to/your/rules/modsecurity.d/51_asl_rootkits.conf<br />
Include /full/path/to/your/rules/modsecurity.d/60_asl_recons.conf<br />
Include /full/path/to/your/rules/modsecurity.d/61_asl_recons_dlp.conf<br />
Include /full/path/to/your/rules/modsecurity.d/99_asl_jitp.conf<br />
<br />
<br />
Note: [[Litespeed]] does not support content inspection (outbound rules), or lua based rules. Therefore, the following rulesets Litespeed does not support, and loading them will have no effect on the system:<br />
<br />
<br />
00_asl_z_searchengines.conf<br />
00_asl_z_aa_threat_intelligence.conf<br />
12_asl_brute.conf<br />
98_asl_adv_redactor.conf<br />
99_asl_zzzz_threat_intelligence.conf<br />
<br />
Note: Some of these rulesets are designed to work with advanced security management systems such as [[ASL]] and may not work completely without an advanced management system.<br />
<br />
===== Notes on Scanner ruleset =====<br />
<br />
NOTE: If you use this file:<br />
<br />
05_asl_scanner.conf<br />
<br />
Or this file:<br />
<br />
99_asl_scanner.conf<br />
<br />
[[ASL]] includes malware upload scanning, rules subscriptions do not.<br />
<br />
If you wish to use this ruleset, and you are not using [[ASL]], then you will need to create a script to pass the files to clamd and read the result. Make sure you have clamd installed and configured correctly to list on a TCP port, or if you use a socket, make sure apache can read/write to this socket or as a last resort, run clamd as root. Using this file will force all web uploads on your system to go thru clamav to look for malware, viruses, etc. If you dont need that, then you can leave this config file out. <br />
<br />
Real time malware upload protection is included in [[ASL]] and uses a faster method than the older style modsecurity scripting method above. So if you need realtime malware upload protection (for web, FTP, or even realtime), then upgrade to [[ASL]] which includes highspeed malware upload protection, full support, automatic and hassle free installation. ASL also protects against any form of upload of malware, including HTTP, HTTPS, SSH and FTP uploads and includes our real-time malware detection and prevention system which will detect and block any malicious software running on the system in realtime. This is just one of the many many features of [[ASL]].<br />
<br />
==== Step 10: Test your web server ====<br />
===== Test nginx =====<br />
<br />
nginx -t -c <NGINX_CONFIG_FILE><br />
<br />
Where NGINX_CONFIG_FILE is your nginx.conf file.<br />
<br />
===== Test Apache =====<br />
<br />
Before restarting apache we recommend you test your configuration by running apache with the "configtest" command. On a standard system you can do this by calling your apache init file like this:<br />
<br />
/etc/init.d/httpd configtest<br />
<br />
If you get errors, check to see that you don't have some extraneous configuration files installed.<br />
<br />
===== Testing to see if the rules are loaded =====<br />
'''<br />
Step 1)''' (for non [[ASL]] systems)<br />
<br />
Make sure you have the rules installed exactly as described on this page. This test may not work if you have not followed these instructions. (If you used ASL to setup your WAF, and you have not installed any third party tools that configure, install or manage modsecurity then your rules are installed correctly and you do not need to review the instructions on this page. If you have manually altered your modsecurity configuration then you will need to review this entire article. Manual modifications of ASL modsecurity configurations are not supported.)<br />
<br />
'''Step 2) Make sure all rules are enabled'''<br />
<br />
'''Ensure that you do not have any of our rules disabled.''' This test assumes you do not have any rules disabled, that you are not whitelisting the source of this test and that your have the Atomicorp rules loaded.<br />
<br />
'''Step 3) Test from a non-whitelisted system''' <br />
<br />
Make sure you do not have the system you are performing this from is whitelisted<br />
<br />
For example, cpanels default modsecurity configuration will configure modsecurity to ignore everything from 127.0.0.1, or from the system itself. So if you perform the test above from the server itself, and you have not removed this cpanel whitelist, then this test will not work.<br />
<br />
'''Step 4) Run the test'''<br />
<br />
On the system where the rules are installed run this command (this assumes you have wget installed, '''127.0.0.1 is NOT whitelisted''' and a web server is listening on 127.0.0.1):<br />
<br />
''wget http://localhost/foo.php?foo=http://www.example.com''<br />
<br />
If the test worked, should get a 403 error if the rules are loaded, which will look similar to this:<br />
<br />
<pre><br />
--2010-05-27 20:12:25-- http://localhost/foo.php?foo=http://www.example.com<br />
Resolving localhost... 127.0.0.1<br />
Connecting to localhost|127.0.0.1|:80... connected.<br />
HTTP request sent, awaiting response... 403 Forbidden<br />
2010-05-27 20:12:25 ERROR 403: Forbidden.<br />
</pre><br />
<br />
If you do not get a 403 error, the test did not work.<br />
<br />
You can also use your browser to test the rules by going to a URL similar to this:<br />
<br />
http://YOUR_HOST/foo.php?foo=http://www.example.com<br />
<br />
Remember to replace YOUR_HOST with the actual HOSTNAME or IP of the server.<br />
<br />
If the rules are properly loaded, you should get a 403 error, if you do not get a 403 error, the rules are not loaded correctly and you need to check your configuration to ensure that you have followed the instructions above correctly.<br />
<br />
If you get a 403 error from the command line and a 404 error from the browser, check to make sure the computer you are testing the browser from is not whitelisted on the server.<br />
<br />
Note: If you do not have wget installed, then you will need to install it or a similar tool to run this test from a Linux or UNIX based system. If you are using Windows, you can use a similar tool or your browser.<br />
<br />
====== What to do if you do not get a 403 error ======<br />
<br />
If you get a different error, such as a 404 error or a 5xx series error check your configuration. The following are common causes of this:<br />
<br />
'''1) You have rules disabled'''<br />
<br />
Make sure you do not have any rules disabled.<br />
<br />
'''2) Your IP is whitelisted'''<br />
<br />
There is a rule whitelisting the system you are conducting this test from. Whitelisting tells the WAF to ignore everything from that source.<br />
<br />
For example, cpanels default modsecurity configuration will configure modsecurity to ignore everything from 127.0.0.1, or from the system itself. So if you perform the test above from the server itself, and you have not removed this cpanel whitelist, then you will not get a 403 error. More than likely you will get a 404 error. The solution is to remove any whitelists from your system.<br />
<br />
Note: Whitelisting the server itself can open a hole in your security. You should not whitelist localhost or the servers own IP address, particularly if you have multi users on the system. This is both unnecessary, and doing so will allow any users on the system to carry out attacks on other domains on the system unimpeded. Make sure you do not have any rules like that, this opens a very large hole in your system.<br />
<br />
'''3) Local error message is different'''<br />
<br />
You or someone else may have configured your system to use a different error message. Check your configuration, and make sure it exactly matches the ones on this wiki. IF you are using kind of plugin that does not return a 403 when a connection is rejected, and you must use this, then you will need to manually check your mod_security logs to see if your test is being rejected by modsecurity. If it is, then your rules are working correctly and you can ignore the error code.<br />
<br />
'''4) Third party addons''' <br />
<br />
You have third party rules or addons installed with your modsecurity configuration that are changing the responses. Remove all third party addons, and make sure your configuration exactly matches the instructions on this page<br />
<br />
'''5) Insecurely configured apache'''<br />
<br />
Some control panels are known to disable modsecurity on localhost, and on the systems IP addresses. These highly insecure control panels essentially disable modsecurity if an attacker connects to the systems IP address. This of course leaves your system wide open to attack, and if you are unlucky enough to be using one of these control panels we recommend you report this to your control panel vendor as a serious vulnerability. If they are unwilling to fix it, then we recommend you find a more security concious control panel vendor.<br />
<br />
Example:<br />
<br />
We have seen some control panels that configure modsecurity to be disabled in the /etc/httpd/conf/httpd.conf file for all the local IPs on the system. <br />
<br />
<pre><br />
<VirtualHost <LOCAL IP ADDRESS>:80 127.0.0.1:80 *><br />
<IfModule mod_security2.c><br />
SecRuleEngine Off<br />
</IfModule><br />
</pre><br />
<br />
If your control panel has this vulnerability, you can remove this, but its very possible the control panel will simply open this hole in your system again. We highly recommend you report this vulnerability to your control panel vendor, and if they are unwilling to fix this vulnerability that you find a more security concious control panel vendor.<br />
<br />
'''6) You arent loading the rules'''<br />
<br />
This is common with custom configurations. Check to make sure your webserver is configured to load the rules. Keep mind that modsecurity will still generate generic messages even though the rules are not loaded. For example, if all you see are events like this:<br />
<br />
<pre><br />
--70c19f31-A--<br />
[01/Jan/2013:11:19:13 --0300] roiKIi6Ni3EKFZSKpSUs2iEb 1.2.3.4 34978 5.6.7.8 80<br />
--70c19f31-B--<br />
HEAD / HTTP/1.1<br />
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) <br />
<br />
Accept: */*<br />
<br />
--70c19f31-F--<br />
HTTP/1.1 403 Forbidden<br />
X-Powered-By: PHP/5.4.20<br />
Expires: Thu, 19 Jan 2001 02:12:00 GMT<br />
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0<br />
Pragma: no-cache<br />
Connection: close<br />
Content-Type: text/html<br />
<br />
--70c19f31-H--<br />
Stopwatch: 1383338363503919 358184 (- - -)<br />
Stopwatch2: 1383338363503919 358184; combined=2144, p1=37, p2=2053, p3=0, p4=0, p5=53, sr=0, sw=1, l=0, gc=0<br />
Producer: ModSecurity for Apache/2.7.5 ( http://www.modsecurity.org/).<br />
Server: Apache<br />
Engine-Mode: "ENABLED"<br />
<br />
--70c19f31-Z--<br />
</pre><br />
<br />
In this example, no rule is being triggered, but modsecurity is logging a basic 403 error. It will do this if the modsecurity configuration is loaded, but not the rules. So if you see this happening on your system, and you have ruled out all other issues in this list, it means your custom configuration isnt loading the rules.<br />
<br />
[[ASL]] will automatically configure modsecurity correctly. So if you are having problems configuring modsecurity yourself, then we recommend you use [[ASL]] to setup modsecurity for you.<br />
<br />
=== Windows ===<br />
<br />
Please see the [[modsecurity iis]] page.<br />
<br />
== Automated rules updates ==<br />
<br />
Please see the [[ASL]] page for installation instructions.<br />
<br />
= Tuning the Rules/Disabling Rules =<br />
<br />
== Disabling Rules ==<br />
<br />
See the [[mod_security]] page for details.<br />
<br />
== Tuning the Rules ==<br />
<br />
See the [[mod_security]] page for details.<br />
<br />
== Troubleshoot the Rules ==<br />
<br />
See the [[Atomicorp WAF Rules Troubleshooting]] page for details.<br />
<br />
== Reporting False Positives ==<br />
<br />
See the [[Reporting False Positives]] page for details.<br />
<br />
= Notes =<br />
<br />
== Special notes for CPANEL users not using ASL ==<br />
<br />
The Atomicorp Modsecurity rules work great with Cpanel, right out of the box. To use them with Cpanel either install [[ASL]], or manually install modsecurity and make a few changes to the mod_security configuration that comes with cpanel and then you are all set!<br />
<br />
=== Installing modsecurity in cpanel ===<br />
<br />
'''Option 1) Simplest and most powerful solution'''<br />
<br />
Install [[ASL]]. This will install modsecurity, configure it and will install the rule and event management GUI available in [[ASL]]<br />
<br />
Option 2) Install just the rules<br />
<br />
=== Manually Configuring modsecurity with cpanel ===<br />
<br />
These are additional considerations for installing modsecurity with cpanel. Please read this entire page, as well as this section if you are installing modsecurity with cpanel (even if you already have modsecurity install with cpanel).<br />
<br />
We recommend if you are using cPanel that you follow this advice, as cpanel includes a very minimal configuration for modsecurity that does not include all of the required and optimal settings documented here. Our settings will make your server faster, and more importantly more secure. If you use mod_security with Cpanel you must add these additional settings to experience the full feature set of mod_security.<br />
<br />
==== Step 1 ====<br />
<br />
Make sure you have read this entire document and have setup all the require directories details above.<br />
<br />
==== Step 2: Configure directory permissions ====<br />
<br />
Certain versions of Cpanel do not run apache as a standard user (such as apache) but as the older non-privileged user "nobody". You will need to determine what use cpanel uses for the httpd processes, and that the modsecurity work directories are owned by the user that Cpanel runs apache as. To find this out you can run this command as root:<br />
<br />
ps auxwww | grep httpd<br />
<br />
root 20594 86.8 3.1 255148 181232 ? Ss 11:39 0:04 /usr/local/apache/bin/httpd -k restart<br />
root 20611 0.0 3.1 255060 179596 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20612 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20613 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20614 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20615 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20616 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
<br />
In this example from a Centos system running Cpanel the user is "nobody", so you would want to use these commands to configure the modsecurity work directories for a system where apache is running as "nobody": <br />
<br />
mkdir /var/asl<br />
mkdir /var/asl/data/<br />
mkdir /var/asl/data/msa<br />
mkdir /var/asl/data/audit<br />
mkdir /var/asl/data/suspicious<br />
chown nobody.nobody /var/asl/data/msa<br />
chown nobody.nobody /var/asl/data/audit<br />
chown nobody.nobody /var/asl/data/suspicious<br />
chmod o-rx -R /var/asl/data/*<br />
chmod ug+rwx -R /var/asl/data/*<br />
<br />
==== Step 3: Install modsecurity ====<br />
<br />
Please see the current minimum version required at the link below:<br />
<br />
https://www.atomicorp.com/wiki/index.php/Atomic_ModSecurity_Rules#Minimum_Version_of_Modsecurity_Required_to_use_the_rules<br />
<br />
==== Step 4: Install mod_uniqueid ====<br />
<br />
Cpanel users will need to manually verify that the mod_unique_id module is loaded by cpanel's apache. It should be loaded by default, but check your cpanel configuration to be sure.<br />
<br />
==== Step 5: Configure cpanel ====<br />
<br />
A typical cpanel modsec2.conf configuration file looks like this:<br />
<br />
LoadFile /opt/xml2/lib/libxml2.so<br />
LoadFile /opt/lua/lib/liblua.so<br />
LoadModule security2_module modules/mod_security2.so<br />
<IfModule mod_security2.c><br />
SecRuleEngine On<br />
# See http://www.modsecurity.org/documentation/ModSecurity-Migration-Matrix.pdf<br />
# "Add the rules that will do exactly the same as the directives"<br />
# SecFilterCheckURLEncoding On<br />
# SecFilterForceByteRange 0 255<br />
SecAuditEngine RelevantOnly<br />
SecAuditLog logs/modsec_audit.log<br />
SecDebugLog logs/modsec_debug_log<br />
SecDebugLogLevel 0<br />
SecDefaultAction "phase:2,deny,log,status:403"<br />
Include "/usr/local/apache/conf/modsec2.user.conf"<br />
</IfModule><br />
<br />
Because cpanel will overwrite this configuration, you need to modify your user configuration file. You will want to setup your user configuration file (/usr/local/apache/conf/modsec2.user.conf) as in the examples below depending on the type of license you have purchased (remote rules vs downloadable rules).<br />
<br />
==== Step 5a: Remote Rules ====<br />
<br />
If you have a remote rules license, simply add these two lines to the /usr/local/apache/conf/modsec2.user.conf file, replacing <API Key> with the value in your license signup email:<br />
<br />
''SecRemoteRulesFailAction Warn<br />
<br />
SecRemoteRules <API Key> https://waf.atomicorp.com/rules/srr.php''<br />
<br />
Additional rule classes can be specified as follows<br />
<br />
''SecRemoteRules <API Key> https://waf.atomicorp.com/rules/srr.php?antispam,recons''<br />
<br />
A full list of rule classes is available at [https://docs.atomicorp.com/gotrootModsec/remoterules.html].<br />
<br />
==== Step 5a: Downloadable Rules ====<br />
<br />
If you have a license for the downloadable rules, this is the recommended configuration and the '''minimum''' recommended rule sets that are designed to work with cpanel without [[ASL]] installed. Please be sure to read this entire page for information about additional rules that you may also want to use with cpanel.<br />
<br />
SecRequestBodyAccess On<br />
SecAuditLogType Concurrent<br />
SecResponseBodyAccess On<br />
SecResponseBodyMimeType (null) text/html text/plain text/xml<br />
SecResponseBodyLimit 2621440<br />
SecAuditLogRelevantStatus "^(?:5|4(?!04))"<br />
SecServerSignature Apache<br />
SecUploadDir /var/asl/data/suspicious<br />
SecUploadKeepFiles Off<br />
SecAuditLogParts ABIFHZ<br />
SecArgumentSeparator "&"<br />
SecCookieFormat 0<br />
SecRequestBodyInMemoryLimit 131072<br />
SecDataDir /var/asl/data/msa<br />
SecTmpDir /tmp<br />
SecAuditLogStorageDir /var/asl/data/audit<br />
SecResponseBodyLimitAction ProcessPartial<br />
<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_z_antievasion.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_zz_strict.conf<br />
Include /full/path/to/your/rules/modsecurity.d/09_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_antimalware.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/11_asl_adv_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/20_asl_useragents.conf<br />
Include /full/path/to/your/rules/modsecurity.d/30_asl_antispam.conf<br />
Include /full/path/to/your/rules/modsecurity.d/50_asl_rootkits.conf<br />
Include /full/path/to/your/rules/modsecurity.d/60_asl_recons.conf<br />
Include /full/path/to/your/rules/modsecurity.d/61_asl_recons_dlp.conf<br />
Include /full/path/to/your/rules/modsecurity.d/99_asl_jitp.conf<br />
<br />
If you want to load just some of the rules, make sure you specify only those rule files. The default list above is the recommended and supported rulesets with cpanel. Do not use the other asl rulesets with cpanel, those other rules either use other apache modules (such as mod_sed) or ASL specific features that require [[ASL]].<br />
<br />
Then run this command as root to install the rules:<br />
<br />
[[aum]] -u<br />
<br />
Or if you want to install the rules files manually, please see the [https://www.atomicorp.com/wiki/index.php/Atomic_ModSecurity_Rules#Step_8:_Download_the_ModSecurity_Rules Downloading rules] section above.<br />
<br />
==== Step 7: Restart Apache ====<br />
<br />
Restart apache, enjoy your new secure web server!<br />
<br />
<br />
<br />
==== Optional Steps ====<br />
<br />
===== Malware Scanner =====<br />
<br />
The malware scanner is included in [[ASL]], it is not included in the rules or rule subscriptions. Therefore, if you use this file:<br />
<br />
05_asl_scanner.conf<br />
<br />
Or this:<br />
<br />
99_asl_scanner.conf<br />
<br />
You will need to include your own scanner, and will need to make sure you have clamd installed and configured correctly to listen on a TCP port, or if you use a socket, make sure apache can read/write to this socket or as a last resort, run clamd as root. Using this file forces all web uploads on your system to go thru clamav to look for malware, viruses, etc. If you dont need that, then you can leave this config file out.<br />
<br />
<br />
==== Cpanel Error Messages ====<br />
<br />
==== modsecparse.pl ====<br />
<br />
'''This is a third party tool not provided by, or supported by Atomicorp.''' If you use this tool, it apparently does not work with the new fast concurrent logging system in modsecurity. The concurrent logging system is much faster, will speed up apache and is less resource intensive that the older serial method. <br />
<br />
However, if you use this tool you must use the slower serial logging method, as it does not support the faster concurrent method. To use this tool, change the SecAuditLogType setting from "Concurrent" to "Serial":<br />
<br />
SecAuditLogType Serial<br />
<br />
'''Keep in mind that this logging method is much slower, may slow down apache and is not supported.''' This performance impact is not caused by the rules. Serial logging is much slower than concurrent logging. Therefore we do not recommend you use this logging method or any tools that require it. There are lots of modsecurity log readers that can use the concurrent logging method, such as [[ASL]] and we encourage you to explore using one of those modern tools instead.<br />
<br />
==== Serial logging ====<br />
<br />
===== Discussion =====<br />
<br />
Serial logging is the older slower depreacted logging method modsecurity original used many years ago. This logging method would log the entire event in a single file. As a result, it would slow apache down because each event needed to wait for the previous event to finish writing before it could write to the log file. Events stack up and slow apache down. This incurs a significant performance penalty on apache, and of course a better method was devised for modsecurity to address this performance issue. The solution is the concurrent logging method. This generates a unique event file for each log event, logging the events data to that file instead of trying to jam tons of data into a single file, and thereby slowing down apache. All modern modsecurity log viewing tools support the concurrent method.<br />
<br />
The concurrent logging system is much faster, will speed up apache and is less resource intensive that the older serial method. This method is highly recommended over the slow serial logging method.<br />
<br />
===== Configuration =====<br />
<br />
====== aum ======<br />
<br />
If you want to use the old slower serial logging method, and you are using aum, change this setting in /etc/asl/config:<br />
<br />
MODSEC_LOGTYPE="Concurrent"<br />
<br />
<br />
To:<br />
<br />
MODSEC_LOGTYPE="Serial"<br />
<br />
<br />
And then run:<br />
<br />
aum -uf<br />
<br />
====== non-aum systems ======<br />
<br />
If you want to use the old slower serial logging method change the SecAuditLogType setting from "Concurrent" to "Serial":<br />
<br />
SecAuditLogType Serial<br />
<br />
'''Warning: Serial logging is much slower than concurrent logging and will slow down apache.''' Any performance impact is not caused by the rules. <br />
<br />
Therefore we do not recommend you use this logging method or any tools that require it. There are lots of modsecurity log readers that can use the fast concurrent logging method, such as [[ASL]] and we encourage you to explore using one of those modern tools instead of a tool that requires the slower and performance degrading serial logging method.<br />
<br />
If you change your system to the slower Serial method, you may also want to change the logfile name you are using for your modsecurity logs. You can do that by changing this option in your configuration:<br />
<br />
SecAuditLog logs/audit_log</div>Mshinnhttps://wiki.atomicorp.com/wiki/index.php/Atomic_ModSecurity_RulesAtomic ModSecurity Rules2022-09-27T17:21:46Z<p>Mshinn: /* Step 5: Configure cpanel */</p>
<hr />
<div>[[Atomic Secured Linux]] includes modsecurity, and the Real Time GotRoot.com/Atomicorp Modsecurity Rules. These docs are for users that do not have [[ASL]].<br />
<br />
'''ASL will install and configure modsecurity, and provides a powerful and easy use to GUI to manage all of this for you. If you don't have ASL, [https://www.atomicorp.com/amember/cart/index/index?c=1 upgrade to ASL today!]'''<br />
<br />
= '''About the rules''' =<br />
<br />
The gotroot.com rules are written by us - we are the gotroot guys. Same great rules, same team, ten years of writing modsecurity rules and still going strong! GotRoot is our Information Assurance lab and [http://www.atomicorp.com Atomicorp] is the product arm of [http://www.progllc.com Prometheus Global] (the parent company for both). So when you get the gotroot.com rules from atomicorp.com or gotroot.com - you're getting the same rules from the same people that created, write and maintain them. In the future we will be merging the gotroot.com, atomicrocketturtle and atomicorp websites into the atomicorp.com website.<br />
<br />
We publish two versions of the rules:<br />
<br />
'''RealTime Rules:''' The latest and greatest version of the rules, with all the performance enhancements, new security features and bug fixes released by us on a daily basis. These rules are fully supported and are recommended for production use.<br />
<br />
'''Free/Delayed Rules:''' A delayed subset of the Advanced rules.<br />
<br />
Installation of the rules assumes a certain level of comfort with configuring apache. If you are not comfortable with configuring apache, you should contact someone that is, or use our [[Atomic Secured Linux]] product which does this automatically for you, and does not require you to configure apache.<br />
<br />
== Getting the rules ==<br />
<br />
[https://www.atomicorp.com/amember/cart/index/index?c=6 Click here] to get the Atomicorp ModSecurity Rules.<br />
<br />
== '''Atomic ModSecurity Rules Frequently Asked Questions''' ==<br />
<br />
Please see the [[Atomic ModSecurity Rules FAQ]] wiki page.<br />
<br />
== '''Real Time Rule Support''' ==<br />
<br />
If you have a subscription to the real time rules, you can request email support by sending an email to:<br />
<br />
support@atomicorp.com<br />
<br />
The Customer Support Forums are located here:<br />
<br />
[http://www.atomicorp.com/forums Customer Support Forums]<br />
<br />
And the Custom Support Portal is located here (you can submit bug reports and open cases through the portal):<br />
<br />
[https://www.atomicorp.com/portal Customer Support Portal]<br />
<br />
== '''Licenses''' ==<br />
<br />
The Real Time Atomic ModSecurity Rules are licensed by the server. You can order licenses from the online store at the link below:<br />
<br />
[https://www.atomicorp.com/amember/cart/index/index?c=6 Online Store]<br />
<br />
If you require additional licenses please log into the [https://www.atomicorp.com/support/license-manager.html AtomiCorp License Manager]. You can add additional systems there, you can control your payment methods and you can also sign up to become an affiliate.<br />
<br />
=== License Terms and Conditions ===<br />
<br />
Purchase of an Atomicorp ModSecurity rule license entitles the purchaser to access and download from the Atomicorp Repository to a single IP address within the time period of the license. A separate license is required for each dedicated server/host or VPS that the rule set is installed upon or is protecting.<br />
<br />
Atomicorp ModSecurity rules installed upon a Reverse Proxy WAF appliance/server requires a separate license. Please contact Atomicorp support for details.<br />
<br />
The rule set cannot be copied, mirrored, or reproduced under protection of US and International copyright laws.<br />
<br />
Use of the rule set is limited to the time period of the license. If the license period of a rule set expires, it must must removed from its installed server and no longer used. Atomicorp reserves the right to track and enforce license compliance of the Atomicorp Modsecurity rule sets.<br />
<br />
Agreement to these terms and conditions and the Atomicorp [https://atomicorp.com/eula.html End User License Agreement] is required to download and use the Atomicorp ModSecurity rules.<br />
<br />
== Important Information about the Rules ==<br />
<br />
=== Minimum Version of Modsecurity Required to use the rules ===<br />
<br />
The rules are supported with the following versions of Modsecurity:<br />
<br />
<br />
* 2.9.3<br />
<br />
We recommend customers use our modsecurity builds, as they are tested to ensure all features work correctly. Third party builds may not include the correct libraries, may cause problems with your web server, including crashes and may disable or incorrectly enable features in modsecurity that can cause unpredictable behavior or failure of rules to process correctly.<br />
<br />
If you need a solution to keep the rules and modsecurity up to date and in sync with your version of modsecurity automatically, please use [[aum]] or [[ASL]] which will do this for you automatically.<br />
<br />
==== What versions of modsecurity do the rules work with ====<br />
<br />
They work with both modsecurity 2.9.x, and modsecurity 3.x.<br />
<br />
=== What does each rule family do? ===<br />
<br />
Please see the [[modsecurity_rule_families]] documents.<br />
<br />
= Installation =<br />
<br />
== Easy One Step Installation ==<br />
<br />
<br />
<br />
===== Full Management Suite =====<br />
<br />
Install [[ASL]]. This installs everything: modsecurity, all the rules, the GUI, rule manager and all ASL components, plus it includes the subscription to the real time rules.<br />
<br />
ASL will automatically download and keep your rules up to date, and will ensure that modsecurity stays up to date so your system can support the latest rules. ASL also provides you with a full security management suite, which will allow you to manage, edit and configure your rules through a web console. It will also protect you from uploaded malware, brute force attacks, DOS attacks, rootkits and many other threats that a WAF can not protect you from.<br />
<br />
A full list of ASLs features is available at the URL below:<br />
<br />
https://www.atomicorp.com/products/asl.html<br />
<br />
===== Just a downloader =====<br />
<br />
We also provide an automated rule updater and modsecurity installation tool, called [[aum]]. You can read more about it on the [[aum]] page. You can install it by running these commands as root:<br />
<br />
Step 1) Install [[aum]]<br />
<br />
''wget -q -O - https://updates.atomicorp.com/installers/aum |bash''<br />
<br />
Step 2) Configure [[aum]]<br />
<br />
''aum configure''<br />
<br />
Step 3) Tell [[aum]] to install the rules<br />
<br />
''aum upgrade''<br />
<br />
You can read more about aum on the [[aum]] documentation page.<br />
<br />
Note: This capability is included in [[ASL]]. ASL users do not need to install aum, its already included.<br />
<br />
== (Optional) Do It Yourself Installation ==<br />
<br />
Note: A manual installation is not necessary if you have [[ASL]] installed. ASL will configure and install modsecurity, and the rules, automatically. This is also not necessary if you are using our new AUM software to handle rule download and installation.<br />
<br />
=== Linux ===<br />
<br />
==== Step 1: Download ModSecurity ====<br />
<br />
Binaries:<br />
<br />
[http://updates.atomicorp.com/channels/atomic/ Install modsecurity from the Atomicorp software repository]<br />
<br />
Source Code:<br />
<br />
[http://updates.atomicorp.com/channels/atomic/ Install modsecurity from the Atomicorp software repository]<br />
<br />
Please note that the rules are only supported with the version of modsecurity [http://wiki.atomicorp.com/wiki/index.php/Atomic_ModSecurity_Rules#Minimum_Version_of_Modsecurity_Required_to_use_the_rules identified in this section of the wiki.]<br />
<br />
Note: Please contact us before using a third party or source build of modsecurity. Its critical modsecurity be built correctly to work with the rules.<br />
<br />
==== Step 2: Set up and configure directories ====<br />
<br />
Create the following directories as root:<br />
<br />
mkdir /etc/httpd/modsecurity.d<br />
mkdir /var/asl<br />
mkdir /var/asl/tmp<br />
mkdir /var/asl/data<br />
mkdir /var/asl/data/msa<br />
mkdir /var/asl/data/audit<br />
mkdir /var/asl/data/suspicious<br />
<br />
==== Step 3: Set permissions for directories ====<br />
<br />
Set the following permissions on the directories you just created. In this example these directories are set to be owned by "apache" and the group "apache", which is standard on a normal Centos or RHEL system. However some control panels configure apache to run as a different user, such as nobody, or http. <br />
<br />
To determine what user this is, check your system to see what user your webserver uses. You can use this command to find the user:<br />
<br />
ps auxwww | grep httpd<br />
<br />
The output will look similar to this:<br />
<br />
(RHEL/Centos example with or without Plesk)<br />
<br />
root 26755 0.0 4.3 430752 86432 ? Ss 04:30 0:01 /usr/sbin/httpd<br />
'''apache''' 26908 0.0 3.7 300564 75076 ? S 04:30 0:00 /usr/sbin/httpd<br />
'''apache''' 26909 0.1 5.5 495812 112084 ? S 04:30 0:37 /usr/sbin/httpd<br />
'''apache''' 26910 0.0 5.3 495424 106672 ? S 04:30 0:23 /usr/sbin/httpd<br />
'''apache''' 26911 0.1 5.7 495892 114368 ? S 04:30 0:57 /usr/sbin/httpd<br />
'''apache''' 26912 0.1 5.7 496056 114440 ? S 04:30 0:52 /usr/sbin/httpd<br />
'''apache''' 26913 0.1 5.5 496604 110692 ? S 04:30 0:57 /usr/sbin/httpd<br />
'''apache''' 26914 0.0 5.7 499324 116236 ? S 04:30 0:16 /usr/sbin/httpd<br />
'''apache''' 26915 0.2 5.5 493600 112192 ? S 04:30 1:09 /usr/sbin/httpd<br />
'''apache''' 26916 0.1 6.4 513760 129992 ? S 04:30 0:30 /usr/sbin/httpd<br />
<br />
In this example the user in bold is "apache" (this may be different for your system). This is the user you will want to set the directory permissions to (as in the example below):<br />
<br />
chown apache.apache /var/asl/data/msa<br />
chown apache.apache /var/asl/data/audit<br />
chown apache.apache /var/asl/data/suspicious<br />
chmod o-rx -R /var/asl/data/*<br />
chmod ug+rwx -R /var/asl/data/*<br />
<br />
(RHEL/Centos example with Cpanel)<br />
<br />
root 20594 86.8 3.1 255148 181232 ? Ss 11:39 0:04 /usr/local/apache/bin/httpd -k restart<br />
root 20611 0.0 3.1 255060 179596 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20612 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20613 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20614 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20615 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20616 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
<br />
In this example from a Centos system running Cpanel the user is "nobody", so you would want to use these commands:<br />
<br />
chown nobody.nobody /var/asl/data/msa<br />
chown nobody.nobody /var/asl/data/audit<br />
chown nobody.nobody /var/asl/data/suspicious<br />
chmod o-rx -R /var/asl/data/*<br />
chmod ug+rwx -R /var/asl/data/*<br />
<br />
==== Step 4: (Optional) Create rule updater directories ====<br />
These directories must as be created if you use optional rules updater. Create these directories as root and they only need to be accessed by root:<br />
<br />
mkdir /var/asl/updates<br />
mkdir /var/asl/rules/<br />
mkdir /var/asl/rules/clamav<br />
<br />
==== Step 5: Create the whitelist file ====<br />
<br />
Create this file:<br />
<br />
touch /etc/asl/whitelist<br />
<br />
This file contains a list of IPs you want to exclude from ALL rules. That means those IPs can do anything to your system - so be very very careful about what IPs you add to this list. This is a dangerous thing to do. The format of the file is a single IP, per line. <br />
<br />
Cpanel users should skip to the notes at the bottom of this page for special additional actions for cpanel systems. All other users should continue with these instructions.<br />
<br />
==== Step 6: Configure your webserver ====<br />
<br />
===== nginx =====<br />
<br />
===== Step 6a: configure nginx to load modsecurity =====<br />
<br />
====== nginx proxying to a backend ======<br />
<br />
If you are using nginx as a frontend to another webserver, then add the following directives to your nginx.conf file.<br />
<br />
<pre><br />
location / {<br />
ModSecurityEnabled on;<br />
ModSecurityConfig modsecurity.conf;<br />
proxy_pass http://localhost:8080;<br />
proxy_read_timeout 180s;<br />
}<br />
<br />
</pre><br />
<br />
Change "localhost:8011" to the server you are proxying nginx to, and change 8080 to the portnumber for that server. For example, if you are running apache on port 8088 on localhost the line would be:<br />
<br />
proxy_pass http://localhost:8088;<br />
<br />
====== nginx standalone ======<br />
<br />
If you are only using nginx, and not using it as a frontend to another web server then you want to use this configuration:<br />
<br />
<pre><br />
location / {<br />
ModSecurityEnabled on;<br />
ModSecurityConfig modsecurity.conf;<br />
}<br />
</pre><br />
<br />
===== Apache =====<br />
<br />
===== Step 6a: configure apache to load modsecurity =====<br />
<br />
You then need to tell apache to load modsecurity. Depending on your apache configuration, apache should be configured to include configuration files. If you have a setting like this in your apache config:<br />
<br />
Include conf.d/*.conf<br />
<br />
Then you are setup to load external configuration files. If you do not have this setup, its highly recommend you add this. This installation guide is written for this type of configuration. Loading mod_security occurs by including a modsecurity configuration file in that directory. We recommend you name the name 00_modsecurity.conf to ensure it runs first. Its vitally important that modsecurity load before other modules, otherwise attacks can occur before modsecurity scans them and some attacks can be missed.<br />
<br />
An example 00_modsecurity.conf file that works with our files is included here:<br />
<br />
LoadModule security2_module modules/mod_security2.so<br />
LoadModule unique_id_module modules/mod_unique_id.so<br />
<IfModule mod_security2.c><br />
Include modsecurity.d/tortix_waf.conf<br />
</IfModule><br />
<br />
Install this file in your conf.d directory. On a standard RHEL or Centos system that directory is located here:<br />
<br />
/etc/httpd/conf.d/<br />
<br />
=== Step 7: Configure modsecurity ===<br />
<br />
You then need to configure modsecurity. This is done via the an apache configuration file. In this example, we will create the file "tortix_waf.conf". Here is an example file that works with our rules:<br />
<br />
SecRuleEngine On<br />
SecRequestBodyAccess On<br />
SecResponseBodyAccess On<br />
SecResponseBodyMimeType (null) text/html text/plain text/xml<br />
SecResponseBodyLimit 2621440<br />
SecServerSignature Apache<br />
SecComponentSignature 200911012341<br />
SecUploadDir /var/asl/data/suspicious<br />
SecUploadKeepFiles Off<br />
SecAuditEngine RelevantOnly<br />
SecAuditLogRelevantStatus "^(?:5|4(?!04))"<br />
SecAuditLogType Concurrent<br />
SecAuditLog logs/audit_log<br />
[[SecAuditLogParts]] ABIFHZ<br />
SecArgumentSeparator "&" <br />
SecCookieFormat 0<br />
SecRequestBodyInMemoryLimit 131072<br />
SecDataDir /var/asl/data/msa<br />
SecTmpDir /tmp<br />
SecAuditLogStorageDir /var/asl/data/audit<br />
SecResponseBodyLimitAction ProcessPartial<br />
SecAuditLogDirMode 0770<br />
SecPcreMatchLimit 250000 <br />
SecPcreMatchLimitRecursion 250000<br />
<br />
You will want to install this file in your modsecurity.d directory, which is located here if you follow the instructions above:<br />
<br />
/etc/httpd/modsecurity.d<br />
<br />
==== tortix_waf.conf ====<br />
<br />
You can also download an example version of the modsecurity configuration file from here:<br />
<br />
https://www.atomicorp.com/installer/tortix_waf.conf<br />
<br />
[[ASL]] will automatically generate this file depending on your needs. If you are not using ASL, you will need to modify this configuration file to suit your system and modsecurity requirements.<br />
<br />
==== Step 8: Download the ModSecurity Rules ====<br />
<br />
See the [[Downloading Rules]] page.<br />
<br />
==== Step 9: Install the rules ====<br />
<br />
==== Remove any previous installations of rules ====<br />
<br />
If you have installed our delayed rules, you will need to make sure you have deleted them. You will not want to have any older versions of the rules installed.<br />
<br />
Also, if you have installed any third party modsecurity rules, you will want to make sure they are using rule id's that are assigned to them. The modsecurity project assigns ranges to the rule id's modsecurity uses. Modsecurity requires a unique id for each rule, otherwise you will get an error like this:<br />
<br />
ModSecurity: Found another rule with the same id<br />
<br />
This means either that someone else is using the same rule id's assigned to our ruleset by the modsecurity project (our official range is 300000-399999), or you have loaded our rules twice.<br />
<br />
==== Installation ====<br />
<br />
Download the rules to a temporary directory using your favorite download tool. Extract the rules:<br />
<br />
tar zxvf /var/asl/updates/modsec-200911012341.tar.gz<br />
<br />
Then copy each of the ASL rule files you wish to use into /etc/httpd/modsecurity.d. Do not copy all of the rule files, you will need to select rule files that are appropriate for your system. Or simply use [[aum]] or [[ASL]] to do this for you automatically.<br />
<br />
If you are using cpanel, please see the notes at the bottom of this page, cpanel does not use the standard locations for apache configuration files.<br />
<br />
Finally, load the rules. '''Make sure you specify only those rule files that are appropriate for your system.''' For example:<br />
<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/99_asl_jitp.conf<br />
<br />
'''Warning: You should NOT include all the rules. There are rulesets, documented above, that replace other rulesets and are incompatible with each other.'''<br />
<br />
===== Recommend minimum rulesets =====<br />
<br />
====== apache ======<br />
<br />
The recommended ''minimum ruleset'' to load is:<br />
<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_0_global.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_antimalware.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/11_asl_adv_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/20_asl_useragents.conf<br />
Include /full/path/to/your/rules/modsecurity.d/30_asl_antispam.conf<br />
Include /full/path/to/your/rules/modsecurity.d/50_asl_rootkits.conf<br />
Include /full/path/to/your/rules/modsecurity.d/60_asl_recons.conf<br />
Include /full/path/to/your/rules/modsecurity.d/61_asl_recons_dlp.conf<br />
Include /full/path/to/your/rules/modsecurity.d/99_asl_jitp.conf<br />
<br />
If you have modsecurity 2.9.0 and up installed, you should also load additional rule files and should use this ruleset:<br />
<br />
Include /full/path/to/your/rules/modsecurity.d/000_asl_threat_intelligence.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_zz_strict.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_0_global.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_z_antievasion.conf<br />
Include /full/path/to/your/rules/modsecurity.d/01_asl_content.conf<br />
Include /full/path/to/your/rules/modsecurity.d/01_asl_content_z.conf<br />
Include /full/path/to/your/rules/modsecurity.d/03_asl_dos.conf<br />
Include /full/path/to/your/rules/modsecurity.d/09_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_antimalware.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/11_asl_adv_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/11_asl_data_loss.conf<br />
Include /full/path/to/your/rules/modsecurity.d/12_asl_adv_xss_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/20_asl_useragents.conf<br />
Include /full/path/to/your/rules/modsecurity.d/30_asl_antispam.conf<br />
Include /full/path/to/your/rules/modsecurity.d/50_asl_rootkits.conf<br />
Include /full/path/to/your/rules/modsecurity.d/51_asl_rootkits.conf<br />
Include /full/path/to/your/rules/modsecurity.d/60_asl_recons.conf<br />
Include /full/path/to/your/rules/modsecurity.d/61_asl_recons_dlp.conf<br />
Include /full/path/to/your/rules/modsecurity.d/99_asl_jitp.conf<br />
Include /full/path/to/your/rules/modsecurity.d/98_asl_adv_redactor.conf<br />
<br />
If you have a [[Local DNS resolver]] setup and properly configured on your system, and you are using modsecurity 2.9.0 and up we also recommend these additional rulesets:<br />
<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_z_searchengines.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_z_aa_threat_intelligence.conf<br />
Include /full/path/to/your/rules/modsecurity.d/99_asl_zzzz_threat_intelligence.conf<br />
<br />
Note: Some of these rulesets are designed to work with advanced security management systems such as [[ASL]] and may not work completely without an advanced management system.<br />
<br />
====== nginx ======<br />
<br />
The same rulesets as apache will work with nginx.<br />
<br />
====== litespeed ======<br />
<br />
[[Litespeed]] has a proprietary implementation of mod_security. It does not support all the features that mod_security with apache, IIS and nginx does. Therefore, you can not use all the rulesets with Litespeed, as Litespeed does not support those features of mod_security. The following rulesets are recommended with Litespeed:<br />
<br />
The recommended ''minimum ruleset'' to load is:<br />
<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_0_global.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_antimalware.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/11_asl_adv_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/20_asl_useragents.conf<br />
Include /full/path/to/your/rules/modsecurity.d/30_asl_antispam.conf<br />
Include /full/path/to/your/rules/modsecurity.d/50_asl_rootkits.conf<br />
Include /full/path/to/your/rules/modsecurity.d/60_asl_recons.conf<br />
Include /full/path/to/your/rules/modsecurity.d/61_asl_recons_dlp.conf<br />
Include /full/path/to/your/rules/modsecurity.d/99_asl_jitp.conf<br />
<br />
If you require more advanced protection, you should also load additional rule files and should use this ruleset:<br />
<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_zz_strict.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_x_searchengines.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_y_searchengines.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_0_global.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_z_antievasion.conf<br />
Include /full/path/to/your/rules/modsecurity.d/01_asl_content.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_zz_strict.conf<br />
Include /full/path/to/your/rules/modsecurity.d/03_asl_dos.conf<br />
Include /full/path/to/your/rules/modsecurity.d/09_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_antimalware.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/11_asl_adv_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/11_asl_data_loss.conf<br />
Include /full/path/to/your/rules/modsecurity.d/12_asl_adv_xss_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/20_asl_useragents.conf<br />
Include /full/path/to/your/rules/modsecurity.d/30_asl_antispam.conf<br />
Include /full/path/to/your/rules/modsecurity.d/50_asl_rootkits.conf<br />
Include /full/path/to/your/rules/modsecurity.d/51_asl_rootkits.conf<br />
Include /full/path/to/your/rules/modsecurity.d/60_asl_recons.conf<br />
Include /full/path/to/your/rules/modsecurity.d/61_asl_recons_dlp.conf<br />
Include /full/path/to/your/rules/modsecurity.d/99_asl_jitp.conf<br />
<br />
<br />
Note: [[Litespeed]] does not support content inspection (outbound rules), or lua based rules. Therefore, the following rulesets Litespeed does not support, and loading them will have no effect on the system:<br />
<br />
<br />
00_asl_z_searchengines.conf<br />
00_asl_z_aa_threat_intelligence.conf<br />
12_asl_brute.conf<br />
98_asl_adv_redactor.conf<br />
99_asl_zzzz_threat_intelligence.conf<br />
<br />
Note: Some of these rulesets are designed to work with advanced security management systems such as [[ASL]] and may not work completely without an advanced management system.<br />
<br />
===== Notes on Scanner ruleset =====<br />
<br />
NOTE: If you use this file:<br />
<br />
05_asl_scanner.conf<br />
<br />
Or this file:<br />
<br />
99_asl_scanner.conf<br />
<br />
[[ASL]] includes malware upload scanning, rules subscriptions do not.<br />
<br />
If you wish to use this ruleset, and you are not using [[ASL]], then you will need to create a script to pass the files to clamd and read the result. Make sure you have clamd installed and configured correctly to list on a TCP port, or if you use a socket, make sure apache can read/write to this socket or as a last resort, run clamd as root. Using this file will force all web uploads on your system to go thru clamav to look for malware, viruses, etc. If you dont need that, then you can leave this config file out. <br />
<br />
Real time malware upload protection is included in [[ASL]] and uses a faster method than the older style modsecurity scripting method above. So if you need realtime malware upload protection (for web, FTP, or even realtime), then upgrade to [[ASL]] which includes highspeed malware upload protection, full support, automatic and hassle free installation. ASL also protects against any form of upload of malware, including HTTP, HTTPS, SSH and FTP uploads and includes our real-time malware detection and prevention system which will detect and block any malicious software running on the system in realtime. This is just one of the many many features of [[ASL]].<br />
<br />
==== Step 10: Test your web server ====<br />
===== Test nginx =====<br />
<br />
nginx -t -c <NGINX_CONFIG_FILE><br />
<br />
Where NGINX_CONFIG_FILE is your nginx.conf file.<br />
<br />
===== Test Apache =====<br />
<br />
Before restarting apache we recommend you test your configuration by running apache with the "configtest" command. On a standard system you can do this by calling your apache init file like this:<br />
<br />
/etc/init.d/httpd configtest<br />
<br />
If you get errors, check to see that you don't have some extraneous configuration files installed.<br />
<br />
===== Testing to see if the rules are loaded =====<br />
'''<br />
Step 1)''' (for non [[ASL]] systems)<br />
<br />
Make sure you have the rules installed exactly as described on this page. This test may not work if you have not followed these instructions. (If you used ASL to setup your WAF, and you have not installed any third party tools that configure, install or manage modsecurity then your rules are installed correctly and you do not need to review the instructions on this page. If you have manually altered your modsecurity configuration then you will need to review this entire article. Manual modifications of ASL modsecurity configurations are not supported.)<br />
<br />
'''Step 2) Make sure all rules are enabled'''<br />
<br />
'''Ensure that you do not have any of our rules disabled.''' This test assumes you do not have any rules disabled, that you are not whitelisting the source of this test and that your have the Atomicorp rules loaded.<br />
<br />
'''Step 3) Test from a non-whitelisted system''' <br />
<br />
Make sure you do not have the system you are performing this from is whitelisted<br />
<br />
For example, cpanels default modsecurity configuration will configure modsecurity to ignore everything from 127.0.0.1, or from the system itself. So if you perform the test above from the server itself, and you have not removed this cpanel whitelist, then this test will not work.<br />
<br />
'''Step 4) Run the test'''<br />
<br />
On the system where the rules are installed run this command (this assumes you have wget installed, '''127.0.0.1 is NOT whitelisted''' and a web server is listening on 127.0.0.1):<br />
<br />
''wget http://localhost/foo.php?foo=http://www.example.com''<br />
<br />
If the test worked, should get a 403 error if the rules are loaded, which will look similar to this:<br />
<br />
<pre><br />
--2010-05-27 20:12:25-- http://localhost/foo.php?foo=http://www.example.com<br />
Resolving localhost... 127.0.0.1<br />
Connecting to localhost|127.0.0.1|:80... connected.<br />
HTTP request sent, awaiting response... 403 Forbidden<br />
2010-05-27 20:12:25 ERROR 403: Forbidden.<br />
</pre><br />
<br />
If you do not get a 403 error, the test did not work.<br />
<br />
You can also use your browser to test the rules by going to a URL similar to this:<br />
<br />
http://YOUR_HOST/foo.php?foo=http://www.example.com<br />
<br />
Remember to replace YOUR_HOST with the actual HOSTNAME or IP of the server.<br />
<br />
If the rules are properly loaded, you should get a 403 error, if you do not get a 403 error, the rules are not loaded correctly and you need to check your configuration to ensure that you have followed the instructions above correctly.<br />
<br />
If you get a 403 error from the command line and a 404 error from the browser, check to make sure the computer you are testing the browser from is not whitelisted on the server.<br />
<br />
Note: If you do not have wget installed, then you will need to install it or a similar tool to run this test from a Linux or UNIX based system. If you are using Windows, you can use a similar tool or your browser.<br />
<br />
====== What to do if you do not get a 403 error ======<br />
<br />
If you get a different error, such as a 404 error or a 5xx series error check your configuration. The following are common causes of this:<br />
<br />
'''1) You have rules disabled'''<br />
<br />
Make sure you do not have any rules disabled.<br />
<br />
'''2) Your IP is whitelisted'''<br />
<br />
There is a rule whitelisting the system you are conducting this test from. Whitelisting tells the WAF to ignore everything from that source.<br />
<br />
For example, cpanels default modsecurity configuration will configure modsecurity to ignore everything from 127.0.0.1, or from the system itself. So if you perform the test above from the server itself, and you have not removed this cpanel whitelist, then you will not get a 403 error. More than likely you will get a 404 error. The solution is to remove any whitelists from your system.<br />
<br />
Note: Whitelisting the server itself can open a hole in your security. You should not whitelist localhost or the servers own IP address, particularly if you have multi users on the system. This is both unnecessary, and doing so will allow any users on the system to carry out attacks on other domains on the system unimpeded. Make sure you do not have any rules like that, this opens a very large hole in your system.<br />
<br />
'''3) Local error message is different'''<br />
<br />
You or someone else may have configured your system to use a different error message. Check your configuration, and make sure it exactly matches the ones on this wiki. IF you are using kind of plugin that does not return a 403 when a connection is rejected, and you must use this, then you will need to manually check your mod_security logs to see if your test is being rejected by modsecurity. If it is, then your rules are working correctly and you can ignore the error code.<br />
<br />
'''4) Third party addons''' <br />
<br />
You have third party rules or addons installed with your modsecurity configuration that are changing the responses. Remove all third party addons, and make sure your configuration exactly matches the instructions on this page<br />
<br />
'''5) Insecurely configured apache'''<br />
<br />
Some control panels are known to disable modsecurity on localhost, and on the systems IP addresses. These highly insecure control panels essentially disable modsecurity if an attacker connects to the systems IP address. This of course leaves your system wide open to attack, and if you are unlucky enough to be using one of these control panels we recommend you report this to your control panel vendor as a serious vulnerability. If they are unwilling to fix it, then we recommend you find a more security concious control panel vendor.<br />
<br />
Example:<br />
<br />
We have seen some control panels that configure modsecurity to be disabled in the /etc/httpd/conf/httpd.conf file for all the local IPs on the system. <br />
<br />
<pre><br />
<VirtualHost <LOCAL IP ADDRESS>:80 127.0.0.1:80 *><br />
<IfModule mod_security2.c><br />
SecRuleEngine Off<br />
</IfModule><br />
</pre><br />
<br />
If your control panel has this vulnerability, you can remove this, but its very possible the control panel will simply open this hole in your system again. We highly recommend you report this vulnerability to your control panel vendor, and if they are unwilling to fix this vulnerability that you find a more security concious control panel vendor.<br />
<br />
'''6) You arent loading the rules'''<br />
<br />
This is common with custom configurations. Check to make sure your webserver is configured to load the rules. Keep mind that modsecurity will still generate generic messages even though the rules are not loaded. For example, if all you see are events like this:<br />
<br />
<pre><br />
--70c19f31-A--<br />
[01/Jan/2013:11:19:13 --0300] roiKIi6Ni3EKFZSKpSUs2iEb 1.2.3.4 34978 5.6.7.8 80<br />
--70c19f31-B--<br />
HEAD / HTTP/1.1<br />
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) <br />
<br />
Accept: */*<br />
<br />
--70c19f31-F--<br />
HTTP/1.1 403 Forbidden<br />
X-Powered-By: PHP/5.4.20<br />
Expires: Thu, 19 Jan 2001 02:12:00 GMT<br />
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0<br />
Pragma: no-cache<br />
Connection: close<br />
Content-Type: text/html<br />
<br />
--70c19f31-H--<br />
Stopwatch: 1383338363503919 358184 (- - -)<br />
Stopwatch2: 1383338363503919 358184; combined=2144, p1=37, p2=2053, p3=0, p4=0, p5=53, sr=0, sw=1, l=0, gc=0<br />
Producer: ModSecurity for Apache/2.7.5 ( http://www.modsecurity.org/).<br />
Server: Apache<br />
Engine-Mode: "ENABLED"<br />
<br />
--70c19f31-Z--<br />
</pre><br />
<br />
In this example, no rule is being triggered, but modsecurity is logging a basic 403 error. It will do this if the modsecurity configuration is loaded, but not the rules. So if you see this happening on your system, and you have ruled out all other issues in this list, it means your custom configuration isnt loading the rules.<br />
<br />
[[ASL]] will automatically configure modsecurity correctly. So if you are having problems configuring modsecurity yourself, then we recommend you use [[ASL]] to setup modsecurity for you.<br />
<br />
=== Windows ===<br />
<br />
Please see the [[modsecurity iis]] page.<br />
<br />
== Automated rules updates ==<br />
<br />
Please see the [[ASL]] page for installation instructions.<br />
<br />
= Tuning the Rules/Disabling Rules =<br />
<br />
== Disabling Rules ==<br />
<br />
See the [[mod_security]] page for details.<br />
<br />
== Tuning the Rules ==<br />
<br />
See the [[mod_security]] page for details.<br />
<br />
== Troubleshoot the Rules ==<br />
<br />
See the [[Atomicorp WAF Rules Troubleshooting]] page for details.<br />
<br />
== Reporting False Positives ==<br />
<br />
See the [[Reporting False Positives]] page for details.<br />
<br />
= Notes =<br />
<br />
== Special notes for CPANEL users not using ASL ==<br />
<br />
The Atomicorp Modsecurity rules work great with Cpanel, right out of the box. To use them with Cpanel either install [[ASL]], or manually install modsecurity and make a few changes to the mod_security configuration that comes with cpanel and then you are all set!<br />
<br />
=== Installing modsecurity in cpanel ===<br />
<br />
'''Option 1) Simplest and most powerful solution'''<br />
<br />
Install [[ASL]]. This will install modsecurity, configure it and will install the rule and event management GUI available in [[ASL]]<br />
<br />
Option 2) Install just the rules<br />
<br />
=== Manually Configuring modsecurity with cpanel ===<br />
<br />
These are additional considerations for installing modsecurity with cpanel. Please read this entire page, as well as this section if you are installing modsecurity with cpanel (even if you already have modsecurity install with cpanel).<br />
<br />
We recommend if you are using cPanel that you follow this advice, as cpanel includes a very minimal configuration for modsecurity that does not include all of the required and optimal settings documented here. Our settings will make your server faster, and more importantly more secure. If you use mod_security with Cpanel you must add these additional settings to experience the full feature set of mod_security.<br />
<br />
==== Step 1 ====<br />
<br />
Make sure you have read this entire document and have setup all the require directories details above.<br />
<br />
==== Step 2: Configure directory permissions ====<br />
<br />
Certain versions of Cpanel do not run apache as a standard user (such as apache) but as the older non-privileged user "nobody". You will need to determine what use cpanel uses for the httpd processes, and that the modsecurity work directories are owned by the user that Cpanel runs apache as. To find this out you can run this command as root:<br />
<br />
ps auxwww | grep httpd<br />
<br />
root 20594 86.8 3.1 255148 181232 ? Ss 11:39 0:04 /usr/local/apache/bin/httpd -k restart<br />
root 20611 0.0 3.1 255060 179596 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20612 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20613 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20614 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20615 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20616 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
<br />
In this example from a Centos system running Cpanel the user is "nobody", so you would want to use these commands to configure the modsecurity work directories for a system where apache is running as "nobody": <br />
<br />
mkdir /var/asl<br />
mkdir /var/asl/data/<br />
mkdir /var/asl/data/msa<br />
mkdir /var/asl/data/audit<br />
mkdir /var/asl/data/suspicious<br />
chown nobody.nobody /var/asl/data/msa<br />
chown nobody.nobody /var/asl/data/audit<br />
chown nobody.nobody /var/asl/data/suspicious<br />
chmod o-rx -R /var/asl/data/*<br />
chmod ug+rwx -R /var/asl/data/*<br />
<br />
==== Step 3: Install modsecurity ====<br />
<br />
Please see the current minimum version required at the link below:<br />
<br />
https://www.atomicorp.com/wiki/index.php/Atomic_ModSecurity_Rules#Minimum_Version_of_Modsecurity_Required_to_use_the_rules<br />
<br />
==== Step 4: Install mod_uniqueid ====<br />
<br />
Cpanel users will need to manually verify that the mod_unique_id module is loaded by cpanel's apache. It should be loaded by default, but check your cpanel configuration to be sure.<br />
<br />
==== Step 5: Configure cpanel ====<br />
<br />
A typical cpanel modsec2.conf configuration file looks like this:<br />
<br />
LoadFile /opt/xml2/lib/libxml2.so<br />
LoadFile /opt/lua/lib/liblua.so<br />
LoadModule security2_module modules/mod_security2.so<br />
<IfModule mod_security2.c><br />
SecRuleEngine On<br />
# See http://www.modsecurity.org/documentation/ModSecurity-Migration-Matrix.pdf<br />
# "Add the rules that will do exactly the same as the directives"<br />
# SecFilterCheckURLEncoding On<br />
# SecFilterForceByteRange 0 255<br />
SecAuditEngine RelevantOnly<br />
SecAuditLog logs/modsec_audit.log<br />
SecDebugLog logs/modsec_debug_log<br />
SecDebugLogLevel 0<br />
SecDefaultAction "phase:2,deny,log,status:403"<br />
Include "/usr/local/apache/conf/modsec2.user.conf"<br />
</IfModule><br />
<br />
Because cpanel will overwrite this configuration, you need to modify your user configuration file. You will want to setup your user configuration file (/usr/local/apache/conf/modsec2.user.conf) as in the examples below depending on the type of license you have purchased (remote rules vs downloadable rules).<br />
<br />
==== Step 5a: Remote Rules ====<br />
<br />
If you have a remote rules license, simply add these two lines to the /usr/local/apache/conf/modsec2.user.conf file,, replacing <API Key> with the value in your license signup email:<br />
<br />
''SecRemoteRulesFailAction Warn<br />
<br />
SecRemoteRules <API Key> https://waf.atomicorp.com/rules/srr.php''<br />
<br />
Additional rule classes can be specified as follows<br />
<br />
''SecRemoteRules <API Key> https://waf.atomicorp.com/rules/srr.php?antispam,recons''<br />
<br />
A full list of rule classes is available at [https://docs.atomicorp.com/gotrootModsec/remoterules.html].<br />
<br />
==== Step 5a: Downloadable Rules ====<br />
<br />
If you have a license for the downloadable rules, this is the recommended configuration and the '''minimum''' recommended rule sets that are designed to work with cpanel without [[ASL]] installed. Please be sure to read this entire page for information about additional rules that you may also want to use with cpanel.<br />
<br />
SecRequestBodyAccess On<br />
SecAuditLogType Concurrent<br />
SecResponseBodyAccess On<br />
SecResponseBodyMimeType (null) text/html text/plain text/xml<br />
SecResponseBodyLimit 2621440<br />
SecAuditLogRelevantStatus "^(?:5|4(?!04))"<br />
SecServerSignature Apache<br />
SecUploadDir /var/asl/data/suspicious<br />
SecUploadKeepFiles Off<br />
SecAuditLogParts ABIFHZ<br />
SecArgumentSeparator "&"<br />
SecCookieFormat 0<br />
SecRequestBodyInMemoryLimit 131072<br />
SecDataDir /var/asl/data/msa<br />
SecTmpDir /tmp<br />
SecAuditLogStorageDir /var/asl/data/audit<br />
SecResponseBodyLimitAction ProcessPartial<br />
<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_z_antievasion.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_zz_strict.conf<br />
Include /full/path/to/your/rules/modsecurity.d/09_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_antimalware.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/11_asl_adv_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/20_asl_useragents.conf<br />
Include /full/path/to/your/rules/modsecurity.d/30_asl_antispam.conf<br />
Include /full/path/to/your/rules/modsecurity.d/50_asl_rootkits.conf<br />
Include /full/path/to/your/rules/modsecurity.d/60_asl_recons.conf<br />
Include /full/path/to/your/rules/modsecurity.d/61_asl_recons_dlp.conf<br />
Include /full/path/to/your/rules/modsecurity.d/99_asl_jitp.conf<br />
<br />
If you want to load just some of the rules, make sure you specify only those rule files. The default list above is the recommended and supported rulesets with cpanel. Do not use the other asl rulesets with cpanel, those other rules either use other apache modules (such as mod_sed) or ASL specific features that require [[ASL]].<br />
<br />
Then run this command as root to install the rules:<br />
<br />
[[aum]] -u<br />
<br />
Or if you want to install the rules files manually, please see the [https://www.atomicorp.com/wiki/index.php/Atomic_ModSecurity_Rules#Step_8:_Download_the_ModSecurity_Rules Downloading rules] section above.<br />
<br />
==== Step 7: Restart Apache ====<br />
<br />
Restart apache, enjoy your new secure web server!<br />
<br />
<br />
<br />
==== Optional Steps ====<br />
<br />
===== Malware Scanner =====<br />
<br />
The malware scanner is included in [[ASL]], it is not included in the rules or rule subscriptions. Therefore, if you use this file:<br />
<br />
05_asl_scanner.conf<br />
<br />
Or this:<br />
<br />
99_asl_scanner.conf<br />
<br />
You will need to include your own scanner, and will need to make sure you have clamd installed and configured correctly to listen on a TCP port, or if you use a socket, make sure apache can read/write to this socket or as a last resort, run clamd as root. Using this file forces all web uploads on your system to go thru clamav to look for malware, viruses, etc. If you dont need that, then you can leave this config file out.<br />
<br />
<br />
==== Cpanel Error Messages ====<br />
<br />
==== modsecparse.pl ====<br />
<br />
'''This is a third party tool not provided by, or supported by Atomicorp.''' If you use this tool, it apparently does not work with the new fast concurrent logging system in modsecurity. The concurrent logging system is much faster, will speed up apache and is less resource intensive that the older serial method. <br />
<br />
However, if you use this tool you must use the slower serial logging method, as it does not support the faster concurrent method. To use this tool, change the SecAuditLogType setting from "Concurrent" to "Serial":<br />
<br />
SecAuditLogType Serial<br />
<br />
'''Keep in mind that this logging method is much slower, may slow down apache and is not supported.''' This performance impact is not caused by the rules. Serial logging is much slower than concurrent logging. Therefore we do not recommend you use this logging method or any tools that require it. There are lots of modsecurity log readers that can use the concurrent logging method, such as [[ASL]] and we encourage you to explore using one of those modern tools instead.<br />
<br />
==== Serial logging ====<br />
<br />
===== Discussion =====<br />
<br />
Serial logging is the older slower depreacted logging method modsecurity original used many years ago. This logging method would log the entire event in a single file. As a result, it would slow apache down because each event needed to wait for the previous event to finish writing before it could write to the log file. Events stack up and slow apache down. This incurs a significant performance penalty on apache, and of course a better method was devised for modsecurity to address this performance issue. The solution is the concurrent logging method. This generates a unique event file for each log event, logging the events data to that file instead of trying to jam tons of data into a single file, and thereby slowing down apache. All modern modsecurity log viewing tools support the concurrent method.<br />
<br />
The concurrent logging system is much faster, will speed up apache and is less resource intensive that the older serial method. This method is highly recommended over the slow serial logging method.<br />
<br />
===== Configuration =====<br />
<br />
====== aum ======<br />
<br />
If you want to use the old slower serial logging method, and you are using aum, change this setting in /etc/asl/config:<br />
<br />
MODSEC_LOGTYPE="Concurrent"<br />
<br />
<br />
To:<br />
<br />
MODSEC_LOGTYPE="Serial"<br />
<br />
<br />
And then run:<br />
<br />
aum -uf<br />
<br />
====== non-aum systems ======<br />
<br />
If you want to use the old slower serial logging method change the SecAuditLogType setting from "Concurrent" to "Serial":<br />
<br />
SecAuditLogType Serial<br />
<br />
'''Warning: Serial logging is much slower than concurrent logging and will slow down apache.''' Any performance impact is not caused by the rules. <br />
<br />
Therefore we do not recommend you use this logging method or any tools that require it. There are lots of modsecurity log readers that can use the fast concurrent logging method, such as [[ASL]] and we encourage you to explore using one of those modern tools instead of a tool that requires the slower and performance degrading serial logging method.<br />
<br />
If you change your system to the slower Serial method, you may also want to change the logfile name you are using for your modsecurity logs. You can do that by changing this option in your configuration:<br />
<br />
SecAuditLog logs/audit_log</div>Mshinnhttps://wiki.atomicorp.com/wiki/index.php/Atomic_ModSecurity_RulesAtomic ModSecurity Rules2022-09-27T17:19:22Z<p>Mshinn: /* Step 2: Configure directory permissions */</p>
<hr />
<div>[[Atomic Secured Linux]] includes modsecurity, and the Real Time GotRoot.com/Atomicorp Modsecurity Rules. These docs are for users that do not have [[ASL]].<br />
<br />
'''ASL will install and configure modsecurity, and provides a powerful and easy use to GUI to manage all of this for you. If you don't have ASL, [https://www.atomicorp.com/amember/cart/index/index?c=1 upgrade to ASL today!]'''<br />
<br />
= '''About the rules''' =<br />
<br />
The gotroot.com rules are written by us - we are the gotroot guys. Same great rules, same team, ten years of writing modsecurity rules and still going strong! GotRoot is our Information Assurance lab and [http://www.atomicorp.com Atomicorp] is the product arm of [http://www.progllc.com Prometheus Global] (the parent company for both). So when you get the gotroot.com rules from atomicorp.com or gotroot.com - you're getting the same rules from the same people that created, write and maintain them. In the future we will be merging the gotroot.com, atomicrocketturtle and atomicorp websites into the atomicorp.com website.<br />
<br />
We publish two versions of the rules:<br />
<br />
'''RealTime Rules:''' The latest and greatest version of the rules, with all the performance enhancements, new security features and bug fixes released by us on a daily basis. These rules are fully supported and are recommended for production use.<br />
<br />
'''Free/Delayed Rules:''' A delayed subset of the Advanced rules.<br />
<br />
Installation of the rules assumes a certain level of comfort with configuring apache. If you are not comfortable with configuring apache, you should contact someone that is, or use our [[Atomic Secured Linux]] product which does this automatically for you, and does not require you to configure apache.<br />
<br />
== Getting the rules ==<br />
<br />
[https://www.atomicorp.com/amember/cart/index/index?c=6 Click here] to get the Atomicorp ModSecurity Rules.<br />
<br />
== '''Atomic ModSecurity Rules Frequently Asked Questions''' ==<br />
<br />
Please see the [[Atomic ModSecurity Rules FAQ]] wiki page.<br />
<br />
== '''Real Time Rule Support''' ==<br />
<br />
If you have a subscription to the real time rules, you can request email support by sending an email to:<br />
<br />
support@atomicorp.com<br />
<br />
The Customer Support Forums are located here:<br />
<br />
[http://www.atomicorp.com/forums Customer Support Forums]<br />
<br />
And the Custom Support Portal is located here (you can submit bug reports and open cases through the portal):<br />
<br />
[https://www.atomicorp.com/portal Customer Support Portal]<br />
<br />
== '''Licenses''' ==<br />
<br />
The Real Time Atomic ModSecurity Rules are licensed by the server. You can order licenses from the online store at the link below:<br />
<br />
[https://www.atomicorp.com/amember/cart/index/index?c=6 Online Store]<br />
<br />
If you require additional licenses please log into the [https://www.atomicorp.com/support/license-manager.html AtomiCorp License Manager]. You can add additional systems there, you can control your payment methods and you can also sign up to become an affiliate.<br />
<br />
=== License Terms and Conditions ===<br />
<br />
Purchase of an Atomicorp ModSecurity rule license entitles the purchaser to access and download from the Atomicorp Repository to a single IP address within the time period of the license. A separate license is required for each dedicated server/host or VPS that the rule set is installed upon or is protecting.<br />
<br />
Atomicorp ModSecurity rules installed upon a Reverse Proxy WAF appliance/server requires a separate license. Please contact Atomicorp support for details.<br />
<br />
The rule set cannot be copied, mirrored, or reproduced under protection of US and International copyright laws.<br />
<br />
Use of the rule set is limited to the time period of the license. If the license period of a rule set expires, it must must removed from its installed server and no longer used. Atomicorp reserves the right to track and enforce license compliance of the Atomicorp Modsecurity rule sets.<br />
<br />
Agreement to these terms and conditions and the Atomicorp [https://atomicorp.com/eula.html End User License Agreement] is required to download and use the Atomicorp ModSecurity rules.<br />
<br />
== Important Information about the Rules ==<br />
<br />
=== Minimum Version of Modsecurity Required to use the rules ===<br />
<br />
The rules are supported with the following versions of Modsecurity:<br />
<br />
<br />
* 2.9.3<br />
<br />
We recommend customers use our modsecurity builds, as they are tested to ensure all features work correctly. Third party builds may not include the correct libraries, may cause problems with your web server, including crashes and may disable or incorrectly enable features in modsecurity that can cause unpredictable behavior or failure of rules to process correctly.<br />
<br />
If you need a solution to keep the rules and modsecurity up to date and in sync with your version of modsecurity automatically, please use [[aum]] or [[ASL]] which will do this for you automatically.<br />
<br />
==== What versions of modsecurity do the rules work with ====<br />
<br />
They work with both modsecurity 2.9.x, and modsecurity 3.x.<br />
<br />
=== What does each rule family do? ===<br />
<br />
Please see the [[modsecurity_rule_families]] documents.<br />
<br />
= Installation =<br />
<br />
== Easy One Step Installation ==<br />
<br />
<br />
<br />
===== Full Management Suite =====<br />
<br />
Install [[ASL]]. This installs everything: modsecurity, all the rules, the GUI, rule manager and all ASL components, plus it includes the subscription to the real time rules.<br />
<br />
ASL will automatically download and keep your rules up to date, and will ensure that modsecurity stays up to date so your system can support the latest rules. ASL also provides you with a full security management suite, which will allow you to manage, edit and configure your rules through a web console. It will also protect you from uploaded malware, brute force attacks, DOS attacks, rootkits and many other threats that a WAF can not protect you from.<br />
<br />
A full list of ASLs features is available at the URL below:<br />
<br />
https://www.atomicorp.com/products/asl.html<br />
<br />
===== Just a downloader =====<br />
<br />
We also provide an automated rule updater and modsecurity installation tool, called [[aum]]. You can read more about it on the [[aum]] page. You can install it by running these commands as root:<br />
<br />
Step 1) Install [[aum]]<br />
<br />
''wget -q -O - https://updates.atomicorp.com/installers/aum |bash''<br />
<br />
Step 2) Configure [[aum]]<br />
<br />
''aum configure''<br />
<br />
Step 3) Tell [[aum]] to install the rules<br />
<br />
''aum upgrade''<br />
<br />
You can read more about aum on the [[aum]] documentation page.<br />
<br />
Note: This capability is included in [[ASL]]. ASL users do not need to install aum, its already included.<br />
<br />
== (Optional) Do It Yourself Installation ==<br />
<br />
Note: A manual installation is not necessary if you have [[ASL]] installed. ASL will configure and install modsecurity, and the rules, automatically. This is also not necessary if you are using our new AUM software to handle rule download and installation.<br />
<br />
=== Linux ===<br />
<br />
==== Step 1: Download ModSecurity ====<br />
<br />
Binaries:<br />
<br />
[http://updates.atomicorp.com/channels/atomic/ Install modsecurity from the Atomicorp software repository]<br />
<br />
Source Code:<br />
<br />
[http://updates.atomicorp.com/channels/atomic/ Install modsecurity from the Atomicorp software repository]<br />
<br />
Please note that the rules are only supported with the version of modsecurity [http://wiki.atomicorp.com/wiki/index.php/Atomic_ModSecurity_Rules#Minimum_Version_of_Modsecurity_Required_to_use_the_rules identified in this section of the wiki.]<br />
<br />
Note: Please contact us before using a third party or source build of modsecurity. Its critical modsecurity be built correctly to work with the rules.<br />
<br />
==== Step 2: Set up and configure directories ====<br />
<br />
Create the following directories as root:<br />
<br />
mkdir /etc/httpd/modsecurity.d<br />
mkdir /var/asl<br />
mkdir /var/asl/tmp<br />
mkdir /var/asl/data<br />
mkdir /var/asl/data/msa<br />
mkdir /var/asl/data/audit<br />
mkdir /var/asl/data/suspicious<br />
<br />
==== Step 3: Set permissions for directories ====<br />
<br />
Set the following permissions on the directories you just created. In this example these directories are set to be owned by "apache" and the group "apache", which is standard on a normal Centos or RHEL system. However some control panels configure apache to run as a different user, such as nobody, or http. <br />
<br />
To determine what user this is, check your system to see what user your webserver uses. You can use this command to find the user:<br />
<br />
ps auxwww | grep httpd<br />
<br />
The output will look similar to this:<br />
<br />
(RHEL/Centos example with or without Plesk)<br />
<br />
root 26755 0.0 4.3 430752 86432 ? Ss 04:30 0:01 /usr/sbin/httpd<br />
'''apache''' 26908 0.0 3.7 300564 75076 ? S 04:30 0:00 /usr/sbin/httpd<br />
'''apache''' 26909 0.1 5.5 495812 112084 ? S 04:30 0:37 /usr/sbin/httpd<br />
'''apache''' 26910 0.0 5.3 495424 106672 ? S 04:30 0:23 /usr/sbin/httpd<br />
'''apache''' 26911 0.1 5.7 495892 114368 ? S 04:30 0:57 /usr/sbin/httpd<br />
'''apache''' 26912 0.1 5.7 496056 114440 ? S 04:30 0:52 /usr/sbin/httpd<br />
'''apache''' 26913 0.1 5.5 496604 110692 ? S 04:30 0:57 /usr/sbin/httpd<br />
'''apache''' 26914 0.0 5.7 499324 116236 ? S 04:30 0:16 /usr/sbin/httpd<br />
'''apache''' 26915 0.2 5.5 493600 112192 ? S 04:30 1:09 /usr/sbin/httpd<br />
'''apache''' 26916 0.1 6.4 513760 129992 ? S 04:30 0:30 /usr/sbin/httpd<br />
<br />
In this example the user in bold is "apache" (this may be different for your system). This is the user you will want to set the directory permissions to (as in the example below):<br />
<br />
chown apache.apache /var/asl/data/msa<br />
chown apache.apache /var/asl/data/audit<br />
chown apache.apache /var/asl/data/suspicious<br />
chmod o-rx -R /var/asl/data/*<br />
chmod ug+rwx -R /var/asl/data/*<br />
<br />
(RHEL/Centos example with Cpanel)<br />
<br />
root 20594 86.8 3.1 255148 181232 ? Ss 11:39 0:04 /usr/local/apache/bin/httpd -k restart<br />
root 20611 0.0 3.1 255060 179596 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20612 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20613 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20614 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20615 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20616 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
<br />
In this example from a Centos system running Cpanel the user is "nobody", so you would want to use these commands:<br />
<br />
chown nobody.nobody /var/asl/data/msa<br />
chown nobody.nobody /var/asl/data/audit<br />
chown nobody.nobody /var/asl/data/suspicious<br />
chmod o-rx -R /var/asl/data/*<br />
chmod ug+rwx -R /var/asl/data/*<br />
<br />
==== Step 4: (Optional) Create rule updater directories ====<br />
These directories must as be created if you use optional rules updater. Create these directories as root and they only need to be accessed by root:<br />
<br />
mkdir /var/asl/updates<br />
mkdir /var/asl/rules/<br />
mkdir /var/asl/rules/clamav<br />
<br />
==== Step 5: Create the whitelist file ====<br />
<br />
Create this file:<br />
<br />
touch /etc/asl/whitelist<br />
<br />
This file contains a list of IPs you want to exclude from ALL rules. That means those IPs can do anything to your system - so be very very careful about what IPs you add to this list. This is a dangerous thing to do. The format of the file is a single IP, per line. <br />
<br />
Cpanel users should skip to the notes at the bottom of this page for special additional actions for cpanel systems. All other users should continue with these instructions.<br />
<br />
==== Step 6: Configure your webserver ====<br />
<br />
===== nginx =====<br />
<br />
===== Step 6a: configure nginx to load modsecurity =====<br />
<br />
====== nginx proxying to a backend ======<br />
<br />
If you are using nginx as a frontend to another webserver, then add the following directives to your nginx.conf file.<br />
<br />
<pre><br />
location / {<br />
ModSecurityEnabled on;<br />
ModSecurityConfig modsecurity.conf;<br />
proxy_pass http://localhost:8080;<br />
proxy_read_timeout 180s;<br />
}<br />
<br />
</pre><br />
<br />
Change "localhost:8011" to the server you are proxying nginx to, and change 8080 to the portnumber for that server. For example, if you are running apache on port 8088 on localhost the line would be:<br />
<br />
proxy_pass http://localhost:8088;<br />
<br />
====== nginx standalone ======<br />
<br />
If you are only using nginx, and not using it as a frontend to another web server then you want to use this configuration:<br />
<br />
<pre><br />
location / {<br />
ModSecurityEnabled on;<br />
ModSecurityConfig modsecurity.conf;<br />
}<br />
</pre><br />
<br />
===== Apache =====<br />
<br />
===== Step 6a: configure apache to load modsecurity =====<br />
<br />
You then need to tell apache to load modsecurity. Depending on your apache configuration, apache should be configured to include configuration files. If you have a setting like this in your apache config:<br />
<br />
Include conf.d/*.conf<br />
<br />
Then you are setup to load external configuration files. If you do not have this setup, its highly recommend you add this. This installation guide is written for this type of configuration. Loading mod_security occurs by including a modsecurity configuration file in that directory. We recommend you name the name 00_modsecurity.conf to ensure it runs first. Its vitally important that modsecurity load before other modules, otherwise attacks can occur before modsecurity scans them and some attacks can be missed.<br />
<br />
An example 00_modsecurity.conf file that works with our files is included here:<br />
<br />
LoadModule security2_module modules/mod_security2.so<br />
LoadModule unique_id_module modules/mod_unique_id.so<br />
<IfModule mod_security2.c><br />
Include modsecurity.d/tortix_waf.conf<br />
</IfModule><br />
<br />
Install this file in your conf.d directory. On a standard RHEL or Centos system that directory is located here:<br />
<br />
/etc/httpd/conf.d/<br />
<br />
=== Step 7: Configure modsecurity ===<br />
<br />
You then need to configure modsecurity. This is done via the an apache configuration file. In this example, we will create the file "tortix_waf.conf". Here is an example file that works with our rules:<br />
<br />
SecRuleEngine On<br />
SecRequestBodyAccess On<br />
SecResponseBodyAccess On<br />
SecResponseBodyMimeType (null) text/html text/plain text/xml<br />
SecResponseBodyLimit 2621440<br />
SecServerSignature Apache<br />
SecComponentSignature 200911012341<br />
SecUploadDir /var/asl/data/suspicious<br />
SecUploadKeepFiles Off<br />
SecAuditEngine RelevantOnly<br />
SecAuditLogRelevantStatus "^(?:5|4(?!04))"<br />
SecAuditLogType Concurrent<br />
SecAuditLog logs/audit_log<br />
[[SecAuditLogParts]] ABIFHZ<br />
SecArgumentSeparator "&" <br />
SecCookieFormat 0<br />
SecRequestBodyInMemoryLimit 131072<br />
SecDataDir /var/asl/data/msa<br />
SecTmpDir /tmp<br />
SecAuditLogStorageDir /var/asl/data/audit<br />
SecResponseBodyLimitAction ProcessPartial<br />
SecAuditLogDirMode 0770<br />
SecPcreMatchLimit 250000 <br />
SecPcreMatchLimitRecursion 250000<br />
<br />
You will want to install this file in your modsecurity.d directory, which is located here if you follow the instructions above:<br />
<br />
/etc/httpd/modsecurity.d<br />
<br />
==== tortix_waf.conf ====<br />
<br />
You can also download an example version of the modsecurity configuration file from here:<br />
<br />
https://www.atomicorp.com/installer/tortix_waf.conf<br />
<br />
[[ASL]] will automatically generate this file depending on your needs. If you are not using ASL, you will need to modify this configuration file to suit your system and modsecurity requirements.<br />
<br />
==== Step 8: Download the ModSecurity Rules ====<br />
<br />
See the [[Downloading Rules]] page.<br />
<br />
==== Step 9: Install the rules ====<br />
<br />
==== Remove any previous installations of rules ====<br />
<br />
If you have installed our delayed rules, you will need to make sure you have deleted them. You will not want to have any older versions of the rules installed.<br />
<br />
Also, if you have installed any third party modsecurity rules, you will want to make sure they are using rule id's that are assigned to them. The modsecurity project assigns ranges to the rule id's modsecurity uses. Modsecurity requires a unique id for each rule, otherwise you will get an error like this:<br />
<br />
ModSecurity: Found another rule with the same id<br />
<br />
This means either that someone else is using the same rule id's assigned to our ruleset by the modsecurity project (our official range is 300000-399999), or you have loaded our rules twice.<br />
<br />
==== Installation ====<br />
<br />
Download the rules to a temporary directory using your favorite download tool. Extract the rules:<br />
<br />
tar zxvf /var/asl/updates/modsec-200911012341.tar.gz<br />
<br />
Then copy each of the ASL rule files you wish to use into /etc/httpd/modsecurity.d. Do not copy all of the rule files, you will need to select rule files that are appropriate for your system. Or simply use [[aum]] or [[ASL]] to do this for you automatically.<br />
<br />
If you are using cpanel, please see the notes at the bottom of this page, cpanel does not use the standard locations for apache configuration files.<br />
<br />
Finally, load the rules. '''Make sure you specify only those rule files that are appropriate for your system.''' For example:<br />
<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/99_asl_jitp.conf<br />
<br />
'''Warning: You should NOT include all the rules. There are rulesets, documented above, that replace other rulesets and are incompatible with each other.'''<br />
<br />
===== Recommend minimum rulesets =====<br />
<br />
====== apache ======<br />
<br />
The recommended ''minimum ruleset'' to load is:<br />
<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_0_global.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_antimalware.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/11_asl_adv_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/20_asl_useragents.conf<br />
Include /full/path/to/your/rules/modsecurity.d/30_asl_antispam.conf<br />
Include /full/path/to/your/rules/modsecurity.d/50_asl_rootkits.conf<br />
Include /full/path/to/your/rules/modsecurity.d/60_asl_recons.conf<br />
Include /full/path/to/your/rules/modsecurity.d/61_asl_recons_dlp.conf<br />
Include /full/path/to/your/rules/modsecurity.d/99_asl_jitp.conf<br />
<br />
If you have modsecurity 2.9.0 and up installed, you should also load additional rule files and should use this ruleset:<br />
<br />
Include /full/path/to/your/rules/modsecurity.d/000_asl_threat_intelligence.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_zz_strict.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_0_global.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_z_antievasion.conf<br />
Include /full/path/to/your/rules/modsecurity.d/01_asl_content.conf<br />
Include /full/path/to/your/rules/modsecurity.d/01_asl_content_z.conf<br />
Include /full/path/to/your/rules/modsecurity.d/03_asl_dos.conf<br />
Include /full/path/to/your/rules/modsecurity.d/09_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_antimalware.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/11_asl_adv_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/11_asl_data_loss.conf<br />
Include /full/path/to/your/rules/modsecurity.d/12_asl_adv_xss_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/20_asl_useragents.conf<br />
Include /full/path/to/your/rules/modsecurity.d/30_asl_antispam.conf<br />
Include /full/path/to/your/rules/modsecurity.d/50_asl_rootkits.conf<br />
Include /full/path/to/your/rules/modsecurity.d/51_asl_rootkits.conf<br />
Include /full/path/to/your/rules/modsecurity.d/60_asl_recons.conf<br />
Include /full/path/to/your/rules/modsecurity.d/61_asl_recons_dlp.conf<br />
Include /full/path/to/your/rules/modsecurity.d/99_asl_jitp.conf<br />
Include /full/path/to/your/rules/modsecurity.d/98_asl_adv_redactor.conf<br />
<br />
If you have a [[Local DNS resolver]] setup and properly configured on your system, and you are using modsecurity 2.9.0 and up we also recommend these additional rulesets:<br />
<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_z_searchengines.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_z_aa_threat_intelligence.conf<br />
Include /full/path/to/your/rules/modsecurity.d/99_asl_zzzz_threat_intelligence.conf<br />
<br />
Note: Some of these rulesets are designed to work with advanced security management systems such as [[ASL]] and may not work completely without an advanced management system.<br />
<br />
====== nginx ======<br />
<br />
The same rulesets as apache will work with nginx.<br />
<br />
====== litespeed ======<br />
<br />
[[Litespeed]] has a proprietary implementation of mod_security. It does not support all the features that mod_security with apache, IIS and nginx does. Therefore, you can not use all the rulesets with Litespeed, as Litespeed does not support those features of mod_security. The following rulesets are recommended with Litespeed:<br />
<br />
The recommended ''minimum ruleset'' to load is:<br />
<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_0_global.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_antimalware.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/11_asl_adv_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/20_asl_useragents.conf<br />
Include /full/path/to/your/rules/modsecurity.d/30_asl_antispam.conf<br />
Include /full/path/to/your/rules/modsecurity.d/50_asl_rootkits.conf<br />
Include /full/path/to/your/rules/modsecurity.d/60_asl_recons.conf<br />
Include /full/path/to/your/rules/modsecurity.d/61_asl_recons_dlp.conf<br />
Include /full/path/to/your/rules/modsecurity.d/99_asl_jitp.conf<br />
<br />
If you require more advanced protection, you should also load additional rule files and should use this ruleset:<br />
<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_zz_strict.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_x_searchengines.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_y_searchengines.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_0_global.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_z_antievasion.conf<br />
Include /full/path/to/your/rules/modsecurity.d/01_asl_content.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_zz_strict.conf<br />
Include /full/path/to/your/rules/modsecurity.d/03_asl_dos.conf<br />
Include /full/path/to/your/rules/modsecurity.d/09_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_antimalware.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/11_asl_adv_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/11_asl_data_loss.conf<br />
Include /full/path/to/your/rules/modsecurity.d/12_asl_adv_xss_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/20_asl_useragents.conf<br />
Include /full/path/to/your/rules/modsecurity.d/30_asl_antispam.conf<br />
Include /full/path/to/your/rules/modsecurity.d/50_asl_rootkits.conf<br />
Include /full/path/to/your/rules/modsecurity.d/51_asl_rootkits.conf<br />
Include /full/path/to/your/rules/modsecurity.d/60_asl_recons.conf<br />
Include /full/path/to/your/rules/modsecurity.d/61_asl_recons_dlp.conf<br />
Include /full/path/to/your/rules/modsecurity.d/99_asl_jitp.conf<br />
<br />
<br />
Note: [[Litespeed]] does not support content inspection (outbound rules), or lua based rules. Therefore, the following rulesets Litespeed does not support, and loading them will have no effect on the system:<br />
<br />
<br />
00_asl_z_searchengines.conf<br />
00_asl_z_aa_threat_intelligence.conf<br />
12_asl_brute.conf<br />
98_asl_adv_redactor.conf<br />
99_asl_zzzz_threat_intelligence.conf<br />
<br />
Note: Some of these rulesets are designed to work with advanced security management systems such as [[ASL]] and may not work completely without an advanced management system.<br />
<br />
===== Notes on Scanner ruleset =====<br />
<br />
NOTE: If you use this file:<br />
<br />
05_asl_scanner.conf<br />
<br />
Or this file:<br />
<br />
99_asl_scanner.conf<br />
<br />
[[ASL]] includes malware upload scanning, rules subscriptions do not.<br />
<br />
If you wish to use this ruleset, and you are not using [[ASL]], then you will need to create a script to pass the files to clamd and read the result. Make sure you have clamd installed and configured correctly to list on a TCP port, or if you use a socket, make sure apache can read/write to this socket or as a last resort, run clamd as root. Using this file will force all web uploads on your system to go thru clamav to look for malware, viruses, etc. If you dont need that, then you can leave this config file out. <br />
<br />
Real time malware upload protection is included in [[ASL]] and uses a faster method than the older style modsecurity scripting method above. So if you need realtime malware upload protection (for web, FTP, or even realtime), then upgrade to [[ASL]] which includes highspeed malware upload protection, full support, automatic and hassle free installation. ASL also protects against any form of upload of malware, including HTTP, HTTPS, SSH and FTP uploads and includes our real-time malware detection and prevention system which will detect and block any malicious software running on the system in realtime. This is just one of the many many features of [[ASL]].<br />
<br />
==== Step 10: Test your web server ====<br />
===== Test nginx =====<br />
<br />
nginx -t -c <NGINX_CONFIG_FILE><br />
<br />
Where NGINX_CONFIG_FILE is your nginx.conf file.<br />
<br />
===== Test Apache =====<br />
<br />
Before restarting apache we recommend you test your configuration by running apache with the "configtest" command. On a standard system you can do this by calling your apache init file like this:<br />
<br />
/etc/init.d/httpd configtest<br />
<br />
If you get errors, check to see that you don't have some extraneous configuration files installed.<br />
<br />
===== Testing to see if the rules are loaded =====<br />
'''<br />
Step 1)''' (for non [[ASL]] systems)<br />
<br />
Make sure you have the rules installed exactly as described on this page. This test may not work if you have not followed these instructions. (If you used ASL to setup your WAF, and you have not installed any third party tools that configure, install or manage modsecurity then your rules are installed correctly and you do not need to review the instructions on this page. If you have manually altered your modsecurity configuration then you will need to review this entire article. Manual modifications of ASL modsecurity configurations are not supported.)<br />
<br />
'''Step 2) Make sure all rules are enabled'''<br />
<br />
'''Ensure that you do not have any of our rules disabled.''' This test assumes you do not have any rules disabled, that you are not whitelisting the source of this test and that your have the Atomicorp rules loaded.<br />
<br />
'''Step 3) Test from a non-whitelisted system''' <br />
<br />
Make sure you do not have the system you are performing this from is whitelisted<br />
<br />
For example, cpanels default modsecurity configuration will configure modsecurity to ignore everything from 127.0.0.1, or from the system itself. So if you perform the test above from the server itself, and you have not removed this cpanel whitelist, then this test will not work.<br />
<br />
'''Step 4) Run the test'''<br />
<br />
On the system where the rules are installed run this command (this assumes you have wget installed, '''127.0.0.1 is NOT whitelisted''' and a web server is listening on 127.0.0.1):<br />
<br />
''wget http://localhost/foo.php?foo=http://www.example.com''<br />
<br />
If the test worked, should get a 403 error if the rules are loaded, which will look similar to this:<br />
<br />
<pre><br />
--2010-05-27 20:12:25-- http://localhost/foo.php?foo=http://www.example.com<br />
Resolving localhost... 127.0.0.1<br />
Connecting to localhost|127.0.0.1|:80... connected.<br />
HTTP request sent, awaiting response... 403 Forbidden<br />
2010-05-27 20:12:25 ERROR 403: Forbidden.<br />
</pre><br />
<br />
If you do not get a 403 error, the test did not work.<br />
<br />
You can also use your browser to test the rules by going to a URL similar to this:<br />
<br />
http://YOUR_HOST/foo.php?foo=http://www.example.com<br />
<br />
Remember to replace YOUR_HOST with the actual HOSTNAME or IP of the server.<br />
<br />
If the rules are properly loaded, you should get a 403 error, if you do not get a 403 error, the rules are not loaded correctly and you need to check your configuration to ensure that you have followed the instructions above correctly.<br />
<br />
If you get a 403 error from the command line and a 404 error from the browser, check to make sure the computer you are testing the browser from is not whitelisted on the server.<br />
<br />
Note: If you do not have wget installed, then you will need to install it or a similar tool to run this test from a Linux or UNIX based system. If you are using Windows, you can use a similar tool or your browser.<br />
<br />
====== What to do if you do not get a 403 error ======<br />
<br />
If you get a different error, such as a 404 error or a 5xx series error check your configuration. The following are common causes of this:<br />
<br />
'''1) You have rules disabled'''<br />
<br />
Make sure you do not have any rules disabled.<br />
<br />
'''2) Your IP is whitelisted'''<br />
<br />
There is a rule whitelisting the system you are conducting this test from. Whitelisting tells the WAF to ignore everything from that source.<br />
<br />
For example, cpanels default modsecurity configuration will configure modsecurity to ignore everything from 127.0.0.1, or from the system itself. So if you perform the test above from the server itself, and you have not removed this cpanel whitelist, then you will not get a 403 error. More than likely you will get a 404 error. The solution is to remove any whitelists from your system.<br />
<br />
Note: Whitelisting the server itself can open a hole in your security. You should not whitelist localhost or the servers own IP address, particularly if you have multi users on the system. This is both unnecessary, and doing so will allow any users on the system to carry out attacks on other domains on the system unimpeded. Make sure you do not have any rules like that, this opens a very large hole in your system.<br />
<br />
'''3) Local error message is different'''<br />
<br />
You or someone else may have configured your system to use a different error message. Check your configuration, and make sure it exactly matches the ones on this wiki. IF you are using kind of plugin that does not return a 403 when a connection is rejected, and you must use this, then you will need to manually check your mod_security logs to see if your test is being rejected by modsecurity. If it is, then your rules are working correctly and you can ignore the error code.<br />
<br />
'''4) Third party addons''' <br />
<br />
You have third party rules or addons installed with your modsecurity configuration that are changing the responses. Remove all third party addons, and make sure your configuration exactly matches the instructions on this page<br />
<br />
'''5) Insecurely configured apache'''<br />
<br />
Some control panels are known to disable modsecurity on localhost, and on the systems IP addresses. These highly insecure control panels essentially disable modsecurity if an attacker connects to the systems IP address. This of course leaves your system wide open to attack, and if you are unlucky enough to be using one of these control panels we recommend you report this to your control panel vendor as a serious vulnerability. If they are unwilling to fix it, then we recommend you find a more security concious control panel vendor.<br />
<br />
Example:<br />
<br />
We have seen some control panels that configure modsecurity to be disabled in the /etc/httpd/conf/httpd.conf file for all the local IPs on the system. <br />
<br />
<pre><br />
<VirtualHost <LOCAL IP ADDRESS>:80 127.0.0.1:80 *><br />
<IfModule mod_security2.c><br />
SecRuleEngine Off<br />
</IfModule><br />
</pre><br />
<br />
If your control panel has this vulnerability, you can remove this, but its very possible the control panel will simply open this hole in your system again. We highly recommend you report this vulnerability to your control panel vendor, and if they are unwilling to fix this vulnerability that you find a more security concious control panel vendor.<br />
<br />
'''6) You arent loading the rules'''<br />
<br />
This is common with custom configurations. Check to make sure your webserver is configured to load the rules. Keep mind that modsecurity will still generate generic messages even though the rules are not loaded. For example, if all you see are events like this:<br />
<br />
<pre><br />
--70c19f31-A--<br />
[01/Jan/2013:11:19:13 --0300] roiKIi6Ni3EKFZSKpSUs2iEb 1.2.3.4 34978 5.6.7.8 80<br />
--70c19f31-B--<br />
HEAD / HTTP/1.1<br />
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) <br />
<br />
Accept: */*<br />
<br />
--70c19f31-F--<br />
HTTP/1.1 403 Forbidden<br />
X-Powered-By: PHP/5.4.20<br />
Expires: Thu, 19 Jan 2001 02:12:00 GMT<br />
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0<br />
Pragma: no-cache<br />
Connection: close<br />
Content-Type: text/html<br />
<br />
--70c19f31-H--<br />
Stopwatch: 1383338363503919 358184 (- - -)<br />
Stopwatch2: 1383338363503919 358184; combined=2144, p1=37, p2=2053, p3=0, p4=0, p5=53, sr=0, sw=1, l=0, gc=0<br />
Producer: ModSecurity for Apache/2.7.5 ( http://www.modsecurity.org/).<br />
Server: Apache<br />
Engine-Mode: "ENABLED"<br />
<br />
--70c19f31-Z--<br />
</pre><br />
<br />
In this example, no rule is being triggered, but modsecurity is logging a basic 403 error. It will do this if the modsecurity configuration is loaded, but not the rules. So if you see this happening on your system, and you have ruled out all other issues in this list, it means your custom configuration isnt loading the rules.<br />
<br />
[[ASL]] will automatically configure modsecurity correctly. So if you are having problems configuring modsecurity yourself, then we recommend you use [[ASL]] to setup modsecurity for you.<br />
<br />
=== Windows ===<br />
<br />
Please see the [[modsecurity iis]] page.<br />
<br />
== Automated rules updates ==<br />
<br />
Please see the [[ASL]] page for installation instructions.<br />
<br />
= Tuning the Rules/Disabling Rules =<br />
<br />
== Disabling Rules ==<br />
<br />
See the [[mod_security]] page for details.<br />
<br />
== Tuning the Rules ==<br />
<br />
See the [[mod_security]] page for details.<br />
<br />
== Troubleshoot the Rules ==<br />
<br />
See the [[Atomicorp WAF Rules Troubleshooting]] page for details.<br />
<br />
== Reporting False Positives ==<br />
<br />
See the [[Reporting False Positives]] page for details.<br />
<br />
= Notes =<br />
<br />
== Special notes for CPANEL users not using ASL ==<br />
<br />
The Atomicorp Modsecurity rules work great with Cpanel, right out of the box. To use them with Cpanel either install [[ASL]], or manually install modsecurity and make a few changes to the mod_security configuration that comes with cpanel and then you are all set!<br />
<br />
=== Installing modsecurity in cpanel ===<br />
<br />
'''Option 1) Simplest and most powerful solution'''<br />
<br />
Install [[ASL]]. This will install modsecurity, configure it and will install the rule and event management GUI available in [[ASL]]<br />
<br />
Option 2) Install just the rules<br />
<br />
=== Manually Configuring modsecurity with cpanel ===<br />
<br />
These are additional considerations for installing modsecurity with cpanel. Please read this entire page, as well as this section if you are installing modsecurity with cpanel (even if you already have modsecurity install with cpanel).<br />
<br />
We recommend if you are using cPanel that you follow this advice, as cpanel includes a very minimal configuration for modsecurity that does not include all of the required and optimal settings documented here. Our settings will make your server faster, and more importantly more secure. If you use mod_security with Cpanel you must add these additional settings to experience the full feature set of mod_security.<br />
<br />
==== Step 1 ====<br />
<br />
Make sure you have read this entire document and have setup all the require directories details above.<br />
<br />
==== Step 2: Configure directory permissions ====<br />
<br />
Certain versions of Cpanel do not run apache as a standard user (such as apache) but as the older non-privileged user "nobody". You will need to determine what use cpanel uses for the httpd processes, and that the modsecurity work directories are owned by the user that Cpanel runs apache as. To find this out you can run this command as root:<br />
<br />
ps auxwww | grep httpd<br />
<br />
root 20594 86.8 3.1 255148 181232 ? Ss 11:39 0:04 /usr/local/apache/bin/httpd -k restart<br />
root 20611 0.0 3.1 255060 179596 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20612 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20613 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20614 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20615 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20616 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
<br />
In this example from a Centos system running Cpanel the user is "nobody", so you would want to use these commands to configure the modsecurity work directories for a system where apache is running as "nobody": <br />
<br />
mkdir /var/asl<br />
mkdir /var/asl/data/<br />
mkdir /var/asl/data/msa<br />
mkdir /var/asl/data/audit<br />
mkdir /var/asl/data/suspicious<br />
chown nobody.nobody /var/asl/data/msa<br />
chown nobody.nobody /var/asl/data/audit<br />
chown nobody.nobody /var/asl/data/suspicious<br />
chmod o-rx -R /var/asl/data/*<br />
chmod ug+rwx -R /var/asl/data/*<br />
<br />
==== Step 3: Install modsecurity ====<br />
<br />
Please see the current minimum version required at the link below:<br />
<br />
https://www.atomicorp.com/wiki/index.php/Atomic_ModSecurity_Rules#Minimum_Version_of_Modsecurity_Required_to_use_the_rules<br />
<br />
==== Step 4: Install mod_uniqueid ====<br />
<br />
Cpanel users will need to manually verify that the mod_unique_id module is loaded by cpanel's apache. It should be loaded by default, but check your cpanel configuration to be sure.<br />
<br />
==== Step 5: Configure cpanel ====<br />
<br />
Make a small change to the cpanel modsecurity configuration. A typical cpanel modsec2.conf configuration file looks like this:<br />
<br />
LoadFile /opt/xml2/lib/libxml2.so<br />
LoadFile /opt/lua/lib/liblua.so<br />
LoadModule security2_module modules/mod_security2.so<br />
<IfModule mod_security2.c><br />
SecRuleEngine On<br />
# See http://www.modsecurity.org/documentation/ModSecurity-Migration-Matrix.pdf<br />
# "Add the rules that will do exactly the same as the directives"<br />
# SecFilterCheckURLEncoding On<br />
# SecFilterForceByteRange 0 255<br />
SecAuditEngine RelevantOnly<br />
SecAuditLog logs/modsec_audit.log<br />
SecDebugLog logs/modsec_debug_log<br />
SecDebugLogLevel 0<br />
SecDefaultAction "phase:2,deny,log,status:403"<br />
Include "/usr/local/apache/conf/modsec2.user.conf"<br />
</IfModule><br />
<br />
Because cpanel will overwrite this configuration, you need to modify your user configuration file. You will want to setup your user configuration file (/usr/local/apache/conf/modsec2.user.conf) as in the examples below depending on the type of license you have purchased (remote rules vs downloadable rules). <br />
<br />
==== Step 5a: Remote Rules ====<br />
<br />
If you have a remote rules license, simply add these two lines to the /usr/local/apache/conf/modsec2.user.conf file,, replacing <API Key> with the value in your license signup email:<br />
<br />
''SecRemoteRulesFailAction Warn<br />
<br />
SecRemoteRules <API Key> https://waf.atomicorp.com/rules/srr.php''<br />
<br />
Additional rule classes can be specified as follows<br />
<br />
''SecRemoteRules <API Key> https://waf.atomicorp.com/rules/srr.php?antispam,recons''<br />
<br />
A full list of rule classes is available at [https://docs.atomicorp.com/gotrootModsec/remoterules.html].<br />
<br />
==== Step 5a: Downloadable Rules ====<br />
<br />
If you have a license for the downloadable rules, this is the recommended configuration and the '''minimum''' recommended rule sets that are designed to work with cpanel without [[ASL]] installed. Please be sure to read this entire page for information about additional rules that you may also want to use with cpanel.<br />
<br />
SecRequestBodyAccess On<br />
SecAuditLogType Concurrent<br />
SecResponseBodyAccess On<br />
SecResponseBodyMimeType (null) text/html text/plain text/xml<br />
SecResponseBodyLimit 2621440<br />
SecAuditLogRelevantStatus "^(?:5|4(?!04))"<br />
SecServerSignature Apache<br />
SecUploadDir /var/asl/data/suspicious<br />
SecUploadKeepFiles Off<br />
SecAuditLogParts ABIFHZ<br />
SecArgumentSeparator "&"<br />
SecCookieFormat 0<br />
SecRequestBodyInMemoryLimit 131072<br />
SecDataDir /var/asl/data/msa<br />
SecTmpDir /tmp<br />
SecAuditLogStorageDir /var/asl/data/audit<br />
SecResponseBodyLimitAction ProcessPartial<br />
<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_z_antievasion.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_zz_strict.conf<br />
Include /full/path/to/your/rules/modsecurity.d/09_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_antimalware.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/11_asl_adv_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/20_asl_useragents.conf<br />
Include /full/path/to/your/rules/modsecurity.d/30_asl_antispam.conf<br />
Include /full/path/to/your/rules/modsecurity.d/50_asl_rootkits.conf<br />
Include /full/path/to/your/rules/modsecurity.d/60_asl_recons.conf<br />
Include /full/path/to/your/rules/modsecurity.d/61_asl_recons_dlp.conf<br />
Include /full/path/to/your/rules/modsecurity.d/99_asl_jitp.conf<br />
<br />
If you want to load just some of the rules, make sure you specify only those rule files. The default list above is the recommended and supported rulesets with cpanel. Do not use the other asl rulesets with cpanel, those other rules either use other apache modules (such as mod_sed) or ASL specific features that require [[ASL]].<br />
<br />
Then run this command as root to install the rules:<br />
<br />
[[aum]] -u<br />
<br />
Or if you want to install the rules files manually, please see the [https://www.atomicorp.com/wiki/index.php/Atomic_ModSecurity_Rules#Step_8:_Download_the_ModSecurity_Rules Downloading rules] section above.<br />
<br />
==== Step 7: Restart Apache ====<br />
<br />
Restart apache, enjoy your new secure web server!<br />
<br />
<br />
<br />
==== Optional Steps ====<br />
<br />
===== Malware Scanner =====<br />
<br />
The malware scanner is included in [[ASL]], it is not included in the rules or rule subscriptions. Therefore, if you use this file:<br />
<br />
05_asl_scanner.conf<br />
<br />
Or this:<br />
<br />
99_asl_scanner.conf<br />
<br />
You will need to include your own scanner, and will need to make sure you have clamd installed and configured correctly to listen on a TCP port, or if you use a socket, make sure apache can read/write to this socket or as a last resort, run clamd as root. Using this file forces all web uploads on your system to go thru clamav to look for malware, viruses, etc. If you dont need that, then you can leave this config file out.<br />
<br />
<br />
==== Cpanel Error Messages ====<br />
<br />
==== modsecparse.pl ====<br />
<br />
'''This is a third party tool not provided by, or supported by Atomicorp.''' If you use this tool, it apparently does not work with the new fast concurrent logging system in modsecurity. The concurrent logging system is much faster, will speed up apache and is less resource intensive that the older serial method. <br />
<br />
However, if you use this tool you must use the slower serial logging method, as it does not support the faster concurrent method. To use this tool, change the SecAuditLogType setting from "Concurrent" to "Serial":<br />
<br />
SecAuditLogType Serial<br />
<br />
'''Keep in mind that this logging method is much slower, may slow down apache and is not supported.''' This performance impact is not caused by the rules. Serial logging is much slower than concurrent logging. Therefore we do not recommend you use this logging method or any tools that require it. There are lots of modsecurity log readers that can use the concurrent logging method, such as [[ASL]] and we encourage you to explore using one of those modern tools instead.<br />
<br />
==== Serial logging ====<br />
<br />
===== Discussion =====<br />
<br />
Serial logging is the older slower depreacted logging method modsecurity original used many years ago. This logging method would log the entire event in a single file. As a result, it would slow apache down because each event needed to wait for the previous event to finish writing before it could write to the log file. Events stack up and slow apache down. This incurs a significant performance penalty on apache, and of course a better method was devised for modsecurity to address this performance issue. The solution is the concurrent logging method. This generates a unique event file for each log event, logging the events data to that file instead of trying to jam tons of data into a single file, and thereby slowing down apache. All modern modsecurity log viewing tools support the concurrent method.<br />
<br />
The concurrent logging system is much faster, will speed up apache and is less resource intensive that the older serial method. This method is highly recommended over the slow serial logging method.<br />
<br />
===== Configuration =====<br />
<br />
====== aum ======<br />
<br />
If you want to use the old slower serial logging method, and you are using aum, change this setting in /etc/asl/config:<br />
<br />
MODSEC_LOGTYPE="Concurrent"<br />
<br />
<br />
To:<br />
<br />
MODSEC_LOGTYPE="Serial"<br />
<br />
<br />
And then run:<br />
<br />
aum -uf<br />
<br />
====== non-aum systems ======<br />
<br />
If you want to use the old slower serial logging method change the SecAuditLogType setting from "Concurrent" to "Serial":<br />
<br />
SecAuditLogType Serial<br />
<br />
'''Warning: Serial logging is much slower than concurrent logging and will slow down apache.''' Any performance impact is not caused by the rules. <br />
<br />
Therefore we do not recommend you use this logging method or any tools that require it. There are lots of modsecurity log readers that can use the fast concurrent logging method, such as [[ASL]] and we encourage you to explore using one of those modern tools instead of a tool that requires the slower and performance degrading serial logging method.<br />
<br />
If you change your system to the slower Serial method, you may also want to change the logfile name you are using for your modsecurity logs. You can do that by changing this option in your configuration:<br />
<br />
SecAuditLog logs/audit_log</div>Mshinnhttps://wiki.atomicorp.com/wiki/index.php/Atomic_ModSecurity_RulesAtomic ModSecurity Rules2022-09-27T17:17:27Z<p>Mshinn: /* Step 5a: Remote Rules */</p>
<hr />
<div>[[Atomic Secured Linux]] includes modsecurity, and the Real Time GotRoot.com/Atomicorp Modsecurity Rules. These docs are for users that do not have [[ASL]].<br />
<br />
'''ASL will install and configure modsecurity, and provides a powerful and easy use to GUI to manage all of this for you. If you don't have ASL, [https://www.atomicorp.com/amember/cart/index/index?c=1 upgrade to ASL today!]'''<br />
<br />
= '''About the rules''' =<br />
<br />
The gotroot.com rules are written by us - we are the gotroot guys. Same great rules, same team, ten years of writing modsecurity rules and still going strong! GotRoot is our Information Assurance lab and [http://www.atomicorp.com Atomicorp] is the product arm of [http://www.progllc.com Prometheus Global] (the parent company for both). So when you get the gotroot.com rules from atomicorp.com or gotroot.com - you're getting the same rules from the same people that created, write and maintain them. In the future we will be merging the gotroot.com, atomicrocketturtle and atomicorp websites into the atomicorp.com website.<br />
<br />
We publish two versions of the rules:<br />
<br />
'''RealTime Rules:''' The latest and greatest version of the rules, with all the performance enhancements, new security features and bug fixes released by us on a daily basis. These rules are fully supported and are recommended for production use.<br />
<br />
'''Free/Delayed Rules:''' A delayed subset of the Advanced rules.<br />
<br />
Installation of the rules assumes a certain level of comfort with configuring apache. If you are not comfortable with configuring apache, you should contact someone that is, or use our [[Atomic Secured Linux]] product which does this automatically for you, and does not require you to configure apache.<br />
<br />
== Getting the rules ==<br />
<br />
[https://www.atomicorp.com/amember/cart/index/index?c=6 Click here] to get the Atomicorp ModSecurity Rules.<br />
<br />
== '''Atomic ModSecurity Rules Frequently Asked Questions''' ==<br />
<br />
Please see the [[Atomic ModSecurity Rules FAQ]] wiki page.<br />
<br />
== '''Real Time Rule Support''' ==<br />
<br />
If you have a subscription to the real time rules, you can request email support by sending an email to:<br />
<br />
support@atomicorp.com<br />
<br />
The Customer Support Forums are located here:<br />
<br />
[http://www.atomicorp.com/forums Customer Support Forums]<br />
<br />
And the Custom Support Portal is located here (you can submit bug reports and open cases through the portal):<br />
<br />
[https://www.atomicorp.com/portal Customer Support Portal]<br />
<br />
== '''Licenses''' ==<br />
<br />
The Real Time Atomic ModSecurity Rules are licensed by the server. You can order licenses from the online store at the link below:<br />
<br />
[https://www.atomicorp.com/amember/cart/index/index?c=6 Online Store]<br />
<br />
If you require additional licenses please log into the [https://www.atomicorp.com/support/license-manager.html AtomiCorp License Manager]. You can add additional systems there, you can control your payment methods and you can also sign up to become an affiliate.<br />
<br />
=== License Terms and Conditions ===<br />
<br />
Purchase of an Atomicorp ModSecurity rule license entitles the purchaser to access and download from the Atomicorp Repository to a single IP address within the time period of the license. A separate license is required for each dedicated server/host or VPS that the rule set is installed upon or is protecting.<br />
<br />
Atomicorp ModSecurity rules installed upon a Reverse Proxy WAF appliance/server requires a separate license. Please contact Atomicorp support for details.<br />
<br />
The rule set cannot be copied, mirrored, or reproduced under protection of US and International copyright laws.<br />
<br />
Use of the rule set is limited to the time period of the license. If the license period of a rule set expires, it must must removed from its installed server and no longer used. Atomicorp reserves the right to track and enforce license compliance of the Atomicorp Modsecurity rule sets.<br />
<br />
Agreement to these terms and conditions and the Atomicorp [https://atomicorp.com/eula.html End User License Agreement] is required to download and use the Atomicorp ModSecurity rules.<br />
<br />
== Important Information about the Rules ==<br />
<br />
=== Minimum Version of Modsecurity Required to use the rules ===<br />
<br />
The rules are supported with the following versions of Modsecurity:<br />
<br />
<br />
* 2.9.3<br />
<br />
We recommend customers use our modsecurity builds, as they are tested to ensure all features work correctly. Third party builds may not include the correct libraries, may cause problems with your web server, including crashes and may disable or incorrectly enable features in modsecurity that can cause unpredictable behavior or failure of rules to process correctly.<br />
<br />
If you need a solution to keep the rules and modsecurity up to date and in sync with your version of modsecurity automatically, please use [[aum]] or [[ASL]] which will do this for you automatically.<br />
<br />
==== What versions of modsecurity do the rules work with ====<br />
<br />
They work with both modsecurity 2.9.x, and modsecurity 3.x.<br />
<br />
=== What does each rule family do? ===<br />
<br />
Please see the [[modsecurity_rule_families]] documents.<br />
<br />
= Installation =<br />
<br />
== Easy One Step Installation ==<br />
<br />
<br />
<br />
===== Full Management Suite =====<br />
<br />
Install [[ASL]]. This installs everything: modsecurity, all the rules, the GUI, rule manager and all ASL components, plus it includes the subscription to the real time rules.<br />
<br />
ASL will automatically download and keep your rules up to date, and will ensure that modsecurity stays up to date so your system can support the latest rules. ASL also provides you with a full security management suite, which will allow you to manage, edit and configure your rules through a web console. It will also protect you from uploaded malware, brute force attacks, DOS attacks, rootkits and many other threats that a WAF can not protect you from.<br />
<br />
A full list of ASLs features is available at the URL below:<br />
<br />
https://www.atomicorp.com/products/asl.html<br />
<br />
===== Just a downloader =====<br />
<br />
We also provide an automated rule updater and modsecurity installation tool, called [[aum]]. You can read more about it on the [[aum]] page. You can install it by running these commands as root:<br />
<br />
Step 1) Install [[aum]]<br />
<br />
''wget -q -O - https://updates.atomicorp.com/installers/aum |bash''<br />
<br />
Step 2) Configure [[aum]]<br />
<br />
''aum configure''<br />
<br />
Step 3) Tell [[aum]] to install the rules<br />
<br />
''aum upgrade''<br />
<br />
You can read more about aum on the [[aum]] documentation page.<br />
<br />
Note: This capability is included in [[ASL]]. ASL users do not need to install aum, its already included.<br />
<br />
== (Optional) Do It Yourself Installation ==<br />
<br />
Note: A manual installation is not necessary if you have [[ASL]] installed. ASL will configure and install modsecurity, and the rules, automatically. This is also not necessary if you are using our new AUM software to handle rule download and installation.<br />
<br />
=== Linux ===<br />
<br />
==== Step 1: Download ModSecurity ====<br />
<br />
Binaries:<br />
<br />
[http://updates.atomicorp.com/channels/atomic/ Install modsecurity from the Atomicorp software repository]<br />
<br />
Source Code:<br />
<br />
[http://updates.atomicorp.com/channels/atomic/ Install modsecurity from the Atomicorp software repository]<br />
<br />
Please note that the rules are only supported with the version of modsecurity [http://wiki.atomicorp.com/wiki/index.php/Atomic_ModSecurity_Rules#Minimum_Version_of_Modsecurity_Required_to_use_the_rules identified in this section of the wiki.]<br />
<br />
Note: Please contact us before using a third party or source build of modsecurity. Its critical modsecurity be built correctly to work with the rules.<br />
<br />
==== Step 2: Set up and configure directories ====<br />
<br />
Create the following directories as root:<br />
<br />
mkdir /etc/httpd/modsecurity.d<br />
mkdir /var/asl<br />
mkdir /var/asl/tmp<br />
mkdir /var/asl/data<br />
mkdir /var/asl/data/msa<br />
mkdir /var/asl/data/audit<br />
mkdir /var/asl/data/suspicious<br />
<br />
==== Step 3: Set permissions for directories ====<br />
<br />
Set the following permissions on the directories you just created. In this example these directories are set to be owned by "apache" and the group "apache", which is standard on a normal Centos or RHEL system. However some control panels configure apache to run as a different user, such as nobody, or http. <br />
<br />
To determine what user this is, check your system to see what user your webserver uses. You can use this command to find the user:<br />
<br />
ps auxwww | grep httpd<br />
<br />
The output will look similar to this:<br />
<br />
(RHEL/Centos example with or without Plesk)<br />
<br />
root 26755 0.0 4.3 430752 86432 ? Ss 04:30 0:01 /usr/sbin/httpd<br />
'''apache''' 26908 0.0 3.7 300564 75076 ? S 04:30 0:00 /usr/sbin/httpd<br />
'''apache''' 26909 0.1 5.5 495812 112084 ? S 04:30 0:37 /usr/sbin/httpd<br />
'''apache''' 26910 0.0 5.3 495424 106672 ? S 04:30 0:23 /usr/sbin/httpd<br />
'''apache''' 26911 0.1 5.7 495892 114368 ? S 04:30 0:57 /usr/sbin/httpd<br />
'''apache''' 26912 0.1 5.7 496056 114440 ? S 04:30 0:52 /usr/sbin/httpd<br />
'''apache''' 26913 0.1 5.5 496604 110692 ? S 04:30 0:57 /usr/sbin/httpd<br />
'''apache''' 26914 0.0 5.7 499324 116236 ? S 04:30 0:16 /usr/sbin/httpd<br />
'''apache''' 26915 0.2 5.5 493600 112192 ? S 04:30 1:09 /usr/sbin/httpd<br />
'''apache''' 26916 0.1 6.4 513760 129992 ? S 04:30 0:30 /usr/sbin/httpd<br />
<br />
In this example the user in bold is "apache" (this may be different for your system). This is the user you will want to set the directory permissions to (as in the example below):<br />
<br />
chown apache.apache /var/asl/data/msa<br />
chown apache.apache /var/asl/data/audit<br />
chown apache.apache /var/asl/data/suspicious<br />
chmod o-rx -R /var/asl/data/*<br />
chmod ug+rwx -R /var/asl/data/*<br />
<br />
(RHEL/Centos example with Cpanel)<br />
<br />
root 20594 86.8 3.1 255148 181232 ? Ss 11:39 0:04 /usr/local/apache/bin/httpd -k restart<br />
root 20611 0.0 3.1 255060 179596 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20612 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20613 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20614 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20615 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20616 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
<br />
In this example from a Centos system running Cpanel the user is "nobody", so you would want to use these commands:<br />
<br />
chown nobody.nobody /var/asl/data/msa<br />
chown nobody.nobody /var/asl/data/audit<br />
chown nobody.nobody /var/asl/data/suspicious<br />
chmod o-rx -R /var/asl/data/*<br />
chmod ug+rwx -R /var/asl/data/*<br />
<br />
==== Step 4: (Optional) Create rule updater directories ====<br />
These directories must as be created if you use optional rules updater. Create these directories as root and they only need to be accessed by root:<br />
<br />
mkdir /var/asl/updates<br />
mkdir /var/asl/rules/<br />
mkdir /var/asl/rules/clamav<br />
<br />
==== Step 5: Create the whitelist file ====<br />
<br />
Create this file:<br />
<br />
touch /etc/asl/whitelist<br />
<br />
This file contains a list of IPs you want to exclude from ALL rules. That means those IPs can do anything to your system - so be very very careful about what IPs you add to this list. This is a dangerous thing to do. The format of the file is a single IP, per line. <br />
<br />
Cpanel users should skip to the notes at the bottom of this page for special additional actions for cpanel systems. All other users should continue with these instructions.<br />
<br />
==== Step 6: Configure your webserver ====<br />
<br />
===== nginx =====<br />
<br />
===== Step 6a: configure nginx to load modsecurity =====<br />
<br />
====== nginx proxying to a backend ======<br />
<br />
If you are using nginx as a frontend to another webserver, then add the following directives to your nginx.conf file.<br />
<br />
<pre><br />
location / {<br />
ModSecurityEnabled on;<br />
ModSecurityConfig modsecurity.conf;<br />
proxy_pass http://localhost:8080;<br />
proxy_read_timeout 180s;<br />
}<br />
<br />
</pre><br />
<br />
Change "localhost:8011" to the server you are proxying nginx to, and change 8080 to the portnumber for that server. For example, if you are running apache on port 8088 on localhost the line would be:<br />
<br />
proxy_pass http://localhost:8088;<br />
<br />
====== nginx standalone ======<br />
<br />
If you are only using nginx, and not using it as a frontend to another web server then you want to use this configuration:<br />
<br />
<pre><br />
location / {<br />
ModSecurityEnabled on;<br />
ModSecurityConfig modsecurity.conf;<br />
}<br />
</pre><br />
<br />
===== Apache =====<br />
<br />
===== Step 6a: configure apache to load modsecurity =====<br />
<br />
You then need to tell apache to load modsecurity. Depending on your apache configuration, apache should be configured to include configuration files. If you have a setting like this in your apache config:<br />
<br />
Include conf.d/*.conf<br />
<br />
Then you are setup to load external configuration files. If you do not have this setup, its highly recommend you add this. This installation guide is written for this type of configuration. Loading mod_security occurs by including a modsecurity configuration file in that directory. We recommend you name the name 00_modsecurity.conf to ensure it runs first. Its vitally important that modsecurity load before other modules, otherwise attacks can occur before modsecurity scans them and some attacks can be missed.<br />
<br />
An example 00_modsecurity.conf file that works with our files is included here:<br />
<br />
LoadModule security2_module modules/mod_security2.so<br />
LoadModule unique_id_module modules/mod_unique_id.so<br />
<IfModule mod_security2.c><br />
Include modsecurity.d/tortix_waf.conf<br />
</IfModule><br />
<br />
Install this file in your conf.d directory. On a standard RHEL or Centos system that directory is located here:<br />
<br />
/etc/httpd/conf.d/<br />
<br />
=== Step 7: Configure modsecurity ===<br />
<br />
You then need to configure modsecurity. This is done via the an apache configuration file. In this example, we will create the file "tortix_waf.conf". Here is an example file that works with our rules:<br />
<br />
SecRuleEngine On<br />
SecRequestBodyAccess On<br />
SecResponseBodyAccess On<br />
SecResponseBodyMimeType (null) text/html text/plain text/xml<br />
SecResponseBodyLimit 2621440<br />
SecServerSignature Apache<br />
SecComponentSignature 200911012341<br />
SecUploadDir /var/asl/data/suspicious<br />
SecUploadKeepFiles Off<br />
SecAuditEngine RelevantOnly<br />
SecAuditLogRelevantStatus "^(?:5|4(?!04))"<br />
SecAuditLogType Concurrent<br />
SecAuditLog logs/audit_log<br />
[[SecAuditLogParts]] ABIFHZ<br />
SecArgumentSeparator "&" <br />
SecCookieFormat 0<br />
SecRequestBodyInMemoryLimit 131072<br />
SecDataDir /var/asl/data/msa<br />
SecTmpDir /tmp<br />
SecAuditLogStorageDir /var/asl/data/audit<br />
SecResponseBodyLimitAction ProcessPartial<br />
SecAuditLogDirMode 0770<br />
SecPcreMatchLimit 250000 <br />
SecPcreMatchLimitRecursion 250000<br />
<br />
You will want to install this file in your modsecurity.d directory, which is located here if you follow the instructions above:<br />
<br />
/etc/httpd/modsecurity.d<br />
<br />
==== tortix_waf.conf ====<br />
<br />
You can also download an example version of the modsecurity configuration file from here:<br />
<br />
https://www.atomicorp.com/installer/tortix_waf.conf<br />
<br />
[[ASL]] will automatically generate this file depending on your needs. If you are not using ASL, you will need to modify this configuration file to suit your system and modsecurity requirements.<br />
<br />
==== Step 8: Download the ModSecurity Rules ====<br />
<br />
See the [[Downloading Rules]] page.<br />
<br />
==== Step 9: Install the rules ====<br />
<br />
==== Remove any previous installations of rules ====<br />
<br />
If you have installed our delayed rules, you will need to make sure you have deleted them. You will not want to have any older versions of the rules installed.<br />
<br />
Also, if you have installed any third party modsecurity rules, you will want to make sure they are using rule id's that are assigned to them. The modsecurity project assigns ranges to the rule id's modsecurity uses. Modsecurity requires a unique id for each rule, otherwise you will get an error like this:<br />
<br />
ModSecurity: Found another rule with the same id<br />
<br />
This means either that someone else is using the same rule id's assigned to our ruleset by the modsecurity project (our official range is 300000-399999), or you have loaded our rules twice.<br />
<br />
==== Installation ====<br />
<br />
Download the rules to a temporary directory using your favorite download tool. Extract the rules:<br />
<br />
tar zxvf /var/asl/updates/modsec-200911012341.tar.gz<br />
<br />
Then copy each of the ASL rule files you wish to use into /etc/httpd/modsecurity.d. Do not copy all of the rule files, you will need to select rule files that are appropriate for your system. Or simply use [[aum]] or [[ASL]] to do this for you automatically.<br />
<br />
If you are using cpanel, please see the notes at the bottom of this page, cpanel does not use the standard locations for apache configuration files.<br />
<br />
Finally, load the rules. '''Make sure you specify only those rule files that are appropriate for your system.''' For example:<br />
<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/99_asl_jitp.conf<br />
<br />
'''Warning: You should NOT include all the rules. There are rulesets, documented above, that replace other rulesets and are incompatible with each other.'''<br />
<br />
===== Recommend minimum rulesets =====<br />
<br />
====== apache ======<br />
<br />
The recommended ''minimum ruleset'' to load is:<br />
<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_0_global.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_antimalware.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/11_asl_adv_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/20_asl_useragents.conf<br />
Include /full/path/to/your/rules/modsecurity.d/30_asl_antispam.conf<br />
Include /full/path/to/your/rules/modsecurity.d/50_asl_rootkits.conf<br />
Include /full/path/to/your/rules/modsecurity.d/60_asl_recons.conf<br />
Include /full/path/to/your/rules/modsecurity.d/61_asl_recons_dlp.conf<br />
Include /full/path/to/your/rules/modsecurity.d/99_asl_jitp.conf<br />
<br />
If you have modsecurity 2.9.0 and up installed, you should also load additional rule files and should use this ruleset:<br />
<br />
Include /full/path/to/your/rules/modsecurity.d/000_asl_threat_intelligence.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_zz_strict.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_0_global.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_z_antievasion.conf<br />
Include /full/path/to/your/rules/modsecurity.d/01_asl_content.conf<br />
Include /full/path/to/your/rules/modsecurity.d/01_asl_content_z.conf<br />
Include /full/path/to/your/rules/modsecurity.d/03_asl_dos.conf<br />
Include /full/path/to/your/rules/modsecurity.d/09_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_antimalware.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/11_asl_adv_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/11_asl_data_loss.conf<br />
Include /full/path/to/your/rules/modsecurity.d/12_asl_adv_xss_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/20_asl_useragents.conf<br />
Include /full/path/to/your/rules/modsecurity.d/30_asl_antispam.conf<br />
Include /full/path/to/your/rules/modsecurity.d/50_asl_rootkits.conf<br />
Include /full/path/to/your/rules/modsecurity.d/51_asl_rootkits.conf<br />
Include /full/path/to/your/rules/modsecurity.d/60_asl_recons.conf<br />
Include /full/path/to/your/rules/modsecurity.d/61_asl_recons_dlp.conf<br />
Include /full/path/to/your/rules/modsecurity.d/99_asl_jitp.conf<br />
Include /full/path/to/your/rules/modsecurity.d/98_asl_adv_redactor.conf<br />
<br />
If you have a [[Local DNS resolver]] setup and properly configured on your system, and you are using modsecurity 2.9.0 and up we also recommend these additional rulesets:<br />
<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_z_searchengines.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_z_aa_threat_intelligence.conf<br />
Include /full/path/to/your/rules/modsecurity.d/99_asl_zzzz_threat_intelligence.conf<br />
<br />
Note: Some of these rulesets are designed to work with advanced security management systems such as [[ASL]] and may not work completely without an advanced management system.<br />
<br />
====== nginx ======<br />
<br />
The same rulesets as apache will work with nginx.<br />
<br />
====== litespeed ======<br />
<br />
[[Litespeed]] has a proprietary implementation of mod_security. It does not support all the features that mod_security with apache, IIS and nginx does. Therefore, you can not use all the rulesets with Litespeed, as Litespeed does not support those features of mod_security. The following rulesets are recommended with Litespeed:<br />
<br />
The recommended ''minimum ruleset'' to load is:<br />
<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_0_global.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_antimalware.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/11_asl_adv_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/20_asl_useragents.conf<br />
Include /full/path/to/your/rules/modsecurity.d/30_asl_antispam.conf<br />
Include /full/path/to/your/rules/modsecurity.d/50_asl_rootkits.conf<br />
Include /full/path/to/your/rules/modsecurity.d/60_asl_recons.conf<br />
Include /full/path/to/your/rules/modsecurity.d/61_asl_recons_dlp.conf<br />
Include /full/path/to/your/rules/modsecurity.d/99_asl_jitp.conf<br />
<br />
If you require more advanced protection, you should also load additional rule files and should use this ruleset:<br />
<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_zz_strict.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_x_searchengines.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_y_searchengines.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_0_global.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_z_antievasion.conf<br />
Include /full/path/to/your/rules/modsecurity.d/01_asl_content.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_zz_strict.conf<br />
Include /full/path/to/your/rules/modsecurity.d/03_asl_dos.conf<br />
Include /full/path/to/your/rules/modsecurity.d/09_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_antimalware.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/11_asl_adv_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/11_asl_data_loss.conf<br />
Include /full/path/to/your/rules/modsecurity.d/12_asl_adv_xss_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/20_asl_useragents.conf<br />
Include /full/path/to/your/rules/modsecurity.d/30_asl_antispam.conf<br />
Include /full/path/to/your/rules/modsecurity.d/50_asl_rootkits.conf<br />
Include /full/path/to/your/rules/modsecurity.d/51_asl_rootkits.conf<br />
Include /full/path/to/your/rules/modsecurity.d/60_asl_recons.conf<br />
Include /full/path/to/your/rules/modsecurity.d/61_asl_recons_dlp.conf<br />
Include /full/path/to/your/rules/modsecurity.d/99_asl_jitp.conf<br />
<br />
<br />
Note: [[Litespeed]] does not support content inspection (outbound rules), or lua based rules. Therefore, the following rulesets Litespeed does not support, and loading them will have no effect on the system:<br />
<br />
<br />
00_asl_z_searchengines.conf<br />
00_asl_z_aa_threat_intelligence.conf<br />
12_asl_brute.conf<br />
98_asl_adv_redactor.conf<br />
99_asl_zzzz_threat_intelligence.conf<br />
<br />
Note: Some of these rulesets are designed to work with advanced security management systems such as [[ASL]] and may not work completely without an advanced management system.<br />
<br />
===== Notes on Scanner ruleset =====<br />
<br />
NOTE: If you use this file:<br />
<br />
05_asl_scanner.conf<br />
<br />
Or this file:<br />
<br />
99_asl_scanner.conf<br />
<br />
[[ASL]] includes malware upload scanning, rules subscriptions do not.<br />
<br />
If you wish to use this ruleset, and you are not using [[ASL]], then you will need to create a script to pass the files to clamd and read the result. Make sure you have clamd installed and configured correctly to list on a TCP port, or if you use a socket, make sure apache can read/write to this socket or as a last resort, run clamd as root. Using this file will force all web uploads on your system to go thru clamav to look for malware, viruses, etc. If you dont need that, then you can leave this config file out. <br />
<br />
Real time malware upload protection is included in [[ASL]] and uses a faster method than the older style modsecurity scripting method above. So if you need realtime malware upload protection (for web, FTP, or even realtime), then upgrade to [[ASL]] which includes highspeed malware upload protection, full support, automatic and hassle free installation. ASL also protects against any form of upload of malware, including HTTP, HTTPS, SSH and FTP uploads and includes our real-time malware detection and prevention system which will detect and block any malicious software running on the system in realtime. This is just one of the many many features of [[ASL]].<br />
<br />
==== Step 10: Test your web server ====<br />
===== Test nginx =====<br />
<br />
nginx -t -c <NGINX_CONFIG_FILE><br />
<br />
Where NGINX_CONFIG_FILE is your nginx.conf file.<br />
<br />
===== Test Apache =====<br />
<br />
Before restarting apache we recommend you test your configuration by running apache with the "configtest" command. On a standard system you can do this by calling your apache init file like this:<br />
<br />
/etc/init.d/httpd configtest<br />
<br />
If you get errors, check to see that you don't have some extraneous configuration files installed.<br />
<br />
===== Testing to see if the rules are loaded =====<br />
'''<br />
Step 1)''' (for non [[ASL]] systems)<br />
<br />
Make sure you have the rules installed exactly as described on this page. This test may not work if you have not followed these instructions. (If you used ASL to setup your WAF, and you have not installed any third party tools that configure, install or manage modsecurity then your rules are installed correctly and you do not need to review the instructions on this page. If you have manually altered your modsecurity configuration then you will need to review this entire article. Manual modifications of ASL modsecurity configurations are not supported.)<br />
<br />
'''Step 2) Make sure all rules are enabled'''<br />
<br />
'''Ensure that you do not have any of our rules disabled.''' This test assumes you do not have any rules disabled, that you are not whitelisting the source of this test and that your have the Atomicorp rules loaded.<br />
<br />
'''Step 3) Test from a non-whitelisted system''' <br />
<br />
Make sure you do not have the system you are performing this from is whitelisted<br />
<br />
For example, cpanels default modsecurity configuration will configure modsecurity to ignore everything from 127.0.0.1, or from the system itself. So if you perform the test above from the server itself, and you have not removed this cpanel whitelist, then this test will not work.<br />
<br />
'''Step 4) Run the test'''<br />
<br />
On the system where the rules are installed run this command (this assumes you have wget installed, '''127.0.0.1 is NOT whitelisted''' and a web server is listening on 127.0.0.1):<br />
<br />
''wget http://localhost/foo.php?foo=http://www.example.com''<br />
<br />
If the test worked, should get a 403 error if the rules are loaded, which will look similar to this:<br />
<br />
<pre><br />
--2010-05-27 20:12:25-- http://localhost/foo.php?foo=http://www.example.com<br />
Resolving localhost... 127.0.0.1<br />
Connecting to localhost|127.0.0.1|:80... connected.<br />
HTTP request sent, awaiting response... 403 Forbidden<br />
2010-05-27 20:12:25 ERROR 403: Forbidden.<br />
</pre><br />
<br />
If you do not get a 403 error, the test did not work.<br />
<br />
You can also use your browser to test the rules by going to a URL similar to this:<br />
<br />
http://YOUR_HOST/foo.php?foo=http://www.example.com<br />
<br />
Remember to replace YOUR_HOST with the actual HOSTNAME or IP of the server.<br />
<br />
If the rules are properly loaded, you should get a 403 error, if you do not get a 403 error, the rules are not loaded correctly and you need to check your configuration to ensure that you have followed the instructions above correctly.<br />
<br />
If you get a 403 error from the command line and a 404 error from the browser, check to make sure the computer you are testing the browser from is not whitelisted on the server.<br />
<br />
Note: If you do not have wget installed, then you will need to install it or a similar tool to run this test from a Linux or UNIX based system. If you are using Windows, you can use a similar tool or your browser.<br />
<br />
====== What to do if you do not get a 403 error ======<br />
<br />
If you get a different error, such as a 404 error or a 5xx series error check your configuration. The following are common causes of this:<br />
<br />
'''1) You have rules disabled'''<br />
<br />
Make sure you do not have any rules disabled.<br />
<br />
'''2) Your IP is whitelisted'''<br />
<br />
There is a rule whitelisting the system you are conducting this test from. Whitelisting tells the WAF to ignore everything from that source.<br />
<br />
For example, cpanels default modsecurity configuration will configure modsecurity to ignore everything from 127.0.0.1, or from the system itself. So if you perform the test above from the server itself, and you have not removed this cpanel whitelist, then you will not get a 403 error. More than likely you will get a 404 error. The solution is to remove any whitelists from your system.<br />
<br />
Note: Whitelisting the server itself can open a hole in your security. You should not whitelist localhost or the servers own IP address, particularly if you have multi users on the system. This is both unnecessary, and doing so will allow any users on the system to carry out attacks on other domains on the system unimpeded. Make sure you do not have any rules like that, this opens a very large hole in your system.<br />
<br />
'''3) Local error message is different'''<br />
<br />
You or someone else may have configured your system to use a different error message. Check your configuration, and make sure it exactly matches the ones on this wiki. IF you are using kind of plugin that does not return a 403 when a connection is rejected, and you must use this, then you will need to manually check your mod_security logs to see if your test is being rejected by modsecurity. If it is, then your rules are working correctly and you can ignore the error code.<br />
<br />
'''4) Third party addons''' <br />
<br />
You have third party rules or addons installed with your modsecurity configuration that are changing the responses. Remove all third party addons, and make sure your configuration exactly matches the instructions on this page<br />
<br />
'''5) Insecurely configured apache'''<br />
<br />
Some control panels are known to disable modsecurity on localhost, and on the systems IP addresses. These highly insecure control panels essentially disable modsecurity if an attacker connects to the systems IP address. This of course leaves your system wide open to attack, and if you are unlucky enough to be using one of these control panels we recommend you report this to your control panel vendor as a serious vulnerability. If they are unwilling to fix it, then we recommend you find a more security concious control panel vendor.<br />
<br />
Example:<br />
<br />
We have seen some control panels that configure modsecurity to be disabled in the /etc/httpd/conf/httpd.conf file for all the local IPs on the system. <br />
<br />
<pre><br />
<VirtualHost <LOCAL IP ADDRESS>:80 127.0.0.1:80 *><br />
<IfModule mod_security2.c><br />
SecRuleEngine Off<br />
</IfModule><br />
</pre><br />
<br />
If your control panel has this vulnerability, you can remove this, but its very possible the control panel will simply open this hole in your system again. We highly recommend you report this vulnerability to your control panel vendor, and if they are unwilling to fix this vulnerability that you find a more security concious control panel vendor.<br />
<br />
'''6) You arent loading the rules'''<br />
<br />
This is common with custom configurations. Check to make sure your webserver is configured to load the rules. Keep mind that modsecurity will still generate generic messages even though the rules are not loaded. For example, if all you see are events like this:<br />
<br />
<pre><br />
--70c19f31-A--<br />
[01/Jan/2013:11:19:13 --0300] roiKIi6Ni3EKFZSKpSUs2iEb 1.2.3.4 34978 5.6.7.8 80<br />
--70c19f31-B--<br />
HEAD / HTTP/1.1<br />
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) <br />
<br />
Accept: */*<br />
<br />
--70c19f31-F--<br />
HTTP/1.1 403 Forbidden<br />
X-Powered-By: PHP/5.4.20<br />
Expires: Thu, 19 Jan 2001 02:12:00 GMT<br />
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0<br />
Pragma: no-cache<br />
Connection: close<br />
Content-Type: text/html<br />
<br />
--70c19f31-H--<br />
Stopwatch: 1383338363503919 358184 (- - -)<br />
Stopwatch2: 1383338363503919 358184; combined=2144, p1=37, p2=2053, p3=0, p4=0, p5=53, sr=0, sw=1, l=0, gc=0<br />
Producer: ModSecurity for Apache/2.7.5 ( http://www.modsecurity.org/).<br />
Server: Apache<br />
Engine-Mode: "ENABLED"<br />
<br />
--70c19f31-Z--<br />
</pre><br />
<br />
In this example, no rule is being triggered, but modsecurity is logging a basic 403 error. It will do this if the modsecurity configuration is loaded, but not the rules. So if you see this happening on your system, and you have ruled out all other issues in this list, it means your custom configuration isnt loading the rules.<br />
<br />
[[ASL]] will automatically configure modsecurity correctly. So if you are having problems configuring modsecurity yourself, then we recommend you use [[ASL]] to setup modsecurity for you.<br />
<br />
=== Windows ===<br />
<br />
Please see the [[modsecurity iis]] page.<br />
<br />
== Automated rules updates ==<br />
<br />
Please see the [[ASL]] page for installation instructions.<br />
<br />
= Tuning the Rules/Disabling Rules =<br />
<br />
== Disabling Rules ==<br />
<br />
See the [[mod_security]] page for details.<br />
<br />
== Tuning the Rules ==<br />
<br />
See the [[mod_security]] page for details.<br />
<br />
== Troubleshoot the Rules ==<br />
<br />
See the [[Atomicorp WAF Rules Troubleshooting]] page for details.<br />
<br />
== Reporting False Positives ==<br />
<br />
See the [[Reporting False Positives]] page for details.<br />
<br />
= Notes =<br />
<br />
== Special notes for CPANEL users not using ASL ==<br />
<br />
The Atomicorp Modsecurity rules work great with Cpanel, right out of the box. To use them with Cpanel either install [[ASL]], or manually install modsecurity and make a few changes to the mod_security configuration that comes with cpanel and then you are all set!<br />
<br />
=== Installing modsecurity in cpanel ===<br />
<br />
'''Option 1) Simplest and most powerful solution'''<br />
<br />
Install [[ASL]]. This will install modsecurity, configure it and will install the rule and event management GUI available in [[ASL]]<br />
<br />
Option 2) Install just the rules<br />
<br />
=== Manually Configuring modsecurity with cpanel ===<br />
<br />
These are additional considerations for installing modsecurity with cpanel. Please read this entire page, as well as this section if you are installing modsecurity with cpanel (even if you already have modsecurity install with cpanel).<br />
<br />
We recommend if you are using cPanel that you follow this advice, as cpanel includes a very minimal configuration for modsecurity that does not include all of the required and optimal settings documented here. Our settings will make your server faster, and more importantly more secure. If you use mod_security with Cpanel you must add these additional settings to experience the full feature set of mod_security.<br />
<br />
==== Step 1 ====<br />
<br />
Make sure you have read this entire document and have setup all the require directories details above.<br />
<br />
==== Step 2: Configure directory permissions ====<br />
<br />
Cpanel also does not run apache as a standard user (such as apache) but as the older non-privileged user "nobody". You will need to ensure then that the work directories that mod_security uses are owned by the user that Cpanel runs apache as. To find this out you can run this command as root:<br />
<br />
ps auxwww | grep httpd<br />
<br />
root 20594 86.8 3.1 255148 181232 ? Ss 11:39 0:04 /usr/local/apache/bin/httpd -k restart<br />
root 20611 0.0 3.1 255060 179596 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20612 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20613 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20614 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20615 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20616 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
<br />
In this example from a Centos system running Cpanel the user is "nobody", so you would want to use these commands to configure the modsecurity work directories for a system where apache is running as "nobody": <br />
<br />
mkdir /var/asl<br />
mkdir /var/asl/data/<br />
mkdir /var/asl/data/msa<br />
mkdir /var/asl/data/audit<br />
mkdir /var/asl/data/suspicious<br />
chown nobody.nobody /var/asl/data/msa<br />
chown nobody.nobody /var/asl/data/audit<br />
chown nobody.nobody /var/asl/data/suspicious<br />
chmod o-rx -R /var/asl/data/*<br />
chmod ug+rwx -R /var/asl/data/*<br />
<br />
==== Step 3: Install modsecurity ====<br />
<br />
Please see the current minimum version required at the link below:<br />
<br />
https://www.atomicorp.com/wiki/index.php/Atomic_ModSecurity_Rules#Minimum_Version_of_Modsecurity_Required_to_use_the_rules<br />
<br />
==== Step 4: Install mod_uniqueid ====<br />
<br />
Cpanel users will need to manually verify that the mod_unique_id module is loaded by cpanel's apache. It should be loaded by default, but check your cpanel configuration to be sure.<br />
<br />
==== Step 5: Configure cpanel ====<br />
<br />
Make a small change to the cpanel modsecurity configuration. A typical cpanel modsec2.conf configuration file looks like this:<br />
<br />
LoadFile /opt/xml2/lib/libxml2.so<br />
LoadFile /opt/lua/lib/liblua.so<br />
LoadModule security2_module modules/mod_security2.so<br />
<IfModule mod_security2.c><br />
SecRuleEngine On<br />
# See http://www.modsecurity.org/documentation/ModSecurity-Migration-Matrix.pdf<br />
# "Add the rules that will do exactly the same as the directives"<br />
# SecFilterCheckURLEncoding On<br />
# SecFilterForceByteRange 0 255<br />
SecAuditEngine RelevantOnly<br />
SecAuditLog logs/modsec_audit.log<br />
SecDebugLog logs/modsec_debug_log<br />
SecDebugLogLevel 0<br />
SecDefaultAction "phase:2,deny,log,status:403"<br />
Include "/usr/local/apache/conf/modsec2.user.conf"<br />
</IfModule><br />
<br />
Because cpanel will overwrite this configuration, you need to modify your user configuration file. You will want to setup your user configuration file (/usr/local/apache/conf/modsec2.user.conf) as in the examples below depending on the type of license you have purchased (remote rules vs downloadable rules). <br />
<br />
==== Step 5a: Remote Rules ====<br />
<br />
If you have a remote rules license, simply add these two lines to the /usr/local/apache/conf/modsec2.user.conf file,, replacing <API Key> with the value in your license signup email:<br />
<br />
''SecRemoteRulesFailAction Warn<br />
<br />
SecRemoteRules <API Key> https://waf.atomicorp.com/rules/srr.php''<br />
<br />
Additional rule classes can be specified as follows<br />
<br />
''SecRemoteRules <API Key> https://waf.atomicorp.com/rules/srr.php?antispam,recons''<br />
<br />
A full list of rule classes is available at [https://docs.atomicorp.com/gotrootModsec/remoterules.html].<br />
<br />
==== Step 5a: Downloadable Rules ====<br />
<br />
If you have a license for the downloadable rules, this is the recommended configuration and the '''minimum''' recommended rule sets that are designed to work with cpanel without [[ASL]] installed. Please be sure to read this entire page for information about additional rules that you may also want to use with cpanel.<br />
<br />
SecRequestBodyAccess On<br />
SecAuditLogType Concurrent<br />
SecResponseBodyAccess On<br />
SecResponseBodyMimeType (null) text/html text/plain text/xml<br />
SecResponseBodyLimit 2621440<br />
SecAuditLogRelevantStatus "^(?:5|4(?!04))"<br />
SecServerSignature Apache<br />
SecUploadDir /var/asl/data/suspicious<br />
SecUploadKeepFiles Off<br />
SecAuditLogParts ABIFHZ<br />
SecArgumentSeparator "&"<br />
SecCookieFormat 0<br />
SecRequestBodyInMemoryLimit 131072<br />
SecDataDir /var/asl/data/msa<br />
SecTmpDir /tmp<br />
SecAuditLogStorageDir /var/asl/data/audit<br />
SecResponseBodyLimitAction ProcessPartial<br />
<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_z_antievasion.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_zz_strict.conf<br />
Include /full/path/to/your/rules/modsecurity.d/09_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_antimalware.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/11_asl_adv_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/20_asl_useragents.conf<br />
Include /full/path/to/your/rules/modsecurity.d/30_asl_antispam.conf<br />
Include /full/path/to/your/rules/modsecurity.d/50_asl_rootkits.conf<br />
Include /full/path/to/your/rules/modsecurity.d/60_asl_recons.conf<br />
Include /full/path/to/your/rules/modsecurity.d/61_asl_recons_dlp.conf<br />
Include /full/path/to/your/rules/modsecurity.d/99_asl_jitp.conf<br />
<br />
If you want to load just some of the rules, make sure you specify only those rule files. The default list above is the recommended and supported rulesets with cpanel. Do not use the other asl rulesets with cpanel, those other rules either use other apache modules (such as mod_sed) or ASL specific features that require [[ASL]].<br />
<br />
Then run this command as root to install the rules:<br />
<br />
[[aum]] -u<br />
<br />
Or if you want to install the rules files manually, please see the [https://www.atomicorp.com/wiki/index.php/Atomic_ModSecurity_Rules#Step_8:_Download_the_ModSecurity_Rules Downloading rules] section above.<br />
<br />
==== Step 7: Restart Apache ====<br />
<br />
Restart apache, enjoy your new secure web server!<br />
<br />
<br />
<br />
==== Optional Steps ====<br />
<br />
===== Malware Scanner =====<br />
<br />
The malware scanner is included in [[ASL]], it is not included in the rules or rule subscriptions. Therefore, if you use this file:<br />
<br />
05_asl_scanner.conf<br />
<br />
Or this:<br />
<br />
99_asl_scanner.conf<br />
<br />
You will need to include your own scanner, and will need to make sure you have clamd installed and configured correctly to listen on a TCP port, or if you use a socket, make sure apache can read/write to this socket or as a last resort, run clamd as root. Using this file forces all web uploads on your system to go thru clamav to look for malware, viruses, etc. If you dont need that, then you can leave this config file out.<br />
<br />
<br />
==== Cpanel Error Messages ====<br />
<br />
==== modsecparse.pl ====<br />
<br />
'''This is a third party tool not provided by, or supported by Atomicorp.''' If you use this tool, it apparently does not work with the new fast concurrent logging system in modsecurity. The concurrent logging system is much faster, will speed up apache and is less resource intensive that the older serial method. <br />
<br />
However, if you use this tool you must use the slower serial logging method, as it does not support the faster concurrent method. To use this tool, change the SecAuditLogType setting from "Concurrent" to "Serial":<br />
<br />
SecAuditLogType Serial<br />
<br />
'''Keep in mind that this logging method is much slower, may slow down apache and is not supported.''' This performance impact is not caused by the rules. Serial logging is much slower than concurrent logging. Therefore we do not recommend you use this logging method or any tools that require it. There are lots of modsecurity log readers that can use the concurrent logging method, such as [[ASL]] and we encourage you to explore using one of those modern tools instead.<br />
<br />
==== Serial logging ====<br />
<br />
===== Discussion =====<br />
<br />
Serial logging is the older slower depreacted logging method modsecurity original used many years ago. This logging method would log the entire event in a single file. As a result, it would slow apache down because each event needed to wait for the previous event to finish writing before it could write to the log file. Events stack up and slow apache down. This incurs a significant performance penalty on apache, and of course a better method was devised for modsecurity to address this performance issue. The solution is the concurrent logging method. This generates a unique event file for each log event, logging the events data to that file instead of trying to jam tons of data into a single file, and thereby slowing down apache. All modern modsecurity log viewing tools support the concurrent method.<br />
<br />
The concurrent logging system is much faster, will speed up apache and is less resource intensive that the older serial method. This method is highly recommended over the slow serial logging method.<br />
<br />
===== Configuration =====<br />
<br />
====== aum ======<br />
<br />
If you want to use the old slower serial logging method, and you are using aum, change this setting in /etc/asl/config:<br />
<br />
MODSEC_LOGTYPE="Concurrent"<br />
<br />
<br />
To:<br />
<br />
MODSEC_LOGTYPE="Serial"<br />
<br />
<br />
And then run:<br />
<br />
aum -uf<br />
<br />
====== non-aum systems ======<br />
<br />
If you want to use the old slower serial logging method change the SecAuditLogType setting from "Concurrent" to "Serial":<br />
<br />
SecAuditLogType Serial<br />
<br />
'''Warning: Serial logging is much slower than concurrent logging and will slow down apache.''' Any performance impact is not caused by the rules. <br />
<br />
Therefore we do not recommend you use this logging method or any tools that require it. There are lots of modsecurity log readers that can use the fast concurrent logging method, such as [[ASL]] and we encourage you to explore using one of those modern tools instead of a tool that requires the slower and performance degrading serial logging method.<br />
<br />
If you change your system to the slower Serial method, you may also want to change the logfile name you are using for your modsecurity logs. You can do that by changing this option in your configuration:<br />
<br />
SecAuditLog logs/audit_log</div>Mshinnhttps://wiki.atomicorp.com/wiki/index.php/Atomic_ModSecurity_RulesAtomic ModSecurity Rules2022-09-27T17:16:11Z<p>Mshinn: /* Special notes for CPANEL users not using ASL */</p>
<hr />
<div>[[Atomic Secured Linux]] includes modsecurity, and the Real Time GotRoot.com/Atomicorp Modsecurity Rules. These docs are for users that do not have [[ASL]].<br />
<br />
'''ASL will install and configure modsecurity, and provides a powerful and easy use to GUI to manage all of this for you. If you don't have ASL, [https://www.atomicorp.com/amember/cart/index/index?c=1 upgrade to ASL today!]'''<br />
<br />
= '''About the rules''' =<br />
<br />
The gotroot.com rules are written by us - we are the gotroot guys. Same great rules, same team, ten years of writing modsecurity rules and still going strong! GotRoot is our Information Assurance lab and [http://www.atomicorp.com Atomicorp] is the product arm of [http://www.progllc.com Prometheus Global] (the parent company for both). So when you get the gotroot.com rules from atomicorp.com or gotroot.com - you're getting the same rules from the same people that created, write and maintain them. In the future we will be merging the gotroot.com, atomicrocketturtle and atomicorp websites into the atomicorp.com website.<br />
<br />
We publish two versions of the rules:<br />
<br />
'''RealTime Rules:''' The latest and greatest version of the rules, with all the performance enhancements, new security features and bug fixes released by us on a daily basis. These rules are fully supported and are recommended for production use.<br />
<br />
'''Free/Delayed Rules:''' A delayed subset of the Advanced rules.<br />
<br />
Installation of the rules assumes a certain level of comfort with configuring apache. If you are not comfortable with configuring apache, you should contact someone that is, or use our [[Atomic Secured Linux]] product which does this automatically for you, and does not require you to configure apache.<br />
<br />
== Getting the rules ==<br />
<br />
[https://www.atomicorp.com/amember/cart/index/index?c=6 Click here] to get the Atomicorp ModSecurity Rules.<br />
<br />
== '''Atomic ModSecurity Rules Frequently Asked Questions''' ==<br />
<br />
Please see the [[Atomic ModSecurity Rules FAQ]] wiki page.<br />
<br />
== '''Real Time Rule Support''' ==<br />
<br />
If you have a subscription to the real time rules, you can request email support by sending an email to:<br />
<br />
support@atomicorp.com<br />
<br />
The Customer Support Forums are located here:<br />
<br />
[http://www.atomicorp.com/forums Customer Support Forums]<br />
<br />
And the Custom Support Portal is located here (you can submit bug reports and open cases through the portal):<br />
<br />
[https://www.atomicorp.com/portal Customer Support Portal]<br />
<br />
== '''Licenses''' ==<br />
<br />
The Real Time Atomic ModSecurity Rules are licensed by the server. You can order licenses from the online store at the link below:<br />
<br />
[https://www.atomicorp.com/amember/cart/index/index?c=6 Online Store]<br />
<br />
If you require additional licenses please log into the [https://www.atomicorp.com/support/license-manager.html AtomiCorp License Manager]. You can add additional systems there, you can control your payment methods and you can also sign up to become an affiliate.<br />
<br />
=== License Terms and Conditions ===<br />
<br />
Purchase of an Atomicorp ModSecurity rule license entitles the purchaser to access and download from the Atomicorp Repository to a single IP address within the time period of the license. A separate license is required for each dedicated server/host or VPS that the rule set is installed upon or is protecting.<br />
<br />
Atomicorp ModSecurity rules installed upon a Reverse Proxy WAF appliance/server requires a separate license. Please contact Atomicorp support for details.<br />
<br />
The rule set cannot be copied, mirrored, or reproduced under protection of US and International copyright laws.<br />
<br />
Use of the rule set is limited to the time period of the license. If the license period of a rule set expires, it must must removed from its installed server and no longer used. Atomicorp reserves the right to track and enforce license compliance of the Atomicorp Modsecurity rule sets.<br />
<br />
Agreement to these terms and conditions and the Atomicorp [https://atomicorp.com/eula.html End User License Agreement] is required to download and use the Atomicorp ModSecurity rules.<br />
<br />
== Important Information about the Rules ==<br />
<br />
=== Minimum Version of Modsecurity Required to use the rules ===<br />
<br />
The rules are supported with the following versions of Modsecurity:<br />
<br />
<br />
* 2.9.3<br />
<br />
We recommend customers use our modsecurity builds, as they are tested to ensure all features work correctly. Third party builds may not include the correct libraries, may cause problems with your web server, including crashes and may disable or incorrectly enable features in modsecurity that can cause unpredictable behavior or failure of rules to process correctly.<br />
<br />
If you need a solution to keep the rules and modsecurity up to date and in sync with your version of modsecurity automatically, please use [[aum]] or [[ASL]] which will do this for you automatically.<br />
<br />
==== What versions of modsecurity do the rules work with ====<br />
<br />
They work with both modsecurity 2.9.x, and modsecurity 3.x.<br />
<br />
=== What does each rule family do? ===<br />
<br />
Please see the [[modsecurity_rule_families]] documents.<br />
<br />
= Installation =<br />
<br />
== Easy One Step Installation ==<br />
<br />
<br />
<br />
===== Full Management Suite =====<br />
<br />
Install [[ASL]]. This installs everything: modsecurity, all the rules, the GUI, rule manager and all ASL components, plus it includes the subscription to the real time rules.<br />
<br />
ASL will automatically download and keep your rules up to date, and will ensure that modsecurity stays up to date so your system can support the latest rules. ASL also provides you with a full security management suite, which will allow you to manage, edit and configure your rules through a web console. It will also protect you from uploaded malware, brute force attacks, DOS attacks, rootkits and many other threats that a WAF can not protect you from.<br />
<br />
A full list of ASLs features is available at the URL below:<br />
<br />
https://www.atomicorp.com/products/asl.html<br />
<br />
===== Just a downloader =====<br />
<br />
We also provide an automated rule updater and modsecurity installation tool, called [[aum]]. You can read more about it on the [[aum]] page. You can install it by running these commands as root:<br />
<br />
Step 1) Install [[aum]]<br />
<br />
''wget -q -O - https://updates.atomicorp.com/installers/aum |bash''<br />
<br />
Step 2) Configure [[aum]]<br />
<br />
''aum configure''<br />
<br />
Step 3) Tell [[aum]] to install the rules<br />
<br />
''aum upgrade''<br />
<br />
You can read more about aum on the [[aum]] documentation page.<br />
<br />
Note: This capability is included in [[ASL]]. ASL users do not need to install aum, its already included.<br />
<br />
== (Optional) Do It Yourself Installation ==<br />
<br />
Note: A manual installation is not necessary if you have [[ASL]] installed. ASL will configure and install modsecurity, and the rules, automatically. This is also not necessary if you are using our new AUM software to handle rule download and installation.<br />
<br />
=== Linux ===<br />
<br />
==== Step 1: Download ModSecurity ====<br />
<br />
Binaries:<br />
<br />
[http://updates.atomicorp.com/channels/atomic/ Install modsecurity from the Atomicorp software repository]<br />
<br />
Source Code:<br />
<br />
[http://updates.atomicorp.com/channels/atomic/ Install modsecurity from the Atomicorp software repository]<br />
<br />
Please note that the rules are only supported with the version of modsecurity [http://wiki.atomicorp.com/wiki/index.php/Atomic_ModSecurity_Rules#Minimum_Version_of_Modsecurity_Required_to_use_the_rules identified in this section of the wiki.]<br />
<br />
Note: Please contact us before using a third party or source build of modsecurity. Its critical modsecurity be built correctly to work with the rules.<br />
<br />
==== Step 2: Set up and configure directories ====<br />
<br />
Create the following directories as root:<br />
<br />
mkdir /etc/httpd/modsecurity.d<br />
mkdir /var/asl<br />
mkdir /var/asl/tmp<br />
mkdir /var/asl/data<br />
mkdir /var/asl/data/msa<br />
mkdir /var/asl/data/audit<br />
mkdir /var/asl/data/suspicious<br />
<br />
==== Step 3: Set permissions for directories ====<br />
<br />
Set the following permissions on the directories you just created. In this example these directories are set to be owned by "apache" and the group "apache", which is standard on a normal Centos or RHEL system. However some control panels configure apache to run as a different user, such as nobody, or http. <br />
<br />
To determine what user this is, check your system to see what user your webserver uses. You can use this command to find the user:<br />
<br />
ps auxwww | grep httpd<br />
<br />
The output will look similar to this:<br />
<br />
(RHEL/Centos example with or without Plesk)<br />
<br />
root 26755 0.0 4.3 430752 86432 ? Ss 04:30 0:01 /usr/sbin/httpd<br />
'''apache''' 26908 0.0 3.7 300564 75076 ? S 04:30 0:00 /usr/sbin/httpd<br />
'''apache''' 26909 0.1 5.5 495812 112084 ? S 04:30 0:37 /usr/sbin/httpd<br />
'''apache''' 26910 0.0 5.3 495424 106672 ? S 04:30 0:23 /usr/sbin/httpd<br />
'''apache''' 26911 0.1 5.7 495892 114368 ? S 04:30 0:57 /usr/sbin/httpd<br />
'''apache''' 26912 0.1 5.7 496056 114440 ? S 04:30 0:52 /usr/sbin/httpd<br />
'''apache''' 26913 0.1 5.5 496604 110692 ? S 04:30 0:57 /usr/sbin/httpd<br />
'''apache''' 26914 0.0 5.7 499324 116236 ? S 04:30 0:16 /usr/sbin/httpd<br />
'''apache''' 26915 0.2 5.5 493600 112192 ? S 04:30 1:09 /usr/sbin/httpd<br />
'''apache''' 26916 0.1 6.4 513760 129992 ? S 04:30 0:30 /usr/sbin/httpd<br />
<br />
In this example the user in bold is "apache" (this may be different for your system). This is the user you will want to set the directory permissions to (as in the example below):<br />
<br />
chown apache.apache /var/asl/data/msa<br />
chown apache.apache /var/asl/data/audit<br />
chown apache.apache /var/asl/data/suspicious<br />
chmod o-rx -R /var/asl/data/*<br />
chmod ug+rwx -R /var/asl/data/*<br />
<br />
(RHEL/Centos example with Cpanel)<br />
<br />
root 20594 86.8 3.1 255148 181232 ? Ss 11:39 0:04 /usr/local/apache/bin/httpd -k restart<br />
root 20611 0.0 3.1 255060 179596 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20612 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20613 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20614 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20615 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20616 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
<br />
In this example from a Centos system running Cpanel the user is "nobody", so you would want to use these commands:<br />
<br />
chown nobody.nobody /var/asl/data/msa<br />
chown nobody.nobody /var/asl/data/audit<br />
chown nobody.nobody /var/asl/data/suspicious<br />
chmod o-rx -R /var/asl/data/*<br />
chmod ug+rwx -R /var/asl/data/*<br />
<br />
==== Step 4: (Optional) Create rule updater directories ====<br />
These directories must as be created if you use optional rules updater. Create these directories as root and they only need to be accessed by root:<br />
<br />
mkdir /var/asl/updates<br />
mkdir /var/asl/rules/<br />
mkdir /var/asl/rules/clamav<br />
<br />
==== Step 5: Create the whitelist file ====<br />
<br />
Create this file:<br />
<br />
touch /etc/asl/whitelist<br />
<br />
This file contains a list of IPs you want to exclude from ALL rules. That means those IPs can do anything to your system - so be very very careful about what IPs you add to this list. This is a dangerous thing to do. The format of the file is a single IP, per line. <br />
<br />
Cpanel users should skip to the notes at the bottom of this page for special additional actions for cpanel systems. All other users should continue with these instructions.<br />
<br />
==== Step 6: Configure your webserver ====<br />
<br />
===== nginx =====<br />
<br />
===== Step 6a: configure nginx to load modsecurity =====<br />
<br />
====== nginx proxying to a backend ======<br />
<br />
If you are using nginx as a frontend to another webserver, then add the following directives to your nginx.conf file.<br />
<br />
<pre><br />
location / {<br />
ModSecurityEnabled on;<br />
ModSecurityConfig modsecurity.conf;<br />
proxy_pass http://localhost:8080;<br />
proxy_read_timeout 180s;<br />
}<br />
<br />
</pre><br />
<br />
Change "localhost:8011" to the server you are proxying nginx to, and change 8080 to the portnumber for that server. For example, if you are running apache on port 8088 on localhost the line would be:<br />
<br />
proxy_pass http://localhost:8088;<br />
<br />
====== nginx standalone ======<br />
<br />
If you are only using nginx, and not using it as a frontend to another web server then you want to use this configuration:<br />
<br />
<pre><br />
location / {<br />
ModSecurityEnabled on;<br />
ModSecurityConfig modsecurity.conf;<br />
}<br />
</pre><br />
<br />
===== Apache =====<br />
<br />
===== Step 6a: configure apache to load modsecurity =====<br />
<br />
You then need to tell apache to load modsecurity. Depending on your apache configuration, apache should be configured to include configuration files. If you have a setting like this in your apache config:<br />
<br />
Include conf.d/*.conf<br />
<br />
Then you are setup to load external configuration files. If you do not have this setup, its highly recommend you add this. This installation guide is written for this type of configuration. Loading mod_security occurs by including a modsecurity configuration file in that directory. We recommend you name the name 00_modsecurity.conf to ensure it runs first. Its vitally important that modsecurity load before other modules, otherwise attacks can occur before modsecurity scans them and some attacks can be missed.<br />
<br />
An example 00_modsecurity.conf file that works with our files is included here:<br />
<br />
LoadModule security2_module modules/mod_security2.so<br />
LoadModule unique_id_module modules/mod_unique_id.so<br />
<IfModule mod_security2.c><br />
Include modsecurity.d/tortix_waf.conf<br />
</IfModule><br />
<br />
Install this file in your conf.d directory. On a standard RHEL or Centos system that directory is located here:<br />
<br />
/etc/httpd/conf.d/<br />
<br />
=== Step 7: Configure modsecurity ===<br />
<br />
You then need to configure modsecurity. This is done via the an apache configuration file. In this example, we will create the file "tortix_waf.conf". Here is an example file that works with our rules:<br />
<br />
SecRuleEngine On<br />
SecRequestBodyAccess On<br />
SecResponseBodyAccess On<br />
SecResponseBodyMimeType (null) text/html text/plain text/xml<br />
SecResponseBodyLimit 2621440<br />
SecServerSignature Apache<br />
SecComponentSignature 200911012341<br />
SecUploadDir /var/asl/data/suspicious<br />
SecUploadKeepFiles Off<br />
SecAuditEngine RelevantOnly<br />
SecAuditLogRelevantStatus "^(?:5|4(?!04))"<br />
SecAuditLogType Concurrent<br />
SecAuditLog logs/audit_log<br />
[[SecAuditLogParts]] ABIFHZ<br />
SecArgumentSeparator "&" <br />
SecCookieFormat 0<br />
SecRequestBodyInMemoryLimit 131072<br />
SecDataDir /var/asl/data/msa<br />
SecTmpDir /tmp<br />
SecAuditLogStorageDir /var/asl/data/audit<br />
SecResponseBodyLimitAction ProcessPartial<br />
SecAuditLogDirMode 0770<br />
SecPcreMatchLimit 250000 <br />
SecPcreMatchLimitRecursion 250000<br />
<br />
You will want to install this file in your modsecurity.d directory, which is located here if you follow the instructions above:<br />
<br />
/etc/httpd/modsecurity.d<br />
<br />
==== tortix_waf.conf ====<br />
<br />
You can also download an example version of the modsecurity configuration file from here:<br />
<br />
https://www.atomicorp.com/installer/tortix_waf.conf<br />
<br />
[[ASL]] will automatically generate this file depending on your needs. If you are not using ASL, you will need to modify this configuration file to suit your system and modsecurity requirements.<br />
<br />
==== Step 8: Download the ModSecurity Rules ====<br />
<br />
See the [[Downloading Rules]] page.<br />
<br />
==== Step 9: Install the rules ====<br />
<br />
==== Remove any previous installations of rules ====<br />
<br />
If you have installed our delayed rules, you will need to make sure you have deleted them. You will not want to have any older versions of the rules installed.<br />
<br />
Also, if you have installed any third party modsecurity rules, you will want to make sure they are using rule id's that are assigned to them. The modsecurity project assigns ranges to the rule id's modsecurity uses. Modsecurity requires a unique id for each rule, otherwise you will get an error like this:<br />
<br />
ModSecurity: Found another rule with the same id<br />
<br />
This means either that someone else is using the same rule id's assigned to our ruleset by the modsecurity project (our official range is 300000-399999), or you have loaded our rules twice.<br />
<br />
==== Installation ====<br />
<br />
Download the rules to a temporary directory using your favorite download tool. Extract the rules:<br />
<br />
tar zxvf /var/asl/updates/modsec-200911012341.tar.gz<br />
<br />
Then copy each of the ASL rule files you wish to use into /etc/httpd/modsecurity.d. Do not copy all of the rule files, you will need to select rule files that are appropriate for your system. Or simply use [[aum]] or [[ASL]] to do this for you automatically.<br />
<br />
If you are using cpanel, please see the notes at the bottom of this page, cpanel does not use the standard locations for apache configuration files.<br />
<br />
Finally, load the rules. '''Make sure you specify only those rule files that are appropriate for your system.''' For example:<br />
<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/99_asl_jitp.conf<br />
<br />
'''Warning: You should NOT include all the rules. There are rulesets, documented above, that replace other rulesets and are incompatible with each other.'''<br />
<br />
===== Recommend minimum rulesets =====<br />
<br />
====== apache ======<br />
<br />
The recommended ''minimum ruleset'' to load is:<br />
<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_0_global.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_antimalware.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/11_asl_adv_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/20_asl_useragents.conf<br />
Include /full/path/to/your/rules/modsecurity.d/30_asl_antispam.conf<br />
Include /full/path/to/your/rules/modsecurity.d/50_asl_rootkits.conf<br />
Include /full/path/to/your/rules/modsecurity.d/60_asl_recons.conf<br />
Include /full/path/to/your/rules/modsecurity.d/61_asl_recons_dlp.conf<br />
Include /full/path/to/your/rules/modsecurity.d/99_asl_jitp.conf<br />
<br />
If you have modsecurity 2.9.0 and up installed, you should also load additional rule files and should use this ruleset:<br />
<br />
Include /full/path/to/your/rules/modsecurity.d/000_asl_threat_intelligence.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_zz_strict.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_0_global.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_z_antievasion.conf<br />
Include /full/path/to/your/rules/modsecurity.d/01_asl_content.conf<br />
Include /full/path/to/your/rules/modsecurity.d/01_asl_content_z.conf<br />
Include /full/path/to/your/rules/modsecurity.d/03_asl_dos.conf<br />
Include /full/path/to/your/rules/modsecurity.d/09_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_antimalware.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/11_asl_adv_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/11_asl_data_loss.conf<br />
Include /full/path/to/your/rules/modsecurity.d/12_asl_adv_xss_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/20_asl_useragents.conf<br />
Include /full/path/to/your/rules/modsecurity.d/30_asl_antispam.conf<br />
Include /full/path/to/your/rules/modsecurity.d/50_asl_rootkits.conf<br />
Include /full/path/to/your/rules/modsecurity.d/51_asl_rootkits.conf<br />
Include /full/path/to/your/rules/modsecurity.d/60_asl_recons.conf<br />
Include /full/path/to/your/rules/modsecurity.d/61_asl_recons_dlp.conf<br />
Include /full/path/to/your/rules/modsecurity.d/99_asl_jitp.conf<br />
Include /full/path/to/your/rules/modsecurity.d/98_asl_adv_redactor.conf<br />
<br />
If you have a [[Local DNS resolver]] setup and properly configured on your system, and you are using modsecurity 2.9.0 and up we also recommend these additional rulesets:<br />
<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_z_searchengines.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_z_aa_threat_intelligence.conf<br />
Include /full/path/to/your/rules/modsecurity.d/99_asl_zzzz_threat_intelligence.conf<br />
<br />
Note: Some of these rulesets are designed to work with advanced security management systems such as [[ASL]] and may not work completely without an advanced management system.<br />
<br />
====== nginx ======<br />
<br />
The same rulesets as apache will work with nginx.<br />
<br />
====== litespeed ======<br />
<br />
[[Litespeed]] has a proprietary implementation of mod_security. It does not support all the features that mod_security with apache, IIS and nginx does. Therefore, you can not use all the rulesets with Litespeed, as Litespeed does not support those features of mod_security. The following rulesets are recommended with Litespeed:<br />
<br />
The recommended ''minimum ruleset'' to load is:<br />
<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_0_global.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_antimalware.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/11_asl_adv_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/20_asl_useragents.conf<br />
Include /full/path/to/your/rules/modsecurity.d/30_asl_antispam.conf<br />
Include /full/path/to/your/rules/modsecurity.d/50_asl_rootkits.conf<br />
Include /full/path/to/your/rules/modsecurity.d/60_asl_recons.conf<br />
Include /full/path/to/your/rules/modsecurity.d/61_asl_recons_dlp.conf<br />
Include /full/path/to/your/rules/modsecurity.d/99_asl_jitp.conf<br />
<br />
If you require more advanced protection, you should also load additional rule files and should use this ruleset:<br />
<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_zz_strict.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_x_searchengines.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_y_searchengines.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_0_global.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_z_antievasion.conf<br />
Include /full/path/to/your/rules/modsecurity.d/01_asl_content.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_zz_strict.conf<br />
Include /full/path/to/your/rules/modsecurity.d/03_asl_dos.conf<br />
Include /full/path/to/your/rules/modsecurity.d/09_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_antimalware.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/11_asl_adv_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/11_asl_data_loss.conf<br />
Include /full/path/to/your/rules/modsecurity.d/12_asl_adv_xss_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/20_asl_useragents.conf<br />
Include /full/path/to/your/rules/modsecurity.d/30_asl_antispam.conf<br />
Include /full/path/to/your/rules/modsecurity.d/50_asl_rootkits.conf<br />
Include /full/path/to/your/rules/modsecurity.d/51_asl_rootkits.conf<br />
Include /full/path/to/your/rules/modsecurity.d/60_asl_recons.conf<br />
Include /full/path/to/your/rules/modsecurity.d/61_asl_recons_dlp.conf<br />
Include /full/path/to/your/rules/modsecurity.d/99_asl_jitp.conf<br />
<br />
<br />
Note: [[Litespeed]] does not support content inspection (outbound rules), or lua based rules. Therefore, the following rulesets Litespeed does not support, and loading them will have no effect on the system:<br />
<br />
<br />
00_asl_z_searchengines.conf<br />
00_asl_z_aa_threat_intelligence.conf<br />
12_asl_brute.conf<br />
98_asl_adv_redactor.conf<br />
99_asl_zzzz_threat_intelligence.conf<br />
<br />
Note: Some of these rulesets are designed to work with advanced security management systems such as [[ASL]] and may not work completely without an advanced management system.<br />
<br />
===== Notes on Scanner ruleset =====<br />
<br />
NOTE: If you use this file:<br />
<br />
05_asl_scanner.conf<br />
<br />
Or this file:<br />
<br />
99_asl_scanner.conf<br />
<br />
[[ASL]] includes malware upload scanning, rules subscriptions do not.<br />
<br />
If you wish to use this ruleset, and you are not using [[ASL]], then you will need to create a script to pass the files to clamd and read the result. Make sure you have clamd installed and configured correctly to list on a TCP port, or if you use a socket, make sure apache can read/write to this socket or as a last resort, run clamd as root. Using this file will force all web uploads on your system to go thru clamav to look for malware, viruses, etc. If you dont need that, then you can leave this config file out. <br />
<br />
Real time malware upload protection is included in [[ASL]] and uses a faster method than the older style modsecurity scripting method above. So if you need realtime malware upload protection (for web, FTP, or even realtime), then upgrade to [[ASL]] which includes highspeed malware upload protection, full support, automatic and hassle free installation. ASL also protects against any form of upload of malware, including HTTP, HTTPS, SSH and FTP uploads and includes our real-time malware detection and prevention system which will detect and block any malicious software running on the system in realtime. This is just one of the many many features of [[ASL]].<br />
<br />
==== Step 10: Test your web server ====<br />
===== Test nginx =====<br />
<br />
nginx -t -c <NGINX_CONFIG_FILE><br />
<br />
Where NGINX_CONFIG_FILE is your nginx.conf file.<br />
<br />
===== Test Apache =====<br />
<br />
Before restarting apache we recommend you test your configuration by running apache with the "configtest" command. On a standard system you can do this by calling your apache init file like this:<br />
<br />
/etc/init.d/httpd configtest<br />
<br />
If you get errors, check to see that you don't have some extraneous configuration files installed.<br />
<br />
===== Testing to see if the rules are loaded =====<br />
'''<br />
Step 1)''' (for non [[ASL]] systems)<br />
<br />
Make sure you have the rules installed exactly as described on this page. This test may not work if you have not followed these instructions. (If you used ASL to setup your WAF, and you have not installed any third party tools that configure, install or manage modsecurity then your rules are installed correctly and you do not need to review the instructions on this page. If you have manually altered your modsecurity configuration then you will need to review this entire article. Manual modifications of ASL modsecurity configurations are not supported.)<br />
<br />
'''Step 2) Make sure all rules are enabled'''<br />
<br />
'''Ensure that you do not have any of our rules disabled.''' This test assumes you do not have any rules disabled, that you are not whitelisting the source of this test and that your have the Atomicorp rules loaded.<br />
<br />
'''Step 3) Test from a non-whitelisted system''' <br />
<br />
Make sure you do not have the system you are performing this from is whitelisted<br />
<br />
For example, cpanels default modsecurity configuration will configure modsecurity to ignore everything from 127.0.0.1, or from the system itself. So if you perform the test above from the server itself, and you have not removed this cpanel whitelist, then this test will not work.<br />
<br />
'''Step 4) Run the test'''<br />
<br />
On the system where the rules are installed run this command (this assumes you have wget installed, '''127.0.0.1 is NOT whitelisted''' and a web server is listening on 127.0.0.1):<br />
<br />
''wget http://localhost/foo.php?foo=http://www.example.com''<br />
<br />
If the test worked, should get a 403 error if the rules are loaded, which will look similar to this:<br />
<br />
<pre><br />
--2010-05-27 20:12:25-- http://localhost/foo.php?foo=http://www.example.com<br />
Resolving localhost... 127.0.0.1<br />
Connecting to localhost|127.0.0.1|:80... connected.<br />
HTTP request sent, awaiting response... 403 Forbidden<br />
2010-05-27 20:12:25 ERROR 403: Forbidden.<br />
</pre><br />
<br />
If you do not get a 403 error, the test did not work.<br />
<br />
You can also use your browser to test the rules by going to a URL similar to this:<br />
<br />
http://YOUR_HOST/foo.php?foo=http://www.example.com<br />
<br />
Remember to replace YOUR_HOST with the actual HOSTNAME or IP of the server.<br />
<br />
If the rules are properly loaded, you should get a 403 error, if you do not get a 403 error, the rules are not loaded correctly and you need to check your configuration to ensure that you have followed the instructions above correctly.<br />
<br />
If you get a 403 error from the command line and a 404 error from the browser, check to make sure the computer you are testing the browser from is not whitelisted on the server.<br />
<br />
Note: If you do not have wget installed, then you will need to install it or a similar tool to run this test from a Linux or UNIX based system. If you are using Windows, you can use a similar tool or your browser.<br />
<br />
====== What to do if you do not get a 403 error ======<br />
<br />
If you get a different error, such as a 404 error or a 5xx series error check your configuration. The following are common causes of this:<br />
<br />
'''1) You have rules disabled'''<br />
<br />
Make sure you do not have any rules disabled.<br />
<br />
'''2) Your IP is whitelisted'''<br />
<br />
There is a rule whitelisting the system you are conducting this test from. Whitelisting tells the WAF to ignore everything from that source.<br />
<br />
For example, cpanels default modsecurity configuration will configure modsecurity to ignore everything from 127.0.0.1, or from the system itself. So if you perform the test above from the server itself, and you have not removed this cpanel whitelist, then you will not get a 403 error. More than likely you will get a 404 error. The solution is to remove any whitelists from your system.<br />
<br />
Note: Whitelisting the server itself can open a hole in your security. You should not whitelist localhost or the servers own IP address, particularly if you have multi users on the system. This is both unnecessary, and doing so will allow any users on the system to carry out attacks on other domains on the system unimpeded. Make sure you do not have any rules like that, this opens a very large hole in your system.<br />
<br />
'''3) Local error message is different'''<br />
<br />
You or someone else may have configured your system to use a different error message. Check your configuration, and make sure it exactly matches the ones on this wiki. IF you are using kind of plugin that does not return a 403 when a connection is rejected, and you must use this, then you will need to manually check your mod_security logs to see if your test is being rejected by modsecurity. If it is, then your rules are working correctly and you can ignore the error code.<br />
<br />
'''4) Third party addons''' <br />
<br />
You have third party rules or addons installed with your modsecurity configuration that are changing the responses. Remove all third party addons, and make sure your configuration exactly matches the instructions on this page<br />
<br />
'''5) Insecurely configured apache'''<br />
<br />
Some control panels are known to disable modsecurity on localhost, and on the systems IP addresses. These highly insecure control panels essentially disable modsecurity if an attacker connects to the systems IP address. This of course leaves your system wide open to attack, and if you are unlucky enough to be using one of these control panels we recommend you report this to your control panel vendor as a serious vulnerability. If they are unwilling to fix it, then we recommend you find a more security concious control panel vendor.<br />
<br />
Example:<br />
<br />
We have seen some control panels that configure modsecurity to be disabled in the /etc/httpd/conf/httpd.conf file for all the local IPs on the system. <br />
<br />
<pre><br />
<VirtualHost <LOCAL IP ADDRESS>:80 127.0.0.1:80 *><br />
<IfModule mod_security2.c><br />
SecRuleEngine Off<br />
</IfModule><br />
</pre><br />
<br />
If your control panel has this vulnerability, you can remove this, but its very possible the control panel will simply open this hole in your system again. We highly recommend you report this vulnerability to your control panel vendor, and if they are unwilling to fix this vulnerability that you find a more security concious control panel vendor.<br />
<br />
'''6) You arent loading the rules'''<br />
<br />
This is common with custom configurations. Check to make sure your webserver is configured to load the rules. Keep mind that modsecurity will still generate generic messages even though the rules are not loaded. For example, if all you see are events like this:<br />
<br />
<pre><br />
--70c19f31-A--<br />
[01/Jan/2013:11:19:13 --0300] roiKIi6Ni3EKFZSKpSUs2iEb 1.2.3.4 34978 5.6.7.8 80<br />
--70c19f31-B--<br />
HEAD / HTTP/1.1<br />
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) <br />
<br />
Accept: */*<br />
<br />
--70c19f31-F--<br />
HTTP/1.1 403 Forbidden<br />
X-Powered-By: PHP/5.4.20<br />
Expires: Thu, 19 Jan 2001 02:12:00 GMT<br />
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0<br />
Pragma: no-cache<br />
Connection: close<br />
Content-Type: text/html<br />
<br />
--70c19f31-H--<br />
Stopwatch: 1383338363503919 358184 (- - -)<br />
Stopwatch2: 1383338363503919 358184; combined=2144, p1=37, p2=2053, p3=0, p4=0, p5=53, sr=0, sw=1, l=0, gc=0<br />
Producer: ModSecurity for Apache/2.7.5 ( http://www.modsecurity.org/).<br />
Server: Apache<br />
Engine-Mode: "ENABLED"<br />
<br />
--70c19f31-Z--<br />
</pre><br />
<br />
In this example, no rule is being triggered, but modsecurity is logging a basic 403 error. It will do this if the modsecurity configuration is loaded, but not the rules. So if you see this happening on your system, and you have ruled out all other issues in this list, it means your custom configuration isnt loading the rules.<br />
<br />
[[ASL]] will automatically configure modsecurity correctly. So if you are having problems configuring modsecurity yourself, then we recommend you use [[ASL]] to setup modsecurity for you.<br />
<br />
=== Windows ===<br />
<br />
Please see the [[modsecurity iis]] page.<br />
<br />
== Automated rules updates ==<br />
<br />
Please see the [[ASL]] page for installation instructions.<br />
<br />
= Tuning the Rules/Disabling Rules =<br />
<br />
== Disabling Rules ==<br />
<br />
See the [[mod_security]] page for details.<br />
<br />
== Tuning the Rules ==<br />
<br />
See the [[mod_security]] page for details.<br />
<br />
== Troubleshoot the Rules ==<br />
<br />
See the [[Atomicorp WAF Rules Troubleshooting]] page for details.<br />
<br />
== Reporting False Positives ==<br />
<br />
See the [[Reporting False Positives]] page for details.<br />
<br />
= Notes =<br />
<br />
== Special notes for CPANEL users not using ASL ==<br />
<br />
The Atomicorp Modsecurity rules work great with Cpanel, right out of the box. To use them with Cpanel either install [[ASL]], or manually install modsecurity and make a few changes to the mod_security configuration that comes with cpanel and then you are all set!<br />
<br />
=== Installing modsecurity in cpanel ===<br />
<br />
'''Option 1) Simplest and most powerful solution'''<br />
<br />
Install [[ASL]]. This will install modsecurity, configure it and will install the rule and event management GUI available in [[ASL]]<br />
<br />
Option 2) Install just the rules<br />
<br />
=== Manually Configuring modsecurity with cpanel ===<br />
<br />
These are additional considerations for installing modsecurity with cpanel. Please read this entire page, as well as this section if you are installing modsecurity with cpanel (even if you already have modsecurity install with cpanel).<br />
<br />
We recommend if you are using cPanel that you follow this advice, as cpanel includes a very minimal configuration for modsecurity that does not include all of the required and optimal settings documented here. Our settings will make your server faster, and more importantly more secure. If you use mod_security with Cpanel you must add these additional settings to experience the full feature set of mod_security.<br />
<br />
==== Step 1 ====<br />
<br />
Make sure you have read this entire document and have setup all the require directories details above.<br />
<br />
==== Step 2: Configure directory permissions ====<br />
<br />
Cpanel also does not run apache as a standard user (such as apache) but as the older non-privileged user "nobody". You will need to ensure then that the work directories that mod_security uses are owned by the user that Cpanel runs apache as. To find this out you can run this command as root:<br />
<br />
ps auxwww | grep httpd<br />
<br />
root 20594 86.8 3.1 255148 181232 ? Ss 11:39 0:04 /usr/local/apache/bin/httpd -k restart<br />
root 20611 0.0 3.1 255060 179596 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20612 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20613 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20614 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20615 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20616 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
<br />
In this example from a Centos system running Cpanel the user is "nobody", so you would want to use these commands to configure the modsecurity work directories for a system where apache is running as "nobody": <br />
<br />
mkdir /var/asl<br />
mkdir /var/asl/data/<br />
mkdir /var/asl/data/msa<br />
mkdir /var/asl/data/audit<br />
mkdir /var/asl/data/suspicious<br />
chown nobody.nobody /var/asl/data/msa<br />
chown nobody.nobody /var/asl/data/audit<br />
chown nobody.nobody /var/asl/data/suspicious<br />
chmod o-rx -R /var/asl/data/*<br />
chmod ug+rwx -R /var/asl/data/*<br />
<br />
==== Step 3: Install modsecurity ====<br />
<br />
Please see the current minimum version required at the link below:<br />
<br />
https://www.atomicorp.com/wiki/index.php/Atomic_ModSecurity_Rules#Minimum_Version_of_Modsecurity_Required_to_use_the_rules<br />
<br />
==== Step 4: Install mod_uniqueid ====<br />
<br />
Cpanel users will need to manually verify that the mod_unique_id module is loaded by cpanel's apache. It should be loaded by default, but check your cpanel configuration to be sure.<br />
<br />
==== Step 5: Configure cpanel ====<br />
<br />
Make a small change to the cpanel modsecurity configuration. A typical cpanel modsec2.conf configuration file looks like this:<br />
<br />
LoadFile /opt/xml2/lib/libxml2.so<br />
LoadFile /opt/lua/lib/liblua.so<br />
LoadModule security2_module modules/mod_security2.so<br />
<IfModule mod_security2.c><br />
SecRuleEngine On<br />
# See http://www.modsecurity.org/documentation/ModSecurity-Migration-Matrix.pdf<br />
# "Add the rules that will do exactly the same as the directives"<br />
# SecFilterCheckURLEncoding On<br />
# SecFilterForceByteRange 0 255<br />
SecAuditEngine RelevantOnly<br />
SecAuditLog logs/modsec_audit.log<br />
SecDebugLog logs/modsec_debug_log<br />
SecDebugLogLevel 0<br />
SecDefaultAction "phase:2,deny,log,status:403"<br />
Include "/usr/local/apache/conf/modsec2.user.conf"<br />
</IfModule><br />
<br />
Because cpanel will overwrite this configuration, you need to modify your user configuration file. You will want to setup your user configuration file (/usr/local/apache/conf/modsec2.user.conf) as in the examples below depending on the type of license you have purchased (remote rules vs downloadable rules). <br />
<br />
==== Step 5a: Remote Rules ====<br />
<br />
If you have a remote rules license, simply add these two lines to the /usr/local/apache/conf/modsec2.user.conf file,, replacing <API Key> with the value in your license signup email:<br />
<br />
''SecRemoteRulesFailAction Warn<br />
SecRemoteRules <API Key> https://waf.atomicorp.com/rules/srr.php''<br />
<br />
Additional rule classes can be specified as follows<br />
<br />
''SecRemoteRules <API Key> https://waf.atomicorp.com/rules/srr.php?antispam,recons''<br />
<br />
A full list of rule classes is available at [https://docs.atomicorp.com/gotrootModsec/remoterules.html].<br />
<br />
==== Step 5a: Downloadable Rules ====<br />
<br />
If you have a license for the downloadable rules, this is the recommended configuration and the '''minimum''' recommended rule sets that are designed to work with cpanel without [[ASL]] installed. Please be sure to read this entire page for information about additional rules that you may also want to use with cpanel.<br />
<br />
SecRequestBodyAccess On<br />
SecAuditLogType Concurrent<br />
SecResponseBodyAccess On<br />
SecResponseBodyMimeType (null) text/html text/plain text/xml<br />
SecResponseBodyLimit 2621440<br />
SecAuditLogRelevantStatus "^(?:5|4(?!04))"<br />
SecServerSignature Apache<br />
SecUploadDir /var/asl/data/suspicious<br />
SecUploadKeepFiles Off<br />
SecAuditLogParts ABIFHZ<br />
SecArgumentSeparator "&"<br />
SecCookieFormat 0<br />
SecRequestBodyInMemoryLimit 131072<br />
SecDataDir /var/asl/data/msa<br />
SecTmpDir /tmp<br />
SecAuditLogStorageDir /var/asl/data/audit<br />
SecResponseBodyLimitAction ProcessPartial<br />
<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_z_antievasion.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_zz_strict.conf<br />
Include /full/path/to/your/rules/modsecurity.d/09_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_antimalware.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/11_asl_adv_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/20_asl_useragents.conf<br />
Include /full/path/to/your/rules/modsecurity.d/30_asl_antispam.conf<br />
Include /full/path/to/your/rules/modsecurity.d/50_asl_rootkits.conf<br />
Include /full/path/to/your/rules/modsecurity.d/60_asl_recons.conf<br />
Include /full/path/to/your/rules/modsecurity.d/61_asl_recons_dlp.conf<br />
Include /full/path/to/your/rules/modsecurity.d/99_asl_jitp.conf<br />
<br />
If you want to load just some of the rules, make sure you specify only those rule files. The default list above is the recommended and supported rulesets with cpanel. Do not use the other asl rulesets with cpanel, those other rules either use other apache modules (such as mod_sed) or ASL specific features that require [[ASL]].<br />
<br />
Then run this command as root to install the rules:<br />
<br />
[[aum]] -u<br />
<br />
Or if you want to install the rules files manually, please see the [https://www.atomicorp.com/wiki/index.php/Atomic_ModSecurity_Rules#Step_8:_Download_the_ModSecurity_Rules Downloading rules] section above.<br />
<br />
==== Step 7: Restart Apache ====<br />
<br />
Restart apache, enjoy your new secure web server!<br />
<br />
<br />
<br />
==== Optional Steps ====<br />
<br />
===== Malware Scanner =====<br />
<br />
The malware scanner is included in [[ASL]], it is not included in the rules or rule subscriptions. Therefore, if you use this file:<br />
<br />
05_asl_scanner.conf<br />
<br />
Or this:<br />
<br />
99_asl_scanner.conf<br />
<br />
You will need to include your own scanner, and will need to make sure you have clamd installed and configured correctly to listen on a TCP port, or if you use a socket, make sure apache can read/write to this socket or as a last resort, run clamd as root. Using this file forces all web uploads on your system to go thru clamav to look for malware, viruses, etc. If you dont need that, then you can leave this config file out.<br />
<br />
<br />
==== Cpanel Error Messages ====<br />
<br />
==== modsecparse.pl ====<br />
<br />
'''This is a third party tool not provided by, or supported by Atomicorp.''' If you use this tool, it apparently does not work with the new fast concurrent logging system in modsecurity. The concurrent logging system is much faster, will speed up apache and is less resource intensive that the older serial method. <br />
<br />
However, if you use this tool you must use the slower serial logging method, as it does not support the faster concurrent method. To use this tool, change the SecAuditLogType setting from "Concurrent" to "Serial":<br />
<br />
SecAuditLogType Serial<br />
<br />
'''Keep in mind that this logging method is much slower, may slow down apache and is not supported.''' This performance impact is not caused by the rules. Serial logging is much slower than concurrent logging. Therefore we do not recommend you use this logging method or any tools that require it. There are lots of modsecurity log readers that can use the concurrent logging method, such as [[ASL]] and we encourage you to explore using one of those modern tools instead.<br />
<br />
==== Serial logging ====<br />
<br />
===== Discussion =====<br />
<br />
Serial logging is the older slower depreacted logging method modsecurity original used many years ago. This logging method would log the entire event in a single file. As a result, it would slow apache down because each event needed to wait for the previous event to finish writing before it could write to the log file. Events stack up and slow apache down. This incurs a significant performance penalty on apache, and of course a better method was devised for modsecurity to address this performance issue. The solution is the concurrent logging method. This generates a unique event file for each log event, logging the events data to that file instead of trying to jam tons of data into a single file, and thereby slowing down apache. All modern modsecurity log viewing tools support the concurrent method.<br />
<br />
The concurrent logging system is much faster, will speed up apache and is less resource intensive that the older serial method. This method is highly recommended over the slow serial logging method.<br />
<br />
===== Configuration =====<br />
<br />
====== aum ======<br />
<br />
If you want to use the old slower serial logging method, and you are using aum, change this setting in /etc/asl/config:<br />
<br />
MODSEC_LOGTYPE="Concurrent"<br />
<br />
<br />
To:<br />
<br />
MODSEC_LOGTYPE="Serial"<br />
<br />
<br />
And then run:<br />
<br />
aum -uf<br />
<br />
====== non-aum systems ======<br />
<br />
If you want to use the old slower serial logging method change the SecAuditLogType setting from "Concurrent" to "Serial":<br />
<br />
SecAuditLogType Serial<br />
<br />
'''Warning: Serial logging is much slower than concurrent logging and will slow down apache.''' Any performance impact is not caused by the rules. <br />
<br />
Therefore we do not recommend you use this logging method or any tools that require it. There are lots of modsecurity log readers that can use the fast concurrent logging method, such as [[ASL]] and we encourage you to explore using one of those modern tools instead of a tool that requires the slower and performance degrading serial logging method.<br />
<br />
If you change your system to the slower Serial method, you may also want to change the logfile name you are using for your modsecurity logs. You can do that by changing this option in your configuration:<br />
<br />
SecAuditLog logs/audit_log</div>Mshinnhttps://wiki.atomicorp.com/wiki/index.php/Atomic_ModSecurity_RulesAtomic ModSecurity Rules2022-09-27T17:13:28Z<p>Mshinn: /* Step 4: Configure cpanel */</p>
<hr />
<div>[[Atomic Secured Linux]] includes modsecurity, and the Real Time GotRoot.com/Atomicorp Modsecurity Rules. These docs are for users that do not have [[ASL]].<br />
<br />
'''ASL will install and configure modsecurity, and provides a powerful and easy use to GUI to manage all of this for you. If you don't have ASL, [https://www.atomicorp.com/amember/cart/index/index?c=1 upgrade to ASL today!]'''<br />
<br />
= '''About the rules''' =<br />
<br />
The gotroot.com rules are written by us - we are the gotroot guys. Same great rules, same team, ten years of writing modsecurity rules and still going strong! GotRoot is our Information Assurance lab and [http://www.atomicorp.com Atomicorp] is the product arm of [http://www.progllc.com Prometheus Global] (the parent company for both). So when you get the gotroot.com rules from atomicorp.com or gotroot.com - you're getting the same rules from the same people that created, write and maintain them. In the future we will be merging the gotroot.com, atomicrocketturtle and atomicorp websites into the atomicorp.com website.<br />
<br />
We publish two versions of the rules:<br />
<br />
'''RealTime Rules:''' The latest and greatest version of the rules, with all the performance enhancements, new security features and bug fixes released by us on a daily basis. These rules are fully supported and are recommended for production use.<br />
<br />
'''Free/Delayed Rules:''' A delayed subset of the Advanced rules.<br />
<br />
Installation of the rules assumes a certain level of comfort with configuring apache. If you are not comfortable with configuring apache, you should contact someone that is, or use our [[Atomic Secured Linux]] product which does this automatically for you, and does not require you to configure apache.<br />
<br />
== Getting the rules ==<br />
<br />
[https://www.atomicorp.com/amember/cart/index/index?c=6 Click here] to get the Atomicorp ModSecurity Rules.<br />
<br />
== '''Atomic ModSecurity Rules Frequently Asked Questions''' ==<br />
<br />
Please see the [[Atomic ModSecurity Rules FAQ]] wiki page.<br />
<br />
== '''Real Time Rule Support''' ==<br />
<br />
If you have a subscription to the real time rules, you can request email support by sending an email to:<br />
<br />
support@atomicorp.com<br />
<br />
The Customer Support Forums are located here:<br />
<br />
[http://www.atomicorp.com/forums Customer Support Forums]<br />
<br />
And the Custom Support Portal is located here (you can submit bug reports and open cases through the portal):<br />
<br />
[https://www.atomicorp.com/portal Customer Support Portal]<br />
<br />
== '''Licenses''' ==<br />
<br />
The Real Time Atomic ModSecurity Rules are licensed by the server. You can order licenses from the online store at the link below:<br />
<br />
[https://www.atomicorp.com/amember/cart/index/index?c=6 Online Store]<br />
<br />
If you require additional licenses please log into the [https://www.atomicorp.com/support/license-manager.html AtomiCorp License Manager]. You can add additional systems there, you can control your payment methods and you can also sign up to become an affiliate.<br />
<br />
=== License Terms and Conditions ===<br />
<br />
Purchase of an Atomicorp ModSecurity rule license entitles the purchaser to access and download from the Atomicorp Repository to a single IP address within the time period of the license. A separate license is required for each dedicated server/host or VPS that the rule set is installed upon or is protecting.<br />
<br />
Atomicorp ModSecurity rules installed upon a Reverse Proxy WAF appliance/server requires a separate license. Please contact Atomicorp support for details.<br />
<br />
The rule set cannot be copied, mirrored, or reproduced under protection of US and International copyright laws.<br />
<br />
Use of the rule set is limited to the time period of the license. If the license period of a rule set expires, it must must removed from its installed server and no longer used. Atomicorp reserves the right to track and enforce license compliance of the Atomicorp Modsecurity rule sets.<br />
<br />
Agreement to these terms and conditions and the Atomicorp [https://atomicorp.com/eula.html End User License Agreement] is required to download and use the Atomicorp ModSecurity rules.<br />
<br />
== Important Information about the Rules ==<br />
<br />
=== Minimum Version of Modsecurity Required to use the rules ===<br />
<br />
The rules are supported with the following versions of Modsecurity:<br />
<br />
<br />
* 2.9.3<br />
<br />
We recommend customers use our modsecurity builds, as they are tested to ensure all features work correctly. Third party builds may not include the correct libraries, may cause problems with your web server, including crashes and may disable or incorrectly enable features in modsecurity that can cause unpredictable behavior or failure of rules to process correctly.<br />
<br />
If you need a solution to keep the rules and modsecurity up to date and in sync with your version of modsecurity automatically, please use [[aum]] or [[ASL]] which will do this for you automatically.<br />
<br />
==== What versions of modsecurity do the rules work with ====<br />
<br />
They work with both modsecurity 2.9.x, and modsecurity 3.x.<br />
<br />
=== What does each rule family do? ===<br />
<br />
Please see the [[modsecurity_rule_families]] documents.<br />
<br />
= Installation =<br />
<br />
== Easy One Step Installation ==<br />
<br />
<br />
<br />
===== Full Management Suite =====<br />
<br />
Install [[ASL]]. This installs everything: modsecurity, all the rules, the GUI, rule manager and all ASL components, plus it includes the subscription to the real time rules.<br />
<br />
ASL will automatically download and keep your rules up to date, and will ensure that modsecurity stays up to date so your system can support the latest rules. ASL also provides you with a full security management suite, which will allow you to manage, edit and configure your rules through a web console. It will also protect you from uploaded malware, brute force attacks, DOS attacks, rootkits and many other threats that a WAF can not protect you from.<br />
<br />
A full list of ASLs features is available at the URL below:<br />
<br />
https://www.atomicorp.com/products/asl.html<br />
<br />
===== Just a downloader =====<br />
<br />
We also provide an automated rule updater and modsecurity installation tool, called [[aum]]. You can read more about it on the [[aum]] page. You can install it by running these commands as root:<br />
<br />
Step 1) Install [[aum]]<br />
<br />
''wget -q -O - https://updates.atomicorp.com/installers/aum |bash''<br />
<br />
Step 2) Configure [[aum]]<br />
<br />
''aum configure''<br />
<br />
Step 3) Tell [[aum]] to install the rules<br />
<br />
''aum upgrade''<br />
<br />
You can read more about aum on the [[aum]] documentation page.<br />
<br />
Note: This capability is included in [[ASL]]. ASL users do not need to install aum, its already included.<br />
<br />
== (Optional) Do It Yourself Installation ==<br />
<br />
Note: A manual installation is not necessary if you have [[ASL]] installed. ASL will configure and install modsecurity, and the rules, automatically. This is also not necessary if you are using our new AUM software to handle rule download and installation.<br />
<br />
=== Linux ===<br />
<br />
==== Step 1: Download ModSecurity ====<br />
<br />
Binaries:<br />
<br />
[http://updates.atomicorp.com/channels/atomic/ Install modsecurity from the Atomicorp software repository]<br />
<br />
Source Code:<br />
<br />
[http://updates.atomicorp.com/channels/atomic/ Install modsecurity from the Atomicorp software repository]<br />
<br />
Please note that the rules are only supported with the version of modsecurity [http://wiki.atomicorp.com/wiki/index.php/Atomic_ModSecurity_Rules#Minimum_Version_of_Modsecurity_Required_to_use_the_rules identified in this section of the wiki.]<br />
<br />
Note: Please contact us before using a third party or source build of modsecurity. Its critical modsecurity be built correctly to work with the rules.<br />
<br />
==== Step 2: Set up and configure directories ====<br />
<br />
Create the following directories as root:<br />
<br />
mkdir /etc/httpd/modsecurity.d<br />
mkdir /var/asl<br />
mkdir /var/asl/tmp<br />
mkdir /var/asl/data<br />
mkdir /var/asl/data/msa<br />
mkdir /var/asl/data/audit<br />
mkdir /var/asl/data/suspicious<br />
<br />
==== Step 3: Set permissions for directories ====<br />
<br />
Set the following permissions on the directories you just created. In this example these directories are set to be owned by "apache" and the group "apache", which is standard on a normal Centos or RHEL system. However some control panels configure apache to run as a different user, such as nobody, or http. <br />
<br />
To determine what user this is, check your system to see what user your webserver uses. You can use this command to find the user:<br />
<br />
ps auxwww | grep httpd<br />
<br />
The output will look similar to this:<br />
<br />
(RHEL/Centos example with or without Plesk)<br />
<br />
root 26755 0.0 4.3 430752 86432 ? Ss 04:30 0:01 /usr/sbin/httpd<br />
'''apache''' 26908 0.0 3.7 300564 75076 ? S 04:30 0:00 /usr/sbin/httpd<br />
'''apache''' 26909 0.1 5.5 495812 112084 ? S 04:30 0:37 /usr/sbin/httpd<br />
'''apache''' 26910 0.0 5.3 495424 106672 ? S 04:30 0:23 /usr/sbin/httpd<br />
'''apache''' 26911 0.1 5.7 495892 114368 ? S 04:30 0:57 /usr/sbin/httpd<br />
'''apache''' 26912 0.1 5.7 496056 114440 ? S 04:30 0:52 /usr/sbin/httpd<br />
'''apache''' 26913 0.1 5.5 496604 110692 ? S 04:30 0:57 /usr/sbin/httpd<br />
'''apache''' 26914 0.0 5.7 499324 116236 ? S 04:30 0:16 /usr/sbin/httpd<br />
'''apache''' 26915 0.2 5.5 493600 112192 ? S 04:30 1:09 /usr/sbin/httpd<br />
'''apache''' 26916 0.1 6.4 513760 129992 ? S 04:30 0:30 /usr/sbin/httpd<br />
<br />
In this example the user in bold is "apache" (this may be different for your system). This is the user you will want to set the directory permissions to (as in the example below):<br />
<br />
chown apache.apache /var/asl/data/msa<br />
chown apache.apache /var/asl/data/audit<br />
chown apache.apache /var/asl/data/suspicious<br />
chmod o-rx -R /var/asl/data/*<br />
chmod ug+rwx -R /var/asl/data/*<br />
<br />
(RHEL/Centos example with Cpanel)<br />
<br />
root 20594 86.8 3.1 255148 181232 ? Ss 11:39 0:04 /usr/local/apache/bin/httpd -k restart<br />
root 20611 0.0 3.1 255060 179596 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20612 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20613 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20614 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20615 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20616 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
<br />
In this example from a Centos system running Cpanel the user is "nobody", so you would want to use these commands:<br />
<br />
chown nobody.nobody /var/asl/data/msa<br />
chown nobody.nobody /var/asl/data/audit<br />
chown nobody.nobody /var/asl/data/suspicious<br />
chmod o-rx -R /var/asl/data/*<br />
chmod ug+rwx -R /var/asl/data/*<br />
<br />
==== Step 4: (Optional) Create rule updater directories ====<br />
These directories must as be created if you use optional rules updater. Create these directories as root and they only need to be accessed by root:<br />
<br />
mkdir /var/asl/updates<br />
mkdir /var/asl/rules/<br />
mkdir /var/asl/rules/clamav<br />
<br />
==== Step 5: Create the whitelist file ====<br />
<br />
Create this file:<br />
<br />
touch /etc/asl/whitelist<br />
<br />
This file contains a list of IPs you want to exclude from ALL rules. That means those IPs can do anything to your system - so be very very careful about what IPs you add to this list. This is a dangerous thing to do. The format of the file is a single IP, per line. <br />
<br />
Cpanel users should skip to the notes at the bottom of this page for special additional actions for cpanel systems. All other users should continue with these instructions.<br />
<br />
==== Step 6: Configure your webserver ====<br />
<br />
===== nginx =====<br />
<br />
===== Step 6a: configure nginx to load modsecurity =====<br />
<br />
====== nginx proxying to a backend ======<br />
<br />
If you are using nginx as a frontend to another webserver, then add the following directives to your nginx.conf file.<br />
<br />
<pre><br />
location / {<br />
ModSecurityEnabled on;<br />
ModSecurityConfig modsecurity.conf;<br />
proxy_pass http://localhost:8080;<br />
proxy_read_timeout 180s;<br />
}<br />
<br />
</pre><br />
<br />
Change "localhost:8011" to the server you are proxying nginx to, and change 8080 to the portnumber for that server. For example, if you are running apache on port 8088 on localhost the line would be:<br />
<br />
proxy_pass http://localhost:8088;<br />
<br />
====== nginx standalone ======<br />
<br />
If you are only using nginx, and not using it as a frontend to another web server then you want to use this configuration:<br />
<br />
<pre><br />
location / {<br />
ModSecurityEnabled on;<br />
ModSecurityConfig modsecurity.conf;<br />
}<br />
</pre><br />
<br />
===== Apache =====<br />
<br />
===== Step 6a: configure apache to load modsecurity =====<br />
<br />
You then need to tell apache to load modsecurity. Depending on your apache configuration, apache should be configured to include configuration files. If you have a setting like this in your apache config:<br />
<br />
Include conf.d/*.conf<br />
<br />
Then you are setup to load external configuration files. If you do not have this setup, its highly recommend you add this. This installation guide is written for this type of configuration. Loading mod_security occurs by including a modsecurity configuration file in that directory. We recommend you name the name 00_modsecurity.conf to ensure it runs first. Its vitally important that modsecurity load before other modules, otherwise attacks can occur before modsecurity scans them and some attacks can be missed.<br />
<br />
An example 00_modsecurity.conf file that works with our files is included here:<br />
<br />
LoadModule security2_module modules/mod_security2.so<br />
LoadModule unique_id_module modules/mod_unique_id.so<br />
<IfModule mod_security2.c><br />
Include modsecurity.d/tortix_waf.conf<br />
</IfModule><br />
<br />
Install this file in your conf.d directory. On a standard RHEL or Centos system that directory is located here:<br />
<br />
/etc/httpd/conf.d/<br />
<br />
=== Step 7: Configure modsecurity ===<br />
<br />
You then need to configure modsecurity. This is done via the an apache configuration file. In this example, we will create the file "tortix_waf.conf". Here is an example file that works with our rules:<br />
<br />
SecRuleEngine On<br />
SecRequestBodyAccess On<br />
SecResponseBodyAccess On<br />
SecResponseBodyMimeType (null) text/html text/plain text/xml<br />
SecResponseBodyLimit 2621440<br />
SecServerSignature Apache<br />
SecComponentSignature 200911012341<br />
SecUploadDir /var/asl/data/suspicious<br />
SecUploadKeepFiles Off<br />
SecAuditEngine RelevantOnly<br />
SecAuditLogRelevantStatus "^(?:5|4(?!04))"<br />
SecAuditLogType Concurrent<br />
SecAuditLog logs/audit_log<br />
[[SecAuditLogParts]] ABIFHZ<br />
SecArgumentSeparator "&" <br />
SecCookieFormat 0<br />
SecRequestBodyInMemoryLimit 131072<br />
SecDataDir /var/asl/data/msa<br />
SecTmpDir /tmp<br />
SecAuditLogStorageDir /var/asl/data/audit<br />
SecResponseBodyLimitAction ProcessPartial<br />
SecAuditLogDirMode 0770<br />
SecPcreMatchLimit 250000 <br />
SecPcreMatchLimitRecursion 250000<br />
<br />
You will want to install this file in your modsecurity.d directory, which is located here if you follow the instructions above:<br />
<br />
/etc/httpd/modsecurity.d<br />
<br />
==== tortix_waf.conf ====<br />
<br />
You can also download an example version of the modsecurity configuration file from here:<br />
<br />
https://www.atomicorp.com/installer/tortix_waf.conf<br />
<br />
[[ASL]] will automatically generate this file depending on your needs. If you are not using ASL, you will need to modify this configuration file to suit your system and modsecurity requirements.<br />
<br />
==== Step 8: Download the ModSecurity Rules ====<br />
<br />
See the [[Downloading Rules]] page.<br />
<br />
==== Step 9: Install the rules ====<br />
<br />
==== Remove any previous installations of rules ====<br />
<br />
If you have installed our delayed rules, you will need to make sure you have deleted them. You will not want to have any older versions of the rules installed.<br />
<br />
Also, if you have installed any third party modsecurity rules, you will want to make sure they are using rule id's that are assigned to them. The modsecurity project assigns ranges to the rule id's modsecurity uses. Modsecurity requires a unique id for each rule, otherwise you will get an error like this:<br />
<br />
ModSecurity: Found another rule with the same id<br />
<br />
This means either that someone else is using the same rule id's assigned to our ruleset by the modsecurity project (our official range is 300000-399999), or you have loaded our rules twice.<br />
<br />
==== Installation ====<br />
<br />
Download the rules to a temporary directory using your favorite download tool. Extract the rules:<br />
<br />
tar zxvf /var/asl/updates/modsec-200911012341.tar.gz<br />
<br />
Then copy each of the ASL rule files you wish to use into /etc/httpd/modsecurity.d. Do not copy all of the rule files, you will need to select rule files that are appropriate for your system. Or simply use [[aum]] or [[ASL]] to do this for you automatically.<br />
<br />
If you are using cpanel, please see the notes at the bottom of this page, cpanel does not use the standard locations for apache configuration files.<br />
<br />
Finally, load the rules. '''Make sure you specify only those rule files that are appropriate for your system.''' For example:<br />
<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/99_asl_jitp.conf<br />
<br />
'''Warning: You should NOT include all the rules. There are rulesets, documented above, that replace other rulesets and are incompatible with each other.'''<br />
<br />
===== Recommend minimum rulesets =====<br />
<br />
====== apache ======<br />
<br />
The recommended ''minimum ruleset'' to load is:<br />
<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_0_global.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_antimalware.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/11_asl_adv_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/20_asl_useragents.conf<br />
Include /full/path/to/your/rules/modsecurity.d/30_asl_antispam.conf<br />
Include /full/path/to/your/rules/modsecurity.d/50_asl_rootkits.conf<br />
Include /full/path/to/your/rules/modsecurity.d/60_asl_recons.conf<br />
Include /full/path/to/your/rules/modsecurity.d/61_asl_recons_dlp.conf<br />
Include /full/path/to/your/rules/modsecurity.d/99_asl_jitp.conf<br />
<br />
If you have modsecurity 2.9.0 and up installed, you should also load additional rule files and should use this ruleset:<br />
<br />
Include /full/path/to/your/rules/modsecurity.d/000_asl_threat_intelligence.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_zz_strict.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_0_global.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_z_antievasion.conf<br />
Include /full/path/to/your/rules/modsecurity.d/01_asl_content.conf<br />
Include /full/path/to/your/rules/modsecurity.d/01_asl_content_z.conf<br />
Include /full/path/to/your/rules/modsecurity.d/03_asl_dos.conf<br />
Include /full/path/to/your/rules/modsecurity.d/09_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_antimalware.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/11_asl_adv_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/11_asl_data_loss.conf<br />
Include /full/path/to/your/rules/modsecurity.d/12_asl_adv_xss_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/20_asl_useragents.conf<br />
Include /full/path/to/your/rules/modsecurity.d/30_asl_antispam.conf<br />
Include /full/path/to/your/rules/modsecurity.d/50_asl_rootkits.conf<br />
Include /full/path/to/your/rules/modsecurity.d/51_asl_rootkits.conf<br />
Include /full/path/to/your/rules/modsecurity.d/60_asl_recons.conf<br />
Include /full/path/to/your/rules/modsecurity.d/61_asl_recons_dlp.conf<br />
Include /full/path/to/your/rules/modsecurity.d/99_asl_jitp.conf<br />
Include /full/path/to/your/rules/modsecurity.d/98_asl_adv_redactor.conf<br />
<br />
If you have a [[Local DNS resolver]] setup and properly configured on your system, and you are using modsecurity 2.9.0 and up we also recommend these additional rulesets:<br />
<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_z_searchengines.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_z_aa_threat_intelligence.conf<br />
Include /full/path/to/your/rules/modsecurity.d/99_asl_zzzz_threat_intelligence.conf<br />
<br />
Note: Some of these rulesets are designed to work with advanced security management systems such as [[ASL]] and may not work completely without an advanced management system.<br />
<br />
====== nginx ======<br />
<br />
The same rulesets as apache will work with nginx.<br />
<br />
====== litespeed ======<br />
<br />
[[Litespeed]] has a proprietary implementation of mod_security. It does not support all the features that mod_security with apache, IIS and nginx does. Therefore, you can not use all the rulesets with Litespeed, as Litespeed does not support those features of mod_security. The following rulesets are recommended with Litespeed:<br />
<br />
The recommended ''minimum ruleset'' to load is:<br />
<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_0_global.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_antimalware.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/11_asl_adv_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/20_asl_useragents.conf<br />
Include /full/path/to/your/rules/modsecurity.d/30_asl_antispam.conf<br />
Include /full/path/to/your/rules/modsecurity.d/50_asl_rootkits.conf<br />
Include /full/path/to/your/rules/modsecurity.d/60_asl_recons.conf<br />
Include /full/path/to/your/rules/modsecurity.d/61_asl_recons_dlp.conf<br />
Include /full/path/to/your/rules/modsecurity.d/99_asl_jitp.conf<br />
<br />
If you require more advanced protection, you should also load additional rule files and should use this ruleset:<br />
<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_zz_strict.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_x_searchengines.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_y_searchengines.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_0_global.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_z_antievasion.conf<br />
Include /full/path/to/your/rules/modsecurity.d/01_asl_content.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_zz_strict.conf<br />
Include /full/path/to/your/rules/modsecurity.d/03_asl_dos.conf<br />
Include /full/path/to/your/rules/modsecurity.d/09_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_antimalware.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/11_asl_adv_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/11_asl_data_loss.conf<br />
Include /full/path/to/your/rules/modsecurity.d/12_asl_adv_xss_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/20_asl_useragents.conf<br />
Include /full/path/to/your/rules/modsecurity.d/30_asl_antispam.conf<br />
Include /full/path/to/your/rules/modsecurity.d/50_asl_rootkits.conf<br />
Include /full/path/to/your/rules/modsecurity.d/51_asl_rootkits.conf<br />
Include /full/path/to/your/rules/modsecurity.d/60_asl_recons.conf<br />
Include /full/path/to/your/rules/modsecurity.d/61_asl_recons_dlp.conf<br />
Include /full/path/to/your/rules/modsecurity.d/99_asl_jitp.conf<br />
<br />
<br />
Note: [[Litespeed]] does not support content inspection (outbound rules), or lua based rules. Therefore, the following rulesets Litespeed does not support, and loading them will have no effect on the system:<br />
<br />
<br />
00_asl_z_searchengines.conf<br />
00_asl_z_aa_threat_intelligence.conf<br />
12_asl_brute.conf<br />
98_asl_adv_redactor.conf<br />
99_asl_zzzz_threat_intelligence.conf<br />
<br />
Note: Some of these rulesets are designed to work with advanced security management systems such as [[ASL]] and may not work completely without an advanced management system.<br />
<br />
===== Notes on Scanner ruleset =====<br />
<br />
NOTE: If you use this file:<br />
<br />
05_asl_scanner.conf<br />
<br />
Or this file:<br />
<br />
99_asl_scanner.conf<br />
<br />
[[ASL]] includes malware upload scanning, rules subscriptions do not.<br />
<br />
If you wish to use this ruleset, and you are not using [[ASL]], then you will need to create a script to pass the files to clamd and read the result. Make sure you have clamd installed and configured correctly to list on a TCP port, or if you use a socket, make sure apache can read/write to this socket or as a last resort, run clamd as root. Using this file will force all web uploads on your system to go thru clamav to look for malware, viruses, etc. If you dont need that, then you can leave this config file out. <br />
<br />
Real time malware upload protection is included in [[ASL]] and uses a faster method than the older style modsecurity scripting method above. So if you need realtime malware upload protection (for web, FTP, or even realtime), then upgrade to [[ASL]] which includes highspeed malware upload protection, full support, automatic and hassle free installation. ASL also protects against any form of upload of malware, including HTTP, HTTPS, SSH and FTP uploads and includes our real-time malware detection and prevention system which will detect and block any malicious software running on the system in realtime. This is just one of the many many features of [[ASL]].<br />
<br />
==== Step 10: Test your web server ====<br />
===== Test nginx =====<br />
<br />
nginx -t -c <NGINX_CONFIG_FILE><br />
<br />
Where NGINX_CONFIG_FILE is your nginx.conf file.<br />
<br />
===== Test Apache =====<br />
<br />
Before restarting apache we recommend you test your configuration by running apache with the "configtest" command. On a standard system you can do this by calling your apache init file like this:<br />
<br />
/etc/init.d/httpd configtest<br />
<br />
If you get errors, check to see that you don't have some extraneous configuration files installed.<br />
<br />
===== Testing to see if the rules are loaded =====<br />
'''<br />
Step 1)''' (for non [[ASL]] systems)<br />
<br />
Make sure you have the rules installed exactly as described on this page. This test may not work if you have not followed these instructions. (If you used ASL to setup your WAF, and you have not installed any third party tools that configure, install or manage modsecurity then your rules are installed correctly and you do not need to review the instructions on this page. If you have manually altered your modsecurity configuration then you will need to review this entire article. Manual modifications of ASL modsecurity configurations are not supported.)<br />
<br />
'''Step 2) Make sure all rules are enabled'''<br />
<br />
'''Ensure that you do not have any of our rules disabled.''' This test assumes you do not have any rules disabled, that you are not whitelisting the source of this test and that your have the Atomicorp rules loaded.<br />
<br />
'''Step 3) Test from a non-whitelisted system''' <br />
<br />
Make sure you do not have the system you are performing this from is whitelisted<br />
<br />
For example, cpanels default modsecurity configuration will configure modsecurity to ignore everything from 127.0.0.1, or from the system itself. So if you perform the test above from the server itself, and you have not removed this cpanel whitelist, then this test will not work.<br />
<br />
'''Step 4) Run the test'''<br />
<br />
On the system where the rules are installed run this command (this assumes you have wget installed, '''127.0.0.1 is NOT whitelisted''' and a web server is listening on 127.0.0.1):<br />
<br />
''wget http://localhost/foo.php?foo=http://www.example.com''<br />
<br />
If the test worked, should get a 403 error if the rules are loaded, which will look similar to this:<br />
<br />
<pre><br />
--2010-05-27 20:12:25-- http://localhost/foo.php?foo=http://www.example.com<br />
Resolving localhost... 127.0.0.1<br />
Connecting to localhost|127.0.0.1|:80... connected.<br />
HTTP request sent, awaiting response... 403 Forbidden<br />
2010-05-27 20:12:25 ERROR 403: Forbidden.<br />
</pre><br />
<br />
If you do not get a 403 error, the test did not work.<br />
<br />
You can also use your browser to test the rules by going to a URL similar to this:<br />
<br />
http://YOUR_HOST/foo.php?foo=http://www.example.com<br />
<br />
Remember to replace YOUR_HOST with the actual HOSTNAME or IP of the server.<br />
<br />
If the rules are properly loaded, you should get a 403 error, if you do not get a 403 error, the rules are not loaded correctly and you need to check your configuration to ensure that you have followed the instructions above correctly.<br />
<br />
If you get a 403 error from the command line and a 404 error from the browser, check to make sure the computer you are testing the browser from is not whitelisted on the server.<br />
<br />
Note: If you do not have wget installed, then you will need to install it or a similar tool to run this test from a Linux or UNIX based system. If you are using Windows, you can use a similar tool or your browser.<br />
<br />
====== What to do if you do not get a 403 error ======<br />
<br />
If you get a different error, such as a 404 error or a 5xx series error check your configuration. The following are common causes of this:<br />
<br />
'''1) You have rules disabled'''<br />
<br />
Make sure you do not have any rules disabled.<br />
<br />
'''2) Your IP is whitelisted'''<br />
<br />
There is a rule whitelisting the system you are conducting this test from. Whitelisting tells the WAF to ignore everything from that source.<br />
<br />
For example, cpanels default modsecurity configuration will configure modsecurity to ignore everything from 127.0.0.1, or from the system itself. So if you perform the test above from the server itself, and you have not removed this cpanel whitelist, then you will not get a 403 error. More than likely you will get a 404 error. The solution is to remove any whitelists from your system.<br />
<br />
Note: Whitelisting the server itself can open a hole in your security. You should not whitelist localhost or the servers own IP address, particularly if you have multi users on the system. This is both unnecessary, and doing so will allow any users on the system to carry out attacks on other domains on the system unimpeded. Make sure you do not have any rules like that, this opens a very large hole in your system.<br />
<br />
'''3) Local error message is different'''<br />
<br />
You or someone else may have configured your system to use a different error message. Check your configuration, and make sure it exactly matches the ones on this wiki. IF you are using kind of plugin that does not return a 403 when a connection is rejected, and you must use this, then you will need to manually check your mod_security logs to see if your test is being rejected by modsecurity. If it is, then your rules are working correctly and you can ignore the error code.<br />
<br />
'''4) Third party addons''' <br />
<br />
You have third party rules or addons installed with your modsecurity configuration that are changing the responses. Remove all third party addons, and make sure your configuration exactly matches the instructions on this page<br />
<br />
'''5) Insecurely configured apache'''<br />
<br />
Some control panels are known to disable modsecurity on localhost, and on the systems IP addresses. These highly insecure control panels essentially disable modsecurity if an attacker connects to the systems IP address. This of course leaves your system wide open to attack, and if you are unlucky enough to be using one of these control panels we recommend you report this to your control panel vendor as a serious vulnerability. If they are unwilling to fix it, then we recommend you find a more security concious control panel vendor.<br />
<br />
Example:<br />
<br />
We have seen some control panels that configure modsecurity to be disabled in the /etc/httpd/conf/httpd.conf file for all the local IPs on the system. <br />
<br />
<pre><br />
<VirtualHost <LOCAL IP ADDRESS>:80 127.0.0.1:80 *><br />
<IfModule mod_security2.c><br />
SecRuleEngine Off<br />
</IfModule><br />
</pre><br />
<br />
If your control panel has this vulnerability, you can remove this, but its very possible the control panel will simply open this hole in your system again. We highly recommend you report this vulnerability to your control panel vendor, and if they are unwilling to fix this vulnerability that you find a more security concious control panel vendor.<br />
<br />
'''6) You arent loading the rules'''<br />
<br />
This is common with custom configurations. Check to make sure your webserver is configured to load the rules. Keep mind that modsecurity will still generate generic messages even though the rules are not loaded. For example, if all you see are events like this:<br />
<br />
<pre><br />
--70c19f31-A--<br />
[01/Jan/2013:11:19:13 --0300] roiKIi6Ni3EKFZSKpSUs2iEb 1.2.3.4 34978 5.6.7.8 80<br />
--70c19f31-B--<br />
HEAD / HTTP/1.1<br />
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) <br />
<br />
Accept: */*<br />
<br />
--70c19f31-F--<br />
HTTP/1.1 403 Forbidden<br />
X-Powered-By: PHP/5.4.20<br />
Expires: Thu, 19 Jan 2001 02:12:00 GMT<br />
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0<br />
Pragma: no-cache<br />
Connection: close<br />
Content-Type: text/html<br />
<br />
--70c19f31-H--<br />
Stopwatch: 1383338363503919 358184 (- - -)<br />
Stopwatch2: 1383338363503919 358184; combined=2144, p1=37, p2=2053, p3=0, p4=0, p5=53, sr=0, sw=1, l=0, gc=0<br />
Producer: ModSecurity for Apache/2.7.5 ( http://www.modsecurity.org/).<br />
Server: Apache<br />
Engine-Mode: "ENABLED"<br />
<br />
--70c19f31-Z--<br />
</pre><br />
<br />
In this example, no rule is being triggered, but modsecurity is logging a basic 403 error. It will do this if the modsecurity configuration is loaded, but not the rules. So if you see this happening on your system, and you have ruled out all other issues in this list, it means your custom configuration isnt loading the rules.<br />
<br />
[[ASL]] will automatically configure modsecurity correctly. So if you are having problems configuring modsecurity yourself, then we recommend you use [[ASL]] to setup modsecurity for you.<br />
<br />
=== Windows ===<br />
<br />
Please see the [[modsecurity iis]] page.<br />
<br />
== Automated rules updates ==<br />
<br />
Please see the [[ASL]] page for installation instructions.<br />
<br />
= Tuning the Rules/Disabling Rules =<br />
<br />
== Disabling Rules ==<br />
<br />
See the [[mod_security]] page for details.<br />
<br />
== Tuning the Rules ==<br />
<br />
See the [[mod_security]] page for details.<br />
<br />
== Troubleshoot the Rules ==<br />
<br />
See the [[Atomicorp WAF Rules Troubleshooting]] page for details.<br />
<br />
== Reporting False Positives ==<br />
<br />
See the [[Reporting False Positives]] page for details.<br />
<br />
= Notes =<br />
<br />
== Special notes for CPANEL users not using ASL ==<br />
<br />
The Atomicorp Modsecurity rules work great with Cpanel, right out of the box. To use them with Cpanel either install [[ASL]], or manually install modsecurity and make a few changes to the mod_security configuration that comes with cpanel and then you are all set!<br />
<br />
=== Installing modsecurity in cpanel ===<br />
<br />
'''Option 1) Simplest and most powerful solution'''<br />
<br />
Install [[ASL]]. This will install modsecurity, configure it and will install the rule and event management GUI available in [[ASL]]<br />
<br />
Option 2) Install just the rules<br />
<br />
=== Manually Configuring modsecurity with cpanel ===<br />
<br />
These are additional considerations for installing modsecurity with cpanel. Please read this entire page, as well as this section if you are installing modsecurity with cpanel (even if you already have modsecurity install with cpanel).<br />
<br />
We recommend if you are using cPanel that you follow this advice, as cpanel includes a very minimal configuration for modsecurity that does not include all of the required and optimal settings documented here. Our settings will make your server faster, and more importantly more secure. If you use mod_security with Cpanel you must add these additional settings to experience the full feature set of mod_security.<br />
<br />
==== Step 1 ====<br />
<br />
Make sure you have read this entire document and have setup all the require directories details above.<br />
<br />
==== Step 2: Configure directory permissions ====<br />
<br />
Cpanel also does not run apache as a standard user (such as apache) but as the older non-privileged user "nobody". You will need to ensure then that the work directories that mod_security uses are owned by the user that Cpanel runs apache as. To find this out you can run this command as root:<br />
<br />
ps auxwww | grep httpd<br />
<br />
root 20594 86.8 3.1 255148 181232 ? Ss 11:39 0:04 /usr/local/apache/bin/httpd -k restart<br />
root 20611 0.0 3.1 255060 179596 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20612 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20613 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20614 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20615 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20616 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
<br />
In this example from a Centos system running Cpanel the user is "nobody", so you would want to use these commands to configure the modsecurity work directories for a system where apache is running as "nobody": <br />
<br />
mkdir /var/asl<br />
mkdir /var/asl/data/<br />
mkdir /var/asl/data/msa<br />
mkdir /var/asl/data/audit<br />
mkdir /var/asl/data/suspicious<br />
chown nobody.nobody /var/asl/data/msa<br />
chown nobody.nobody /var/asl/data/audit<br />
chown nobody.nobody /var/asl/data/suspicious<br />
chmod o-rx -R /var/asl/data/*<br />
chmod ug+rwx -R /var/asl/data/*<br />
<br />
==== Step 3: Install modsecurity ====<br />
<br />
Please see the current minimum version required at the link below:<br />
<br />
https://www.atomicorp.com/wiki/index.php/Atomic_ModSecurity_Rules#Minimum_Version_of_Modsecurity_Required_to_use_the_rules<br />
<br />
==== Step 4: Configure cpanel ====<br />
<br />
Make a small change to the cpanel modsecurity configuration. A typical cpanel modsec2.conf configuration file looks like this:<br />
<br />
LoadFile /opt/xml2/lib/libxml2.so<br />
LoadFile /opt/lua/lib/liblua.so<br />
LoadModule security2_module modules/mod_security2.so<br />
<IfModule mod_security2.c><br />
SecRuleEngine On<br />
# See http://www.modsecurity.org/documentation/ModSecurity-Migration-Matrix.pdf<br />
# "Add the rules that will do exactly the same as the directives"<br />
# SecFilterCheckURLEncoding On<br />
# SecFilterForceByteRange 0 255<br />
SecAuditEngine RelevantOnly<br />
SecAuditLog logs/modsec_audit.log<br />
SecDebugLog logs/modsec_debug_log<br />
SecDebugLogLevel 0<br />
SecDefaultAction "phase:2,deny,log,status:403"<br />
Include "/usr/local/apache/conf/modsec2.user.conf"<br />
</IfModule><br />
<br />
Because cpanel will overwrite this configuration, you need to modify your user configuration file. You will want to setup your user configuration file (/usr/local/apache/conf/modsec2.user.conf) as in the examples below depending on the type of license you have purchased (remote rules vs downloadable rules). <br />
<br />
==== Step 4a: Remote Rules ====<br />
<br />
If you have a remote rules license, simply add these two lines to the /usr/local/apache/conf/modsec2.user.conf file,, replacing <API Key> with the value in your license signup email:<br />
<br />
''SecRemoteRulesFailAction Warn<br />
SecRemoteRules <API Key> https://waf.atomicorp.com/rules/srr.php''<br />
<br />
Additional rule classes can be specified as follows<br />
<br />
''SecRemoteRules <API Key> https://waf.atomicorp.com/rules/srr.php?antispam,recons''<br />
<br />
A full list of rule classes is available at [https://docs.atomicorp.com/gotrootModsec/remoterules.html].<br />
<br />
==== Step 4a: Downloadable Rules ====<br />
<br />
If you have a license for the downloadable rules, this is the recommended configuration and the '''minimum''' recommended rule sets that are designed to work with cpanel without [[ASL]] installed. Please be sure to read this entire page for information about additional rules that you may also want to use with cpanel.<br />
<br />
SecRequestBodyAccess On<br />
SecAuditLogType Concurrent<br />
SecResponseBodyAccess On<br />
SecResponseBodyMimeType (null) text/html text/plain text/xml<br />
SecResponseBodyLimit 2621440<br />
SecAuditLogRelevantStatus "^(?:5|4(?!04))"<br />
SecServerSignature Apache<br />
SecUploadDir /var/asl/data/suspicious<br />
SecUploadKeepFiles Off<br />
SecAuditLogParts ABIFHZ<br />
SecArgumentSeparator "&"<br />
SecCookieFormat 0<br />
SecRequestBodyInMemoryLimit 131072<br />
SecDataDir /var/asl/data/msa<br />
SecTmpDir /tmp<br />
SecAuditLogStorageDir /var/asl/data/audit<br />
SecResponseBodyLimitAction ProcessPartial<br />
<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_z_antievasion.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_zz_strict.conf<br />
Include /full/path/to/your/rules/modsecurity.d/09_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_antimalware.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/11_asl_adv_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/20_asl_useragents.conf<br />
Include /full/path/to/your/rules/modsecurity.d/30_asl_antispam.conf<br />
Include /full/path/to/your/rules/modsecurity.d/50_asl_rootkits.conf<br />
Include /full/path/to/your/rules/modsecurity.d/60_asl_recons.conf<br />
Include /full/path/to/your/rules/modsecurity.d/61_asl_recons_dlp.conf<br />
Include /full/path/to/your/rules/modsecurity.d/99_asl_jitp.conf<br />
<br />
If you want to load just some of the rules, make sure you specify only those rule files. The default list above is the recommended and supported rulesets with cpanel. Do not use the other asl rulesets with cpanel, those other rules either use other apache modules (such as mod_sed) or ASL specific features that require [[ASL]].<br />
<br />
==== Step 5: Install mod_uniqueid ====<br />
<br />
Cpanel users will need to manually verify that the mod_unique_id module is loaded by cpanel's apache. It should be loaded by default, but check your cpanel configuration to be sure.<br />
<br />
==== Step 6: Install the rules ====<br />
<br />
===== Automatic Rule Updater =====<br />
<br />
[[aum]] -u<br />
<br />
===== Manually install the rules =====<br />
<br />
See the [https://www.atomicorp.com/wiki/index.php/Atomic_ModSecurity_Rules#Step_8:_Download_the_ModSecurity_Rules Downloading rules] section above.<br />
<br />
==== Step 7: Restart Apache ====<br />
<br />
Restart apache, enjoy your new secure web server!<br />
<br />
==== Optional Steps ====<br />
<br />
===== Malware Scanner =====<br />
<br />
The malware scanner is included in [[ASL]], it is not included in the rules or rule subscriptions. Therefore, if you use this file:<br />
<br />
05_asl_scanner.conf<br />
<br />
Or this:<br />
<br />
99_asl_scanner.conf<br />
<br />
You will need to include your own scanner, and will need to make sure you have clamd installed and configured correctly to listen on a TCP port, or if you use a socket, make sure apache can read/write to this socket or as a last resort, run clamd as root. Using this file forces all web uploads on your system to go thru clamav to look for malware, viruses, etc. If you dont need that, then you can leave this config file out.<br />
<br />
<br />
==== Cpanel Error Messages ====<br />
<br />
==== modsecparse.pl ====<br />
<br />
'''This is a third party tool not provided by, or supported by Atomicorp.''' If you use this tool, it apparently does not work with the new fast concurrent logging system in modsecurity. The concurrent logging system is much faster, will speed up apache and is less resource intensive that the older serial method. <br />
<br />
However, if you use this tool you must use the slower serial logging method, as it does not support the faster concurrent method. To use this tool, change the SecAuditLogType setting from "Concurrent" to "Serial":<br />
<br />
SecAuditLogType Serial<br />
<br />
'''Keep in mind that this logging method is much slower, may slow down apache and is not supported.''' This performance impact is not caused by the rules. Serial logging is much slower than concurrent logging. Therefore we do not recommend you use this logging method or any tools that require it. There are lots of modsecurity log readers that can use the concurrent logging method, such as [[ASL]] and we encourage you to explore using one of those modern tools instead.<br />
<br />
==== Serial logging ====<br />
<br />
===== Discussion =====<br />
<br />
Serial logging is the older slower depreacted logging method modsecurity original used many years ago. This logging method would log the entire event in a single file. As a result, it would slow apache down because each event needed to wait for the previous event to finish writing before it could write to the log file. Events stack up and slow apache down. This incurs a significant performance penalty on apache, and of course a better method was devised for modsecurity to address this performance issue. The solution is the concurrent logging method. This generates a unique event file for each log event, logging the events data to that file instead of trying to jam tons of data into a single file, and thereby slowing down apache. All modern modsecurity log viewing tools support the concurrent method.<br />
<br />
The concurrent logging system is much faster, will speed up apache and is less resource intensive that the older serial method. This method is highly recommended over the slow serial logging method.<br />
<br />
===== Configuration =====<br />
<br />
====== aum ======<br />
<br />
If you want to use the old slower serial logging method, and you are using aum, change this setting in /etc/asl/config:<br />
<br />
MODSEC_LOGTYPE="Concurrent"<br />
<br />
<br />
To:<br />
<br />
MODSEC_LOGTYPE="Serial"<br />
<br />
<br />
And then run:<br />
<br />
aum -uf<br />
<br />
====== non-aum systems ======<br />
<br />
If you want to use the old slower serial logging method change the SecAuditLogType setting from "Concurrent" to "Serial":<br />
<br />
SecAuditLogType Serial<br />
<br />
'''Warning: Serial logging is much slower than concurrent logging and will slow down apache.''' Any performance impact is not caused by the rules. <br />
<br />
Therefore we do not recommend you use this logging method or any tools that require it. There are lots of modsecurity log readers that can use the fast concurrent logging method, such as [[ASL]] and we encourage you to explore using one of those modern tools instead of a tool that requires the slower and performance degrading serial logging method.<br />
<br />
If you change your system to the slower Serial method, you may also want to change the logfile name you are using for your modsecurity logs. You can do that by changing this option in your configuration:<br />
<br />
SecAuditLog logs/audit_log</div>Mshinnhttps://wiki.atomicorp.com/wiki/index.php/Mod_securityMod security2022-09-16T19:27:37Z<p>Mshinn: /* phase:1 rules */</p>
<hr />
<div>=Installing modsecurity Rules =<br />
<br />
Please see this article:<br />
<br />
[[Atomic ModSecurity Rules]]<br />
<br />
=Tuning and managing modsecurity Rules=<br />
<br />
== Disabling Rules ==<br />
<br />
=== Important Notes ===<br />
<br />
==== phase:1 rules ====<br />
<br />
Note: ASL/AWP/AEO users should disable rules from the rule manager. There is no need to create custom rules, apache configuration files or other customizations when using ASL/AWP/AEO, and ASL/AWP/AEO supports disabling any rule on both a global and per domain basis.<br />
<br />
For non-ASL users, LocationMatch and Location do not work for phase:1 rules. Location and LocationMatch are not available in apache until phase:2. If you need to disable a phase:1 rule, use ASL/AWP/AEO which can disable phase:1 rules on a per domain and global basis.<br />
<br />
<br />
If you are not using ASL/AWP/AEO, and need to disable a phase:1 rule, you will need to create a custom rule to do this. This following is an example of a custom rule to do this for rule 123456.<br />
<br />
<br />
''SecRule REQUEST_HEADERS:Host "example.com$" "phase:1,id:91001,t:none,t:lowercase,pass,nolog,noauditlog,ctl:ruleRemovebyID=123456"''<br />
<br />
<br />
In the example above, "example.com" is the domain to exclude this rule. This custom rule must be loaded before the rule you want to disable. This custom rule *must be loaded before the rule you wish to disable*.<br />
<br />
If you do not know how to create this kind of custom rule, please contact support and we'll put a quote together to help develop these custom rules for you.<br />
<br />
=== Global ===<br />
<br />
==== Disabling Mod_Security Globally ====<br />
<br />
If you are using ASL, just change this setting:<br />
<br />
https://www.atomicorp.com/wiki/index.php/ASL_WAF#MODSEC_ENABLED<br />
<br />
If you are not using ASL, you will need to do this manually:<br />
<br />
Step 1) Disable config file<br />
mv /etc/httpd/conf.d/00_mod_security.conf /etc/httpd/conf.d/00_mod_security.conf.disabled<br />
<br />
Step 2) Restart Apache<br />
service httpd restart<br />
<br />
==== Disable Mod_security on a global URL ====<br />
<br />
Step 1) Create a global exclude file<br />
<br />
vim /etc/httpd/modsecurity.d/00_custom_exclude.conf<br />
<br />
Step 2) Add the LocationMatch for the url to exclude. Example: /server.php<br />
<br />
<LocationMatch /server.php><br />
<IfModule mod_security2.c><br />
SecRuleEngine Off <br />
</IfModule><br />
</LocationMatch><br />
<br />
Step 3) Restart apache<br />
<br />
service httpd restart<br />
<br />
<br />
<br />
Step 3) Restart apache<br />
<br />
service httpd restart<br />
<br />
==== Set a URL to alert only ====<br />
<br />
Step 1) Create a global exclude file<br />
<br />
vim /etc/httpd/modsecurity.d/00000_custom_exclude.conf<br />
<br />
Step 2) Add a custom rule<br />
<br />
In this example the URL is: /foo/bar<br />
<br />
Add this line to the file you created in Step 1:<br />
<br />
SecRule REQUEST_URI "/foo/bar" "phase:1,id:1000000,t:none,t:lowercase,pass,nolog,noauditlog,ctl:ruleEngine=DetectionOnly"<br />
<br />
Important Note: See the section customizing rules below to pick a unique id for your rule above. Duplicate rule ids will cause the rule to not load.<br />
<br />
Step 3) Restart apache<br />
<br />
service httpd restart<br />
<br />
=== Per domain ===<br />
<br />
==== Disabling Mod_security per domain ====<br />
<br />
Note: If you only want to disable a specific rule for a domain, please see this article:<br />
<br />
https://wiki.atomicorp.com/wiki/index.php/Mod_security#Per_application<br />
<br />
===== For Plesk Based Systems =====<br />
<br />
For Plesk and similar systems you can also disable modsecurity in the Apache configuration.<br />
<br />
Step 1) Edit the vhost/vhost_ssl.conf for the domain<br />
vim /var/www/vhosts/<DOMAINNAME>/conf/vhost.conf<br />
<br />
Step 2) Add the following<br />
<IfModule mod_security2.c><br />
SecRuleEngine Off<br />
</IfModule><br />
<br />
Then restart apache, if you are using Plesk then you will also need follow steps 3 and 4.<br />
<br />
Step 3) Add vhost.conf to domain config <br />
<br />
Plesk 9:<br />
/usr/local/psa/admin/bin/websrvmng -a<br />
<br />
Plesk 10/11:<br />
/usr/local/psa/admin/bin/httpdmng --reconfigure-domain <domain_name><br />
<br />
Step 4) Restart Apache<br />
service httpd restart<br />
<br />
===== For Cpanel based systems with EasyApache 4 =====<br />
<br />
For full information about include file path expectations, see the official cPanel documentation at [https://documentation.cpanel.net/display/EA4/Modify+Apache+Virtual+Hosts+with+Include+Files Modify Apache Virtual Hosts with Include Files]<br />
<br />
Step 1) Create the following paths, replacing <user> and <domain> with the correct values for your needs:<br />
<br />
* mkdir -p /etc/apache2/conf.d/userdata/ssl/2_4/<user>/<domain><br />
* mkdir -p /etc/apache2/conf.d/userdata/std/2_4/<user>/<domain><br />
<br />
Step 2) In each of the above paths, create a file named 'vhost.conf'<br />
<br />
Step 3) Add in the lines below to this file:<br />
<br />
<pre><br />
<IfModule mod_security2.c><br />
SecRuleEngine Off<br />
</IfModule><br />
</pre><br />
<br />
Step 4) After any addition, modification or removal of userdata files, cPanel requires both of the following scripts to be run:<br />
<br />
* /usr/local/cpanel/scripts/rebuildhttpdconf<br />
* /usr/local/cpanel/scripts/restartsrv_httpd<br />
<br />
<br />
===== For Cpanel based systems with EasyApache 3 =====<br />
<br />
Step 1) Create the custom modsecurity configuration directory for the domain<br />
<br />
For example, if the domain is example.com, you would need to create this directory:<br />
<br />
<br />
mkdir /usr/local/apache/conf/userdata/std/2/username/example.com<br />
<br />
Step 2) Create the file vhost.conf in this directory<br />
<br />
cd /usr/local/apache/conf/userdata/std/2/username/example.com<br />
<br />
touch vhost.conf<br />
<br />
Step 3) Add in the lines below to this file:<br />
<br />
<pre><br />
<IfModule mod_security2.c><br />
SecRuleEngine Off<br />
</IfModule><br />
</pre><br />
<br />
Step 4) Run the vhost includes script, for example if the domains username is "example":<br />
<br />
/scripts/ensure_vhost_includes --user=example<br />
<br />
<br />
<br />
==== Disabling Mod_security per domain for an IP address ====<br />
<br />
===== For Plesk based systems =====<br />
<br />
For Plesk and similar systems you can also disable modsecurity in the Apache configuration.<br />
<br />
Step 1) Edit the vhost/vhost_ssl.conf for the domain<br />
vim /var/www/vhosts/<DOMAINNAME>/conf/vhost.conf<br />
<br />
Step 2) Add the following<br />
<IfModule mod_security2.c><br />
SecRule REMOTE_ADDR "^1.2.3.4$" "phase:1,t:none,nolog,allow,ctl:ruleEngine=Off,ctl:auditEngine=Off,id:9999"<br />
</IfModule><br />
<br />
'''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.'''<br />
<br />
Then restart apache, if you are using Plesk then you will also need follow steps 3 and 4.<br />
<br />
Step 3) Add vhost.conf to domain config <br />
<br />
Plesk 9:<br />
/usr/local/psa/admin/bin/websrvmng -a<br />
<br />
Plesk 10/11:<br />
/usr/local/psa/admin/bin/httpdmng --reconfigure-domain <domain_name><br />
<br />
Step 4) Restart Apache<br />
service httpd restart<br />
<br />
===== For cpanel based systems =====<br />
<br />
Step 1) Create the custom modsecurity configuration directory for the domain<br />
<br />
For example, if the domain is example.com, you would need to create this directory:<br />
<br />
mkdir /usr/local/apache/conf/userdata/std/2/username/example.com<br />
<br />
Step 2) Create the file vhost.conf in this directory<br />
<br />
cd /usr/local/apache/conf/userdata/std/2/username/example.com<br />
<br />
touch vhost.conf<br />
<br />
Step 3) Add in the lines below to this file:<br />
<br />
<IfModule mod_security2.c><br />
SecRule REMOTE_ADDR "^1.2.3.4$" "phase:1,t:none,nolog,allow,ctl:ruleEngine=Off,ctl:auditEngine=Off,id:9999"<br />
</IfModule><br />
<br />
'''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.'''<br />
<br />
Step 4) Run the vhost includes script, for example if the domains username is "example":<br />
<br />
/scripts/ensure_vhost_includes –user=example<br />
<br />
==== Disable a rule for a single domain ====<br />
<br />
'''If you have ASL installed''':<br />
<br />
Method 1:<br />
<br />
Log into the ASL GUI, and click on the "ASL" tab. Then click "WAF & HIDS Rules", 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.<br />
<br />
Type in the hostname into the Text box on the left side of the options you want to exclude the rule for, then click "add".<br />
<br />
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, or a regular expression *.example.com.<br />
<br />
Note: You can use regular expressions in this field, but each end of the expression is anchored.<br />
<br />
<br />
Method 2: Run this command as root:<br />
<br />
In ASL v3.x:<br />
asl -dr RULE_ID --vhost www.example.com<br />
<br />
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:<br />
<br />
asl -dr RULE_ID --vhost www.example.com<br />
<br />
asl -dr RULE_ID --vhost ftp.example.com<br />
<br />
asl -dr RULE_ID --vhost example.com<br />
<br />
<br />
In ASL v4:<br />
asl -drv RULE_ID[,RULE_ID...] VHOST[,VHOST...]<br />
or <br />
asl --disable-rule-vhost RULE_ID[,RULE_ID...] VHOST[,VHOST...]<br />
<br />
All supplied rules will be disabled on all supplied vhosts.<br />
<br />
asl -drv 111111,222222,333333 www.example.com,ftp.example.com,example.com<br />
<br />
<br />
<br />
<br />
'''If you do not have ASL installed''' you will have to do this manually:<br />
<br />
Step 1) Edit your domains vhost.conf file (the location of this file will vary based on your control panel, contact your control panel vendor for assistance)<br />
<br />
vim vhost.conf<br />
<br />
Step 2) Add the LocationMatch for the rule to exclude. Example, ruleid 950005<br />
<LocationMatch .*><br />
<IfModule mod_security2.c><br />
SecRuleRemoveById 950005<br />
</IfModule><br />
</LocationMatch><br />
<br />
If you want to disable multiple rules:<br />
<br />
Step 2) Add the LocationMatch for the rule to exclude. Example, ruleids 950005 and 950006<br />
<LocationMatch .*><br />
<IfModule mod_security2.c><br />
SecRuleRemoveById 950005<br />
SecRuleRemoveById 950006<br />
</IfModule><br />
</LocationMatch><br />
<br />
<br />
==== Non Control Panel systems ====<br />
<br />
For nginx, or phase:1 rules rules can be disabled for a domain/FQDN by adding a custom rule before the rule you wish to disable is loaded. For example, if you wanted to disable rule 123456 for domain example.com, you would add this rule to your custom rules:<br />
<br />
SecRule REQUEST_HEADERS:Host "example.com$" "phase:1,id:91001,t:none,t:lowercase,pass,nolog,noauditlog,ctl:ruleRemovebyID=123456"<br />
<br />
This method can also be used for Apache.<br />
<br />
==== Disable a rule for all domains ====<br />
<br />
Method 1:<br />
<br />
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.<br />
<br />
Set "disabled" to yes and click update.<br />
<br />
Method 2:<br />
<br />
Use ASL utility to disable rule by ID. Example: 950005<br />
asl --disable-rule 950005<br />
<br />
Note: This requires that [[Atomic Secured Linux]] be installed.<br />
'''<br />
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:<br />
<br />
<LocationMatch .*><br />
<IfModule mod_security2.c><br />
SecRuleRemoveById 340000<br />
</IfModule><br />
</LocationMatch><br />
<br />
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.<br />
<br />
=== Per IP or network ===<br />
<br />
==== Disable Mod_security for an IP address ====<br />
<br />
In ASL, just click the "Whitelist" button.<br />
<br />
If you are not using ASL, simply add your IP address to the file:<br />
<br />
/etc/asl/whitelist<br />
<br />
And restart Apache.<br />
<br />
Note: For this rule to work, in ASL you must have the MODSEC_00_WHITELIST ruleset enabled.<br />
<br />
If you are not using ASL, then you must have the 00_asl_whitelist.conf ruleset loaded.<br />
<br />
==== Whitelist an IP ====<br />
<br />
See above, "Disable Mod_security for an IP address"<br />
<br />
==== Disable a rule by IP or network====<br />
<br />
You will need to create a custom rule, loaded after all your other rules. Lets say you wanted to exclude rule id 330039 for the network 1.2.0.0/16. You would construct a custom rule like this:<br />
<br />
<pre><br />
SecRule REMOTE_HOST "@ipmatch 1.2.0.0/16" \<br />
"id:12345,phase:2,t:none,pass,nolog,noauditlog,ctl:ruleRemovebyID=330039"<br />
</pre><br />
<br />
Note: ipmatch can also use a list, with a combination of IPs and network for example:<br />
<br />
@ipmatch 1.2.0.0/16,5.6.7.8,127.0.0.0/8<br />
<br />
Warning: If the CIDR is invalid, this may cause a segfault of the mod_security module. Check to make sure your CIDR is valid before use.<br />
<br />
=== Per application ===<br />
<br />
==== Disable modsecurity for a specific web application ====<br />
<br />
Note: this is not recommended<br />
<br />
Add a custom rule (see the section below on creating [https://www.atomicorp.com/wiki/index.php/Mod_security#Creating_custom_rules custom rules]) after all your rules have been loaded. For example, if you wanted to disable modsecurity for the application /foo/bar.cgi you would add a custom rule like this:<br />
<br />
<pre><br />
<LocationMatch /foo/bar.cgi><br />
SecRuleEngine Off<br />
<br />
</LocationMatch><br />
</pre><br />
<br />
<br />
<br />
==== Disable a rule for a specific web application ====<br />
Add a custom rule (see the section below on creating [https://www.atomicorp.com/wiki/index.php/Mod_security#Creating_custom_rules custom rules]) after all your rules have been loaded. For example, if you wanted to disable rule 950005, you would add a custom rule like this:<br />
<br />
<pre><br />
<LocationMatch /URL/path/to/application.php><br />
SecRuleRemoveById 950005<br />
<br />
</LocationMatch><br />
</pre><br />
<br />
==== Disable a rule for a single domain or FQDN ====<br />
<br />
===== For non control panel systems =====<br />
<br />
If you are using any of our GUI products, just click on the rule event, and type in the domain or hostname you want to exclude for this rule. <br />
<br />
For DIY users, you will need to create custom rules that load *before* the rule that you wish to exclude. This means you will need to add a custom rule file that loads before the rules we supply.<br />
<br />
Once you have set this up for your DIY modsecurity configuration, you will add a rule that inspects the Host: header sent by the client, which will the disable the rule(s) you wish to disable when that field is populated by that value. Keep in mind this field is completely controlled by the client, not the server. In the example below, the entire domain "example.com" is excluded for rule 123456:<br />
<br />
''SecRule REQUEST_HEADERS:Host ".example.com$" "phase:1,id:91010,t:none,t:lowercase,pass,nolog,noauditlog,ctl:ruleRemovebyID=123456"''<br />
<br />
Then restart the web server to apply this custom exclusion.<br />
<br />
===== For Plesk systems =====<br />
<br />
<br />
Step 1) Edit the virtual servers configuration for the domain for the domain<br />
<br />
Example:<br />
<br />
vim /var/www/vhosts/<DOMAINNAME>/conf/vhost.conf<br />
<br />
Step 2) Add the LocationMatch for the rule to exclude. Example, ruleid 950005<br />
<br />
<pre><br />
<LocationMatch /URL/path/to/application.php><br />
<br />
SecRuleRemoveById 950005<br />
</IfModule><br />
<br />
</pre><br />
<br />
==== Disable Mod_security rules globally for a specific application ====<br />
<br />
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.<br />
<br />
<LocationMatch /url/to/your/application><br />
<IfModule mod_security2.c><br />
SecRuleRemoveById 1234567<br />
SecRuleRemoveById 9999999<br />
</IfModule><br />
</LocationMatch><br />
<br />
Whats important to remember is that the LocationMatch variable must match the URL, not the path on the system.<br />
<br />
==== Disable Mod_security rules by domain, for a specific application, for a list of IPs ====<br />
<br />
Step 1) Edit the vhost/vhost_ssl.conf for the domain<br />
vim /var/www/vhosts/<DOMAINNAME>/conf/vhost.conf<br />
<br />
Step 2) Add the LocationMatch for the rule to exclude.<br />
<LocationMatch /foo/bar.php><br />
<IfModule mod_security2.c><br />
SecRule REMOTE_ADDR "@pmFromFile /etc/asl/whitelist" "nolog,phase:1,allow"<br />
</IfModule><br />
</LocationMatch><br />
<br />
Step 3) Add IP to /etc/asl/whitelist<br />
echo "10.11.12.13" >> /etc/asl/whitelist<br />
<br />
Or:<br />
<br />
If you want to create a special whitelist for just that application:<br />
<br />
Step 1) Edit the vhost/vhost_ssl.conf for the domain<br />
vim /var/www/vhosts/<DOMAINNAME>/conf/vhost.conf<br />
<br />
Step 2) Add the LocationMatch for the rule to exclude.<br />
<LocationMatch /foo/bar.php><br />
<IfModule mod_security2.c><br />
SecRule REMOTE_ADDR "@pmFromFile /path/to/your/custom/whitelist_for_this_application" "nolog,phase:1,allow,id:9999"<br />
</IfModule><br />
</LocationMatch><br />
<br />
'''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.'''<br />
<br />
<br />
Step 3) Create your custom whitelist and add IP to /etc/asl/whitelist<br />
echo "10.11.12.13" >> /path/to/your/custom/whitelist_for_this_application<br />
<br />
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.<br />
<br />
==== Disable rule for a specific argument for a specific application ====<br />
<br />
You can also tell modsecurity to change a rule, in some cases, without editing or forking the rule. For example, if you want to configure modsecurity to ignore a specific argument (in the argument below the argument is "foo"), for a specific application (in the example the application name is /example/application), for a specific rule (in the example below the rule if is 12345), you would create a custom rule like this:<br />
<br />
<br />
<pre><br />
SecRule REQUEST_URI "^/example/application" \<br />
"id:9999,phase:1,t:none,t:lowercase,nolog,pass,ctl:ruleRemoveTargetByID=12345;ARGS:foo"<br />
</pre><br />
<br />
As with all custom rules, this rule also needs a unique id as explained in the article above. And this type of custom rule must be loaded '''before''' the rule it modifies.<br />
<br />
Note: This does not support regular expressions for the excluded argument. At this time, they must be explicitly defined.<br />
<br />
==== Disable rule for a specific argument ====<br />
<br />
As is the example above, a rule can also be changed to exclude a specific argument, but for all applications. For example, if you want to configure modsecurity to ignore a specific argument (in the argument below the argument is "foo"), for a specific rule (in the example below the rule if is 12345), you would create a custom rule like this:<br />
<br />
<pre><br />
SecAction "phase:1,id:9999,t:none,auditlog,nolog,pass,ctl:ruleRemoveTargetById=12345;ARGS:foo"<br />
</pre><br />
<br />
As with all custom rules, this rule also needs a unique id as explained in the article above. And this type of custom rule must be loaded '''before''' the rule it modifies.<br />
<br />
Note: This does not support regular expressions for the excluded argument. At this time, they must be explicitly defined.<br />
<br />
==== Disable modsecurity for a specific argument ====<br />
<br />
As is the example above, modsecurity can also be configured to exclude a specific argument for all rules. For example, if you want to configure modsecurity to ignore a specific argument (in the argument below the argument is "foo"),you would create a custom rule like this:<br />
<br />
<pre><br />
SecAction "phase:1,id:9999,t:none,auditlog,nolog,pass,ctl:ruleRemoveTargetById=1-1000000;ARGS:foo"<br />
</pre><br />
<br />
When 1-100000 is the rule IDs you want to exclude. As with all custom rules, this rule also needs a unique id as explained in the article above. <br />
<br />
Note: This does not support regular expressions for the excluded argument. At this time, they must be explicitly defined.<br />
<br />
== Changing the action for a rule ==<br />
<br />
You can also change the default action for a rule by using the SecRuleActionById directive. <br />
<br />
=== Changing a rule to be detect only by ID===<br />
<br />
To change a rule to only detect, but not block attacks, simply change the action for the rule with the above directive. For example, to change the action for rule 12345, simply add this rule directive to your custom rules. <br />
<br />
SecRuleUpdateActionById 12345 "pass,status:200"<br />
<br />
Note 1: this directive must be added after the rule it is modifying has been loaded.<br />
<br />
Note 2: This does not work if you are using the redirect action.<br />
<br />
=== Changing a range of rules ot be detect only by ID===<br />
<br />
This is similar to the method above, however you can define a range of rule IDs. For example, if you want to disable rules 1000-2000:<br />
<br />
SecRuleUpdateActionById 1000-2000 "pass,status:200"<br />
<br />
Note 1: this directive must be added after the rule it is modifying has been loaded.<br />
<br />
Note 2: This does not work if you are using the redirect action.<br />
<br />
== Disabling POST inspection for a specific URL ==<br />
<br />
Should you want to disable inspection of a POST for a specific URL, use the format below.<br />
<br />
Assuming the URL you wanted to skip POST inspection was "upload", your exclusion rule would look like this:<br />
<br />
''SecRule REQUEST_URI "^/upload" \<br />
"phase:1,id:1234567,t:none,t:lowercase,pass,nolog,ctl:requestBodyAccess=off"''<br />
<br />
Install this rule before any of your other rules. For example, in the file /etc/httpd/modsecurity.d/00_custom_exclude.conf.<br />
<br />
== Enabling rules for only specific domains ==<br />
<br />
If you wish to disable all the rules, except for specific domains, you need to copy in the two files from the subdirectory "special" where you have the rules installed. Then create this file:<br />
<br />
/etc/asl/custom_include_domains<br />
<br />
<br />
Include the domains and/or FQDNs you want the rules to apply to. Anything not on that list will cause those rules to skip all of our rules. <br />
<br />
#File must contain exactly one domain or FQDN per line. End of line markers (both LF and CRLF) will be stripped from each phrase and any whitespace trimmed from both the beginning and the end. Empty lines and comment lines (those beginning with the # character) will be ignored.<br />
#This file does not support metacharacters. (For example, * is not supported)<br />
<br />
Example:<br />
<br />
<br />
<pre><br />
www.example.com<br />
.foo.com<br />
</pre><br />
<br />
== Disabling rules using .htaccess ==<br />
<br />
This is a new feature in modsecurity 2.7.3. This capability is available if you compile modsecurity using this option:<br />
<br />
--enable-htaccess-config<br />
<br />
From there, you will be able to disable rules using .htaccess files. The format to disable a rule via .htaccess is:<br />
<br />
SecRuleRemoveById 12345<br />
<br />
Where 12345 is the rule id.<br />
<br />
'''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 and/or this option has not been enabled. <br />
<br />
Warning: Enabling this capability will allow users to disable rules, including on compromised accounts which may cause the system to become compromised. This capability was specifically disabled by default in modsecurity to prevent this from occurring. Use this option with extreme caution!<br />
<br />
=== Specific actions available in .htaccess ===<br />
<br />
<br />
* SecAction<br />
* SecRule<br />
* SecRuleRemoveByMsg<br />
* SecRuleRemoveByTag<br />
* SecRuleRemoveById<br />
* SecRuleUpdateActionById<br />
* SecRuleUpdateTargetById<br />
* SecRuleUpdateTargetByTag<br />
* SecRuleUpdateTargetByMsg<br />
<br />
'''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.<br />
<br />
Warning: Enabling this capability in modsecurity can allow an attacker to disable modsecurity rules that you may be using to protect the entire server. We do not recommend you enable this capability on a shared server.<br />
<br />
== Customizing a rule ==<br />
<br />
If you need to customize a rule do not change the asl*conf files. These files will be overwritten by updates. <br />
<br />
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.<br />
<br />
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:<br />
<br />
If you had an original rule like this:<br />
<br />
SecRule REQUEST_URI "/foo" "t:normalisePath,id:9000,rev:1,severity:2,msg:'Atomicorp.com WAF Rules: Block /foo'"<br />
<br />
<br />
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.<br />
<br />
SecRuleRemoveById 9000000<br />
SecRule REQUEST_URI "/bar" "t:normalisePath,id:9999,rev:1,severity:2,msg:'Atomicorp.com WAF Rules: Block /foo'"<br />
<br />
'''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.'''<br />
<br />
<br />
These are the reserved ranges:<br />
<br />
* 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.<br />
* 100,000-199,999; reserved for internal use of the engine, to assign to rules that do not have explicit IDs.<br />
* 200,000-299,999; reserved for rules published at modsecurity.org.<br />
* 300,000-399,999; reserved for rules published at gotroot.com.<br />
* 400,000-419,999; unused (available for reservation).<br />
* 420,000-429,999; reserved for ScallyWhack.<br />
* 430,000-699,999; unused (available for reservation).<br />
* 700,000-799,999; reserved for Ivan Ristic.<br />
* 900,000-999,999; reserved for the Core Rules project.<br />
* 1,000,000 and above; unused (available for reservation).<br />
<br />
=== For a domain ===<br />
<br />
==== Apache ====<br />
<br />
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.<br />
<br />
==== Changing the argument separator ====<br />
<br />
If you have a web application that uses the uncommon ";" argument separator, as opposed to the widely used "&" you will want to change SecArgumentSeparator value for that application. You can do this in one of two ways:<br />
<br />
1) Globally<br />
<br />
If all your applications use the older delimiter, just change the SecArgumentSeparator in the tortix_waf.conf file. Do not change this if your applications use other delimiters.<br />
<br />
''SecArgumentSeparator ";"'' <br />
<br />
2) Per Application<br />
<br />
You can also configure this per application. For example, if your web applications URL is /foo/bar.php you can create a customer rule like this:<br />
<br />
<br />
<pre><br />
<LocationMatch /foo/bar.php><br />
SecArgumentSeparator ";"<br />
</LocationMatch><br />
</pre><br />
<br />
This will only work if modsecurity is loaded before your virtual host definitions. This is the case with most control panels, but some control panels are known to load modsecurity after vhosts are defined. In which case this will fail because Apache will not know how to process this directive (it will need modsecurity loaded to understand what this means). If you get a syntax error, that means your apache configuration is loaded modsecurity after your vhosts are defined. You will need to change your apache configuration to ensure this loading occurs before vhosts are defined.<br />
<br />
[[ASL]] will automatically configure modsecurity to load first.<br />
<br />
= Creating custom rules =<br />
<br />
== Discussion ==<br />
<br />
If you need to create your own custom rules, do not change the asl*conf files. These files will be overwritten by updates. <br />
<br />
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.<br />
<br />
== Rule Ids for custom rules ==<br />
<br />
For custom rules, '''you must create your own rule ids which must be unique'''. The id: fields contain the rule ids. For custom rules you should use the local (internal) use range (see below for the reserved id ranges). '''Do not use assigned ranges.'''<br />
<br />
These are the reserved ranges:<br />
<br />
* 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.<br />
* 100,000-199,999; reserved for internal use of the engine, to assign to rules that do not have explicit IDs. (deprecated, all rules require assigned ids in 2.7.x and up)<br />
* 200,000-299,999; reserved for rules published at modsecurity.org.<br />
* 300,000-399,999; reserved for rules published by atomicorp.com<br />
* 400,000-419,999; unused (available for reservation).<br />
* 420,000-429,999; reserved for ScallyWhack.<br />
* 430,000-699,999; unused (available for reservation).<br />
* 700,000-799,999; reserved for Ivan Ristic.<br />
* 900,000-999,999; reserved for the Core Rules project.<br />
* 1,000,000 and above; unused (available for reservation).<br />
<br />
== Installing custom rules ==<br />
<br />
<br />
=== Linux ===<br />
<br />
==== Apache ====<br />
<br />
'''Step 1) Create your custom rules directory:'''<br />
<br />
''mkdir /etc/httpd/modsecurity.custom.d''<br />
<br />
'''Step 2) Create a configuration file for your custom rules in /etc/httpd/conf.d directory. For example:'''<br />
<br />
Create the file 01_modsecurity.conf and add this line to it:<br />
<br />
''Include modsecurity.custom.d/[https://www.atomicorp.com/examples/99_zzz_custom.conf 99_zzz_custom.conf]''<br />
<br />
You can download an example file from the URL below that will do this:<br />
<br />
[https://www.atomicorp.com/examples/01_modsecurity.conf 01_modsecurity.conf]<br />
<br />
And add 01_modsecurity.conf to this directory:<br />
<br />
/etc/httpd/conf.d<br />
<br />
If you have wget installed on your system, the following commands will do this automatically for you:<br />
''<br />
<br />
cd /etc/httpd/conf.d<br />
<br />
wget https://www.atomicorp.com/examples/01_modsecurity.conf''<br />
<br />
Note: 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. Please contact your control panel vendor for assistance.<br />
<br />
'''Step 3) Install your custom rules in the /etc/httpd/modsecurity.custom.d directory'''<br />
<br />
''cd /etc/httpd/modsecurity.custom.d''<br />
<br />
and edit the file 99_zzz_custom.conf and put in your custom rules.<br />
<br />
You can also download an example custom rule file by running these commands:<br />
<br />
''cd /etc/httpd/modsecurity.custom.d<br />
<br />
wget https://www.atomicorp.com/examples/99_zzz_custom.conf''<br />
<br />
'''Step 4) Test your apache configuration'''<br />
<br />
''service httpd configtest''<br />
<br />
If you have any errors, do not restart apache. You will need to correct these errors or apache will not start.<br />
<br />
'''Step 5) If your test was successful, restart apache.'''<br />
<br />
''service httpd restart''<br />
<br />
Our professional services group would be happy to help you with your custom rules needs, including developing the rules for you. If your request is something that we can safely include in the rules for all our customers, we're generally able to develop these new rules for free. Please contact us to discuss your rules needs.<br />
<br />
=== Windows ===<br />
<br />
==== IIS ====<br />
<br />
'''Step 1) Modify your modsecurity configuration file on windows and add this line to the end of your configuration. For example:'''<br />
<br />
''Include [https://www.atomicorp.com/examples/99_zzz_custom.conf 99_zzz_custom.conf]''<br />
<br />
'''Step 2) Edit the file 99_zzz_custom.conf and save it in the same directory as your modsecurity config file'''<br />
<br />
'''Step 3)Restart IIS'''<br />
<br />
<br />
Our professional services group would be happy to help you with your custom rules needs, including developing the rules for you. If your request is something that we can safely include in the rules for all our customers, we're generally able to develop these new rules for free. Please contact us to discuss your rules needs.<br />
<br />
== Modifying a rule ==<br />
<br />
If you want to modify the internal logic of a rule, you will want to "fork" or copy that rule into a custom rule. Do not modify the actual rules provided by us, your modifications will be overwritten with the next update.<br />
<br />
'''Step 1: Copy the rule you want to modify into your custom rules file.'''<br />
<br />
Copy the rule in its entirety into your custom rule file. For example, if you wanted to modify rule 390707, you would copy the entire rule into your custom rules file. For example:<br />
<br />
<pre><br />
# Restrict the maximum number of arguments in a request<br />
SecRule &ARGS "@gt 1000" \<br />
"chain,phase:2,t:none,log,auditlog,deny,status:403,msg:'Atomicorp.com WAF Rules: Too many arguments in request (max set to 1000, increase as necessary for your system)',id:'390707',severity:'4',rev:'8'"<br />
SecRule REQUEST_URI "!((?:^/(?:imaclean|massdelete)/)|^/cgi-bin/dada/mail\.cgi$|^/index\.php/mageworx/customoptions_options|^/za/|^/back-?office/|^/moderate\.php|^/backend/configdomains\.php|\.do$|^/admin[a-z0-9]+?/index\.php\?controller=adminmodules)" "t:none,t:lowercase"<br />
</pre><br />
<br />
'''Step 2: Change the rule id.''' <br />
<br />
This is absolutely required. No two rules can have the same ID. See this article for chosing a custom rule id: https://wiki.atomicorp.com/wiki/index.php/Mod_security#Rule_Ids_for_custom_rules<br />
<br />
For example:<br />
<br />
<pre><br />
# Restrict the maximum number of arguments in a request<br />
SecRule &ARGS "@gt 1000" \<br />
"chain,phase:2,t:none,log,auditlog,deny,status:403,msg:'Atomicorp.com WAF Rules: Too many arguments in request (max set to 1000, increase as necessary for your system)',id:'12345678',severity:'4',rev:'8'"<br />
SecRule REQUEST_URI "!((?:^/(?:imaclean|massdelete)/)|^/cgi-bin/dada/mail\.cgi$|^/index\.php/mageworx/customoptions_options|^/za/|^/back-?office/|^/moderate\.php|^/backend/configdomains\.php|\.do$|^/admin[a-z0-9]+?/index\.php\?controller=adminmodules)" "t:none,t:lowercase"<br />
</pre><br />
<br />
'''Step 3: Disable the original rule'''<br />
<br />
If you want your custom rule to be global, that is your modification applies to the entire system, then you will want to disable the original rule per this article:<br />
<br />
https://wiki.atomicorp.com/wiki/index.php/Mod_security#Disable_a_rule_for_all_domains<br />
<br />
If you want to disable the rule for a single application, see this article:<br />
<br />
https://wiki.atomicorp.com/wiki/index.php/Mod_security#Disable_a_rule_for_a_specific_web_application<br />
<br />
If you want to disable the rule for a specific IP or network:<br />
<br />
https://wiki.atomicorp.com/wiki/index.php/Mod_security#Disable_a_rule_by_IP_or_network<br />
<br />
If you want to disable the rule for a single domain:<br />
<br />
https://wiki.atomicorp.com/wiki/index.php/Mod_security#Disable_a_rule_for_a_single_domain<br />
<br />
'''Step 4: Set the scope of the rule.'''<br />
<br />
If you havent disabled the original rule globally, or for one or more domains, then you will need to set the scope of your custom rule. To limit your modification to a specific application, place your custom rule inside <LocationMatch> tags. For example:<br />
<br />
<pre><br />
<br />
<LocationMatch /url/to/your/custom/application><br />
# Restrict the maximum number of arguments in a request<br />
SecRule &ARGS "@gt 2048" \<br />
"chain,phase:2,t:none,log,auditlog,deny,status:403,msg:'Atomicorp.com WAF Rules: Too many arguments in request (max set to 1000, increase as necessary for your system)',id:'12345678',severity:'4',rev:'8'"<br />
SecRule REQUEST_URI "!((?:^/(?:imaclean|massdelete)/)|^/cgi-bin/dada/mail\.cgi$|^/index\.php/mageworx/customoptions_options|^/za/|^/back-?office/|^/moderate\.php|^/backend/configdomains\.php|\.do$|^/admin[a-z0-9]+?/index\.php\?controller=adminmodules)" "t:none,t:lowercase"<br />
</LocationMatch><br />
<br />
</pre><br />
<br />
= Configuring and Setting up mod_security =<br />
'''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.'''<br />
<br />
To setup and configured modsecurity, please see the [[Atomic_ModSecurity_Rules]] wiki page.</div>Mshinnhttps://wiki.atomicorp.com/wiki/index.php/Mod_securityMod security2022-09-16T19:25:00Z<p>Mshinn: /* Disable a rule for a single domain */</p>
<hr />
<div>=Installing modsecurity Rules =<br />
<br />
Please see this article:<br />
<br />
[[Atomic ModSecurity Rules]]<br />
<br />
=Tuning and managing modsecurity Rules=<br />
<br />
== Disabling Rules ==<br />
<br />
=== Important Notes ===<br />
<br />
==== phase:1 rules ====<br />
<br />
Note: ASL users should disable rules from the rule manager. There is no need to create custom rules, apache configuration files or other customizations when using ASL, and ASL supports disabling any rule on both a global and per domain basis.<br />
<br />
For non-ASL users, LocationMatch and Location do not work for phase:1 rules. Location and LocationMatch are not available in apache until phase:2. If you need to disable a phase:1 rule, use [[ASL]] which can disable phase:1 rules on a per domain and global basis.<br />
<br />
If you are not using [[ASL]], and need to disable a phase:1 rule, you will need to create a custom rule to do this. This following is an example of a custom rule to do this for rule 123456.<br />
<br />
''SecRule REQUEST_HEADERS:Host "example.com$" "phase:1,id:91001,t:none,t:lowercase,pass,nolog,noauditlog,ctl:ruleRemovebyID=123456"''<br />
<br />
In the example above, "example.com" is the domain to exclude this rule. This custom rule must be loaded before the rule you want to disable. This custom rule *must be loaded before the rule you wish to disable*.<br />
<br />
If you do not know how to create this kind of custom rule, please contact support and we'll put a quote together to help develop these custom rules for you.<br />
<br />
=== Global ===<br />
<br />
==== Disabling Mod_Security Globally ====<br />
<br />
If you are using ASL, just change this setting:<br />
<br />
https://www.atomicorp.com/wiki/index.php/ASL_WAF#MODSEC_ENABLED<br />
<br />
If you are not using ASL, you will need to do this manually:<br />
<br />
Step 1) Disable config file<br />
mv /etc/httpd/conf.d/00_mod_security.conf /etc/httpd/conf.d/00_mod_security.conf.disabled<br />
<br />
Step 2) Restart Apache<br />
service httpd restart<br />
<br />
==== Disable Mod_security on a global URL ====<br />
<br />
Step 1) Create a global exclude file<br />
<br />
vim /etc/httpd/modsecurity.d/00_custom_exclude.conf<br />
<br />
Step 2) Add the LocationMatch for the url to exclude. Example: /server.php<br />
<br />
<LocationMatch /server.php><br />
<IfModule mod_security2.c><br />
SecRuleEngine Off <br />
</IfModule><br />
</LocationMatch><br />
<br />
Step 3) Restart apache<br />
<br />
service httpd restart<br />
<br />
<br />
<br />
Step 3) Restart apache<br />
<br />
service httpd restart<br />
<br />
==== Set a URL to alert only ====<br />
<br />
Step 1) Create a global exclude file<br />
<br />
vim /etc/httpd/modsecurity.d/00000_custom_exclude.conf<br />
<br />
Step 2) Add a custom rule<br />
<br />
In this example the URL is: /foo/bar<br />
<br />
Add this line to the file you created in Step 1:<br />
<br />
SecRule REQUEST_URI "/foo/bar" "phase:1,id:1000000,t:none,t:lowercase,pass,nolog,noauditlog,ctl:ruleEngine=DetectionOnly"<br />
<br />
Important Note: See the section customizing rules below to pick a unique id for your rule above. Duplicate rule ids will cause the rule to not load.<br />
<br />
Step 3) Restart apache<br />
<br />
service httpd restart<br />
<br />
=== Per domain ===<br />
<br />
==== Disabling Mod_security per domain ====<br />
<br />
Note: If you only want to disable a specific rule for a domain, please see this article:<br />
<br />
https://wiki.atomicorp.com/wiki/index.php/Mod_security#Per_application<br />
<br />
===== For Plesk Based Systems =====<br />
<br />
For Plesk and similar systems you can also disable modsecurity in the Apache configuration.<br />
<br />
Step 1) Edit the vhost/vhost_ssl.conf for the domain<br />
vim /var/www/vhosts/<DOMAINNAME>/conf/vhost.conf<br />
<br />
Step 2) Add the following<br />
<IfModule mod_security2.c><br />
SecRuleEngine Off<br />
</IfModule><br />
<br />
Then restart apache, if you are using Plesk then you will also need follow steps 3 and 4.<br />
<br />
Step 3) Add vhost.conf to domain config <br />
<br />
Plesk 9:<br />
/usr/local/psa/admin/bin/websrvmng -a<br />
<br />
Plesk 10/11:<br />
/usr/local/psa/admin/bin/httpdmng --reconfigure-domain <domain_name><br />
<br />
Step 4) Restart Apache<br />
service httpd restart<br />
<br />
===== For Cpanel based systems with EasyApache 4 =====<br />
<br />
For full information about include file path expectations, see the official cPanel documentation at [https://documentation.cpanel.net/display/EA4/Modify+Apache+Virtual+Hosts+with+Include+Files Modify Apache Virtual Hosts with Include Files]<br />
<br />
Step 1) Create the following paths, replacing <user> and <domain> with the correct values for your needs:<br />
<br />
* mkdir -p /etc/apache2/conf.d/userdata/ssl/2_4/<user>/<domain><br />
* mkdir -p /etc/apache2/conf.d/userdata/std/2_4/<user>/<domain><br />
<br />
Step 2) In each of the above paths, create a file named 'vhost.conf'<br />
<br />
Step 3) Add in the lines below to this file:<br />
<br />
<pre><br />
<IfModule mod_security2.c><br />
SecRuleEngine Off<br />
</IfModule><br />
</pre><br />
<br />
Step 4) After any addition, modification or removal of userdata files, cPanel requires both of the following scripts to be run:<br />
<br />
* /usr/local/cpanel/scripts/rebuildhttpdconf<br />
* /usr/local/cpanel/scripts/restartsrv_httpd<br />
<br />
<br />
===== For Cpanel based systems with EasyApache 3 =====<br />
<br />
Step 1) Create the custom modsecurity configuration directory for the domain<br />
<br />
For example, if the domain is example.com, you would need to create this directory:<br />
<br />
<br />
mkdir /usr/local/apache/conf/userdata/std/2/username/example.com<br />
<br />
Step 2) Create the file vhost.conf in this directory<br />
<br />
cd /usr/local/apache/conf/userdata/std/2/username/example.com<br />
<br />
touch vhost.conf<br />
<br />
Step 3) Add in the lines below to this file:<br />
<br />
<pre><br />
<IfModule mod_security2.c><br />
SecRuleEngine Off<br />
</IfModule><br />
</pre><br />
<br />
Step 4) Run the vhost includes script, for example if the domains username is "example":<br />
<br />
/scripts/ensure_vhost_includes --user=example<br />
<br />
<br />
<br />
==== Disabling Mod_security per domain for an IP address ====<br />
<br />
===== For Plesk based systems =====<br />
<br />
For Plesk and similar systems you can also disable modsecurity in the Apache configuration.<br />
<br />
Step 1) Edit the vhost/vhost_ssl.conf for the domain<br />
vim /var/www/vhosts/<DOMAINNAME>/conf/vhost.conf<br />
<br />
Step 2) Add the following<br />
<IfModule mod_security2.c><br />
SecRule REMOTE_ADDR "^1.2.3.4$" "phase:1,t:none,nolog,allow,ctl:ruleEngine=Off,ctl:auditEngine=Off,id:9999"<br />
</IfModule><br />
<br />
'''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.'''<br />
<br />
Then restart apache, if you are using Plesk then you will also need follow steps 3 and 4.<br />
<br />
Step 3) Add vhost.conf to domain config <br />
<br />
Plesk 9:<br />
/usr/local/psa/admin/bin/websrvmng -a<br />
<br />
Plesk 10/11:<br />
/usr/local/psa/admin/bin/httpdmng --reconfigure-domain <domain_name><br />
<br />
Step 4) Restart Apache<br />
service httpd restart<br />
<br />
===== For cpanel based systems =====<br />
<br />
Step 1) Create the custom modsecurity configuration directory for the domain<br />
<br />
For example, if the domain is example.com, you would need to create this directory:<br />
<br />
mkdir /usr/local/apache/conf/userdata/std/2/username/example.com<br />
<br />
Step 2) Create the file vhost.conf in this directory<br />
<br />
cd /usr/local/apache/conf/userdata/std/2/username/example.com<br />
<br />
touch vhost.conf<br />
<br />
Step 3) Add in the lines below to this file:<br />
<br />
<IfModule mod_security2.c><br />
SecRule REMOTE_ADDR "^1.2.3.4$" "phase:1,t:none,nolog,allow,ctl:ruleEngine=Off,ctl:auditEngine=Off,id:9999"<br />
</IfModule><br />
<br />
'''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.'''<br />
<br />
Step 4) Run the vhost includes script, for example if the domains username is "example":<br />
<br />
/scripts/ensure_vhost_includes –user=example<br />
<br />
==== Disable a rule for a single domain ====<br />
<br />
'''If you have ASL installed''':<br />
<br />
Method 1:<br />
<br />
Log into the ASL GUI, and click on the "ASL" tab. Then click "WAF & HIDS Rules", 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.<br />
<br />
Type in the hostname into the Text box on the left side of the options you want to exclude the rule for, then click "add".<br />
<br />
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, or a regular expression *.example.com.<br />
<br />
Note: You can use regular expressions in this field, but each end of the expression is anchored.<br />
<br />
<br />
Method 2: Run this command as root:<br />
<br />
In ASL v3.x:<br />
asl -dr RULE_ID --vhost www.example.com<br />
<br />
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:<br />
<br />
asl -dr RULE_ID --vhost www.example.com<br />
<br />
asl -dr RULE_ID --vhost ftp.example.com<br />
<br />
asl -dr RULE_ID --vhost example.com<br />
<br />
<br />
In ASL v4:<br />
asl -drv RULE_ID[,RULE_ID...] VHOST[,VHOST...]<br />
or <br />
asl --disable-rule-vhost RULE_ID[,RULE_ID...] VHOST[,VHOST...]<br />
<br />
All supplied rules will be disabled on all supplied vhosts.<br />
<br />
asl -drv 111111,222222,333333 www.example.com,ftp.example.com,example.com<br />
<br />
<br />
<br />
<br />
'''If you do not have ASL installed''' you will have to do this manually:<br />
<br />
Step 1) Edit your domains vhost.conf file (the location of this file will vary based on your control panel, contact your control panel vendor for assistance)<br />
<br />
vim vhost.conf<br />
<br />
Step 2) Add the LocationMatch for the rule to exclude. Example, ruleid 950005<br />
<LocationMatch .*><br />
<IfModule mod_security2.c><br />
SecRuleRemoveById 950005<br />
</IfModule><br />
</LocationMatch><br />
<br />
If you want to disable multiple rules:<br />
<br />
Step 2) Add the LocationMatch for the rule to exclude. Example, ruleids 950005 and 950006<br />
<LocationMatch .*><br />
<IfModule mod_security2.c><br />
SecRuleRemoveById 950005<br />
SecRuleRemoveById 950006<br />
</IfModule><br />
</LocationMatch><br />
<br />
<br />
==== Non Control Panel systems ====<br />
<br />
For nginx, or phase:1 rules rules can be disabled for a domain/FQDN by adding a custom rule before the rule you wish to disable is loaded. For example, if you wanted to disable rule 123456 for domain example.com, you would add this rule to your custom rules:<br />
<br />
SecRule REQUEST_HEADERS:Host "example.com$" "phase:1,id:91001,t:none,t:lowercase,pass,nolog,noauditlog,ctl:ruleRemovebyID=123456"<br />
<br />
This method can also be used for Apache.<br />
<br />
==== Disable a rule for all domains ====<br />
<br />
Method 1:<br />
<br />
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.<br />
<br />
Set "disabled" to yes and click update.<br />
<br />
Method 2:<br />
<br />
Use ASL utility to disable rule by ID. Example: 950005<br />
asl --disable-rule 950005<br />
<br />
Note: This requires that [[Atomic Secured Linux]] be installed.<br />
'''<br />
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:<br />
<br />
<LocationMatch .*><br />
<IfModule mod_security2.c><br />
SecRuleRemoveById 340000<br />
</IfModule><br />
</LocationMatch><br />
<br />
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.<br />
<br />
=== Per IP or network ===<br />
<br />
==== Disable Mod_security for an IP address ====<br />
<br />
In ASL, just click the "Whitelist" button.<br />
<br />
If you are not using ASL, simply add your IP address to the file:<br />
<br />
/etc/asl/whitelist<br />
<br />
And restart Apache.<br />
<br />
Note: For this rule to work, in ASL you must have the MODSEC_00_WHITELIST ruleset enabled.<br />
<br />
If you are not using ASL, then you must have the 00_asl_whitelist.conf ruleset loaded.<br />
<br />
==== Whitelist an IP ====<br />
<br />
See above, "Disable Mod_security for an IP address"<br />
<br />
==== Disable a rule by IP or network====<br />
<br />
You will need to create a custom rule, loaded after all your other rules. Lets say you wanted to exclude rule id 330039 for the network 1.2.0.0/16. You would construct a custom rule like this:<br />
<br />
<pre><br />
SecRule REMOTE_HOST "@ipmatch 1.2.0.0/16" \<br />
"id:12345,phase:2,t:none,pass,nolog,noauditlog,ctl:ruleRemovebyID=330039"<br />
</pre><br />
<br />
Note: ipmatch can also use a list, with a combination of IPs and network for example:<br />
<br />
@ipmatch 1.2.0.0/16,5.6.7.8,127.0.0.0/8<br />
<br />
Warning: If the CIDR is invalid, this may cause a segfault of the mod_security module. Check to make sure your CIDR is valid before use.<br />
<br />
=== Per application ===<br />
<br />
==== Disable modsecurity for a specific web application ====<br />
<br />
Note: this is not recommended<br />
<br />
Add a custom rule (see the section below on creating [https://www.atomicorp.com/wiki/index.php/Mod_security#Creating_custom_rules custom rules]) after all your rules have been loaded. For example, if you wanted to disable modsecurity for the application /foo/bar.cgi you would add a custom rule like this:<br />
<br />
<pre><br />
<LocationMatch /foo/bar.cgi><br />
SecRuleEngine Off<br />
<br />
</LocationMatch><br />
</pre><br />
<br />
<br />
<br />
==== Disable a rule for a specific web application ====<br />
Add a custom rule (see the section below on creating [https://www.atomicorp.com/wiki/index.php/Mod_security#Creating_custom_rules custom rules]) after all your rules have been loaded. For example, if you wanted to disable rule 950005, you would add a custom rule like this:<br />
<br />
<pre><br />
<LocationMatch /URL/path/to/application.php><br />
SecRuleRemoveById 950005<br />
<br />
</LocationMatch><br />
</pre><br />
<br />
==== Disable a rule for a single domain or FQDN ====<br />
<br />
===== For non control panel systems =====<br />
<br />
If you are using any of our GUI products, just click on the rule event, and type in the domain or hostname you want to exclude for this rule. <br />
<br />
For DIY users, you will need to create custom rules that load *before* the rule that you wish to exclude. This means you will need to add a custom rule file that loads before the rules we supply.<br />
<br />
Once you have set this up for your DIY modsecurity configuration, you will add a rule that inspects the Host: header sent by the client, which will the disable the rule(s) you wish to disable when that field is populated by that value. Keep in mind this field is completely controlled by the client, not the server. In the example below, the entire domain "example.com" is excluded for rule 123456:<br />
<br />
''SecRule REQUEST_HEADERS:Host ".example.com$" "phase:1,id:91010,t:none,t:lowercase,pass,nolog,noauditlog,ctl:ruleRemovebyID=123456"''<br />
<br />
Then restart the web server to apply this custom exclusion.<br />
<br />
===== For Plesk systems =====<br />
<br />
<br />
Step 1) Edit the virtual servers configuration for the domain for the domain<br />
<br />
Example:<br />
<br />
vim /var/www/vhosts/<DOMAINNAME>/conf/vhost.conf<br />
<br />
Step 2) Add the LocationMatch for the rule to exclude. Example, ruleid 950005<br />
<br />
<pre><br />
<LocationMatch /URL/path/to/application.php><br />
<br />
SecRuleRemoveById 950005<br />
</IfModule><br />
<br />
</pre><br />
<br />
==== Disable Mod_security rules globally for a specific application ====<br />
<br />
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.<br />
<br />
<LocationMatch /url/to/your/application><br />
<IfModule mod_security2.c><br />
SecRuleRemoveById 1234567<br />
SecRuleRemoveById 9999999<br />
</IfModule><br />
</LocationMatch><br />
<br />
Whats important to remember is that the LocationMatch variable must match the URL, not the path on the system.<br />
<br />
==== Disable Mod_security rules by domain, for a specific application, for a list of IPs ====<br />
<br />
Step 1) Edit the vhost/vhost_ssl.conf for the domain<br />
vim /var/www/vhosts/<DOMAINNAME>/conf/vhost.conf<br />
<br />
Step 2) Add the LocationMatch for the rule to exclude.<br />
<LocationMatch /foo/bar.php><br />
<IfModule mod_security2.c><br />
SecRule REMOTE_ADDR "@pmFromFile /etc/asl/whitelist" "nolog,phase:1,allow"<br />
</IfModule><br />
</LocationMatch><br />
<br />
Step 3) Add IP to /etc/asl/whitelist<br />
echo "10.11.12.13" >> /etc/asl/whitelist<br />
<br />
Or:<br />
<br />
If you want to create a special whitelist for just that application:<br />
<br />
Step 1) Edit the vhost/vhost_ssl.conf for the domain<br />
vim /var/www/vhosts/<DOMAINNAME>/conf/vhost.conf<br />
<br />
Step 2) Add the LocationMatch for the rule to exclude.<br />
<LocationMatch /foo/bar.php><br />
<IfModule mod_security2.c><br />
SecRule REMOTE_ADDR "@pmFromFile /path/to/your/custom/whitelist_for_this_application" "nolog,phase:1,allow,id:9999"<br />
</IfModule><br />
</LocationMatch><br />
<br />
'''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.'''<br />
<br />
<br />
Step 3) Create your custom whitelist and add IP to /etc/asl/whitelist<br />
echo "10.11.12.13" >> /path/to/your/custom/whitelist_for_this_application<br />
<br />
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.<br />
<br />
==== Disable rule for a specific argument for a specific application ====<br />
<br />
You can also tell modsecurity to change a rule, in some cases, without editing or forking the rule. For example, if you want to configure modsecurity to ignore a specific argument (in the argument below the argument is "foo"), for a specific application (in the example the application name is /example/application), for a specific rule (in the example below the rule if is 12345), you would create a custom rule like this:<br />
<br />
<br />
<pre><br />
SecRule REQUEST_URI "^/example/application" \<br />
"id:9999,phase:1,t:none,t:lowercase,nolog,pass,ctl:ruleRemoveTargetByID=12345;ARGS:foo"<br />
</pre><br />
<br />
As with all custom rules, this rule also needs a unique id as explained in the article above. And this type of custom rule must be loaded '''before''' the rule it modifies.<br />
<br />
Note: This does not support regular expressions for the excluded argument. At this time, they must be explicitly defined.<br />
<br />
==== Disable rule for a specific argument ====<br />
<br />
As is the example above, a rule can also be changed to exclude a specific argument, but for all applications. For example, if you want to configure modsecurity to ignore a specific argument (in the argument below the argument is "foo"), for a specific rule (in the example below the rule if is 12345), you would create a custom rule like this:<br />
<br />
<pre><br />
SecAction "phase:1,id:9999,t:none,auditlog,nolog,pass,ctl:ruleRemoveTargetById=12345;ARGS:foo"<br />
</pre><br />
<br />
As with all custom rules, this rule also needs a unique id as explained in the article above. And this type of custom rule must be loaded '''before''' the rule it modifies.<br />
<br />
Note: This does not support regular expressions for the excluded argument. At this time, they must be explicitly defined.<br />
<br />
==== Disable modsecurity for a specific argument ====<br />
<br />
As is the example above, modsecurity can also be configured to exclude a specific argument for all rules. For example, if you want to configure modsecurity to ignore a specific argument (in the argument below the argument is "foo"),you would create a custom rule like this:<br />
<br />
<pre><br />
SecAction "phase:1,id:9999,t:none,auditlog,nolog,pass,ctl:ruleRemoveTargetById=1-1000000;ARGS:foo"<br />
</pre><br />
<br />
When 1-100000 is the rule IDs you want to exclude. As with all custom rules, this rule also needs a unique id as explained in the article above. <br />
<br />
Note: This does not support regular expressions for the excluded argument. At this time, they must be explicitly defined.<br />
<br />
== Changing the action for a rule ==<br />
<br />
You can also change the default action for a rule by using the SecRuleActionById directive. <br />
<br />
=== Changing a rule to be detect only by ID===<br />
<br />
To change a rule to only detect, but not block attacks, simply change the action for the rule with the above directive. For example, to change the action for rule 12345, simply add this rule directive to your custom rules. <br />
<br />
SecRuleUpdateActionById 12345 "pass,status:200"<br />
<br />
Note 1: this directive must be added after the rule it is modifying has been loaded.<br />
<br />
Note 2: This does not work if you are using the redirect action.<br />
<br />
=== Changing a range of rules ot be detect only by ID===<br />
<br />
This is similar to the method above, however you can define a range of rule IDs. For example, if you want to disable rules 1000-2000:<br />
<br />
SecRuleUpdateActionById 1000-2000 "pass,status:200"<br />
<br />
Note 1: this directive must be added after the rule it is modifying has been loaded.<br />
<br />
Note 2: This does not work if you are using the redirect action.<br />
<br />
== Disabling POST inspection for a specific URL ==<br />
<br />
Should you want to disable inspection of a POST for a specific URL, use the format below.<br />
<br />
Assuming the URL you wanted to skip POST inspection was "upload", your exclusion rule would look like this:<br />
<br />
''SecRule REQUEST_URI "^/upload" \<br />
"phase:1,id:1234567,t:none,t:lowercase,pass,nolog,ctl:requestBodyAccess=off"''<br />
<br />
Install this rule before any of your other rules. For example, in the file /etc/httpd/modsecurity.d/00_custom_exclude.conf.<br />
<br />
== Enabling rules for only specific domains ==<br />
<br />
If you wish to disable all the rules, except for specific domains, you need to copy in the two files from the subdirectory "special" where you have the rules installed. Then create this file:<br />
<br />
/etc/asl/custom_include_domains<br />
<br />
<br />
Include the domains and/or FQDNs you want the rules to apply to. Anything not on that list will cause those rules to skip all of our rules. <br />
<br />
#File must contain exactly one domain or FQDN per line. End of line markers (both LF and CRLF) will be stripped from each phrase and any whitespace trimmed from both the beginning and the end. Empty lines and comment lines (those beginning with the # character) will be ignored.<br />
#This file does not support metacharacters. (For example, * is not supported)<br />
<br />
Example:<br />
<br />
<br />
<pre><br />
www.example.com<br />
.foo.com<br />
</pre><br />
<br />
== Disabling rules using .htaccess ==<br />
<br />
This is a new feature in modsecurity 2.7.3. This capability is available if you compile modsecurity using this option:<br />
<br />
--enable-htaccess-config<br />
<br />
From there, you will be able to disable rules using .htaccess files. The format to disable a rule via .htaccess is:<br />
<br />
SecRuleRemoveById 12345<br />
<br />
Where 12345 is the rule id.<br />
<br />
'''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 and/or this option has not been enabled. <br />
<br />
Warning: Enabling this capability will allow users to disable rules, including on compromised accounts which may cause the system to become compromised. This capability was specifically disabled by default in modsecurity to prevent this from occurring. Use this option with extreme caution!<br />
<br />
=== Specific actions available in .htaccess ===<br />
<br />
<br />
* SecAction<br />
* SecRule<br />
* SecRuleRemoveByMsg<br />
* SecRuleRemoveByTag<br />
* SecRuleRemoveById<br />
* SecRuleUpdateActionById<br />
* SecRuleUpdateTargetById<br />
* SecRuleUpdateTargetByTag<br />
* SecRuleUpdateTargetByMsg<br />
<br />
'''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.<br />
<br />
Warning: Enabling this capability in modsecurity can allow an attacker to disable modsecurity rules that you may be using to protect the entire server. We do not recommend you enable this capability on a shared server.<br />
<br />
== Customizing a rule ==<br />
<br />
If you need to customize a rule do not change the asl*conf files. These files will be overwritten by updates. <br />
<br />
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.<br />
<br />
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:<br />
<br />
If you had an original rule like this:<br />
<br />
SecRule REQUEST_URI "/foo" "t:normalisePath,id:9000,rev:1,severity:2,msg:'Atomicorp.com WAF Rules: Block /foo'"<br />
<br />
<br />
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.<br />
<br />
SecRuleRemoveById 9000000<br />
SecRule REQUEST_URI "/bar" "t:normalisePath,id:9999,rev:1,severity:2,msg:'Atomicorp.com WAF Rules: Block /foo'"<br />
<br />
'''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.'''<br />
<br />
<br />
These are the reserved ranges:<br />
<br />
* 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.<br />
* 100,000-199,999; reserved for internal use of the engine, to assign to rules that do not have explicit IDs.<br />
* 200,000-299,999; reserved for rules published at modsecurity.org.<br />
* 300,000-399,999; reserved for rules published at gotroot.com.<br />
* 400,000-419,999; unused (available for reservation).<br />
* 420,000-429,999; reserved for ScallyWhack.<br />
* 430,000-699,999; unused (available for reservation).<br />
* 700,000-799,999; reserved for Ivan Ristic.<br />
* 900,000-999,999; reserved for the Core Rules project.<br />
* 1,000,000 and above; unused (available for reservation).<br />
<br />
=== For a domain ===<br />
<br />
==== Apache ====<br />
<br />
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.<br />
<br />
==== Changing the argument separator ====<br />
<br />
If you have a web application that uses the uncommon ";" argument separator, as opposed to the widely used "&" you will want to change SecArgumentSeparator value for that application. You can do this in one of two ways:<br />
<br />
1) Globally<br />
<br />
If all your applications use the older delimiter, just change the SecArgumentSeparator in the tortix_waf.conf file. Do not change this if your applications use other delimiters.<br />
<br />
''SecArgumentSeparator ";"'' <br />
<br />
2) Per Application<br />
<br />
You can also configure this per application. For example, if your web applications URL is /foo/bar.php you can create a customer rule like this:<br />
<br />
<br />
<pre><br />
<LocationMatch /foo/bar.php><br />
SecArgumentSeparator ";"<br />
</LocationMatch><br />
</pre><br />
<br />
This will only work if modsecurity is loaded before your virtual host definitions. This is the case with most control panels, but some control panels are known to load modsecurity after vhosts are defined. In which case this will fail because Apache will not know how to process this directive (it will need modsecurity loaded to understand what this means). If you get a syntax error, that means your apache configuration is loaded modsecurity after your vhosts are defined. You will need to change your apache configuration to ensure this loading occurs before vhosts are defined.<br />
<br />
[[ASL]] will automatically configure modsecurity to load first.<br />
<br />
= Creating custom rules =<br />
<br />
== Discussion ==<br />
<br />
If you need to create your own custom rules, do not change the asl*conf files. These files will be overwritten by updates. <br />
<br />
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.<br />
<br />
== Rule Ids for custom rules ==<br />
<br />
For custom rules, '''you must create your own rule ids which must be unique'''. The id: fields contain the rule ids. For custom rules you should use the local (internal) use range (see below for the reserved id ranges). '''Do not use assigned ranges.'''<br />
<br />
These are the reserved ranges:<br />
<br />
* 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.<br />
* 100,000-199,999; reserved for internal use of the engine, to assign to rules that do not have explicit IDs. (deprecated, all rules require assigned ids in 2.7.x and up)<br />
* 200,000-299,999; reserved for rules published at modsecurity.org.<br />
* 300,000-399,999; reserved for rules published by atomicorp.com<br />
* 400,000-419,999; unused (available for reservation).<br />
* 420,000-429,999; reserved for ScallyWhack.<br />
* 430,000-699,999; unused (available for reservation).<br />
* 700,000-799,999; reserved for Ivan Ristic.<br />
* 900,000-999,999; reserved for the Core Rules project.<br />
* 1,000,000 and above; unused (available for reservation).<br />
<br />
== Installing custom rules ==<br />
<br />
<br />
=== Linux ===<br />
<br />
==== Apache ====<br />
<br />
'''Step 1) Create your custom rules directory:'''<br />
<br />
''mkdir /etc/httpd/modsecurity.custom.d''<br />
<br />
'''Step 2) Create a configuration file for your custom rules in /etc/httpd/conf.d directory. For example:'''<br />
<br />
Create the file 01_modsecurity.conf and add this line to it:<br />
<br />
''Include modsecurity.custom.d/[https://www.atomicorp.com/examples/99_zzz_custom.conf 99_zzz_custom.conf]''<br />
<br />
You can download an example file from the URL below that will do this:<br />
<br />
[https://www.atomicorp.com/examples/01_modsecurity.conf 01_modsecurity.conf]<br />
<br />
And add 01_modsecurity.conf to this directory:<br />
<br />
/etc/httpd/conf.d<br />
<br />
If you have wget installed on your system, the following commands will do this automatically for you:<br />
''<br />
<br />
cd /etc/httpd/conf.d<br />
<br />
wget https://www.atomicorp.com/examples/01_modsecurity.conf''<br />
<br />
Note: 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. Please contact your control panel vendor for assistance.<br />
<br />
'''Step 3) Install your custom rules in the /etc/httpd/modsecurity.custom.d directory'''<br />
<br />
''cd /etc/httpd/modsecurity.custom.d''<br />
<br />
and edit the file 99_zzz_custom.conf and put in your custom rules.<br />
<br />
You can also download an example custom rule file by running these commands:<br />
<br />
''cd /etc/httpd/modsecurity.custom.d<br />
<br />
wget https://www.atomicorp.com/examples/99_zzz_custom.conf''<br />
<br />
'''Step 4) Test your apache configuration'''<br />
<br />
''service httpd configtest''<br />
<br />
If you have any errors, do not restart apache. You will need to correct these errors or apache will not start.<br />
<br />
'''Step 5) If your test was successful, restart apache.'''<br />
<br />
''service httpd restart''<br />
<br />
Our professional services group would be happy to help you with your custom rules needs, including developing the rules for you. If your request is something that we can safely include in the rules for all our customers, we're generally able to develop these new rules for free. Please contact us to discuss your rules needs.<br />
<br />
=== Windows ===<br />
<br />
==== IIS ====<br />
<br />
'''Step 1) Modify your modsecurity configuration file on windows and add this line to the end of your configuration. For example:'''<br />
<br />
''Include [https://www.atomicorp.com/examples/99_zzz_custom.conf 99_zzz_custom.conf]''<br />
<br />
'''Step 2) Edit the file 99_zzz_custom.conf and save it in the same directory as your modsecurity config file'''<br />
<br />
'''Step 3)Restart IIS'''<br />
<br />
<br />
Our professional services group would be happy to help you with your custom rules needs, including developing the rules for you. If your request is something that we can safely include in the rules for all our customers, we're generally able to develop these new rules for free. Please contact us to discuss your rules needs.<br />
<br />
== Modifying a rule ==<br />
<br />
If you want to modify the internal logic of a rule, you will want to "fork" or copy that rule into a custom rule. Do not modify the actual rules provided by us, your modifications will be overwritten with the next update.<br />
<br />
'''Step 1: Copy the rule you want to modify into your custom rules file.'''<br />
<br />
Copy the rule in its entirety into your custom rule file. For example, if you wanted to modify rule 390707, you would copy the entire rule into your custom rules file. For example:<br />
<br />
<pre><br />
# Restrict the maximum number of arguments in a request<br />
SecRule &ARGS "@gt 1000" \<br />
"chain,phase:2,t:none,log,auditlog,deny,status:403,msg:'Atomicorp.com WAF Rules: Too many arguments in request (max set to 1000, increase as necessary for your system)',id:'390707',severity:'4',rev:'8'"<br />
SecRule REQUEST_URI "!((?:^/(?:imaclean|massdelete)/)|^/cgi-bin/dada/mail\.cgi$|^/index\.php/mageworx/customoptions_options|^/za/|^/back-?office/|^/moderate\.php|^/backend/configdomains\.php|\.do$|^/admin[a-z0-9]+?/index\.php\?controller=adminmodules)" "t:none,t:lowercase"<br />
</pre><br />
<br />
'''Step 2: Change the rule id.''' <br />
<br />
This is absolutely required. No two rules can have the same ID. See this article for chosing a custom rule id: https://wiki.atomicorp.com/wiki/index.php/Mod_security#Rule_Ids_for_custom_rules<br />
<br />
For example:<br />
<br />
<pre><br />
# Restrict the maximum number of arguments in a request<br />
SecRule &ARGS "@gt 1000" \<br />
"chain,phase:2,t:none,log,auditlog,deny,status:403,msg:'Atomicorp.com WAF Rules: Too many arguments in request (max set to 1000, increase as necessary for your system)',id:'12345678',severity:'4',rev:'8'"<br />
SecRule REQUEST_URI "!((?:^/(?:imaclean|massdelete)/)|^/cgi-bin/dada/mail\.cgi$|^/index\.php/mageworx/customoptions_options|^/za/|^/back-?office/|^/moderate\.php|^/backend/configdomains\.php|\.do$|^/admin[a-z0-9]+?/index\.php\?controller=adminmodules)" "t:none,t:lowercase"<br />
</pre><br />
<br />
'''Step 3: Disable the original rule'''<br />
<br />
If you want your custom rule to be global, that is your modification applies to the entire system, then you will want to disable the original rule per this article:<br />
<br />
https://wiki.atomicorp.com/wiki/index.php/Mod_security#Disable_a_rule_for_all_domains<br />
<br />
If you want to disable the rule for a single application, see this article:<br />
<br />
https://wiki.atomicorp.com/wiki/index.php/Mod_security#Disable_a_rule_for_a_specific_web_application<br />
<br />
If you want to disable the rule for a specific IP or network:<br />
<br />
https://wiki.atomicorp.com/wiki/index.php/Mod_security#Disable_a_rule_by_IP_or_network<br />
<br />
If you want to disable the rule for a single domain:<br />
<br />
https://wiki.atomicorp.com/wiki/index.php/Mod_security#Disable_a_rule_for_a_single_domain<br />
<br />
'''Step 4: Set the scope of the rule.'''<br />
<br />
If you havent disabled the original rule globally, or for one or more domains, then you will need to set the scope of your custom rule. To limit your modification to a specific application, place your custom rule inside <LocationMatch> tags. For example:<br />
<br />
<pre><br />
<br />
<LocationMatch /url/to/your/custom/application><br />
# Restrict the maximum number of arguments in a request<br />
SecRule &ARGS "@gt 2048" \<br />
"chain,phase:2,t:none,log,auditlog,deny,status:403,msg:'Atomicorp.com WAF Rules: Too many arguments in request (max set to 1000, increase as necessary for your system)',id:'12345678',severity:'4',rev:'8'"<br />
SecRule REQUEST_URI "!((?:^/(?:imaclean|massdelete)/)|^/cgi-bin/dada/mail\.cgi$|^/index\.php/mageworx/customoptions_options|^/za/|^/back-?office/|^/moderate\.php|^/backend/configdomains\.php|\.do$|^/admin[a-z0-9]+?/index\.php\?controller=adminmodules)" "t:none,t:lowercase"<br />
</LocationMatch><br />
<br />
</pre><br />
<br />
= Configuring and Setting up mod_security =<br />
'''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.'''<br />
<br />
To setup and configured modsecurity, please see the [[Atomic_ModSecurity_Rules]] wiki page.</div>Mshinnhttps://wiki.atomicorp.com/wiki/index.php/Mod_securityMod security2022-09-16T19:23:38Z<p>Mshinn: /* Non Control Panel systems */</p>
<hr />
<div>=Installing modsecurity Rules =<br />
<br />
Please see this article:<br />
<br />
[[Atomic ModSecurity Rules]]<br />
<br />
=Tuning and managing modsecurity Rules=<br />
<br />
== Disabling Rules ==<br />
<br />
=== Important Notes ===<br />
<br />
==== phase:1 rules ====<br />
<br />
Note: ASL users should disable rules from the rule manager. There is no need to create custom rules, apache configuration files or other customizations when using ASL, and ASL supports disabling any rule on both a global and per domain basis.<br />
<br />
For non-ASL users, LocationMatch and Location do not work for phase:1 rules. Location and LocationMatch are not available in apache until phase:2. If you need to disable a phase:1 rule, use [[ASL]] which can disable phase:1 rules on a per domain and global basis.<br />
<br />
If you are not using [[ASL]], and need to disable a phase:1 rule, you will need to create a custom rule to do this. This following is an example of a custom rule to do this for rule 123456.<br />
<br />
''SecRule REQUEST_HEADERS:Host "example.com$" "phase:1,id:91001,t:none,t:lowercase,pass,nolog,noauditlog,ctl:ruleRemovebyID=123456"''<br />
<br />
In the example above, "example.com" is the domain to exclude this rule. This custom rule must be loaded before the rule you want to disable. This custom rule *must be loaded before the rule you wish to disable*.<br />
<br />
If you do not know how to create this kind of custom rule, please contact support and we'll put a quote together to help develop these custom rules for you.<br />
<br />
=== Global ===<br />
<br />
==== Disabling Mod_Security Globally ====<br />
<br />
If you are using ASL, just change this setting:<br />
<br />
https://www.atomicorp.com/wiki/index.php/ASL_WAF#MODSEC_ENABLED<br />
<br />
If you are not using ASL, you will need to do this manually:<br />
<br />
Step 1) Disable config file<br />
mv /etc/httpd/conf.d/00_mod_security.conf /etc/httpd/conf.d/00_mod_security.conf.disabled<br />
<br />
Step 2) Restart Apache<br />
service httpd restart<br />
<br />
==== Disable Mod_security on a global URL ====<br />
<br />
Step 1) Create a global exclude file<br />
<br />
vim /etc/httpd/modsecurity.d/00_custom_exclude.conf<br />
<br />
Step 2) Add the LocationMatch for the url to exclude. Example: /server.php<br />
<br />
<LocationMatch /server.php><br />
<IfModule mod_security2.c><br />
SecRuleEngine Off <br />
</IfModule><br />
</LocationMatch><br />
<br />
Step 3) Restart apache<br />
<br />
service httpd restart<br />
<br />
<br />
<br />
Step 3) Restart apache<br />
<br />
service httpd restart<br />
<br />
==== Set a URL to alert only ====<br />
<br />
Step 1) Create a global exclude file<br />
<br />
vim /etc/httpd/modsecurity.d/00000_custom_exclude.conf<br />
<br />
Step 2) Add a custom rule<br />
<br />
In this example the URL is: /foo/bar<br />
<br />
Add this line to the file you created in Step 1:<br />
<br />
SecRule REQUEST_URI "/foo/bar" "phase:1,id:1000000,t:none,t:lowercase,pass,nolog,noauditlog,ctl:ruleEngine=DetectionOnly"<br />
<br />
Important Note: See the section customizing rules below to pick a unique id for your rule above. Duplicate rule ids will cause the rule to not load.<br />
<br />
Step 3) Restart apache<br />
<br />
service httpd restart<br />
<br />
=== Per domain ===<br />
<br />
==== Disabling Mod_security per domain ====<br />
<br />
Note: If you only want to disable a specific rule for a domain, please see this article:<br />
<br />
https://wiki.atomicorp.com/wiki/index.php/Mod_security#Per_application<br />
<br />
===== For Plesk Based Systems =====<br />
<br />
For Plesk and similar systems you can also disable modsecurity in the Apache configuration.<br />
<br />
Step 1) Edit the vhost/vhost_ssl.conf for the domain<br />
vim /var/www/vhosts/<DOMAINNAME>/conf/vhost.conf<br />
<br />
Step 2) Add the following<br />
<IfModule mod_security2.c><br />
SecRuleEngine Off<br />
</IfModule><br />
<br />
Then restart apache, if you are using Plesk then you will also need follow steps 3 and 4.<br />
<br />
Step 3) Add vhost.conf to domain config <br />
<br />
Plesk 9:<br />
/usr/local/psa/admin/bin/websrvmng -a<br />
<br />
Plesk 10/11:<br />
/usr/local/psa/admin/bin/httpdmng --reconfigure-domain <domain_name><br />
<br />
Step 4) Restart Apache<br />
service httpd restart<br />
<br />
===== For Cpanel based systems with EasyApache 4 =====<br />
<br />
For full information about include file path expectations, see the official cPanel documentation at [https://documentation.cpanel.net/display/EA4/Modify+Apache+Virtual+Hosts+with+Include+Files Modify Apache Virtual Hosts with Include Files]<br />
<br />
Step 1) Create the following paths, replacing <user> and <domain> with the correct values for your needs:<br />
<br />
* mkdir -p /etc/apache2/conf.d/userdata/ssl/2_4/<user>/<domain><br />
* mkdir -p /etc/apache2/conf.d/userdata/std/2_4/<user>/<domain><br />
<br />
Step 2) In each of the above paths, create a file named 'vhost.conf'<br />
<br />
Step 3) Add in the lines below to this file:<br />
<br />
<pre><br />
<IfModule mod_security2.c><br />
SecRuleEngine Off<br />
</IfModule><br />
</pre><br />
<br />
Step 4) After any addition, modification or removal of userdata files, cPanel requires both of the following scripts to be run:<br />
<br />
* /usr/local/cpanel/scripts/rebuildhttpdconf<br />
* /usr/local/cpanel/scripts/restartsrv_httpd<br />
<br />
<br />
===== For Cpanel based systems with EasyApache 3 =====<br />
<br />
Step 1) Create the custom modsecurity configuration directory for the domain<br />
<br />
For example, if the domain is example.com, you would need to create this directory:<br />
<br />
<br />
mkdir /usr/local/apache/conf/userdata/std/2/username/example.com<br />
<br />
Step 2) Create the file vhost.conf in this directory<br />
<br />
cd /usr/local/apache/conf/userdata/std/2/username/example.com<br />
<br />
touch vhost.conf<br />
<br />
Step 3) Add in the lines below to this file:<br />
<br />
<pre><br />
<IfModule mod_security2.c><br />
SecRuleEngine Off<br />
</IfModule><br />
</pre><br />
<br />
Step 4) Run the vhost includes script, for example if the domains username is "example":<br />
<br />
/scripts/ensure_vhost_includes --user=example<br />
<br />
<br />
<br />
==== Disabling Mod_security per domain for an IP address ====<br />
<br />
===== For Plesk based systems =====<br />
<br />
For Plesk and similar systems you can also disable modsecurity in the Apache configuration.<br />
<br />
Step 1) Edit the vhost/vhost_ssl.conf for the domain<br />
vim /var/www/vhosts/<DOMAINNAME>/conf/vhost.conf<br />
<br />
Step 2) Add the following<br />
<IfModule mod_security2.c><br />
SecRule REMOTE_ADDR "^1.2.3.4$" "phase:1,t:none,nolog,allow,ctl:ruleEngine=Off,ctl:auditEngine=Off,id:9999"<br />
</IfModule><br />
<br />
'''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.'''<br />
<br />
Then restart apache, if you are using Plesk then you will also need follow steps 3 and 4.<br />
<br />
Step 3) Add vhost.conf to domain config <br />
<br />
Plesk 9:<br />
/usr/local/psa/admin/bin/websrvmng -a<br />
<br />
Plesk 10/11:<br />
/usr/local/psa/admin/bin/httpdmng --reconfigure-domain <domain_name><br />
<br />
Step 4) Restart Apache<br />
service httpd restart<br />
<br />
===== For cpanel based systems =====<br />
<br />
Step 1) Create the custom modsecurity configuration directory for the domain<br />
<br />
For example, if the domain is example.com, you would need to create this directory:<br />
<br />
mkdir /usr/local/apache/conf/userdata/std/2/username/example.com<br />
<br />
Step 2) Create the file vhost.conf in this directory<br />
<br />
cd /usr/local/apache/conf/userdata/std/2/username/example.com<br />
<br />
touch vhost.conf<br />
<br />
Step 3) Add in the lines below to this file:<br />
<br />
<IfModule mod_security2.c><br />
SecRule REMOTE_ADDR "^1.2.3.4$" "phase:1,t:none,nolog,allow,ctl:ruleEngine=Off,ctl:auditEngine=Off,id:9999"<br />
</IfModule><br />
<br />
'''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.'''<br />
<br />
Step 4) Run the vhost includes script, for example if the domains username is "example":<br />
<br />
/scripts/ensure_vhost_includes –user=example<br />
<br />
==== Disable a rule for a single domain ====<br />
<br />
'''If you have ASL installed''':<br />
<br />
Method 1:<br />
<br />
Log into the ASL GUI, and click on the "ASL" tab. Then click "WAF & HIDS Rules", 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.<br />
<br />
Type in the hostname into the Text box on the left side of the options you want to exclude the rule for, then click "add".<br />
<br />
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, or a regular expression *.example.com.<br />
<br />
Note: You can use regular expressions in this field, but each end of the expression is anchored.<br />
<br />
<br />
Method 2: Run this command as root:<br />
<br />
In ASL v3.x:<br />
asl -dr RULE_ID --vhost www.example.com<br />
<br />
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:<br />
<br />
asl -dr RULE_ID --vhost www.example.com<br />
<br />
asl -dr RULE_ID --vhost ftp.example.com<br />
<br />
asl -dr RULE_ID --vhost example.com<br />
<br />
<br />
In ASL v4:<br />
asl -drv RULE_ID[,RULE_ID...] VHOST[,VHOST...]<br />
or <br />
asl --disable-rule-vhost RULE_ID[,RULE_ID...] VHOST[,VHOST...]<br />
<br />
All supplied rules will be disabled on all supplied vhosts.<br />
<br />
asl -drv 111111,222222,333333 www.example.com,ftp.example.com,example.com<br />
<br />
<br />
<br />
<br />
'''If you do not have ASL installed''' you will have to do this manually:<br />
<br />
Step 1) Edit your domains vhost.conf file (the location of this file will vary based on your control panel, contact your control panel vendor for assistance)<br />
<br />
vim vhost.conf<br />
<br />
Step 2) Add the LocationMatch for the rule to exclude. Example, ruleid 950005<br />
<LocationMatch .*><br />
<IfModule mod_security2.c><br />
SecRuleRemoveById 950005<br />
</IfModule><br />
</LocationMatch><br />
<br />
If you want to disable multiple rules:<br />
<br />
Step 2) Add the LocationMatch for the rule to exclude. Example, ruleids 950005 and 950006<br />
<LocationMatch .*><br />
<IfModule mod_security2.c><br />
SecRuleRemoveById 950005<br />
SecRuleRemoveById 950006<br />
</IfModule><br />
</LocationMatch><br />
<br />
==== Disable a rule for all domains ====<br />
<br />
Method 1:<br />
<br />
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.<br />
<br />
Set "disabled" to yes and click update.<br />
<br />
Method 2:<br />
<br />
Use ASL utility to disable rule by ID. Example: 950005<br />
asl --disable-rule 950005<br />
<br />
Note: This requires that [[Atomic Secured Linux]] be installed.<br />
'''<br />
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:<br />
<br />
<LocationMatch .*><br />
<IfModule mod_security2.c><br />
SecRuleRemoveById 340000<br />
</IfModule><br />
</LocationMatch><br />
<br />
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.<br />
<br />
=== Per IP or network ===<br />
<br />
==== Disable Mod_security for an IP address ====<br />
<br />
In ASL, just click the "Whitelist" button.<br />
<br />
If you are not using ASL, simply add your IP address to the file:<br />
<br />
/etc/asl/whitelist<br />
<br />
And restart Apache.<br />
<br />
Note: For this rule to work, in ASL you must have the MODSEC_00_WHITELIST ruleset enabled.<br />
<br />
If you are not using ASL, then you must have the 00_asl_whitelist.conf ruleset loaded.<br />
<br />
==== Whitelist an IP ====<br />
<br />
See above, "Disable Mod_security for an IP address"<br />
<br />
==== Disable a rule by IP or network====<br />
<br />
You will need to create a custom rule, loaded after all your other rules. Lets say you wanted to exclude rule id 330039 for the network 1.2.0.0/16. You would construct a custom rule like this:<br />
<br />
<pre><br />
SecRule REMOTE_HOST "@ipmatch 1.2.0.0/16" \<br />
"id:12345,phase:2,t:none,pass,nolog,noauditlog,ctl:ruleRemovebyID=330039"<br />
</pre><br />
<br />
Note: ipmatch can also use a list, with a combination of IPs and network for example:<br />
<br />
@ipmatch 1.2.0.0/16,5.6.7.8,127.0.0.0/8<br />
<br />
Warning: If the CIDR is invalid, this may cause a segfault of the mod_security module. Check to make sure your CIDR is valid before use.<br />
<br />
=== Per application ===<br />
<br />
==== Disable modsecurity for a specific web application ====<br />
<br />
Note: this is not recommended<br />
<br />
Add a custom rule (see the section below on creating [https://www.atomicorp.com/wiki/index.php/Mod_security#Creating_custom_rules custom rules]) after all your rules have been loaded. For example, if you wanted to disable modsecurity for the application /foo/bar.cgi you would add a custom rule like this:<br />
<br />
<pre><br />
<LocationMatch /foo/bar.cgi><br />
SecRuleEngine Off<br />
<br />
</LocationMatch><br />
</pre><br />
<br />
<br />
<br />
==== Disable a rule for a specific web application ====<br />
Add a custom rule (see the section below on creating [https://www.atomicorp.com/wiki/index.php/Mod_security#Creating_custom_rules custom rules]) after all your rules have been loaded. For example, if you wanted to disable rule 950005, you would add a custom rule like this:<br />
<br />
<pre><br />
<LocationMatch /URL/path/to/application.php><br />
SecRuleRemoveById 950005<br />
<br />
</LocationMatch><br />
</pre><br />
<br />
==== Disable a rule for a single domain or FQDN ====<br />
<br />
===== For non control panel systems =====<br />
<br />
If you are using any of our GUI products, just click on the rule event, and type in the domain or hostname you want to exclude for this rule. <br />
<br />
For DIY users, you will need to create custom rules that load *before* the rule that you wish to exclude. This means you will need to add a custom rule file that loads before the rules we supply.<br />
<br />
Once you have set this up for your DIY modsecurity configuration, you will add a rule that inspects the Host: header sent by the client, which will the disable the rule(s) you wish to disable when that field is populated by that value. Keep in mind this field is completely controlled by the client, not the server. In the example below, the entire domain "example.com" is excluded for rule 123456:<br />
<br />
''SecRule REQUEST_HEADERS:Host ".example.com$" "phase:1,id:91010,t:none,t:lowercase,pass,nolog,noauditlog,ctl:ruleRemovebyID=123456"''<br />
<br />
Then restart the web server to apply this custom exclusion.<br />
<br />
===== For Plesk systems =====<br />
<br />
<br />
Step 1) Edit the virtual servers configuration for the domain for the domain<br />
<br />
Example:<br />
<br />
vim /var/www/vhosts/<DOMAINNAME>/conf/vhost.conf<br />
<br />
Step 2) Add the LocationMatch for the rule to exclude. Example, ruleid 950005<br />
<br />
<pre><br />
<LocationMatch /URL/path/to/application.php><br />
<br />
SecRuleRemoveById 950005<br />
</IfModule><br />
<br />
</pre><br />
<br />
==== Disable Mod_security rules globally for a specific application ====<br />
<br />
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.<br />
<br />
<LocationMatch /url/to/your/application><br />
<IfModule mod_security2.c><br />
SecRuleRemoveById 1234567<br />
SecRuleRemoveById 9999999<br />
</IfModule><br />
</LocationMatch><br />
<br />
Whats important to remember is that the LocationMatch variable must match the URL, not the path on the system.<br />
<br />
==== Disable Mod_security rules by domain, for a specific application, for a list of IPs ====<br />
<br />
Step 1) Edit the vhost/vhost_ssl.conf for the domain<br />
vim /var/www/vhosts/<DOMAINNAME>/conf/vhost.conf<br />
<br />
Step 2) Add the LocationMatch for the rule to exclude.<br />
<LocationMatch /foo/bar.php><br />
<IfModule mod_security2.c><br />
SecRule REMOTE_ADDR "@pmFromFile /etc/asl/whitelist" "nolog,phase:1,allow"<br />
</IfModule><br />
</LocationMatch><br />
<br />
Step 3) Add IP to /etc/asl/whitelist<br />
echo "10.11.12.13" >> /etc/asl/whitelist<br />
<br />
Or:<br />
<br />
If you want to create a special whitelist for just that application:<br />
<br />
Step 1) Edit the vhost/vhost_ssl.conf for the domain<br />
vim /var/www/vhosts/<DOMAINNAME>/conf/vhost.conf<br />
<br />
Step 2) Add the LocationMatch for the rule to exclude.<br />
<LocationMatch /foo/bar.php><br />
<IfModule mod_security2.c><br />
SecRule REMOTE_ADDR "@pmFromFile /path/to/your/custom/whitelist_for_this_application" "nolog,phase:1,allow,id:9999"<br />
</IfModule><br />
</LocationMatch><br />
<br />
'''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.'''<br />
<br />
<br />
Step 3) Create your custom whitelist and add IP to /etc/asl/whitelist<br />
echo "10.11.12.13" >> /path/to/your/custom/whitelist_for_this_application<br />
<br />
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.<br />
<br />
==== Disable rule for a specific argument for a specific application ====<br />
<br />
You can also tell modsecurity to change a rule, in some cases, without editing or forking the rule. For example, if you want to configure modsecurity to ignore a specific argument (in the argument below the argument is "foo"), for a specific application (in the example the application name is /example/application), for a specific rule (in the example below the rule if is 12345), you would create a custom rule like this:<br />
<br />
<br />
<pre><br />
SecRule REQUEST_URI "^/example/application" \<br />
"id:9999,phase:1,t:none,t:lowercase,nolog,pass,ctl:ruleRemoveTargetByID=12345;ARGS:foo"<br />
</pre><br />
<br />
As with all custom rules, this rule also needs a unique id as explained in the article above. And this type of custom rule must be loaded '''before''' the rule it modifies.<br />
<br />
Note: This does not support regular expressions for the excluded argument. At this time, they must be explicitly defined.<br />
<br />
==== Disable rule for a specific argument ====<br />
<br />
As is the example above, a rule can also be changed to exclude a specific argument, but for all applications. For example, if you want to configure modsecurity to ignore a specific argument (in the argument below the argument is "foo"), for a specific rule (in the example below the rule if is 12345), you would create a custom rule like this:<br />
<br />
<pre><br />
SecAction "phase:1,id:9999,t:none,auditlog,nolog,pass,ctl:ruleRemoveTargetById=12345;ARGS:foo"<br />
</pre><br />
<br />
As with all custom rules, this rule also needs a unique id as explained in the article above. And this type of custom rule must be loaded '''before''' the rule it modifies.<br />
<br />
Note: This does not support regular expressions for the excluded argument. At this time, they must be explicitly defined.<br />
<br />
==== Disable modsecurity for a specific argument ====<br />
<br />
As is the example above, modsecurity can also be configured to exclude a specific argument for all rules. For example, if you want to configure modsecurity to ignore a specific argument (in the argument below the argument is "foo"),you would create a custom rule like this:<br />
<br />
<pre><br />
SecAction "phase:1,id:9999,t:none,auditlog,nolog,pass,ctl:ruleRemoveTargetById=1-1000000;ARGS:foo"<br />
</pre><br />
<br />
When 1-100000 is the rule IDs you want to exclude. As with all custom rules, this rule also needs a unique id as explained in the article above. <br />
<br />
Note: This does not support regular expressions for the excluded argument. At this time, they must be explicitly defined.<br />
<br />
== Changing the action for a rule ==<br />
<br />
You can also change the default action for a rule by using the SecRuleActionById directive. <br />
<br />
=== Changing a rule to be detect only by ID===<br />
<br />
To change a rule to only detect, but not block attacks, simply change the action for the rule with the above directive. For example, to change the action for rule 12345, simply add this rule directive to your custom rules. <br />
<br />
SecRuleUpdateActionById 12345 "pass,status:200"<br />
<br />
Note 1: this directive must be added after the rule it is modifying has been loaded.<br />
<br />
Note 2: This does not work if you are using the redirect action.<br />
<br />
=== Changing a range of rules ot be detect only by ID===<br />
<br />
This is similar to the method above, however you can define a range of rule IDs. For example, if you want to disable rules 1000-2000:<br />
<br />
SecRuleUpdateActionById 1000-2000 "pass,status:200"<br />
<br />
Note 1: this directive must be added after the rule it is modifying has been loaded.<br />
<br />
Note 2: This does not work if you are using the redirect action.<br />
<br />
== Disabling POST inspection for a specific URL ==<br />
<br />
Should you want to disable inspection of a POST for a specific URL, use the format below.<br />
<br />
Assuming the URL you wanted to skip POST inspection was "upload", your exclusion rule would look like this:<br />
<br />
''SecRule REQUEST_URI "^/upload" \<br />
"phase:1,id:1234567,t:none,t:lowercase,pass,nolog,ctl:requestBodyAccess=off"''<br />
<br />
Install this rule before any of your other rules. For example, in the file /etc/httpd/modsecurity.d/00_custom_exclude.conf.<br />
<br />
== Enabling rules for only specific domains ==<br />
<br />
If you wish to disable all the rules, except for specific domains, you need to copy in the two files from the subdirectory "special" where you have the rules installed. Then create this file:<br />
<br />
/etc/asl/custom_include_domains<br />
<br />
<br />
Include the domains and/or FQDNs you want the rules to apply to. Anything not on that list will cause those rules to skip all of our rules. <br />
<br />
#File must contain exactly one domain or FQDN per line. End of line markers (both LF and CRLF) will be stripped from each phrase and any whitespace trimmed from both the beginning and the end. Empty lines and comment lines (those beginning with the # character) will be ignored.<br />
#This file does not support metacharacters. (For example, * is not supported)<br />
<br />
Example:<br />
<br />
<br />
<pre><br />
www.example.com<br />
.foo.com<br />
</pre><br />
<br />
== Disabling rules using .htaccess ==<br />
<br />
This is a new feature in modsecurity 2.7.3. This capability is available if you compile modsecurity using this option:<br />
<br />
--enable-htaccess-config<br />
<br />
From there, you will be able to disable rules using .htaccess files. The format to disable a rule via .htaccess is:<br />
<br />
SecRuleRemoveById 12345<br />
<br />
Where 12345 is the rule id.<br />
<br />
'''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 and/or this option has not been enabled. <br />
<br />
Warning: Enabling this capability will allow users to disable rules, including on compromised accounts which may cause the system to become compromised. This capability was specifically disabled by default in modsecurity to prevent this from occurring. Use this option with extreme caution!<br />
<br />
=== Specific actions available in .htaccess ===<br />
<br />
<br />
* SecAction<br />
* SecRule<br />
* SecRuleRemoveByMsg<br />
* SecRuleRemoveByTag<br />
* SecRuleRemoveById<br />
* SecRuleUpdateActionById<br />
* SecRuleUpdateTargetById<br />
* SecRuleUpdateTargetByTag<br />
* SecRuleUpdateTargetByMsg<br />
<br />
'''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.<br />
<br />
Warning: Enabling this capability in modsecurity can allow an attacker to disable modsecurity rules that you may be using to protect the entire server. We do not recommend you enable this capability on a shared server.<br />
<br />
== Customizing a rule ==<br />
<br />
If you need to customize a rule do not change the asl*conf files. These files will be overwritten by updates. <br />
<br />
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.<br />
<br />
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:<br />
<br />
If you had an original rule like this:<br />
<br />
SecRule REQUEST_URI "/foo" "t:normalisePath,id:9000,rev:1,severity:2,msg:'Atomicorp.com WAF Rules: Block /foo'"<br />
<br />
<br />
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.<br />
<br />
SecRuleRemoveById 9000000<br />
SecRule REQUEST_URI "/bar" "t:normalisePath,id:9999,rev:1,severity:2,msg:'Atomicorp.com WAF Rules: Block /foo'"<br />
<br />
'''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.'''<br />
<br />
<br />
These are the reserved ranges:<br />
<br />
* 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.<br />
* 100,000-199,999; reserved for internal use of the engine, to assign to rules that do not have explicit IDs.<br />
* 200,000-299,999; reserved for rules published at modsecurity.org.<br />
* 300,000-399,999; reserved for rules published at gotroot.com.<br />
* 400,000-419,999; unused (available for reservation).<br />
* 420,000-429,999; reserved for ScallyWhack.<br />
* 430,000-699,999; unused (available for reservation).<br />
* 700,000-799,999; reserved for Ivan Ristic.<br />
* 900,000-999,999; reserved for the Core Rules project.<br />
* 1,000,000 and above; unused (available for reservation).<br />
<br />
=== For a domain ===<br />
<br />
==== Apache ====<br />
<br />
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.<br />
<br />
==== Changing the argument separator ====<br />
<br />
If you have a web application that uses the uncommon ";" argument separator, as opposed to the widely used "&" you will want to change SecArgumentSeparator value for that application. You can do this in one of two ways:<br />
<br />
1) Globally<br />
<br />
If all your applications use the older delimiter, just change the SecArgumentSeparator in the tortix_waf.conf file. Do not change this if your applications use other delimiters.<br />
<br />
''SecArgumentSeparator ";"'' <br />
<br />
2) Per Application<br />
<br />
You can also configure this per application. For example, if your web applications URL is /foo/bar.php you can create a customer rule like this:<br />
<br />
<br />
<pre><br />
<LocationMatch /foo/bar.php><br />
SecArgumentSeparator ";"<br />
</LocationMatch><br />
</pre><br />
<br />
This will only work if modsecurity is loaded before your virtual host definitions. This is the case with most control panels, but some control panels are known to load modsecurity after vhosts are defined. In which case this will fail because Apache will not know how to process this directive (it will need modsecurity loaded to understand what this means). If you get a syntax error, that means your apache configuration is loaded modsecurity after your vhosts are defined. You will need to change your apache configuration to ensure this loading occurs before vhosts are defined.<br />
<br />
[[ASL]] will automatically configure modsecurity to load first.<br />
<br />
= Creating custom rules =<br />
<br />
== Discussion ==<br />
<br />
If you need to create your own custom rules, do not change the asl*conf files. These files will be overwritten by updates. <br />
<br />
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.<br />
<br />
== Rule Ids for custom rules ==<br />
<br />
For custom rules, '''you must create your own rule ids which must be unique'''. The id: fields contain the rule ids. For custom rules you should use the local (internal) use range (see below for the reserved id ranges). '''Do not use assigned ranges.'''<br />
<br />
These are the reserved ranges:<br />
<br />
* 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.<br />
* 100,000-199,999; reserved for internal use of the engine, to assign to rules that do not have explicit IDs. (deprecated, all rules require assigned ids in 2.7.x and up)<br />
* 200,000-299,999; reserved for rules published at modsecurity.org.<br />
* 300,000-399,999; reserved for rules published by atomicorp.com<br />
* 400,000-419,999; unused (available for reservation).<br />
* 420,000-429,999; reserved for ScallyWhack.<br />
* 430,000-699,999; unused (available for reservation).<br />
* 700,000-799,999; reserved for Ivan Ristic.<br />
* 900,000-999,999; reserved for the Core Rules project.<br />
* 1,000,000 and above; unused (available for reservation).<br />
<br />
== Installing custom rules ==<br />
<br />
<br />
=== Linux ===<br />
<br />
==== Apache ====<br />
<br />
'''Step 1) Create your custom rules directory:'''<br />
<br />
''mkdir /etc/httpd/modsecurity.custom.d''<br />
<br />
'''Step 2) Create a configuration file for your custom rules in /etc/httpd/conf.d directory. For example:'''<br />
<br />
Create the file 01_modsecurity.conf and add this line to it:<br />
<br />
''Include modsecurity.custom.d/[https://www.atomicorp.com/examples/99_zzz_custom.conf 99_zzz_custom.conf]''<br />
<br />
You can download an example file from the URL below that will do this:<br />
<br />
[https://www.atomicorp.com/examples/01_modsecurity.conf 01_modsecurity.conf]<br />
<br />
And add 01_modsecurity.conf to this directory:<br />
<br />
/etc/httpd/conf.d<br />
<br />
If you have wget installed on your system, the following commands will do this automatically for you:<br />
''<br />
<br />
cd /etc/httpd/conf.d<br />
<br />
wget https://www.atomicorp.com/examples/01_modsecurity.conf''<br />
<br />
Note: 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. Please contact your control panel vendor for assistance.<br />
<br />
'''Step 3) Install your custom rules in the /etc/httpd/modsecurity.custom.d directory'''<br />
<br />
''cd /etc/httpd/modsecurity.custom.d''<br />
<br />
and edit the file 99_zzz_custom.conf and put in your custom rules.<br />
<br />
You can also download an example custom rule file by running these commands:<br />
<br />
''cd /etc/httpd/modsecurity.custom.d<br />
<br />
wget https://www.atomicorp.com/examples/99_zzz_custom.conf''<br />
<br />
'''Step 4) Test your apache configuration'''<br />
<br />
''service httpd configtest''<br />
<br />
If you have any errors, do not restart apache. You will need to correct these errors or apache will not start.<br />
<br />
'''Step 5) If your test was successful, restart apache.'''<br />
<br />
''service httpd restart''<br />
<br />
Our professional services group would be happy to help you with your custom rules needs, including developing the rules for you. If your request is something that we can safely include in the rules for all our customers, we're generally able to develop these new rules for free. Please contact us to discuss your rules needs.<br />
<br />
=== Windows ===<br />
<br />
==== IIS ====<br />
<br />
'''Step 1) Modify your modsecurity configuration file on windows and add this line to the end of your configuration. For example:'''<br />
<br />
''Include [https://www.atomicorp.com/examples/99_zzz_custom.conf 99_zzz_custom.conf]''<br />
<br />
'''Step 2) Edit the file 99_zzz_custom.conf and save it in the same directory as your modsecurity config file'''<br />
<br />
'''Step 3)Restart IIS'''<br />
<br />
<br />
Our professional services group would be happy to help you with your custom rules needs, including developing the rules for you. If your request is something that we can safely include in the rules for all our customers, we're generally able to develop these new rules for free. Please contact us to discuss your rules needs.<br />
<br />
== Modifying a rule ==<br />
<br />
If you want to modify the internal logic of a rule, you will want to "fork" or copy that rule into a custom rule. Do not modify the actual rules provided by us, your modifications will be overwritten with the next update.<br />
<br />
'''Step 1: Copy the rule you want to modify into your custom rules file.'''<br />
<br />
Copy the rule in its entirety into your custom rule file. For example, if you wanted to modify rule 390707, you would copy the entire rule into your custom rules file. For example:<br />
<br />
<pre><br />
# Restrict the maximum number of arguments in a request<br />
SecRule &ARGS "@gt 1000" \<br />
"chain,phase:2,t:none,log,auditlog,deny,status:403,msg:'Atomicorp.com WAF Rules: Too many arguments in request (max set to 1000, increase as necessary for your system)',id:'390707',severity:'4',rev:'8'"<br />
SecRule REQUEST_URI "!((?:^/(?:imaclean|massdelete)/)|^/cgi-bin/dada/mail\.cgi$|^/index\.php/mageworx/customoptions_options|^/za/|^/back-?office/|^/moderate\.php|^/backend/configdomains\.php|\.do$|^/admin[a-z0-9]+?/index\.php\?controller=adminmodules)" "t:none,t:lowercase"<br />
</pre><br />
<br />
'''Step 2: Change the rule id.''' <br />
<br />
This is absolutely required. No two rules can have the same ID. See this article for chosing a custom rule id: https://wiki.atomicorp.com/wiki/index.php/Mod_security#Rule_Ids_for_custom_rules<br />
<br />
For example:<br />
<br />
<pre><br />
# Restrict the maximum number of arguments in a request<br />
SecRule &ARGS "@gt 1000" \<br />
"chain,phase:2,t:none,log,auditlog,deny,status:403,msg:'Atomicorp.com WAF Rules: Too many arguments in request (max set to 1000, increase as necessary for your system)',id:'12345678',severity:'4',rev:'8'"<br />
SecRule REQUEST_URI "!((?:^/(?:imaclean|massdelete)/)|^/cgi-bin/dada/mail\.cgi$|^/index\.php/mageworx/customoptions_options|^/za/|^/back-?office/|^/moderate\.php|^/backend/configdomains\.php|\.do$|^/admin[a-z0-9]+?/index\.php\?controller=adminmodules)" "t:none,t:lowercase"<br />
</pre><br />
<br />
'''Step 3: Disable the original rule'''<br />
<br />
If you want your custom rule to be global, that is your modification applies to the entire system, then you will want to disable the original rule per this article:<br />
<br />
https://wiki.atomicorp.com/wiki/index.php/Mod_security#Disable_a_rule_for_all_domains<br />
<br />
If you want to disable the rule for a single application, see this article:<br />
<br />
https://wiki.atomicorp.com/wiki/index.php/Mod_security#Disable_a_rule_for_a_specific_web_application<br />
<br />
If you want to disable the rule for a specific IP or network:<br />
<br />
https://wiki.atomicorp.com/wiki/index.php/Mod_security#Disable_a_rule_by_IP_or_network<br />
<br />
If you want to disable the rule for a single domain:<br />
<br />
https://wiki.atomicorp.com/wiki/index.php/Mod_security#Disable_a_rule_for_a_single_domain<br />
<br />
'''Step 4: Set the scope of the rule.'''<br />
<br />
If you havent disabled the original rule globally, or for one or more domains, then you will need to set the scope of your custom rule. To limit your modification to a specific application, place your custom rule inside <LocationMatch> tags. For example:<br />
<br />
<pre><br />
<br />
<LocationMatch /url/to/your/custom/application><br />
# Restrict the maximum number of arguments in a request<br />
SecRule &ARGS "@gt 2048" \<br />
"chain,phase:2,t:none,log,auditlog,deny,status:403,msg:'Atomicorp.com WAF Rules: Too many arguments in request (max set to 1000, increase as necessary for your system)',id:'12345678',severity:'4',rev:'8'"<br />
SecRule REQUEST_URI "!((?:^/(?:imaclean|massdelete)/)|^/cgi-bin/dada/mail\.cgi$|^/index\.php/mageworx/customoptions_options|^/za/|^/back-?office/|^/moderate\.php|^/backend/configdomains\.php|\.do$|^/admin[a-z0-9]+?/index\.php\?controller=adminmodules)" "t:none,t:lowercase"<br />
</LocationMatch><br />
<br />
</pre><br />
<br />
= Configuring and Setting up mod_security =<br />
'''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.'''<br />
<br />
To setup and configured modsecurity, please see the [[Atomic_ModSecurity_Rules]] wiki page.</div>Mshinnhttps://wiki.atomicorp.com/wiki/index.php/Mod_securityMod security2022-09-16T19:22:58Z<p>Mshinn: /* Disabling Mod_security per domain */</p>
<hr />
<div>=Installing modsecurity Rules =<br />
<br />
Please see this article:<br />
<br />
[[Atomic ModSecurity Rules]]<br />
<br />
=Tuning and managing modsecurity Rules=<br />
<br />
== Disabling Rules ==<br />
<br />
=== Important Notes ===<br />
<br />
==== phase:1 rules ====<br />
<br />
Note: ASL users should disable rules from the rule manager. There is no need to create custom rules, apache configuration files or other customizations when using ASL, and ASL supports disabling any rule on both a global and per domain basis.<br />
<br />
For non-ASL users, LocationMatch and Location do not work for phase:1 rules. Location and LocationMatch are not available in apache until phase:2. If you need to disable a phase:1 rule, use [[ASL]] which can disable phase:1 rules on a per domain and global basis.<br />
<br />
If you are not using [[ASL]], and need to disable a phase:1 rule, you will need to create a custom rule to do this. This following is an example of a custom rule to do this for rule 123456.<br />
<br />
''SecRule REQUEST_HEADERS:Host "example.com$" "phase:1,id:91001,t:none,t:lowercase,pass,nolog,noauditlog,ctl:ruleRemovebyID=123456"''<br />
<br />
In the example above, "example.com" is the domain to exclude this rule. This custom rule must be loaded before the rule you want to disable. This custom rule *must be loaded before the rule you wish to disable*.<br />
<br />
If you do not know how to create this kind of custom rule, please contact support and we'll put a quote together to help develop these custom rules for you.<br />
<br />
=== Global ===<br />
<br />
==== Disabling Mod_Security Globally ====<br />
<br />
If you are using ASL, just change this setting:<br />
<br />
https://www.atomicorp.com/wiki/index.php/ASL_WAF#MODSEC_ENABLED<br />
<br />
If you are not using ASL, you will need to do this manually:<br />
<br />
Step 1) Disable config file<br />
mv /etc/httpd/conf.d/00_mod_security.conf /etc/httpd/conf.d/00_mod_security.conf.disabled<br />
<br />
Step 2) Restart Apache<br />
service httpd restart<br />
<br />
==== Disable Mod_security on a global URL ====<br />
<br />
Step 1) Create a global exclude file<br />
<br />
vim /etc/httpd/modsecurity.d/00_custom_exclude.conf<br />
<br />
Step 2) Add the LocationMatch for the url to exclude. Example: /server.php<br />
<br />
<LocationMatch /server.php><br />
<IfModule mod_security2.c><br />
SecRuleEngine Off <br />
</IfModule><br />
</LocationMatch><br />
<br />
Step 3) Restart apache<br />
<br />
service httpd restart<br />
<br />
<br />
<br />
Step 3) Restart apache<br />
<br />
service httpd restart<br />
<br />
==== Set a URL to alert only ====<br />
<br />
Step 1) Create a global exclude file<br />
<br />
vim /etc/httpd/modsecurity.d/00000_custom_exclude.conf<br />
<br />
Step 2) Add a custom rule<br />
<br />
In this example the URL is: /foo/bar<br />
<br />
Add this line to the file you created in Step 1:<br />
<br />
SecRule REQUEST_URI "/foo/bar" "phase:1,id:1000000,t:none,t:lowercase,pass,nolog,noauditlog,ctl:ruleEngine=DetectionOnly"<br />
<br />
Important Note: See the section customizing rules below to pick a unique id for your rule above. Duplicate rule ids will cause the rule to not load.<br />
<br />
Step 3) Restart apache<br />
<br />
service httpd restart<br />
<br />
=== Per domain ===<br />
<br />
==== Disabling Mod_security per domain ====<br />
<br />
Note: If you only want to disable a specific rule for a domain, please see this article:<br />
<br />
https://wiki.atomicorp.com/wiki/index.php/Mod_security#Per_application<br />
<br />
===== For Plesk Based Systems =====<br />
<br />
For Plesk and similar systems you can also disable modsecurity in the Apache configuration.<br />
<br />
Step 1) Edit the vhost/vhost_ssl.conf for the domain<br />
vim /var/www/vhosts/<DOMAINNAME>/conf/vhost.conf<br />
<br />
Step 2) Add the following<br />
<IfModule mod_security2.c><br />
SecRuleEngine Off<br />
</IfModule><br />
<br />
Then restart apache, if you are using Plesk then you will also need follow steps 3 and 4.<br />
<br />
Step 3) Add vhost.conf to domain config <br />
<br />
Plesk 9:<br />
/usr/local/psa/admin/bin/websrvmng -a<br />
<br />
Plesk 10/11:<br />
/usr/local/psa/admin/bin/httpdmng --reconfigure-domain <domain_name><br />
<br />
Step 4) Restart Apache<br />
service httpd restart<br />
<br />
===== For Cpanel based systems with EasyApache 4 =====<br />
<br />
For full information about include file path expectations, see the official cPanel documentation at [https://documentation.cpanel.net/display/EA4/Modify+Apache+Virtual+Hosts+with+Include+Files Modify Apache Virtual Hosts with Include Files]<br />
<br />
Step 1) Create the following paths, replacing <user> and <domain> with the correct values for your needs:<br />
<br />
* mkdir -p /etc/apache2/conf.d/userdata/ssl/2_4/<user>/<domain><br />
* mkdir -p /etc/apache2/conf.d/userdata/std/2_4/<user>/<domain><br />
<br />
Step 2) In each of the above paths, create a file named 'vhost.conf'<br />
<br />
Step 3) Add in the lines below to this file:<br />
<br />
<pre><br />
<IfModule mod_security2.c><br />
SecRuleEngine Off<br />
</IfModule><br />
</pre><br />
<br />
Step 4) After any addition, modification or removal of userdata files, cPanel requires both of the following scripts to be run:<br />
<br />
* /usr/local/cpanel/scripts/rebuildhttpdconf<br />
* /usr/local/cpanel/scripts/restartsrv_httpd<br />
<br />
<br />
===== For Cpanel based systems with EasyApache 3 =====<br />
<br />
Step 1) Create the custom modsecurity configuration directory for the domain<br />
<br />
For example, if the domain is example.com, you would need to create this directory:<br />
<br />
<br />
mkdir /usr/local/apache/conf/userdata/std/2/username/example.com<br />
<br />
Step 2) Create the file vhost.conf in this directory<br />
<br />
cd /usr/local/apache/conf/userdata/std/2/username/example.com<br />
<br />
touch vhost.conf<br />
<br />
Step 3) Add in the lines below to this file:<br />
<br />
<pre><br />
<IfModule mod_security2.c><br />
SecRuleEngine Off<br />
</IfModule><br />
</pre><br />
<br />
Step 4) Run the vhost includes script, for example if the domains username is "example":<br />
<br />
/scripts/ensure_vhost_includes --user=example<br />
<br />
== Non Control Panel systems ==<br />
<br />
For non-control panel systems, rules can be disabled for a domain/FQDN by adding a custom rule before the rule you wish to disable is loaded. For example, if you wanted to disable rule 123456 for domain example.com, you would add this rule to your custom rules:<br />
<br />
SecRule REQUEST_HEADERS:Host "example.com$" "phase:1,id:91001,t:none,t:lowercase,pass,nolog,noauditlog,ctl:ruleRemovebyID=123456"<br />
<br />
==== Disabling Mod_security per domain for an IP address ====<br />
<br />
===== For Plesk based systems =====<br />
<br />
For Plesk and similar systems you can also disable modsecurity in the Apache configuration.<br />
<br />
Step 1) Edit the vhost/vhost_ssl.conf for the domain<br />
vim /var/www/vhosts/<DOMAINNAME>/conf/vhost.conf<br />
<br />
Step 2) Add the following<br />
<IfModule mod_security2.c><br />
SecRule REMOTE_ADDR "^1.2.3.4$" "phase:1,t:none,nolog,allow,ctl:ruleEngine=Off,ctl:auditEngine=Off,id:9999"<br />
</IfModule><br />
<br />
'''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.'''<br />
<br />
Then restart apache, if you are using Plesk then you will also need follow steps 3 and 4.<br />
<br />
Step 3) Add vhost.conf to domain config <br />
<br />
Plesk 9:<br />
/usr/local/psa/admin/bin/websrvmng -a<br />
<br />
Plesk 10/11:<br />
/usr/local/psa/admin/bin/httpdmng --reconfigure-domain <domain_name><br />
<br />
Step 4) Restart Apache<br />
service httpd restart<br />
<br />
===== For cpanel based systems =====<br />
<br />
Step 1) Create the custom modsecurity configuration directory for the domain<br />
<br />
For example, if the domain is example.com, you would need to create this directory:<br />
<br />
mkdir /usr/local/apache/conf/userdata/std/2/username/example.com<br />
<br />
Step 2) Create the file vhost.conf in this directory<br />
<br />
cd /usr/local/apache/conf/userdata/std/2/username/example.com<br />
<br />
touch vhost.conf<br />
<br />
Step 3) Add in the lines below to this file:<br />
<br />
<IfModule mod_security2.c><br />
SecRule REMOTE_ADDR "^1.2.3.4$" "phase:1,t:none,nolog,allow,ctl:ruleEngine=Off,ctl:auditEngine=Off,id:9999"<br />
</IfModule><br />
<br />
'''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.'''<br />
<br />
Step 4) Run the vhost includes script, for example if the domains username is "example":<br />
<br />
/scripts/ensure_vhost_includes –user=example<br />
<br />
==== Disable a rule for a single domain ====<br />
<br />
'''If you have ASL installed''':<br />
<br />
Method 1:<br />
<br />
Log into the ASL GUI, and click on the "ASL" tab. Then click "WAF & HIDS Rules", 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.<br />
<br />
Type in the hostname into the Text box on the left side of the options you want to exclude the rule for, then click "add".<br />
<br />
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, or a regular expression *.example.com.<br />
<br />
Note: You can use regular expressions in this field, but each end of the expression is anchored.<br />
<br />
<br />
Method 2: Run this command as root:<br />
<br />
In ASL v3.x:<br />
asl -dr RULE_ID --vhost www.example.com<br />
<br />
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:<br />
<br />
asl -dr RULE_ID --vhost www.example.com<br />
<br />
asl -dr RULE_ID --vhost ftp.example.com<br />
<br />
asl -dr RULE_ID --vhost example.com<br />
<br />
<br />
In ASL v4:<br />
asl -drv RULE_ID[,RULE_ID...] VHOST[,VHOST...]<br />
or <br />
asl --disable-rule-vhost RULE_ID[,RULE_ID...] VHOST[,VHOST...]<br />
<br />
All supplied rules will be disabled on all supplied vhosts.<br />
<br />
asl -drv 111111,222222,333333 www.example.com,ftp.example.com,example.com<br />
<br />
<br />
<br />
<br />
'''If you do not have ASL installed''' you will have to do this manually:<br />
<br />
Step 1) Edit your domains vhost.conf file (the location of this file will vary based on your control panel, contact your control panel vendor for assistance)<br />
<br />
vim vhost.conf<br />
<br />
Step 2) Add the LocationMatch for the rule to exclude. Example, ruleid 950005<br />
<LocationMatch .*><br />
<IfModule mod_security2.c><br />
SecRuleRemoveById 950005<br />
</IfModule><br />
</LocationMatch><br />
<br />
If you want to disable multiple rules:<br />
<br />
Step 2) Add the LocationMatch for the rule to exclude. Example, ruleids 950005 and 950006<br />
<LocationMatch .*><br />
<IfModule mod_security2.c><br />
SecRuleRemoveById 950005<br />
SecRuleRemoveById 950006<br />
</IfModule><br />
</LocationMatch><br />
<br />
==== Disable a rule for all domains ====<br />
<br />
Method 1:<br />
<br />
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.<br />
<br />
Set "disabled" to yes and click update.<br />
<br />
Method 2:<br />
<br />
Use ASL utility to disable rule by ID. Example: 950005<br />
asl --disable-rule 950005<br />
<br />
Note: This requires that [[Atomic Secured Linux]] be installed.<br />
'''<br />
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:<br />
<br />
<LocationMatch .*><br />
<IfModule mod_security2.c><br />
SecRuleRemoveById 340000<br />
</IfModule><br />
</LocationMatch><br />
<br />
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.<br />
<br />
=== Per IP or network ===<br />
<br />
==== Disable Mod_security for an IP address ====<br />
<br />
In ASL, just click the "Whitelist" button.<br />
<br />
If you are not using ASL, simply add your IP address to the file:<br />
<br />
/etc/asl/whitelist<br />
<br />
And restart Apache.<br />
<br />
Note: For this rule to work, in ASL you must have the MODSEC_00_WHITELIST ruleset enabled.<br />
<br />
If you are not using ASL, then you must have the 00_asl_whitelist.conf ruleset loaded.<br />
<br />
==== Whitelist an IP ====<br />
<br />
See above, "Disable Mod_security for an IP address"<br />
<br />
==== Disable a rule by IP or network====<br />
<br />
You will need to create a custom rule, loaded after all your other rules. Lets say you wanted to exclude rule id 330039 for the network 1.2.0.0/16. You would construct a custom rule like this:<br />
<br />
<pre><br />
SecRule REMOTE_HOST "@ipmatch 1.2.0.0/16" \<br />
"id:12345,phase:2,t:none,pass,nolog,noauditlog,ctl:ruleRemovebyID=330039"<br />
</pre><br />
<br />
Note: ipmatch can also use a list, with a combination of IPs and network for example:<br />
<br />
@ipmatch 1.2.0.0/16,5.6.7.8,127.0.0.0/8<br />
<br />
Warning: If the CIDR is invalid, this may cause a segfault of the mod_security module. Check to make sure your CIDR is valid before use.<br />
<br />
=== Per application ===<br />
<br />
==== Disable modsecurity for a specific web application ====<br />
<br />
Note: this is not recommended<br />
<br />
Add a custom rule (see the section below on creating [https://www.atomicorp.com/wiki/index.php/Mod_security#Creating_custom_rules custom rules]) after all your rules have been loaded. For example, if you wanted to disable modsecurity for the application /foo/bar.cgi you would add a custom rule like this:<br />
<br />
<pre><br />
<LocationMatch /foo/bar.cgi><br />
SecRuleEngine Off<br />
<br />
</LocationMatch><br />
</pre><br />
<br />
<br />
<br />
==== Disable a rule for a specific web application ====<br />
Add a custom rule (see the section below on creating [https://www.atomicorp.com/wiki/index.php/Mod_security#Creating_custom_rules custom rules]) after all your rules have been loaded. For example, if you wanted to disable rule 950005, you would add a custom rule like this:<br />
<br />
<pre><br />
<LocationMatch /URL/path/to/application.php><br />
SecRuleRemoveById 950005<br />
<br />
</LocationMatch><br />
</pre><br />
<br />
==== Disable a rule for a single domain or FQDN ====<br />
<br />
===== For non control panel systems =====<br />
<br />
If you are using any of our GUI products, just click on the rule event, and type in the domain or hostname you want to exclude for this rule. <br />
<br />
For DIY users, you will need to create custom rules that load *before* the rule that you wish to exclude. This means you will need to add a custom rule file that loads before the rules we supply.<br />
<br />
Once you have set this up for your DIY modsecurity configuration, you will add a rule that inspects the Host: header sent by the client, which will the disable the rule(s) you wish to disable when that field is populated by that value. Keep in mind this field is completely controlled by the client, not the server. In the example below, the entire domain "example.com" is excluded for rule 123456:<br />
<br />
''SecRule REQUEST_HEADERS:Host ".example.com$" "phase:1,id:91010,t:none,t:lowercase,pass,nolog,noauditlog,ctl:ruleRemovebyID=123456"''<br />
<br />
Then restart the web server to apply this custom exclusion.<br />
<br />
===== For Plesk systems =====<br />
<br />
<br />
Step 1) Edit the virtual servers configuration for the domain for the domain<br />
<br />
Example:<br />
<br />
vim /var/www/vhosts/<DOMAINNAME>/conf/vhost.conf<br />
<br />
Step 2) Add the LocationMatch for the rule to exclude. Example, ruleid 950005<br />
<br />
<pre><br />
<LocationMatch /URL/path/to/application.php><br />
<br />
SecRuleRemoveById 950005<br />
</IfModule><br />
<br />
</pre><br />
<br />
==== Disable Mod_security rules globally for a specific application ====<br />
<br />
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.<br />
<br />
<LocationMatch /url/to/your/application><br />
<IfModule mod_security2.c><br />
SecRuleRemoveById 1234567<br />
SecRuleRemoveById 9999999<br />
</IfModule><br />
</LocationMatch><br />
<br />
Whats important to remember is that the LocationMatch variable must match the URL, not the path on the system.<br />
<br />
==== Disable Mod_security rules by domain, for a specific application, for a list of IPs ====<br />
<br />
Step 1) Edit the vhost/vhost_ssl.conf for the domain<br />
vim /var/www/vhosts/<DOMAINNAME>/conf/vhost.conf<br />
<br />
Step 2) Add the LocationMatch for the rule to exclude.<br />
<LocationMatch /foo/bar.php><br />
<IfModule mod_security2.c><br />
SecRule REMOTE_ADDR "@pmFromFile /etc/asl/whitelist" "nolog,phase:1,allow"<br />
</IfModule><br />
</LocationMatch><br />
<br />
Step 3) Add IP to /etc/asl/whitelist<br />
echo "10.11.12.13" >> /etc/asl/whitelist<br />
<br />
Or:<br />
<br />
If you want to create a special whitelist for just that application:<br />
<br />
Step 1) Edit the vhost/vhost_ssl.conf for the domain<br />
vim /var/www/vhosts/<DOMAINNAME>/conf/vhost.conf<br />
<br />
Step 2) Add the LocationMatch for the rule to exclude.<br />
<LocationMatch /foo/bar.php><br />
<IfModule mod_security2.c><br />
SecRule REMOTE_ADDR "@pmFromFile /path/to/your/custom/whitelist_for_this_application" "nolog,phase:1,allow,id:9999"<br />
</IfModule><br />
</LocationMatch><br />
<br />
'''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.'''<br />
<br />
<br />
Step 3) Create your custom whitelist and add IP to /etc/asl/whitelist<br />
echo "10.11.12.13" >> /path/to/your/custom/whitelist_for_this_application<br />
<br />
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.<br />
<br />
==== Disable rule for a specific argument for a specific application ====<br />
<br />
You can also tell modsecurity to change a rule, in some cases, without editing or forking the rule. For example, if you want to configure modsecurity to ignore a specific argument (in the argument below the argument is "foo"), for a specific application (in the example the application name is /example/application), for a specific rule (in the example below the rule if is 12345), you would create a custom rule like this:<br />
<br />
<br />
<pre><br />
SecRule REQUEST_URI "^/example/application" \<br />
"id:9999,phase:1,t:none,t:lowercase,nolog,pass,ctl:ruleRemoveTargetByID=12345;ARGS:foo"<br />
</pre><br />
<br />
As with all custom rules, this rule also needs a unique id as explained in the article above. And this type of custom rule must be loaded '''before''' the rule it modifies.<br />
<br />
Note: This does not support regular expressions for the excluded argument. At this time, they must be explicitly defined.<br />
<br />
==== Disable rule for a specific argument ====<br />
<br />
As is the example above, a rule can also be changed to exclude a specific argument, but for all applications. For example, if you want to configure modsecurity to ignore a specific argument (in the argument below the argument is "foo"), for a specific rule (in the example below the rule if is 12345), you would create a custom rule like this:<br />
<br />
<pre><br />
SecAction "phase:1,id:9999,t:none,auditlog,nolog,pass,ctl:ruleRemoveTargetById=12345;ARGS:foo"<br />
</pre><br />
<br />
As with all custom rules, this rule also needs a unique id as explained in the article above. And this type of custom rule must be loaded '''before''' the rule it modifies.<br />
<br />
Note: This does not support regular expressions for the excluded argument. At this time, they must be explicitly defined.<br />
<br />
==== Disable modsecurity for a specific argument ====<br />
<br />
As is the example above, modsecurity can also be configured to exclude a specific argument for all rules. For example, if you want to configure modsecurity to ignore a specific argument (in the argument below the argument is "foo"),you would create a custom rule like this:<br />
<br />
<pre><br />
SecAction "phase:1,id:9999,t:none,auditlog,nolog,pass,ctl:ruleRemoveTargetById=1-1000000;ARGS:foo"<br />
</pre><br />
<br />
When 1-100000 is the rule IDs you want to exclude. As with all custom rules, this rule also needs a unique id as explained in the article above. <br />
<br />
Note: This does not support regular expressions for the excluded argument. At this time, they must be explicitly defined.<br />
<br />
== Changing the action for a rule ==<br />
<br />
You can also change the default action for a rule by using the SecRuleActionById directive. <br />
<br />
=== Changing a rule to be detect only by ID===<br />
<br />
To change a rule to only detect, but not block attacks, simply change the action for the rule with the above directive. For example, to change the action for rule 12345, simply add this rule directive to your custom rules. <br />
<br />
SecRuleUpdateActionById 12345 "pass,status:200"<br />
<br />
Note 1: this directive must be added after the rule it is modifying has been loaded.<br />
<br />
Note 2: This does not work if you are using the redirect action.<br />
<br />
=== Changing a range of rules ot be detect only by ID===<br />
<br />
This is similar to the method above, however you can define a range of rule IDs. For example, if you want to disable rules 1000-2000:<br />
<br />
SecRuleUpdateActionById 1000-2000 "pass,status:200"<br />
<br />
Note 1: this directive must be added after the rule it is modifying has been loaded.<br />
<br />
Note 2: This does not work if you are using the redirect action.<br />
<br />
== Disabling POST inspection for a specific URL ==<br />
<br />
Should you want to disable inspection of a POST for a specific URL, use the format below.<br />
<br />
Assuming the URL you wanted to skip POST inspection was "upload", your exclusion rule would look like this:<br />
<br />
''SecRule REQUEST_URI "^/upload" \<br />
"phase:1,id:1234567,t:none,t:lowercase,pass,nolog,ctl:requestBodyAccess=off"''<br />
<br />
Install this rule before any of your other rules. For example, in the file /etc/httpd/modsecurity.d/00_custom_exclude.conf.<br />
<br />
== Enabling rules for only specific domains ==<br />
<br />
If you wish to disable all the rules, except for specific domains, you need to copy in the two files from the subdirectory "special" where you have the rules installed. Then create this file:<br />
<br />
/etc/asl/custom_include_domains<br />
<br />
<br />
Include the domains and/or FQDNs you want the rules to apply to. Anything not on that list will cause those rules to skip all of our rules. <br />
<br />
#File must contain exactly one domain or FQDN per line. End of line markers (both LF and CRLF) will be stripped from each phrase and any whitespace trimmed from both the beginning and the end. Empty lines and comment lines (those beginning with the # character) will be ignored.<br />
#This file does not support metacharacters. (For example, * is not supported)<br />
<br />
Example:<br />
<br />
<br />
<pre><br />
www.example.com<br />
.foo.com<br />
</pre><br />
<br />
== Disabling rules using .htaccess ==<br />
<br />
This is a new feature in modsecurity 2.7.3. This capability is available if you compile modsecurity using this option:<br />
<br />
--enable-htaccess-config<br />
<br />
From there, you will be able to disable rules using .htaccess files. The format to disable a rule via .htaccess is:<br />
<br />
SecRuleRemoveById 12345<br />
<br />
Where 12345 is the rule id.<br />
<br />
'''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 and/or this option has not been enabled. <br />
<br />
Warning: Enabling this capability will allow users to disable rules, including on compromised accounts which may cause the system to become compromised. This capability was specifically disabled by default in modsecurity to prevent this from occurring. Use this option with extreme caution!<br />
<br />
=== Specific actions available in .htaccess ===<br />
<br />
<br />
* SecAction<br />
* SecRule<br />
* SecRuleRemoveByMsg<br />
* SecRuleRemoveByTag<br />
* SecRuleRemoveById<br />
* SecRuleUpdateActionById<br />
* SecRuleUpdateTargetById<br />
* SecRuleUpdateTargetByTag<br />
* SecRuleUpdateTargetByMsg<br />
<br />
'''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.<br />
<br />
Warning: Enabling this capability in modsecurity can allow an attacker to disable modsecurity rules that you may be using to protect the entire server. We do not recommend you enable this capability on a shared server.<br />
<br />
== Customizing a rule ==<br />
<br />
If you need to customize a rule do not change the asl*conf files. These files will be overwritten by updates. <br />
<br />
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.<br />
<br />
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:<br />
<br />
If you had an original rule like this:<br />
<br />
SecRule REQUEST_URI "/foo" "t:normalisePath,id:9000,rev:1,severity:2,msg:'Atomicorp.com WAF Rules: Block /foo'"<br />
<br />
<br />
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.<br />
<br />
SecRuleRemoveById 9000000<br />
SecRule REQUEST_URI "/bar" "t:normalisePath,id:9999,rev:1,severity:2,msg:'Atomicorp.com WAF Rules: Block /foo'"<br />
<br />
'''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.'''<br />
<br />
<br />
These are the reserved ranges:<br />
<br />
* 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.<br />
* 100,000-199,999; reserved for internal use of the engine, to assign to rules that do not have explicit IDs.<br />
* 200,000-299,999; reserved for rules published at modsecurity.org.<br />
* 300,000-399,999; reserved for rules published at gotroot.com.<br />
* 400,000-419,999; unused (available for reservation).<br />
* 420,000-429,999; reserved for ScallyWhack.<br />
* 430,000-699,999; unused (available for reservation).<br />
* 700,000-799,999; reserved for Ivan Ristic.<br />
* 900,000-999,999; reserved for the Core Rules project.<br />
* 1,000,000 and above; unused (available for reservation).<br />
<br />
=== For a domain ===<br />
<br />
==== Apache ====<br />
<br />
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.<br />
<br />
==== Changing the argument separator ====<br />
<br />
If you have a web application that uses the uncommon ";" argument separator, as opposed to the widely used "&" you will want to change SecArgumentSeparator value for that application. You can do this in one of two ways:<br />
<br />
1) Globally<br />
<br />
If all your applications use the older delimiter, just change the SecArgumentSeparator in the tortix_waf.conf file. Do not change this if your applications use other delimiters.<br />
<br />
''SecArgumentSeparator ";"'' <br />
<br />
2) Per Application<br />
<br />
You can also configure this per application. For example, if your web applications URL is /foo/bar.php you can create a customer rule like this:<br />
<br />
<br />
<pre><br />
<LocationMatch /foo/bar.php><br />
SecArgumentSeparator ";"<br />
</LocationMatch><br />
</pre><br />
<br />
This will only work if modsecurity is loaded before your virtual host definitions. This is the case with most control panels, but some control panels are known to load modsecurity after vhosts are defined. In which case this will fail because Apache will not know how to process this directive (it will need modsecurity loaded to understand what this means). If you get a syntax error, that means your apache configuration is loaded modsecurity after your vhosts are defined. You will need to change your apache configuration to ensure this loading occurs before vhosts are defined.<br />
<br />
[[ASL]] will automatically configure modsecurity to load first.<br />
<br />
= Creating custom rules =<br />
<br />
== Discussion ==<br />
<br />
If you need to create your own custom rules, do not change the asl*conf files. These files will be overwritten by updates. <br />
<br />
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.<br />
<br />
== Rule Ids for custom rules ==<br />
<br />
For custom rules, '''you must create your own rule ids which must be unique'''. The id: fields contain the rule ids. For custom rules you should use the local (internal) use range (see below for the reserved id ranges). '''Do not use assigned ranges.'''<br />
<br />
These are the reserved ranges:<br />
<br />
* 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.<br />
* 100,000-199,999; reserved for internal use of the engine, to assign to rules that do not have explicit IDs. (deprecated, all rules require assigned ids in 2.7.x and up)<br />
* 200,000-299,999; reserved for rules published at modsecurity.org.<br />
* 300,000-399,999; reserved for rules published by atomicorp.com<br />
* 400,000-419,999; unused (available for reservation).<br />
* 420,000-429,999; reserved for ScallyWhack.<br />
* 430,000-699,999; unused (available for reservation).<br />
* 700,000-799,999; reserved for Ivan Ristic.<br />
* 900,000-999,999; reserved for the Core Rules project.<br />
* 1,000,000 and above; unused (available for reservation).<br />
<br />
== Installing custom rules ==<br />
<br />
<br />
=== Linux ===<br />
<br />
==== Apache ====<br />
<br />
'''Step 1) Create your custom rules directory:'''<br />
<br />
''mkdir /etc/httpd/modsecurity.custom.d''<br />
<br />
'''Step 2) Create a configuration file for your custom rules in /etc/httpd/conf.d directory. For example:'''<br />
<br />
Create the file 01_modsecurity.conf and add this line to it:<br />
<br />
''Include modsecurity.custom.d/[https://www.atomicorp.com/examples/99_zzz_custom.conf 99_zzz_custom.conf]''<br />
<br />
You can download an example file from the URL below that will do this:<br />
<br />
[https://www.atomicorp.com/examples/01_modsecurity.conf 01_modsecurity.conf]<br />
<br />
And add 01_modsecurity.conf to this directory:<br />
<br />
/etc/httpd/conf.d<br />
<br />
If you have wget installed on your system, the following commands will do this automatically for you:<br />
''<br />
<br />
cd /etc/httpd/conf.d<br />
<br />
wget https://www.atomicorp.com/examples/01_modsecurity.conf''<br />
<br />
Note: 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. Please contact your control panel vendor for assistance.<br />
<br />
'''Step 3) Install your custom rules in the /etc/httpd/modsecurity.custom.d directory'''<br />
<br />
''cd /etc/httpd/modsecurity.custom.d''<br />
<br />
and edit the file 99_zzz_custom.conf and put in your custom rules.<br />
<br />
You can also download an example custom rule file by running these commands:<br />
<br />
''cd /etc/httpd/modsecurity.custom.d<br />
<br />
wget https://www.atomicorp.com/examples/99_zzz_custom.conf''<br />
<br />
'''Step 4) Test your apache configuration'''<br />
<br />
''service httpd configtest''<br />
<br />
If you have any errors, do not restart apache. You will need to correct these errors or apache will not start.<br />
<br />
'''Step 5) If your test was successful, restart apache.'''<br />
<br />
''service httpd restart''<br />
<br />
Our professional services group would be happy to help you with your custom rules needs, including developing the rules for you. If your request is something that we can safely include in the rules for all our customers, we're generally able to develop these new rules for free. Please contact us to discuss your rules needs.<br />
<br />
=== Windows ===<br />
<br />
==== IIS ====<br />
<br />
'''Step 1) Modify your modsecurity configuration file on windows and add this line to the end of your configuration. For example:'''<br />
<br />
''Include [https://www.atomicorp.com/examples/99_zzz_custom.conf 99_zzz_custom.conf]''<br />
<br />
'''Step 2) Edit the file 99_zzz_custom.conf and save it in the same directory as your modsecurity config file'''<br />
<br />
'''Step 3)Restart IIS'''<br />
<br />
<br />
Our professional services group would be happy to help you with your custom rules needs, including developing the rules for you. If your request is something that we can safely include in the rules for all our customers, we're generally able to develop these new rules for free. Please contact us to discuss your rules needs.<br />
<br />
== Modifying a rule ==<br />
<br />
If you want to modify the internal logic of a rule, you will want to "fork" or copy that rule into a custom rule. Do not modify the actual rules provided by us, your modifications will be overwritten with the next update.<br />
<br />
'''Step 1: Copy the rule you want to modify into your custom rules file.'''<br />
<br />
Copy the rule in its entirety into your custom rule file. For example, if you wanted to modify rule 390707, you would copy the entire rule into your custom rules file. For example:<br />
<br />
<pre><br />
# Restrict the maximum number of arguments in a request<br />
SecRule &ARGS "@gt 1000" \<br />
"chain,phase:2,t:none,log,auditlog,deny,status:403,msg:'Atomicorp.com WAF Rules: Too many arguments in request (max set to 1000, increase as necessary for your system)',id:'390707',severity:'4',rev:'8'"<br />
SecRule REQUEST_URI "!((?:^/(?:imaclean|massdelete)/)|^/cgi-bin/dada/mail\.cgi$|^/index\.php/mageworx/customoptions_options|^/za/|^/back-?office/|^/moderate\.php|^/backend/configdomains\.php|\.do$|^/admin[a-z0-9]+?/index\.php\?controller=adminmodules)" "t:none,t:lowercase"<br />
</pre><br />
<br />
'''Step 2: Change the rule id.''' <br />
<br />
This is absolutely required. No two rules can have the same ID. See this article for chosing a custom rule id: https://wiki.atomicorp.com/wiki/index.php/Mod_security#Rule_Ids_for_custom_rules<br />
<br />
For example:<br />
<br />
<pre><br />
# Restrict the maximum number of arguments in a request<br />
SecRule &ARGS "@gt 1000" \<br />
"chain,phase:2,t:none,log,auditlog,deny,status:403,msg:'Atomicorp.com WAF Rules: Too many arguments in request (max set to 1000, increase as necessary for your system)',id:'12345678',severity:'4',rev:'8'"<br />
SecRule REQUEST_URI "!((?:^/(?:imaclean|massdelete)/)|^/cgi-bin/dada/mail\.cgi$|^/index\.php/mageworx/customoptions_options|^/za/|^/back-?office/|^/moderate\.php|^/backend/configdomains\.php|\.do$|^/admin[a-z0-9]+?/index\.php\?controller=adminmodules)" "t:none,t:lowercase"<br />
</pre><br />
<br />
'''Step 3: Disable the original rule'''<br />
<br />
If you want your custom rule to be global, that is your modification applies to the entire system, then you will want to disable the original rule per this article:<br />
<br />
https://wiki.atomicorp.com/wiki/index.php/Mod_security#Disable_a_rule_for_all_domains<br />
<br />
If you want to disable the rule for a single application, see this article:<br />
<br />
https://wiki.atomicorp.com/wiki/index.php/Mod_security#Disable_a_rule_for_a_specific_web_application<br />
<br />
If you want to disable the rule for a specific IP or network:<br />
<br />
https://wiki.atomicorp.com/wiki/index.php/Mod_security#Disable_a_rule_by_IP_or_network<br />
<br />
If you want to disable the rule for a single domain:<br />
<br />
https://wiki.atomicorp.com/wiki/index.php/Mod_security#Disable_a_rule_for_a_single_domain<br />
<br />
'''Step 4: Set the scope of the rule.'''<br />
<br />
If you havent disabled the original rule globally, or for one or more domains, then you will need to set the scope of your custom rule. To limit your modification to a specific application, place your custom rule inside <LocationMatch> tags. For example:<br />
<br />
<pre><br />
<br />
<LocationMatch /url/to/your/custom/application><br />
# Restrict the maximum number of arguments in a request<br />
SecRule &ARGS "@gt 2048" \<br />
"chain,phase:2,t:none,log,auditlog,deny,status:403,msg:'Atomicorp.com WAF Rules: Too many arguments in request (max set to 1000, increase as necessary for your system)',id:'12345678',severity:'4',rev:'8'"<br />
SecRule REQUEST_URI "!((?:^/(?:imaclean|massdelete)/)|^/cgi-bin/dada/mail\.cgi$|^/index\.php/mageworx/customoptions_options|^/za/|^/back-?office/|^/moderate\.php|^/backend/configdomains\.php|\.do$|^/admin[a-z0-9]+?/index\.php\?controller=adminmodules)" "t:none,t:lowercase"<br />
</LocationMatch><br />
<br />
</pre><br />
<br />
= Configuring and Setting up mod_security =<br />
'''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.'''<br />
<br />
To setup and configured modsecurity, please see the [[Atomic_ModSecurity_Rules]] wiki page.</div>Mshinnhttps://wiki.atomicorp.com/wiki/index.php/Mod_securityMod security2022-09-16T19:20:51Z<p>Mshinn: /* phase:1 rules */</p>
<hr />
<div>=Installing modsecurity Rules =<br />
<br />
Please see this article:<br />
<br />
[[Atomic ModSecurity Rules]]<br />
<br />
=Tuning and managing modsecurity Rules=<br />
<br />
== Disabling Rules ==<br />
<br />
=== Important Notes ===<br />
<br />
==== phase:1 rules ====<br />
<br />
Note: ASL users should disable rules from the rule manager. There is no need to create custom rules, apache configuration files or other customizations when using ASL, and ASL supports disabling any rule on both a global and per domain basis.<br />
<br />
For non-ASL users, LocationMatch and Location do not work for phase:1 rules. Location and LocationMatch are not available in apache until phase:2. If you need to disable a phase:1 rule, use [[ASL]] which can disable phase:1 rules on a per domain and global basis.<br />
<br />
If you are not using [[ASL]], and need to disable a phase:1 rule, you will need to create a custom rule to do this. This following is an example of a custom rule to do this for rule 123456.<br />
<br />
''SecRule REQUEST_HEADERS:Host "example.com$" "phase:1,id:91001,t:none,t:lowercase,pass,nolog,noauditlog,ctl:ruleRemovebyID=123456"''<br />
<br />
In the example above, "example.com" is the domain to exclude this rule. This custom rule must be loaded before the rule you want to disable. This custom rule *must be loaded before the rule you wish to disable*.<br />
<br />
If you do not know how to create this kind of custom rule, please contact support and we'll put a quote together to help develop these custom rules for you.<br />
<br />
=== Global ===<br />
<br />
==== Disabling Mod_Security Globally ====<br />
<br />
If you are using ASL, just change this setting:<br />
<br />
https://www.atomicorp.com/wiki/index.php/ASL_WAF#MODSEC_ENABLED<br />
<br />
If you are not using ASL, you will need to do this manually:<br />
<br />
Step 1) Disable config file<br />
mv /etc/httpd/conf.d/00_mod_security.conf /etc/httpd/conf.d/00_mod_security.conf.disabled<br />
<br />
Step 2) Restart Apache<br />
service httpd restart<br />
<br />
==== Disable Mod_security on a global URL ====<br />
<br />
Step 1) Create a global exclude file<br />
<br />
vim /etc/httpd/modsecurity.d/00_custom_exclude.conf<br />
<br />
Step 2) Add the LocationMatch for the url to exclude. Example: /server.php<br />
<br />
<LocationMatch /server.php><br />
<IfModule mod_security2.c><br />
SecRuleEngine Off <br />
</IfModule><br />
</LocationMatch><br />
<br />
Step 3) Restart apache<br />
<br />
service httpd restart<br />
<br />
<br />
<br />
Step 3) Restart apache<br />
<br />
service httpd restart<br />
<br />
==== Set a URL to alert only ====<br />
<br />
Step 1) Create a global exclude file<br />
<br />
vim /etc/httpd/modsecurity.d/00000_custom_exclude.conf<br />
<br />
Step 2) Add a custom rule<br />
<br />
In this example the URL is: /foo/bar<br />
<br />
Add this line to the file you created in Step 1:<br />
<br />
SecRule REQUEST_URI "/foo/bar" "phase:1,id:1000000,t:none,t:lowercase,pass,nolog,noauditlog,ctl:ruleEngine=DetectionOnly"<br />
<br />
Important Note: See the section customizing rules below to pick a unique id for your rule above. Duplicate rule ids will cause the rule to not load.<br />
<br />
Step 3) Restart apache<br />
<br />
service httpd restart<br />
<br />
=== Per domain ===<br />
<br />
==== Disabling Mod_security per domain ====<br />
<br />
Note: If you only want to disable a specific rule for a domain, please see this article:<br />
<br />
https://wiki.atomicorp.com/wiki/index.php/Mod_security#Per_application<br />
<br />
===== For Plesk Based Systems =====<br />
<br />
For Plesk and similar systems you can also disable modsecurity in the Apache configuration.<br />
<br />
Step 1) Edit the vhost/vhost_ssl.conf for the domain<br />
vim /var/www/vhosts/<DOMAINNAME>/conf/vhost.conf<br />
<br />
Step 2) Add the following<br />
<IfModule mod_security2.c><br />
SecRuleEngine Off<br />
</IfModule><br />
<br />
Then restart apache, if you are using Plesk then you will also need follow steps 3 and 4.<br />
<br />
Step 3) Add vhost.conf to domain config <br />
<br />
Plesk 9:<br />
/usr/local/psa/admin/bin/websrvmng -a<br />
<br />
Plesk 10/11:<br />
/usr/local/psa/admin/bin/httpdmng --reconfigure-domain <domain_name><br />
<br />
Step 4) Restart Apache<br />
service httpd restart<br />
<br />
===== For Cpanel based systems with EasyApache 4 =====<br />
<br />
For full information about include file path expectations, see the official cPanel documentation at [https://documentation.cpanel.net/display/EA4/Modify+Apache+Virtual+Hosts+with+Include+Files Modify Apache Virtual Hosts with Include Files]<br />
<br />
Step 1) Create the following paths, replacing <user> and <domain> with the correct values for your needs:<br />
<br />
* mkdir -p /etc/apache2/conf.d/userdata/ssl/2_4/<user>/<domain><br />
* mkdir -p /etc/apache2/conf.d/userdata/std/2_4/<user>/<domain><br />
<br />
Step 2) In each of the above paths, create a file named 'vhost.conf'<br />
<br />
Step 3) Add in the lines below to this file:<br />
<br />
<pre><br />
<IfModule mod_security2.c><br />
SecRuleEngine Off<br />
</IfModule><br />
</pre><br />
<br />
Step 4) After any addition, modification or removal of userdata files, cPanel requires both of the following scripts to be run:<br />
<br />
* /usr/local/cpanel/scripts/rebuildhttpdconf<br />
* /usr/local/cpanel/scripts/restartsrv_httpd<br />
<br />
<br />
===== For Cpanel based systems with EasyApache 3 =====<br />
<br />
Step 1) Create the custom modsecurity configuration directory for the domain<br />
<br />
For example, if the domain is example.com, you would need to create this directory:<br />
<br />
<br />
mkdir /usr/local/apache/conf/userdata/std/2/username/example.com<br />
<br />
Step 2) Create the file vhost.conf in this directory<br />
<br />
cd /usr/local/apache/conf/userdata/std/2/username/example.com<br />
<br />
touch vhost.conf<br />
<br />
Step 3) Add in the lines below to this file:<br />
<br />
<pre><br />
<IfModule mod_security2.c><br />
SecRuleEngine Off<br />
</IfModule><br />
</pre><br />
<br />
Step 4) Run the vhost includes script, for example if the domains username is "example":<br />
<br />
/scripts/ensure_vhost_includes --user=example<br />
<br />
==== Disabling Mod_security per domain for an IP address ====<br />
<br />
===== For Plesk based systems =====<br />
<br />
For Plesk and similar systems you can also disable modsecurity in the Apache configuration.<br />
<br />
Step 1) Edit the vhost/vhost_ssl.conf for the domain<br />
vim /var/www/vhosts/<DOMAINNAME>/conf/vhost.conf<br />
<br />
Step 2) Add the following<br />
<IfModule mod_security2.c><br />
SecRule REMOTE_ADDR "^1.2.3.4$" "phase:1,t:none,nolog,allow,ctl:ruleEngine=Off,ctl:auditEngine=Off,id:9999"<br />
</IfModule><br />
<br />
'''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.'''<br />
<br />
Then restart apache, if you are using Plesk then you will also need follow steps 3 and 4.<br />
<br />
Step 3) Add vhost.conf to domain config <br />
<br />
Plesk 9:<br />
/usr/local/psa/admin/bin/websrvmng -a<br />
<br />
Plesk 10/11:<br />
/usr/local/psa/admin/bin/httpdmng --reconfigure-domain <domain_name><br />
<br />
Step 4) Restart Apache<br />
service httpd restart<br />
<br />
===== For cpanel based systems =====<br />
<br />
Step 1) Create the custom modsecurity configuration directory for the domain<br />
<br />
For example, if the domain is example.com, you would need to create this directory:<br />
<br />
mkdir /usr/local/apache/conf/userdata/std/2/username/example.com<br />
<br />
Step 2) Create the file vhost.conf in this directory<br />
<br />
cd /usr/local/apache/conf/userdata/std/2/username/example.com<br />
<br />
touch vhost.conf<br />
<br />
Step 3) Add in the lines below to this file:<br />
<br />
<IfModule mod_security2.c><br />
SecRule REMOTE_ADDR "^1.2.3.4$" "phase:1,t:none,nolog,allow,ctl:ruleEngine=Off,ctl:auditEngine=Off,id:9999"<br />
</IfModule><br />
<br />
'''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.'''<br />
<br />
Step 4) Run the vhost includes script, for example if the domains username is "example":<br />
<br />
/scripts/ensure_vhost_includes –user=example<br />
<br />
==== Disable a rule for a single domain ====<br />
<br />
'''If you have ASL installed''':<br />
<br />
Method 1:<br />
<br />
Log into the ASL GUI, and click on the "ASL" tab. Then click "WAF & HIDS Rules", 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.<br />
<br />
Type in the hostname into the Text box on the left side of the options you want to exclude the rule for, then click "add".<br />
<br />
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, or a regular expression *.example.com.<br />
<br />
Note: You can use regular expressions in this field, but each end of the expression is anchored.<br />
<br />
<br />
Method 2: Run this command as root:<br />
<br />
In ASL v3.x:<br />
asl -dr RULE_ID --vhost www.example.com<br />
<br />
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:<br />
<br />
asl -dr RULE_ID --vhost www.example.com<br />
<br />
asl -dr RULE_ID --vhost ftp.example.com<br />
<br />
asl -dr RULE_ID --vhost example.com<br />
<br />
<br />
In ASL v4:<br />
asl -drv RULE_ID[,RULE_ID...] VHOST[,VHOST...]<br />
or <br />
asl --disable-rule-vhost RULE_ID[,RULE_ID...] VHOST[,VHOST...]<br />
<br />
All supplied rules will be disabled on all supplied vhosts.<br />
<br />
asl -drv 111111,222222,333333 www.example.com,ftp.example.com,example.com<br />
<br />
<br />
<br />
<br />
'''If you do not have ASL installed''' you will have to do this manually:<br />
<br />
Step 1) Edit your domains vhost.conf file (the location of this file will vary based on your control panel, contact your control panel vendor for assistance)<br />
<br />
vim vhost.conf<br />
<br />
Step 2) Add the LocationMatch for the rule to exclude. Example, ruleid 950005<br />
<LocationMatch .*><br />
<IfModule mod_security2.c><br />
SecRuleRemoveById 950005<br />
</IfModule><br />
</LocationMatch><br />
<br />
If you want to disable multiple rules:<br />
<br />
Step 2) Add the LocationMatch for the rule to exclude. Example, ruleids 950005 and 950006<br />
<LocationMatch .*><br />
<IfModule mod_security2.c><br />
SecRuleRemoveById 950005<br />
SecRuleRemoveById 950006<br />
</IfModule><br />
</LocationMatch><br />
<br />
==== Disable a rule for all domains ====<br />
<br />
Method 1:<br />
<br />
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.<br />
<br />
Set "disabled" to yes and click update.<br />
<br />
Method 2:<br />
<br />
Use ASL utility to disable rule by ID. Example: 950005<br />
asl --disable-rule 950005<br />
<br />
Note: This requires that [[Atomic Secured Linux]] be installed.<br />
'''<br />
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:<br />
<br />
<LocationMatch .*><br />
<IfModule mod_security2.c><br />
SecRuleRemoveById 340000<br />
</IfModule><br />
</LocationMatch><br />
<br />
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.<br />
<br />
=== Per IP or network ===<br />
<br />
==== Disable Mod_security for an IP address ====<br />
<br />
In ASL, just click the "Whitelist" button.<br />
<br />
If you are not using ASL, simply add your IP address to the file:<br />
<br />
/etc/asl/whitelist<br />
<br />
And restart Apache.<br />
<br />
Note: For this rule to work, in ASL you must have the MODSEC_00_WHITELIST ruleset enabled.<br />
<br />
If you are not using ASL, then you must have the 00_asl_whitelist.conf ruleset loaded.<br />
<br />
==== Whitelist an IP ====<br />
<br />
See above, "Disable Mod_security for an IP address"<br />
<br />
==== Disable a rule by IP or network====<br />
<br />
You will need to create a custom rule, loaded after all your other rules. Lets say you wanted to exclude rule id 330039 for the network 1.2.0.0/16. You would construct a custom rule like this:<br />
<br />
<pre><br />
SecRule REMOTE_HOST "@ipmatch 1.2.0.0/16" \<br />
"id:12345,phase:2,t:none,pass,nolog,noauditlog,ctl:ruleRemovebyID=330039"<br />
</pre><br />
<br />
Note: ipmatch can also use a list, with a combination of IPs and network for example:<br />
<br />
@ipmatch 1.2.0.0/16,5.6.7.8,127.0.0.0/8<br />
<br />
Warning: If the CIDR is invalid, this may cause a segfault of the mod_security module. Check to make sure your CIDR is valid before use.<br />
<br />
=== Per application ===<br />
<br />
==== Disable modsecurity for a specific web application ====<br />
<br />
Note: this is not recommended<br />
<br />
Add a custom rule (see the section below on creating [https://www.atomicorp.com/wiki/index.php/Mod_security#Creating_custom_rules custom rules]) after all your rules have been loaded. For example, if you wanted to disable modsecurity for the application /foo/bar.cgi you would add a custom rule like this:<br />
<br />
<pre><br />
<LocationMatch /foo/bar.cgi><br />
SecRuleEngine Off<br />
<br />
</LocationMatch><br />
</pre><br />
<br />
<br />
<br />
==== Disable a rule for a specific web application ====<br />
Add a custom rule (see the section below on creating [https://www.atomicorp.com/wiki/index.php/Mod_security#Creating_custom_rules custom rules]) after all your rules have been loaded. For example, if you wanted to disable rule 950005, you would add a custom rule like this:<br />
<br />
<pre><br />
<LocationMatch /URL/path/to/application.php><br />
SecRuleRemoveById 950005<br />
<br />
</LocationMatch><br />
</pre><br />
<br />
==== Disable a rule for a single domain or FQDN ====<br />
<br />
===== For non control panel systems =====<br />
<br />
If you are using any of our GUI products, just click on the rule event, and type in the domain or hostname you want to exclude for this rule. <br />
<br />
For DIY users, you will need to create custom rules that load *before* the rule that you wish to exclude. This means you will need to add a custom rule file that loads before the rules we supply.<br />
<br />
Once you have set this up for your DIY modsecurity configuration, you will add a rule that inspects the Host: header sent by the client, which will the disable the rule(s) you wish to disable when that field is populated by that value. Keep in mind this field is completely controlled by the client, not the server. In the example below, the entire domain "example.com" is excluded for rule 123456:<br />
<br />
''SecRule REQUEST_HEADERS:Host ".example.com$" "phase:1,id:91010,t:none,t:lowercase,pass,nolog,noauditlog,ctl:ruleRemovebyID=123456"''<br />
<br />
Then restart the web server to apply this custom exclusion.<br />
<br />
===== For Plesk systems =====<br />
<br />
<br />
Step 1) Edit the virtual servers configuration for the domain for the domain<br />
<br />
Example:<br />
<br />
vim /var/www/vhosts/<DOMAINNAME>/conf/vhost.conf<br />
<br />
Step 2) Add the LocationMatch for the rule to exclude. Example, ruleid 950005<br />
<br />
<pre><br />
<LocationMatch /URL/path/to/application.php><br />
<br />
SecRuleRemoveById 950005<br />
</IfModule><br />
<br />
</pre><br />
<br />
==== Disable Mod_security rules globally for a specific application ====<br />
<br />
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.<br />
<br />
<LocationMatch /url/to/your/application><br />
<IfModule mod_security2.c><br />
SecRuleRemoveById 1234567<br />
SecRuleRemoveById 9999999<br />
</IfModule><br />
</LocationMatch><br />
<br />
Whats important to remember is that the LocationMatch variable must match the URL, not the path on the system.<br />
<br />
==== Disable Mod_security rules by domain, for a specific application, for a list of IPs ====<br />
<br />
Step 1) Edit the vhost/vhost_ssl.conf for the domain<br />
vim /var/www/vhosts/<DOMAINNAME>/conf/vhost.conf<br />
<br />
Step 2) Add the LocationMatch for the rule to exclude.<br />
<LocationMatch /foo/bar.php><br />
<IfModule mod_security2.c><br />
SecRule REMOTE_ADDR "@pmFromFile /etc/asl/whitelist" "nolog,phase:1,allow"<br />
</IfModule><br />
</LocationMatch><br />
<br />
Step 3) Add IP to /etc/asl/whitelist<br />
echo "10.11.12.13" >> /etc/asl/whitelist<br />
<br />
Or:<br />
<br />
If you want to create a special whitelist for just that application:<br />
<br />
Step 1) Edit the vhost/vhost_ssl.conf for the domain<br />
vim /var/www/vhosts/<DOMAINNAME>/conf/vhost.conf<br />
<br />
Step 2) Add the LocationMatch for the rule to exclude.<br />
<LocationMatch /foo/bar.php><br />
<IfModule mod_security2.c><br />
SecRule REMOTE_ADDR "@pmFromFile /path/to/your/custom/whitelist_for_this_application" "nolog,phase:1,allow,id:9999"<br />
</IfModule><br />
</LocationMatch><br />
<br />
'''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.'''<br />
<br />
<br />
Step 3) Create your custom whitelist and add IP to /etc/asl/whitelist<br />
echo "10.11.12.13" >> /path/to/your/custom/whitelist_for_this_application<br />
<br />
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.<br />
<br />
==== Disable rule for a specific argument for a specific application ====<br />
<br />
You can also tell modsecurity to change a rule, in some cases, without editing or forking the rule. For example, if you want to configure modsecurity to ignore a specific argument (in the argument below the argument is "foo"), for a specific application (in the example the application name is /example/application), for a specific rule (in the example below the rule if is 12345), you would create a custom rule like this:<br />
<br />
<br />
<pre><br />
SecRule REQUEST_URI "^/example/application" \<br />
"id:9999,phase:1,t:none,t:lowercase,nolog,pass,ctl:ruleRemoveTargetByID=12345;ARGS:foo"<br />
</pre><br />
<br />
As with all custom rules, this rule also needs a unique id as explained in the article above. And this type of custom rule must be loaded '''before''' the rule it modifies.<br />
<br />
Note: This does not support regular expressions for the excluded argument. At this time, they must be explicitly defined.<br />
<br />
==== Disable rule for a specific argument ====<br />
<br />
As is the example above, a rule can also be changed to exclude a specific argument, but for all applications. For example, if you want to configure modsecurity to ignore a specific argument (in the argument below the argument is "foo"), for a specific rule (in the example below the rule if is 12345), you would create a custom rule like this:<br />
<br />
<pre><br />
SecAction "phase:1,id:9999,t:none,auditlog,nolog,pass,ctl:ruleRemoveTargetById=12345;ARGS:foo"<br />
</pre><br />
<br />
As with all custom rules, this rule also needs a unique id as explained in the article above. And this type of custom rule must be loaded '''before''' the rule it modifies.<br />
<br />
Note: This does not support regular expressions for the excluded argument. At this time, they must be explicitly defined.<br />
<br />
==== Disable modsecurity for a specific argument ====<br />
<br />
As is the example above, modsecurity can also be configured to exclude a specific argument for all rules. For example, if you want to configure modsecurity to ignore a specific argument (in the argument below the argument is "foo"),you would create a custom rule like this:<br />
<br />
<pre><br />
SecAction "phase:1,id:9999,t:none,auditlog,nolog,pass,ctl:ruleRemoveTargetById=1-1000000;ARGS:foo"<br />
</pre><br />
<br />
When 1-100000 is the rule IDs you want to exclude. As with all custom rules, this rule also needs a unique id as explained in the article above. <br />
<br />
Note: This does not support regular expressions for the excluded argument. At this time, they must be explicitly defined.<br />
<br />
== Changing the action for a rule ==<br />
<br />
You can also change the default action for a rule by using the SecRuleActionById directive. <br />
<br />
=== Changing a rule to be detect only by ID===<br />
<br />
To change a rule to only detect, but not block attacks, simply change the action for the rule with the above directive. For example, to change the action for rule 12345, simply add this rule directive to your custom rules. <br />
<br />
SecRuleUpdateActionById 12345 "pass,status:200"<br />
<br />
Note 1: this directive must be added after the rule it is modifying has been loaded.<br />
<br />
Note 2: This does not work if you are using the redirect action.<br />
<br />
=== Changing a range of rules ot be detect only by ID===<br />
<br />
This is similar to the method above, however you can define a range of rule IDs. For example, if you want to disable rules 1000-2000:<br />
<br />
SecRuleUpdateActionById 1000-2000 "pass,status:200"<br />
<br />
Note 1: this directive must be added after the rule it is modifying has been loaded.<br />
<br />
Note 2: This does not work if you are using the redirect action.<br />
<br />
== Disabling POST inspection for a specific URL ==<br />
<br />
Should you want to disable inspection of a POST for a specific URL, use the format below.<br />
<br />
Assuming the URL you wanted to skip POST inspection was "upload", your exclusion rule would look like this:<br />
<br />
''SecRule REQUEST_URI "^/upload" \<br />
"phase:1,id:1234567,t:none,t:lowercase,pass,nolog,ctl:requestBodyAccess=off"''<br />
<br />
Install this rule before any of your other rules. For example, in the file /etc/httpd/modsecurity.d/00_custom_exclude.conf.<br />
<br />
== Enabling rules for only specific domains ==<br />
<br />
If you wish to disable all the rules, except for specific domains, you need to copy in the two files from the subdirectory "special" where you have the rules installed. Then create this file:<br />
<br />
/etc/asl/custom_include_domains<br />
<br />
<br />
Include the domains and/or FQDNs you want the rules to apply to. Anything not on that list will cause those rules to skip all of our rules. <br />
<br />
#File must contain exactly one domain or FQDN per line. End of line markers (both LF and CRLF) will be stripped from each phrase and any whitespace trimmed from both the beginning and the end. Empty lines and comment lines (those beginning with the # character) will be ignored.<br />
#This file does not support metacharacters. (For example, * is not supported)<br />
<br />
Example:<br />
<br />
<br />
<pre><br />
www.example.com<br />
.foo.com<br />
</pre><br />
<br />
== Disabling rules using .htaccess ==<br />
<br />
This is a new feature in modsecurity 2.7.3. This capability is available if you compile modsecurity using this option:<br />
<br />
--enable-htaccess-config<br />
<br />
From there, you will be able to disable rules using .htaccess files. The format to disable a rule via .htaccess is:<br />
<br />
SecRuleRemoveById 12345<br />
<br />
Where 12345 is the rule id.<br />
<br />
'''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 and/or this option has not been enabled. <br />
<br />
Warning: Enabling this capability will allow users to disable rules, including on compromised accounts which may cause the system to become compromised. This capability was specifically disabled by default in modsecurity to prevent this from occurring. Use this option with extreme caution!<br />
<br />
=== Specific actions available in .htaccess ===<br />
<br />
<br />
* SecAction<br />
* SecRule<br />
* SecRuleRemoveByMsg<br />
* SecRuleRemoveByTag<br />
* SecRuleRemoveById<br />
* SecRuleUpdateActionById<br />
* SecRuleUpdateTargetById<br />
* SecRuleUpdateTargetByTag<br />
* SecRuleUpdateTargetByMsg<br />
<br />
'''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.<br />
<br />
Warning: Enabling this capability in modsecurity can allow an attacker to disable modsecurity rules that you may be using to protect the entire server. We do not recommend you enable this capability on a shared server.<br />
<br />
== Customizing a rule ==<br />
<br />
If you need to customize a rule do not change the asl*conf files. These files will be overwritten by updates. <br />
<br />
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.<br />
<br />
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:<br />
<br />
If you had an original rule like this:<br />
<br />
SecRule REQUEST_URI "/foo" "t:normalisePath,id:9000,rev:1,severity:2,msg:'Atomicorp.com WAF Rules: Block /foo'"<br />
<br />
<br />
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.<br />
<br />
SecRuleRemoveById 9000000<br />
SecRule REQUEST_URI "/bar" "t:normalisePath,id:9999,rev:1,severity:2,msg:'Atomicorp.com WAF Rules: Block /foo'"<br />
<br />
'''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.'''<br />
<br />
<br />
These are the reserved ranges:<br />
<br />
* 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.<br />
* 100,000-199,999; reserved for internal use of the engine, to assign to rules that do not have explicit IDs.<br />
* 200,000-299,999; reserved for rules published at modsecurity.org.<br />
* 300,000-399,999; reserved for rules published at gotroot.com.<br />
* 400,000-419,999; unused (available for reservation).<br />
* 420,000-429,999; reserved for ScallyWhack.<br />
* 430,000-699,999; unused (available for reservation).<br />
* 700,000-799,999; reserved for Ivan Ristic.<br />
* 900,000-999,999; reserved for the Core Rules project.<br />
* 1,000,000 and above; unused (available for reservation).<br />
<br />
=== For a domain ===<br />
<br />
==== Apache ====<br />
<br />
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.<br />
<br />
==== Changing the argument separator ====<br />
<br />
If you have a web application that uses the uncommon ";" argument separator, as opposed to the widely used "&" you will want to change SecArgumentSeparator value for that application. You can do this in one of two ways:<br />
<br />
1) Globally<br />
<br />
If all your applications use the older delimiter, just change the SecArgumentSeparator in the tortix_waf.conf file. Do not change this if your applications use other delimiters.<br />
<br />
''SecArgumentSeparator ";"'' <br />
<br />
2) Per Application<br />
<br />
You can also configure this per application. For example, if your web applications URL is /foo/bar.php you can create a customer rule like this:<br />
<br />
<br />
<pre><br />
<LocationMatch /foo/bar.php><br />
SecArgumentSeparator ";"<br />
</LocationMatch><br />
</pre><br />
<br />
This will only work if modsecurity is loaded before your virtual host definitions. This is the case with most control panels, but some control panels are known to load modsecurity after vhosts are defined. In which case this will fail because Apache will not know how to process this directive (it will need modsecurity loaded to understand what this means). If you get a syntax error, that means your apache configuration is loaded modsecurity after your vhosts are defined. You will need to change your apache configuration to ensure this loading occurs before vhosts are defined.<br />
<br />
[[ASL]] will automatically configure modsecurity to load first.<br />
<br />
= Creating custom rules =<br />
<br />
== Discussion ==<br />
<br />
If you need to create your own custom rules, do not change the asl*conf files. These files will be overwritten by updates. <br />
<br />
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.<br />
<br />
== Rule Ids for custom rules ==<br />
<br />
For custom rules, '''you must create your own rule ids which must be unique'''. The id: fields contain the rule ids. For custom rules you should use the local (internal) use range (see below for the reserved id ranges). '''Do not use assigned ranges.'''<br />
<br />
These are the reserved ranges:<br />
<br />
* 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.<br />
* 100,000-199,999; reserved for internal use of the engine, to assign to rules that do not have explicit IDs. (deprecated, all rules require assigned ids in 2.7.x and up)<br />
* 200,000-299,999; reserved for rules published at modsecurity.org.<br />
* 300,000-399,999; reserved for rules published by atomicorp.com<br />
* 400,000-419,999; unused (available for reservation).<br />
* 420,000-429,999; reserved for ScallyWhack.<br />
* 430,000-699,999; unused (available for reservation).<br />
* 700,000-799,999; reserved for Ivan Ristic.<br />
* 900,000-999,999; reserved for the Core Rules project.<br />
* 1,000,000 and above; unused (available for reservation).<br />
<br />
== Installing custom rules ==<br />
<br />
<br />
=== Linux ===<br />
<br />
==== Apache ====<br />
<br />
'''Step 1) Create your custom rules directory:'''<br />
<br />
''mkdir /etc/httpd/modsecurity.custom.d''<br />
<br />
'''Step 2) Create a configuration file for your custom rules in /etc/httpd/conf.d directory. For example:'''<br />
<br />
Create the file 01_modsecurity.conf and add this line to it:<br />
<br />
''Include modsecurity.custom.d/[https://www.atomicorp.com/examples/99_zzz_custom.conf 99_zzz_custom.conf]''<br />
<br />
You can download an example file from the URL below that will do this:<br />
<br />
[https://www.atomicorp.com/examples/01_modsecurity.conf 01_modsecurity.conf]<br />
<br />
And add 01_modsecurity.conf to this directory:<br />
<br />
/etc/httpd/conf.d<br />
<br />
If you have wget installed on your system, the following commands will do this automatically for you:<br />
''<br />
<br />
cd /etc/httpd/conf.d<br />
<br />
wget https://www.atomicorp.com/examples/01_modsecurity.conf''<br />
<br />
Note: 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. Please contact your control panel vendor for assistance.<br />
<br />
'''Step 3) Install your custom rules in the /etc/httpd/modsecurity.custom.d directory'''<br />
<br />
''cd /etc/httpd/modsecurity.custom.d''<br />
<br />
and edit the file 99_zzz_custom.conf and put in your custom rules.<br />
<br />
You can also download an example custom rule file by running these commands:<br />
<br />
''cd /etc/httpd/modsecurity.custom.d<br />
<br />
wget https://www.atomicorp.com/examples/99_zzz_custom.conf''<br />
<br />
'''Step 4) Test your apache configuration'''<br />
<br />
''service httpd configtest''<br />
<br />
If you have any errors, do not restart apache. You will need to correct these errors or apache will not start.<br />
<br />
'''Step 5) If your test was successful, restart apache.'''<br />
<br />
''service httpd restart''<br />
<br />
Our professional services group would be happy to help you with your custom rules needs, including developing the rules for you. If your request is something that we can safely include in the rules for all our customers, we're generally able to develop these new rules for free. Please contact us to discuss your rules needs.<br />
<br />
=== Windows ===<br />
<br />
==== IIS ====<br />
<br />
'''Step 1) Modify your modsecurity configuration file on windows and add this line to the end of your configuration. For example:'''<br />
<br />
''Include [https://www.atomicorp.com/examples/99_zzz_custom.conf 99_zzz_custom.conf]''<br />
<br />
'''Step 2) Edit the file 99_zzz_custom.conf and save it in the same directory as your modsecurity config file'''<br />
<br />
'''Step 3)Restart IIS'''<br />
<br />
<br />
Our professional services group would be happy to help you with your custom rules needs, including developing the rules for you. If your request is something that we can safely include in the rules for all our customers, we're generally able to develop these new rules for free. Please contact us to discuss your rules needs.<br />
<br />
== Modifying a rule ==<br />
<br />
If you want to modify the internal logic of a rule, you will want to "fork" or copy that rule into a custom rule. Do not modify the actual rules provided by us, your modifications will be overwritten with the next update.<br />
<br />
'''Step 1: Copy the rule you want to modify into your custom rules file.'''<br />
<br />
Copy the rule in its entirety into your custom rule file. For example, if you wanted to modify rule 390707, you would copy the entire rule into your custom rules file. For example:<br />
<br />
<pre><br />
# Restrict the maximum number of arguments in a request<br />
SecRule &ARGS "@gt 1000" \<br />
"chain,phase:2,t:none,log,auditlog,deny,status:403,msg:'Atomicorp.com WAF Rules: Too many arguments in request (max set to 1000, increase as necessary for your system)',id:'390707',severity:'4',rev:'8'"<br />
SecRule REQUEST_URI "!((?:^/(?:imaclean|massdelete)/)|^/cgi-bin/dada/mail\.cgi$|^/index\.php/mageworx/customoptions_options|^/za/|^/back-?office/|^/moderate\.php|^/backend/configdomains\.php|\.do$|^/admin[a-z0-9]+?/index\.php\?controller=adminmodules)" "t:none,t:lowercase"<br />
</pre><br />
<br />
'''Step 2: Change the rule id.''' <br />
<br />
This is absolutely required. No two rules can have the same ID. See this article for chosing a custom rule id: https://wiki.atomicorp.com/wiki/index.php/Mod_security#Rule_Ids_for_custom_rules<br />
<br />
For example:<br />
<br />
<pre><br />
# Restrict the maximum number of arguments in a request<br />
SecRule &ARGS "@gt 1000" \<br />
"chain,phase:2,t:none,log,auditlog,deny,status:403,msg:'Atomicorp.com WAF Rules: Too many arguments in request (max set to 1000, increase as necessary for your system)',id:'12345678',severity:'4',rev:'8'"<br />
SecRule REQUEST_URI "!((?:^/(?:imaclean|massdelete)/)|^/cgi-bin/dada/mail\.cgi$|^/index\.php/mageworx/customoptions_options|^/za/|^/back-?office/|^/moderate\.php|^/backend/configdomains\.php|\.do$|^/admin[a-z0-9]+?/index\.php\?controller=adminmodules)" "t:none,t:lowercase"<br />
</pre><br />
<br />
'''Step 3: Disable the original rule'''<br />
<br />
If you want your custom rule to be global, that is your modification applies to the entire system, then you will want to disable the original rule per this article:<br />
<br />
https://wiki.atomicorp.com/wiki/index.php/Mod_security#Disable_a_rule_for_all_domains<br />
<br />
If you want to disable the rule for a single application, see this article:<br />
<br />
https://wiki.atomicorp.com/wiki/index.php/Mod_security#Disable_a_rule_for_a_specific_web_application<br />
<br />
If you want to disable the rule for a specific IP or network:<br />
<br />
https://wiki.atomicorp.com/wiki/index.php/Mod_security#Disable_a_rule_by_IP_or_network<br />
<br />
If you want to disable the rule for a single domain:<br />
<br />
https://wiki.atomicorp.com/wiki/index.php/Mod_security#Disable_a_rule_for_a_single_domain<br />
<br />
'''Step 4: Set the scope of the rule.'''<br />
<br />
If you havent disabled the original rule globally, or for one or more domains, then you will need to set the scope of your custom rule. To limit your modification to a specific application, place your custom rule inside <LocationMatch> tags. For example:<br />
<br />
<pre><br />
<br />
<LocationMatch /url/to/your/custom/application><br />
# Restrict the maximum number of arguments in a request<br />
SecRule &ARGS "@gt 2048" \<br />
"chain,phase:2,t:none,log,auditlog,deny,status:403,msg:'Atomicorp.com WAF Rules: Too many arguments in request (max set to 1000, increase as necessary for your system)',id:'12345678',severity:'4',rev:'8'"<br />
SecRule REQUEST_URI "!((?:^/(?:imaclean|massdelete)/)|^/cgi-bin/dada/mail\.cgi$|^/index\.php/mageworx/customoptions_options|^/za/|^/back-?office/|^/moderate\.php|^/backend/configdomains\.php|\.do$|^/admin[a-z0-9]+?/index\.php\?controller=adminmodules)" "t:none,t:lowercase"<br />
</LocationMatch><br />
<br />
</pre><br />
<br />
= Configuring and Setting up mod_security =<br />
'''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.'''<br />
<br />
To setup and configured modsecurity, please see the [[Atomic_ModSecurity_Rules]] wiki page.</div>Mshinnhttps://wiki.atomicorp.com/wiki/index.php/LitespeedLitespeed2022-07-26T21:29:29Z<p>Mshinn: /* Do the modsecurity rules work with Litespeed */</p>
<hr />
<div>== Does ASL work with LiteSpeed? ==<br />
<br />
Yes, ASL is supported with LiteSpeed. <br />
<br />
== Do the modsecurity rules work with Litespeed ==<br />
<br />
'''Yes, when used with the [https://www.atomicorp.com/wiki/index.php/ASL_WAF#WAF_Tab ASL Transparent WAF (T-WAF)] in front of Litespeed all rules are supported.'''<br />
<br />
When using the rules without the ASL Transparent WAF, where the rules are only loaded directly into Litespeed, please see the official Litespeed page for what modsecurity features Litespeed supports: <br />
<br />
http://www.litespeedtech.com/support/wiki/doku.php?id=litespeed_wiki:mod_security_compatibility<br />
<br />
Currently, if you do not use the T-WAF, this means Litespeed does not support the following features:<br />
<br />
# Output analysis: This means Litespeed can not inspect the output from the web server. This means rules like malware detection, malicious shell prevention, brute force protection, data loss protection and other rules that analyze the output from the web server are not supported by Litespeed, unless you use [https://www.atomicorp.com/wiki/index.php/ASL_WAF#WAF_Tab the ASL Transparent WAF (T-WAF) in front of Litespeed].<br />
# XML inspection: Litespeed has chosen to not support XML inspection, this means XML based attacks are unfortunately not protected on that platform, unless you use [https://www.atomicorp.com/wiki/index.php/ASL_WAF#WAF_Tab the ASL Transparent WAF (T-WAF) in front of Litespeed].<br />
# Multi-part Upload protection: Litspeed does not support scanning attached files content in multi-part upload. If you use [https://www.atomicorp.com/wiki/index.php/ASL_WAF#WAF_Tab the ASL Transparent WAF (T-WAF) in front of Litespeed] you will be able to scan attached files in a multi-part upload.<br />
# lua: This is a language that lets us construct advanced rules. Currently they are used for advanced anti-spam protection and advanced SQLi and XSS injection protection. Therefore, these types of rules are not supported by Litespeed, unless you use [https://www.atomicorp.com/wiki/index.php/ASL_WAF#WAF_Tab the ASL Transparent WAF (T-WAF) in front of Litespeed].<br />
<br />
== How to configure a local WAF for litespeed ==<br />
<br />
=== ASL V ===<br />
<br />
Step 1) Log into ASL. <br />
<br />
Step 2) Click on the "ASL" tab. <br />
<br />
Step 3) Click on the "WAF Configuration" menu option. <br />
<br />
Step 4) Click the "Add" button.<br />
<br />
Step 5) In the "Add New TWAF Setting" window from the "Add protection for ..." drop down, select "Local Web Server"<br />
<br />
Step 6) Select the port that litespeed runs on. Normally this is port 80. <br />
<br />
Step 7) Check the SSL box<br />
<br />
Enter the file system path to your SSL certificate, and SSL key in the "Path to SSL Certificate" and "Path to SSL Key file" boxes.<br />
<br />
Step 8) Click Save<br />
<br />
=== ASL 4 ===<br />
<br />
Step 1) Log into ASL. <br />
<br />
Step 2) Click on the "Configuration" tab. <br />
<br />
Step 3) Click on the "WAF" tab and select "WAF configuration". <br />
<br />
Step 4) Click the "Add" button.<br />
<br />
Step 5) Select "Local Web Server" from the "Add protection for" drop down.<br />
<br />
Step 6) Select the port that litespeed runs on. Normally this is port 80. <br />
<br />
Step 7) Check the SSL box<br />
<br />
Enter the file system path to your SSL certificate, and SSL key in the "Path to SSL Certificate" and "Path to SSL Key file" boxes.<br />
<br />
Step 8) Click Save<br />
<br />
Note: Litespeed does not support the WAF in embedded mode.<br />
<br />
= Questions =<br />
<br />
== I've loaded the rules into Litespeed, does that mean they work with Litespeed? ==<br />
<br />
Yes, however please see the LSWS official page for what modsecurity features Litespeed supports and does not support. <br />
<br />
https://www.litespeedtech.com/support/wiki/doku.php/litespeed_wiki:config:mod_security-compatibility</div>Mshinnhttps://wiki.atomicorp.com/wiki/index.php/LitespeedLitespeed2022-07-26T21:28:32Z<p>Mshinn: /* I've loaded the rules into Litespeed, does that mean they work with Litespeed? */</p>
<hr />
<div>== Does ASL work with LiteSpeed? ==<br />
<br />
Yes, ASL is supported with LiteSpeed. <br />
<br />
== Do the modsecurity rules work with Litespeed ==<br />
<br />
'''When used with the [https://www.atomicorp.com/wiki/index.php/ASL_WAF#WAF_Tab ASL Transparent WAF (T-WAF)] in front of Litespeed all rules are supported.'''<br />
<br />
When using the rules without the ASL Transparent WAF (where the rules are only loaded directly into Litespeed), please see the official Litespeed page for what modsecurity features Litespeed supports: <br />
<br />
http://www.litespeedtech.com/support/wiki/doku.php?id=litespeed_wiki:mod_security_compatibility<br />
<br />
Currently, if you do not use the T-WAF, this means Litespeed does not support the following features:<br />
<br />
# Output analysis: This means Litespeed can not inspect the output from the web server. This means rules like malware detection, malicious shell prevention, brute force protection, data loss protection and other rules that analyze the output from the web server are not supported by Litespeed, unless you use [https://www.atomicorp.com/wiki/index.php/ASL_WAF#WAF_Tab the ASL Transparent WAF (T-WAF) in front of Litespeed].<br />
# XML inspection: Litespeed has chosen to not support XML inspection, this means XML based attacks are unfortunately not protected on that platform, unless you use [https://www.atomicorp.com/wiki/index.php/ASL_WAF#WAF_Tab the ASL Transparent WAF (T-WAF) in front of Litespeed].<br />
# Multi-part Upload protection: Litspeed does not support scanning attached files content in multi-part upload. If you use [https://www.atomicorp.com/wiki/index.php/ASL_WAF#WAF_Tab the ASL Transparent WAF (T-WAF) in front of Litespeed] you will be able to scan attached files in a multi-part upload.<br />
# lua: This is a language that lets us construct advanced rules. Currently they are used for advanced anti-spam protection and advanced SQLi and XSS injection protection. Therefore, these types of rules are not supported by Litespeed, unless you use [https://www.atomicorp.com/wiki/index.php/ASL_WAF#WAF_Tab the ASL Transparent WAF (T-WAF) in front of Litespeed].<br />
<br />
== How to configure a local WAF for litespeed ==<br />
<br />
=== ASL V ===<br />
<br />
Step 1) Log into ASL. <br />
<br />
Step 2) Click on the "ASL" tab. <br />
<br />
Step 3) Click on the "WAF Configuration" menu option. <br />
<br />
Step 4) Click the "Add" button.<br />
<br />
Step 5) In the "Add New TWAF Setting" window from the "Add protection for ..." drop down, select "Local Web Server"<br />
<br />
Step 6) Select the port that litespeed runs on. Normally this is port 80. <br />
<br />
Step 7) Check the SSL box<br />
<br />
Enter the file system path to your SSL certificate, and SSL key in the "Path to SSL Certificate" and "Path to SSL Key file" boxes.<br />
<br />
Step 8) Click Save<br />
<br />
=== ASL 4 ===<br />
<br />
Step 1) Log into ASL. <br />
<br />
Step 2) Click on the "Configuration" tab. <br />
<br />
Step 3) Click on the "WAF" tab and select "WAF configuration". <br />
<br />
Step 4) Click the "Add" button.<br />
<br />
Step 5) Select "Local Web Server" from the "Add protection for" drop down.<br />
<br />
Step 6) Select the port that litespeed runs on. Normally this is port 80. <br />
<br />
Step 7) Check the SSL box<br />
<br />
Enter the file system path to your SSL certificate, and SSL key in the "Path to SSL Certificate" and "Path to SSL Key file" boxes.<br />
<br />
Step 8) Click Save<br />
<br />
Note: Litespeed does not support the WAF in embedded mode.<br />
<br />
= Questions =<br />
<br />
== I've loaded the rules into Litespeed, does that mean they work with Litespeed? ==<br />
<br />
Yes, however please see the LSWS official page for what modsecurity features Litespeed supports and does not support. <br />
<br />
https://www.litespeedtech.com/support/wiki/doku.php/litespeed_wiki:config:mod_security-compatibility</div>Mshinnhttps://wiki.atomicorp.com/wiki/index.php/LitespeedLitespeed2022-07-26T21:28:14Z<p>Mshinn: /* I've loaded the rules into Litespeed, does that mean they work with Litespeed? */</p>
<hr />
<div>== Does ASL work with LiteSpeed? ==<br />
<br />
Yes, ASL is supported with LiteSpeed. <br />
<br />
== Do the modsecurity rules work with Litespeed ==<br />
<br />
'''When used with the [https://www.atomicorp.com/wiki/index.php/ASL_WAF#WAF_Tab ASL Transparent WAF (T-WAF)] in front of Litespeed all rules are supported.'''<br />
<br />
When using the rules without the ASL Transparent WAF (where the rules are only loaded directly into Litespeed), please see the official Litespeed page for what modsecurity features Litespeed supports: <br />
<br />
http://www.litespeedtech.com/support/wiki/doku.php?id=litespeed_wiki:mod_security_compatibility<br />
<br />
Currently, if you do not use the T-WAF, this means Litespeed does not support the following features:<br />
<br />
# Output analysis: This means Litespeed can not inspect the output from the web server. This means rules like malware detection, malicious shell prevention, brute force protection, data loss protection and other rules that analyze the output from the web server are not supported by Litespeed, unless you use [https://www.atomicorp.com/wiki/index.php/ASL_WAF#WAF_Tab the ASL Transparent WAF (T-WAF) in front of Litespeed].<br />
# XML inspection: Litespeed has chosen to not support XML inspection, this means XML based attacks are unfortunately not protected on that platform, unless you use [https://www.atomicorp.com/wiki/index.php/ASL_WAF#WAF_Tab the ASL Transparent WAF (T-WAF) in front of Litespeed].<br />
# Multi-part Upload protection: Litspeed does not support scanning attached files content in multi-part upload. If you use [https://www.atomicorp.com/wiki/index.php/ASL_WAF#WAF_Tab the ASL Transparent WAF (T-WAF) in front of Litespeed] you will be able to scan attached files in a multi-part upload.<br />
# lua: This is a language that lets us construct advanced rules. Currently they are used for advanced anti-spam protection and advanced SQLi and XSS injection protection. Therefore, these types of rules are not supported by Litespeed, unless you use [https://www.atomicorp.com/wiki/index.php/ASL_WAF#WAF_Tab the ASL Transparent WAF (T-WAF) in front of Litespeed].<br />
<br />
== How to configure a local WAF for litespeed ==<br />
<br />
=== ASL V ===<br />
<br />
Step 1) Log into ASL. <br />
<br />
Step 2) Click on the "ASL" tab. <br />
<br />
Step 3) Click on the "WAF Configuration" menu option. <br />
<br />
Step 4) Click the "Add" button.<br />
<br />
Step 5) In the "Add New TWAF Setting" window from the "Add protection for ..." drop down, select "Local Web Server"<br />
<br />
Step 6) Select the port that litespeed runs on. Normally this is port 80. <br />
<br />
Step 7) Check the SSL box<br />
<br />
Enter the file system path to your SSL certificate, and SSL key in the "Path to SSL Certificate" and "Path to SSL Key file" boxes.<br />
<br />
Step 8) Click Save<br />
<br />
=== ASL 4 ===<br />
<br />
Step 1) Log into ASL. <br />
<br />
Step 2) Click on the "Configuration" tab. <br />
<br />
Step 3) Click on the "WAF" tab and select "WAF configuration". <br />
<br />
Step 4) Click the "Add" button.<br />
<br />
Step 5) Select "Local Web Server" from the "Add protection for" drop down.<br />
<br />
Step 6) Select the port that litespeed runs on. Normally this is port 80. <br />
<br />
Step 7) Check the SSL box<br />
<br />
Enter the file system path to your SSL certificate, and SSL key in the "Path to SSL Certificate" and "Path to SSL Key file" boxes.<br />
<br />
Step 8) Click Save<br />
<br />
Note: Litespeed does not support the WAF in embedded mode.<br />
<br />
= Questions =<br />
<br />
== I've loaded the rules into Litespeed, does that mean they work with Litespeed? ==<br />
<br />
Yes, but please see the LSWS official page for what modsecurity features Litespeed supports and does not support. <br />
<br />
https://www.litespeedtech.com/support/wiki/doku.php/litespeed_wiki:config:mod_security-compatibility</div>Mshinnhttps://wiki.atomicorp.com/wiki/index.php/LitespeedLitespeed2022-07-26T21:27:32Z<p>Mshinn: /* Do the modsecurity rules work with Litespeed */</p>
<hr />
<div>== Does ASL work with LiteSpeed? ==<br />
<br />
Yes, ASL is supported with LiteSpeed. <br />
<br />
== Do the modsecurity rules work with Litespeed ==<br />
<br />
'''When used with the [https://www.atomicorp.com/wiki/index.php/ASL_WAF#WAF_Tab ASL Transparent WAF (T-WAF)] in front of Litespeed all rules are supported.'''<br />
<br />
When using the rules without the ASL Transparent WAF (where the rules are only loaded directly into Litespeed), please see the official Litespeed page for what modsecurity features Litespeed supports: <br />
<br />
http://www.litespeedtech.com/support/wiki/doku.php?id=litespeed_wiki:mod_security_compatibility<br />
<br />
Currently, if you do not use the T-WAF, this means Litespeed does not support the following features:<br />
<br />
# Output analysis: This means Litespeed can not inspect the output from the web server. This means rules like malware detection, malicious shell prevention, brute force protection, data loss protection and other rules that analyze the output from the web server are not supported by Litespeed, unless you use [https://www.atomicorp.com/wiki/index.php/ASL_WAF#WAF_Tab the ASL Transparent WAF (T-WAF) in front of Litespeed].<br />
# XML inspection: Litespeed has chosen to not support XML inspection, this means XML based attacks are unfortunately not protected on that platform, unless you use [https://www.atomicorp.com/wiki/index.php/ASL_WAF#WAF_Tab the ASL Transparent WAF (T-WAF) in front of Litespeed].<br />
# Multi-part Upload protection: Litspeed does not support scanning attached files content in multi-part upload. If you use [https://www.atomicorp.com/wiki/index.php/ASL_WAF#WAF_Tab the ASL Transparent WAF (T-WAF) in front of Litespeed] you will be able to scan attached files in a multi-part upload.<br />
# lua: This is a language that lets us construct advanced rules. Currently they are used for advanced anti-spam protection and advanced SQLi and XSS injection protection. Therefore, these types of rules are not supported by Litespeed, unless you use [https://www.atomicorp.com/wiki/index.php/ASL_WAF#WAF_Tab the ASL Transparent WAF (T-WAF) in front of Litespeed].<br />
<br />
== How to configure a local WAF for litespeed ==<br />
<br />
=== ASL V ===<br />
<br />
Step 1) Log into ASL. <br />
<br />
Step 2) Click on the "ASL" tab. <br />
<br />
Step 3) Click on the "WAF Configuration" menu option. <br />
<br />
Step 4) Click the "Add" button.<br />
<br />
Step 5) In the "Add New TWAF Setting" window from the "Add protection for ..." drop down, select "Local Web Server"<br />
<br />
Step 6) Select the port that litespeed runs on. Normally this is port 80. <br />
<br />
Step 7) Check the SSL box<br />
<br />
Enter the file system path to your SSL certificate, and SSL key in the "Path to SSL Certificate" and "Path to SSL Key file" boxes.<br />
<br />
Step 8) Click Save<br />
<br />
=== ASL 4 ===<br />
<br />
Step 1) Log into ASL. <br />
<br />
Step 2) Click on the "Configuration" tab. <br />
<br />
Step 3) Click on the "WAF" tab and select "WAF configuration". <br />
<br />
Step 4) Click the "Add" button.<br />
<br />
Step 5) Select "Local Web Server" from the "Add protection for" drop down.<br />
<br />
Step 6) Select the port that litespeed runs on. Normally this is port 80. <br />
<br />
Step 7) Check the SSL box<br />
<br />
Enter the file system path to your SSL certificate, and SSL key in the "Path to SSL Certificate" and "Path to SSL Key file" boxes.<br />
<br />
Step 8) Click Save<br />
<br />
Note: Litespeed does not support the WAF in embedded mode.<br />
<br />
= Questions =<br />
<br />
== I've loaded the rules into Litespeed, does that mean they work with Litespeed? ==<br />
<br />
Yes, but please see the LSWS official page for what language features Litespeed supports and does not support. <br />
<br />
https://www.litespeedtech.com/support/wiki/doku.php/litespeed_wiki:config:mod_security-compatibility</div>Mshinnhttps://wiki.atomicorp.com/wiki/index.php/ASL_WAFASL WAF2022-07-01T22:24:32Z<p>Mshinn: /* MODSEC_11_DLP */</p>
<hr />
<div>= Introduction =<br />
<br />
The ASL WAF has two non-exclusive modes operation:<br />
<br />
1) Embedded mode<br />
<br />
2) Transparent/Proxy mode (T-WAF)<br />
<br />
== Embedded mode ==<br />
<br />
Embedded mode works with Apache 2.x. ASL will install a special module in Apache to give it native WAF protection capabilities. This installation will occur when ASL is installed.<br />
<br />
== Proxy mode (T-WAF) ==<br />
<br />
Proxy mode or the Transparent WAF (T-WAF) system allows ASL to protect any HTTP and/or HTTPS service, either a local server (such as when using a web server that does not support embedded mode) or a remove server.<br />
<br />
= Configuration =<br />
<br />
The ASL WAF is initially configured during the install of ASL. If Apache is installed on the system, ASL will attempt to install the embedded WAF module. If Apache is installed on the system via package management, then this will occur automatically and you will not need to configure the WAF further to protect an installed Apache instance. <br />
<br />
Once ASL is installed, if you need to do so, you can configure the WAF through three parts of the ASL GUI:<br />
<br />
== WAF Tab ==<br />
<br />
This tab is used to setup the WAF. There are three types of WAF you can configure:<br />
<br />
=== embedded ===<br />
<br />
The embedded WAF is an apache module that is installed on any local Apache installations. This should be setup by default, if you are running apache on the system and a [https://www.atomicorp.com/wiki/index.php/ASL_FAQ#Apache supported version and build of Apache].<br />
<br />
=== local ===<br />
<br />
Note: You do not need to setup a local WAF for package managed installs of apache. ASL will detect if a package managed version of Apache is installed, and will install the WAF module into apache [https://www.atomicorp.com/wiki/index.php/ASL_WAF#embedded embedded mode], as described above. For custom apache installs, please follow these directions.<br />
<br />
This type of WAF is used to protect any local HTTP and/or HTTPS services that may be running on the system itself, where the embedded WAF module can not be used. For example, if the system was running a tomcat or litespeed web server, which do not support the embedded WAF module, or a control panel that uses it own web server (such as Plesk, Cpanel, Webmin, and others). You can configure a WAF to protect these services.<br />
<br />
To setup a local WAF simply follow these steps:<br />
<br />
Step 1) Log into the ASL GUI<br />
<br />
Step 2) Click the WAF tab<br />
<br />
Step 3) Select WAF Config<br />
<br />
This will pull up the WAF Config window, which will show the existing WAFs.<br />
<br />
Step 4) Click "Enable T-WAF". If you see "Disable T-WAF" this option has already been enabled.<br />
<br />
Step 5) Click "Add"<br />
<br />
This will will pull up the "Add WAF Config" window.<br />
<br />
Step 6) Click on the "Add protection for" drop down. Select "local"<br />
<br />
This will present you with two options:<br />
<br />
Local Port: Type in the local HTTP/HTTPS port you wish to protect. Only type in one port number.<br />
<br />
Note: Check if you have any embedded WAFs installed on the system before you do this. If you have an embedded WAF already installed on port 80, as should occur if you have Apache installed (and its package managed), then enabling the T-WAF in front of Apache would create a loop. Its not necessary to put a WAF in front of a service that is protected via embedded mode.<br />
<br />
SSL: Select this if the service you wish to protect is SSL based.<br />
<br />
If you select SSL, then you will see this additional options:<br />
<br />
Path to SSL Certificate: Provide the filesystem path to the SSL certificate for this service.<br />
<br />
Path to SSL Key file: Provide the filesystem path to the SSL key file for this service.<br />
<br />
Step 7) Then click Save<br />
<br />
Note: You do not need to reconfigure your web server to use a different port, ASL will transparently intercept the packets to your web server based on the port you configure above. If you change your web servers port, ASL will not intercept packets to that port.<br />
<br />
=== remote ===<br />
<br />
'''Note: You need a [https://www.atomicorp.com/amember/cart/index/index?c=9 reverse proxy ASL license] to use this feature. This feature will not work without a reverse proxy license.'''<br />
<br />
This type of WAF is used to protect any remote HTTP and/or HTTPS services that are not running on the system itself. For example, if you have a remote webserver you wish to protect, you can configure a WAF to protect these services. The remote WAF can support two proxy modes: domain based and IP based.<br />
<br />
==== name based remote ====<br />
<br />
Domain based or name nased WAFs allow you to use a single IP address on the WAF, and to direct WAF requests to different backend servers depending on their domain or full qualified domain name, or even to specific URL.<br />
<br />
==== IP based remote ====<br />
<br />
IP based WAFs allow you to redirect all traffic to an IP address on WAF to a specific destination host or URL.<br />
<br />
==== Setting up a remote WAF ====<br />
<br />
To setup a remote WAF simply follow these steps:<br />
<br />
Step 1) Log into the ASL GUI<br />
<br />
Step 2) Click the WAF tab<br />
<br />
Step 3) Select WAF Config<br />
<br />
This will pull up the WAF Config window, which will show the existing WAFs.<br />
<br />
Step 4) Click "Enable T-WAF". If you see "Disable T-WAF" this option has already been enabled.<br />
<br />
Step 5) Click "Add"<br />
<br />
This will will pull up the "Add WAF Config" window.<br />
<br />
Step 6) Click on the "Add protection for" drop down. Select "remote"<br />
<br />
This will present you with a dropdown options to setup the WAF as either domain based or IP based.<br />
<br />
Step 7) If you select name based you will be presented with these options:<br />
<br />
Domain Name: Enter the domain name or full qualified domain you wish to use. For example, if you want the WAF to handle traffic for intranet.example.com enter that FQDN in this box.<br />
<br />
Local Url: Enter the local URL, if any, that the WAF should expect from the client to direct this connection to the remote host. The default of / is usually correct if you are forwarding all traffic for an FQDN or domain. If you only want the WAF to pass on specific requests for specific URLs, enter them here. <br />
<br />
Destination: Enter the full URL you want the WAF to use as the destination server. Make sure you have DNS or /etc/hosts entries for this, otherwise the WAF will not be able to find the destination. This should also not be the same thing as "Domain Name:". You can also use https:// URLs here.<br />
<br />
Remote Port: Type in the remote port for the backend server the WAF will be sending requests to.<br />
<br />
SSL: Select SSL if you wish to accept SSL connections to the WAF. If you select this you will be presented with these additional options:<br />
<br />
Path to SSL Certificate: Provide the filesystem path to the SSL certificate for this service.<br />
<br />
Path to SSL Key file: Provide the filesystem path to the SSL key file for this service.<br />
<br />
Skip to step 8<br />
<br />
Step 7) If you select IP based you will be presented with these options<br />
<br />
IP Address: Enter the IP address you want the WAF to listen on (you can set multiple IPs by adding additional remote WAFs). For example, if you want the WAF to redirect all traffic on IP address 1.2.3.4 to internal.example.com, type in 1.2.3.4.<br />
<br />
Local Url: Enter the local URL, if any, that the WAF should expect from the client to direct this connection to the remote host. The default of / is usually correct if you are forwarding all traffic for an FQDN or domain. If you only want the WAF to pass on specific requests for specific URLs, enter them here. <br />
<br />
Destination: Enter the full URL you want the WAF to use as the destination server. Make sure you have DNS or /etc/hosts entries for this, otherwise the WAF will not be able to find the destination. This should also not be the same thing as "Domain Name:". You can also use https:// here.<br />
<br />
Remote Port: Type in the remote port for the backend server the WAF will be sending requests to.<br />
<br />
SSL: Select SSL if you wish to accept SSL connections to the WAF. If you select this you will be presented with these additional options:<br />
<br />
Path to SSL Certificate: Provide the filesystem path to the SSL certificate for this service.<br />
<br />
Path to SSL Key file: Provide the filesystem path to the SSL key file for this service.<br />
<br />
Step 8) Then click Save<br />
<br />
== SSL/TLS ==<br />
<br />
If you select SSL for either the local or remote WAF options, your SSL certificates and keys must be in an Apache compatible format to be imported by the T-WAF.<br />
<br />
== ASL Configuration Settings ==<br />
<br />
The WAFs settings are contained under the Configuration tab. To Configure the WAF follow this process:<br />
<br />
Step 1) Log into the ASL GUI<br />
<br />
Step 2) Click on the Settings Tab<br />
<br />
Step 3) Select the "ASL Configuration" sub menu<br />
<br />
Step 4) Scroll down to the "Web Application Firewall" configuration section. The following options are available:<br />
<br />
=== MODSEC_ENABLED ===<br />
<br />
This setting Enables/Disables the entire WAF system. This is the only supported method for disabling the WAF in ASL. Uninstalling mod_security and the use of third party methods to remove modsecurity will not work if this setting is still configured to enable the WAF. This setting is specifically designed to ensure that the WAF is not disabled accidentally by a third party product.<br />
<br />
=== WAF_ENGINE ===<br />
<br />
Set the WAF engine mode, there are three modes:<br />
<br />
On - this tells the WAF to detect and block attacks.<br />
<br />
DetectionOnly - this tells the WAF to only detect and report attacks, but not to block them.<br />
<br />
Off - Disables the WAF.<br />
<br />
=== WAF_ENABLED ===<br />
<br />
Enable/Disable Tortix WAF proxy. The tortix waf module, this module can process local or remote services through the Tortix Web Application Firewall (T-WAF) . (Default: Off)<br />
<br />
'''Note: This option is deprecated in ASL 4.'''<br />
<br />
=== WAF_CHROOTDIR ===<br />
<br />
Configures the directory path that will be used to jail the web server process. (For the embedded WAF modules only). This lets you put the local apache instance into a chroot jail.<br />
<br />
=== WAF_READSTATELIMIT ===<br />
<br />
Sets the limit of the number of connections from the same IP address that can be in the Read state for the WAF. This helps to prevent "slow" DOS attacks. For example, if this was set to "5" a single IP would only be able to keep 5 connections in a busy state with the web server at a single time.<br />
<br />
ASL 3 Default: 10<br />
<br />
ASL 4 Default: 100<br />
<br />
=== Write State Limit ===<br />
<br />
WAF_WRITESTATELIMIT: Sets the limit of the number of connections from the same IP address that can be in the Write state for the WAF. This helps to prevent "slow" DOS attacks. For example, if this was set to "5" a single IP would only be able to keep 5 connections in a busy state with the web server at a single time.<br />
<br />
(Default: 100)<br />
<br />
Note: This option is only available in ASL 4 and up.<br />
<br />
=== WAF_SECREQUESTBODYNOFILESLIMIT ===<br />
<br />
(Default: 1048576) Configures the maximum request body size the WAF modules will accept for buffering. There is a hard limit of 1GB. This is not a limit on file sizes sent through the WAF, just request body sizes.<br />
<br />
=== WAF_SECREQUESTBODYINMEMORYLIMIT ===<br />
<br />
(Default: 131072) Configures the maximum request body size the WAF modules will store in memory. There is a hard limit of 1GB. The default of 128 MB is generally sufficient for any site.<br />
<br />
=== WAF_DEFAULT_ACTION ===<br />
<br />
Configures the block policy, deny the request or redirect the client to a landing page. <br />
<br />
=== WAF_REDIRECT_URL ===<br />
<br />
Used for WAF_DEFAULT_ACTION of "redirect". This is the URL to redirect blocked pages. This must include http:// or https:// in the URL.<br />
<br />
Example:<br />
<br />
https://%{server_name}:30000/blocked.php?eventid=%{eventid}<br />
<br />
You can use variables in the URL. They must be represented in this format:<br />
<br />
<pre>%{variable_name}</pre><br />
<br />
'''Important Note:''' If you have [https://www.atomicorp.com/wiki/index.php/ASL_Configuration#OSSEC_ACTIVE_RESPONSE OSSEC_ACTIVE_RESPONSE] enabled, then redirects will not work as the systems firewall will still block the user. You must disable OSSEC_ACTIVE_RESPONSE to use redirects.<br />
<br />
==== Supported Variables ====<br />
<br />
Currently supported variables are listed below. As new variables are supported, we will add them to the documentation here. <br />
<br />
===== server_name =====<br />
<br />
This is the value the client sent in the Host: header, which would be the FQDN the client accessed.<br />
<br />
==== ruleid ====<br />
<br />
The rule ID for the rule that was triggered.<br />
<br />
===== unique_id =====<br />
<br />
The unique ID for each event recorded by the WAF.<br />
<br />
The variable UNIQUE_ID is set to the identifier for each request. The UNIQUE_ID environment variable is constructed by encoding the 112-bit (32-bit IP address, 32 bit pid, 32 bit time stamp, 16 bit counter) quadruple using the alphabet [A-Za-z0-9@-] in a manner similar to MIME base64 encoding, producing 19 characters.<br />
<br />
===== remote_addr =====<br />
<br />
The client IP address.<br />
<br />
===== server_port =====<br />
<br />
This variable contains the local port of the webserver that the request was received on.<br />
<br />
==== Experimental Variables ====<br />
<br />
These are additional variables that should be considered experimental, and are available in the engine, but are not currently supported. They require newer versions of modsecurity, which may not be available in the stable channel.<br />
<br />
===== auth_type =====<br />
<br />
This variable holds the authentication method used to validate a user, if any of the methods built into HTTP are used. In a reverse-proxy deployment, this information will not be available if the authentication is handled in the backend web server. <br />
<br />
===== remote_user =====<br />
<br />
This variable holds the username of the authenticated user. If there are no password access controls in place (Basic or Digest authentication), then this variable will be empty. <br />
<br />
===== time =====<br />
<br />
This variable holds a formatted string representing the time (hour:minute:second). <br />
<br />
===== time_day =====<br />
<br />
This variable holds the current date (1–31). <br />
<br />
===== time_epoch =====<br />
<br />
This variable holds the time in seconds since 1970. <br />
<br />
===== time_hour =====<br />
<br />
This variable holds the current hour value (0–23). <br />
<br />
===== time_min =====<br />
<br />
This variable holds the current minute value (0–59).<br />
<br />
===== time_mon =====<br />
<br />
This variable holds the current month value (0–11).<br />
<br />
===== time_sec =====<br />
<br />
This variable holds the current second value (0–59). <br />
<br />
===== time_wday =====<br />
<br />
This variable holds the current weekday value (0–6).<br />
<br />
===== time_year =====<br />
<br />
This variable holds the current four-digit year value. <br />
<br />
===== response_status =====<br />
<br />
This variable holds the HTTP response status code.<br />
<br />
===== request_protocol =====<br />
<br />
This variable holds the request method used in the transaction.<br />
<br />
===== useragent_ip =====<br />
<br />
This variable is created when running modsecurity with apache 2.4 and will contain the client ip address set by mod_remoteip in proxied connections. Requires mod_remoteip to be installed, and Apache 2.4.<br />
<br />
=== Intercept on error===<br />
<br />
WAF_SECINTERCEPTONERROR: Configures how to respond when rule processing fails. [Default: on]<br />
<br />
===Analyze response body===<br />
<br />
WAF_SECRESPONSEBODYACCESS: Configures whether response bodies are to be buffer and analysed or not. [Default: on]<br />
<br />
=== MODSEC_SERVERSIG ===<br />
<br />
Field returned when a remote host queries what kind of web server this is. This can be used to hide what kind of server is running on the system, or what the WAFs are protecting.<br />
<br />
=== MODSEC_UPLOADDIR ===<br />
<br />
Configures the directory where intercepted files will be stored. If the WAF is configured to scan uploads, and this is set to On, then any malicious files the WAF detects will be stored in this directory on the server. <br />
<br />
=== MODSEC_KEEPFILES ===<br />
<br />
Configures whether or not the intercepted files will be kept after transaction is processed. It is recommended you set to this off.<br />
<br />
=== MODSEC_LOGTYPE ===<br />
<br />
Configures the type of audit logging mechanism to be used. Concurrent - audit log entries will be stored in separate files, one for each transaction. Serial - all audit log entries will be stored in the main audit logging file. The default is Concurrent, which is both faster and more reliable and works with ASL Gui. Serial logging is for legacy purposes and should not be enabled.<br />
<br />
=== MODSEC_LOGFILE ===<br />
<br />
The name of the log file that is used to store audit record headers. Do not change this unless you know what you are doing. It is generally not necessary to change this setting.<br />
<br />
=== MODSEC_LOGELEMENT ===<br />
<br />
Defines which part of each transaction are going to be recorded in audit log. Do not change the defaults unless you know what you are doing, this may break the GUI and active response systems.<br />
<br />
Available audit log parts:<br />
<br />
A: Audit log header (mandatory).<br />
<br />
B: Request headers.<br />
<br />
C: Request body (present only if the request body exists and ModSecurity is configured to intercept it).<br />
<br />
D: Reserved for intermediary response headers; not implemented yet.<br />
<br />
E: Intermediary response body (present only if ModSecurity is configured to intercept response bodies, and if the audit log engine is configured to record it). Intermediary response body is the same as the actual response body unless ModSecurity intercepts the intermediary response body, in which case the actual response body will contain the error message (either the Apache default error message, or the ErrorDocument page).<br />
<br />
F: Final response headers (excluding the Date and Server headers, which are always added by Apache in the late stage of content delivery).<br />
<br />
G: Reserved for the actual response body; not implemented yet.<br />
<br />
H: Audit log trailer.<br />
<br />
I: This part is a replacement for part C. It will log the same data as C in all cases except when multipart/form-data encoding in used. In this case, it will log a fake application/x-www-form-urlencoded body that contains the information about parameters but not about the files. This is handy if you don’t want to have (often large) files stored in your audit logs.<br />
<br />
J: This part contains information about the files uploaded using multipart/form-data encoding.<br />
<br />
K: This part contains a full list of every rule that matched (one per line) in the order they were matched. The rules are fully qualified and will thus show inherited actions and default operators. <br />
<br />
Z: Final boundary, signifies the end of the entry (mandatory). <br />
<br />
=== MODSEC_REQMEMLIMIT ===<br />
<br />
Configures the maximum request body size ModSecurity will store in memory. The default are adequate for most sites, you should not change this unless you know what you are doing.<br />
<br />
=== MODSEC_DEBUGLOG ===<br />
<br />
Enable/Disable the ModSecurity debug log file. The debug log is located in /var/log/httpd/modsec_debug.log Enabling this will incur a substantial performance penalty on the system. You should not enable this on a production system, and only if you are debugging modsecurity rules.<br />
<br />
Most users will want to leave this disabled.<br />
<br />
=== MODSEC_CLEAN_ALERT ===<br />
<br />
Number of days to retain mod_security alert data. The WAF will store the actual full requests of any intercepted attacks, to make it possible for you to investigate them and to report these to us, either for further investigation, false positives or for other forensics needs. The default is to keep these for 30 days.<br />
<br />
Audit log events are kept in this directory by default:<br />
<br />
/var/asl/data/audit/<br />
<br />
=== MODSEC_DATADIR ===<br />
<br />
Path where persistent data (e.g. IP address data, session data, etc) is to be stored.<br />
<br />
=== MODSEC_AUDITDIR ===<br />
<br />
'''Warning: This setting is unsupported'''<br />
<br />
Defines the path to the audit log files. Used only when Concurrent mode is configured.<br />
<br />
=== MODSEC_TMPDIR ===<br />
<br />
Configures the directory where temporary files will be created.<br />
<br />
Note: If this is changed form the default of /tmp, the directory must be writable by apache, which means depending on how you have configured apache by whatever users the web application may be running as. For example, if you use suphp, then the web application will run as a specific user. The directory must be writable by that user. In that case, you will need to either create a group that all your users belong to and make sure that group can write to that directory, or you will need to make that directory world writable. We also recommend you set the sticky bit on the directory. The simplest solution is to set the directories permissions thusly:<br />
<br />
For example, if you change this directory to /var/asl/mod_sec_tmp, these permissions should work generically in all cases:<br />
<br />
chmod ogu+rwx /var/asl/mod_sec_tmp<br />
<br />
chmod o+t /var/asl/mod_sec_tmp<br />
<br />
=== MODSEC_RESPONSEBODYLIMIT ===<br />
<br />
Configures the maximum response body size that will be accepted for buffering.<br />
<br />
=== MODSEC_RESPONSEBODYLIMITACTION ===<br />
<br />
Controls what happens once a response body limit, configured with SecResponseBodyLimit, is encountered. There are two options:<br />
<br />
ProcessPartial: Scan the response up to the limit and stop scanning when the limit is reached, but send the rest of the response.<br />
<br />
Reject: If the response is greater than the Limit, reject the response entirely.<br />
<br />
=== MODSEC_REQUESTBODYLIMIT === <br />
<br />
This sets the maximum size for a request body in bytes. The default is 134217728 bytes.<br />
<br />
Anything over the limit will be rejected with status code 413 (Request Entity Too Large). There is a hard limit of 1 GB. <br />
<br />
==== Ruleset Settings ====<br />
<br />
These allow you to enable/disable entire Rulesets and classes of rules. If you want to configure a specific rule, use the Rule Manager.<br />
<br />
===== Crawler Protector =====<br />
<br />
This unique feature of [[ASL]] protects not only your system, but also your search engine rankings. Unlike other security products, ASL can automatically and securely detect real search engine crawlers and prevent your system from accidentally blocking them. It can also detect when attackers are trying to pretend to be search engines, in hopes of getting around your security systems, and can safely block them, without blocking the real crawlers!<br />
<br />
<br />
====== WAF_LUA_00_SEARCHENGINE ======<br />
<br />
This will protect your page rank with search engine crawlers, prevent search engines from being blocked and will also block attackers pretending to be search engine crawlers. It can securely determine if a bot is legitimate, or a forgery.<br />
<br />
Default: disabled<br />
<br />
'''Note: This ruleset will only perform this function if a client claims to be a search engine, and is much faster than the legacy system and does not require that apache be configured with HostNameLookups Double. While this is significantly faster than looking up the A and PTR records for all FQDNS, this ruleset should only be used if the ASL server has a [[local DNS resolver]] server installed on the ASL server.''' You can use a remote resolver, but a local resolver will be faster and more reliable.<br />
<br />
These rules require a locally installed DNS server for maximum performance. It is not recommended you enable these rules without a local DNS server installed on this server. <br />
<br />
Requires ASL 4.0.11 and up.<br />
<br />
====== Legacy system ======<br />
<br />
If you are using a version of modsecurity prior to 2.9.0 then you may want to use the legacy options below. Do not use the legacy options with 2.9.0 and above.<br />
<br />
======= MODSEC_00_SEARCHENGINE =======<br />
<br />
'''NOTE: This setting is deprecated and unsupported. Users should use the Lua method above.'''<br />
<br />
Bogus Search Engine Ruleset<br />
<br />
This ruleset will detect search engine crawlers, as well as attackers pretending to be search engine crawlers. It can securely determine if a bot is legitimate, or a forgery.<br />
<br />
Default: disabled<br />
<br />
'''Note: You should only use this ruleset if the ASL server has a [[local DNS resolver]] server installed on the ASL server.''' You can use a remote resolver, but a local resolver will be faster and more reliable.<br />
<br />
These rules require a locally installed DNS server for maximum performance. It is not recommended you enable these rules without a local DNS server installed on this server. (If you do not know if you have a DNS server installed on this server, do not enable these rules). Apache must also be configured with "HostnameLookups Double". ASL will attempt to configure HostnameLookups Double, but on non-standard systems, such as source build Apache installs and third party Apache installations this may not occur automatically. If you find that Apache is not resolving IP addresses, check to make sure HostnameLookups Double is configured for Apache.<br />
<br />
Note: These are legacy rules, and should not be used with modsecurity 2.9.x You should use these rules instead:<br />
<br />
http://wiki.atomicorp.com/wiki/index.php?title=ASL_WAF#WAF_LUA_00_SEARCHENGINE<br />
<br />
======= MODSEC_00_AUTOWHITELIST_SEARCHENGINE =======<br />
<br />
'''NOTE: This setting is deprecated and unsupported. Users should use the Lua method above.'''<br />
<br />
Autowhitelist Search Engine Ruleset<br />
<br />
This ruleset will automatically, and securely, whitelist search engine crawlers to prevent them from being blocked accidentally. This will protect your page rank with search engine crawlers.<br />
<br />
NOTE: This ruleset requires the MODSEC_00_SEARCENGINE setting to be enabled for this to work.<br />
<br />
Default: disabled<br />
<br />
Note: These are legacy rules, and should not be used with modsecurity 2.9.x You should use these rules instead:<br />
<br />
http://wiki.atomicorp.com/wiki/index.php?title=ASL_WAF#WAF_LUA_00_SEARCHENGINE<br />
<br />
'''Warning: You should only use this ruleset if the ASL server has a fast [[local DNS resolver]] server installed on the ASL server.'''<br />
<br />
===== MODSEC_00_WHITELIST =====<br />
<br />
Whitelist Ruleset<br />
<br />
Enable/Disable application of the whitelist '''for the WAF'''. <br />
<br />
''By default whitelisting does not apply to the WAF.''<br />
<br />
Note: enabling this will bypass *ALL* security checks for hosts on the whitelist '''for the WAF.'''<br />
<br />
Default: off<br />
<br />
By default, this is not enabled. <br />
<br />
ASL can respond to attacks in several different ways. The two that relate to the WAF are:<br />
<br />
*blocking<br />
*shunning<br />
<br />
Blocking is when ASL stops a single attack, and does not take any further action. <br />
<br />
Shunning is when ASL both block the single attack, and implement a firewall rule to block any further attacks from the same IP.<br />
<br />
ASL is configured to use the whitelist to prevent shunning by default, for IPs on the whitelist, but still to block attacks from that IP. This helps to prevent attacks from trusted sources, but prevents accidentally firewall rules when false positives occur. We do not recommend you disable blocking for trusted IPs. If you have a false positive, report it to us. Enabling this option tells ASL to totally ignore everything from the IPs on the whitelist, which includes not generating any alerts on this source and not to block anything. Which means if you do have a real attack from a trusted IP, you will not idea its occurred and theres nothing ASL can do to stop it.<br />
<br />
We dont recommend you you use this unless you know you can completely and totally trust every host on your whitelist every time. <br />
<br />
Most users will not need to enable this.<br />
<br />
Warning: We do not recommend you include your servers IP on this whitelist if you have a shared hosting server. Whitelisting localhost (127.0.0.1) and your local servers IP(s) from the WAF will means that local users can launch attacks against the server and against other domains on the server which will be neither detected nor prevented. If you have a rule that is being triggered by a local script, please report it as a false positive if it is a false positive, and if not, this may be an actual attack on your system or a poorly developed application. If you have a false positive from a whitelisted IP, please report it to us. Whitelisting in general is extremely dangerous and attackers know that users do this, which is why they target desktops and other trusted systems. If they can get access to these trusted systems, they can usually gain unfetered access to everything that users desktop, mobile device, laptop or other trusted system can access.<br />
<br />
Note: This ruleset requires this file to exist:<br />
<br />
/etc/asl/whitelist<br />
<br />
The format is one IP or CIDR per line. For example:<br />
<br />
<pre><br />
1.2.3.4<br />
10.0.0.0/8<br />
</pre><br />
<br />
=====MODSEC_00_BLACKLIST=====<br />
<br />
Blacklist Ruleset<br />
<br />
Enable/Disable application of the blacklist '''for the WAF'''. <br />
<br />
''By default blacklist is accomplished at Layer 3, and this ruleset is not necessary for most systems. This ruleset is only necessary if your configuration does not allow you to block attackers at Layer 3, such as when the system is behind a layer 7 proxy or load balancer.''<br />
<br />
Note: enabling this will block all IPs on the users custom blacklist '''for the WAF.'''<br />
<br />
Default: off<br />
<br />
ASL can respond to attacks in several different ways. The two that relate to the WAF are:<br />
<br />
*blocking<br />
*shunning<br />
<br />
Blocking is when ASL stops a single attack, and does not take any further action. <br />
<br />
Shunning is when ASL both blocks the single attack, and implements a layer 3 firewall rule to block any further attacks from the same IP.<br />
<br />
ASL is configured to use the blacklist to block all IPs at layer 3. It is not configured by default to do this at layer 7, the WAF, as this is generally not necessary for most systems. Most users will not need to enable this.<br />
<br />
Note: This ruleset requires this file to exist:<br />
<br />
/etc/asl/blacklist<br />
<br />
The format is one IP or CIDR per line. For example:<br />
<br />
<pre><br />
1.2.3.4<br />
10.0.0.0/8<br />
</pre><br />
<br />
Requires ASL 4.0.15 and up.<br />
<br />
===== MODSEC_00_THREAT =====<br />
<br />
Threat Intelligence System<br />
<br />
Enabling this allows your system to use Atomicorp Threat Intelligence system to block knownn attackers.<br />
<br />
'''Important: It is highly recommended you enable these rules only with a local DNS resolver installed and configured on the system. (If you do not know if you have a local DNS resolver installed and configured on your system, do not enable these rules until you have confirmed that you do).''' Please see this article for information on [[Local DNS resolver]]s.<br />
<br />
Note: hosts on the whitelist are automatically excluded from being blocked by this ruleset.<br />
<br />
===== MODSEC_00_ANTIEVASION =====<br />
<br />
Antievasion Ruleset<br />
<br />
Enable/Disable the antievasion rule class. This ruleset prevents attacks that try to bypass the WAF itself.<br />
<br />
===== MODSEC_00_STRICT ===== <br />
<br />
Strict Multiform Ruleset<br />
<br />
Enable/Disable the strict multiform checks rule class. This ruleset enforces strict adherence RFCs for multiform messages, strictly enforces allowed types and implements enhanced checks on inputs. This prevents advanced attacks that may try to bypass the WAF, or involve more complex evasion attacks. <br />
<br />
Note: Broken applications and clients that do not adhere to RFCs will not be able to send multiform to the system if you enable this. This not a false positive, these clients and applications are broken. If you are unfortunately stuck with these, you will have to disable this.<br />
<br />
===== MODSEC_00_RBL ===== <br />
<br />
RBL Ruleset<br />
<br />
Enable/Disable Real-time Black List (RBL) rule class. Currently this uses the [http://www.spamhaus.org/xbl/ Spamhaus XBL] which is operated by the Spamhaus project. This RBL is not operated or controlled by Atomicorp. Please contact Spamhaus if you have issues with the IPs on this RBL, or disable this option.<br />
<br />
'''Default: off'''<br />
<br />
'''Warning: You should only use this ruleset if the ASL server has a really fast DNS server installed on the ASL server.''' <br />
<br />
This ruleset will look up every request in the DNS to see if its on a blacklist, and will not finish serving the request until the DNS server responds. This can slow down requests if the DNS server is slow. Basically, web requests will move at the speed of the DNS servers replies.<br />
<br />
If your web server is responding slowly to requests, and you have this ruleset enabled your DNS server is too slow to meet your lookup needs. You will need to either disable this ruleset, or tune your DNS server to respond to queries more quickly.<br />
<br />
===== MODSEC_00_AE_RULES =====<br />
<br />
'''Anti-Evasion Protection system'''<br />
<br />
Antievasion Ruleset/MODSEC_00_ANTIEVASION: Enable/Disable the antievasion rule class. This ruleset prevents attacks that try to bypass the WAF itself.<br />
<br />
===== MODSEC_01_RULES ===== <br />
<br />
Advanced Antievasion Ruleset<br />
<br />
Enable/Disable the advanced antievasion protection rule class. This ruleset prevents attacks that try to bypass the WAF itself or can be used to trick applications into parsing data in ways that may compromise the application.<br />
<br />
===== MODSEC_01_APP_RULES =====<br />
<br />
This is a special ruleset that most users will never need. Please see this article to see if this ruleset applies to you:<br />
<br />
[[WAF_rule_families#01_asl_rules_special.conf]]<br />
<br />
Default:no<br />
<br />
Note: Do not enable this ruleset unless you know what you are doing.<br />
<br />
===== MODSEC_01_DOMAIN_BLOCKS =====<br />
<br />
MODSEC_01_DOMAIN_BLOCKS<br />
<br />
Enable/Disable user defined custom domain blocking class. This ruleset blocks connections from a user defined list of domains when DNS records exist that match the incoming IP (This allows you to block hosts based on their DNS names), and also blocks referrers that contain that domain name. <br />
<br />
[Default: no]<br />
<br />
In the ASL gui, click on the ASL tab, then select Blocking, and then the Domains tab. Domains or FQDNs are defined, one per line. Matching is by string, regular expressions are not supported. Therefore, example.com will also match anotherexample.com. If you want to limit the domain you will need to use a delimiter, as in the example, such as:<br />
<br />
.example.com<br />
<br />
Which will only match on FQDNs that include .example.com, and in the previous example would not match on anotherexample.com.<br />
<br />
Note: Available in ASL 4.0.1 and up. This works by comparing the forward and reverse DNS records, if they do not match the rule will not match.<br />
<br />
===== MODSEC_03_DOS ===== <br />
<br />
Denial of Service Protection<br />
<br />
Enable/Disable the Denial of Services protection rule class. This ruleset prevents the so-called "slowaris" Denial of Service attacks, as well as "fast" DOS attacks. DDOS attacks can not be mitigated on the host itself. <br />
<br />
''Note: Some fastcgi implementations, specifically cpanel, require this to be disabled.''<br />
<br />
===== MODSEC_06_HONEYPOT =====<br />
<br />
Custom User Defined Honeypot Ruleset<br />
<br />
Enable/Disable the Custom User Defined Honeypot Ruleset. This ruleset allows you to define custom files, directories or a combination of the two in the file below that you want to block access to:<br />
<br />
/etc/httpd/modsecurity.d/honeypot-files.txt<br />
<br />
The format is one rentry per line. '''This method does not support regular expressions, but is case insensitive.''' For example:<br />
<br />
<pre><br />
/backups/admin.php<br />
/wp-config.php<br />
/admin/secret<br />
</pre><br />
<br />
===== MODSEC_10_ANTIMALWARE ===== <br />
<br />
Anti-Malware Ruleset<br />
<br />
Enable/Disable the anti-malware rule class. This will look at any requests to the system for known malware domains and indicators of malware injection requests (this does not do the same thing as the MODSEC_99_SCANNER class, which will inspect uploads for malware).<br />
<br />
===== MODSEC_10_RULES ===== <br />
<br />
Generic Attack Ruleset<br />
<br />
Enable/Disable the core rule class. This class contains the core generic rules, which will look for things like SQLi, XSS, CSRF, recursion, code injection, command injection, XML attacks and other generic attack patterns. You should always leave this class enabled.<br />
<br />
===== MODSEC_11_ADV_RULES ===== <br />
<br />
Advanced Attack Ruleset<br />
<br />
Enable/Disable the advanced protection rule class. This class contains advanced rules.<br />
<br />
===== MODSEC_11_DLP ===== <br />
<br />
Data Loss Protection Ruleset<br />
<br />
Enable/Disable the data loss protection rule class. This will detect certain Data Loss events, such as credit card information being sent or errors messages from applications that may reveal sensitive information or that the system or application is vulnerable to particular attack.<br />
<br />
Additional types of data and errors this ruleset can detect in the output:<br />
<br />
# Credit Card Numbers <br />
# SSN numbers<br />
# Application Errors/Debug information/Sensitive Files that may leak sensitive data from:<br />
* Mysql<br />
* Postgres<br />
* MS-SQL<br />
* Oracle DB<br />
* hsqldb<br />
* SQLite<br />
* Informix<br />
* max DB<br />
* IBM DB2<br />
* EMC<br />
* ODBC<br />
* Jet DB<br />
* Access DB<br />
* Generic SQL errors/debug messages/info<br />
* Wordpress<br />
<br />
===== MODSEC_12_ADV_XSS_RULES =====<br />
<br />
Advanced Cross Scripting Protection (AXSSP)<br />
<br />
This is the advanced Cross Site Scripting (XSS) protection rule set. It performs deep level inspections of web requests and responses to look for potential XSS attacks. <br />
<br />
Note: This requires EL 6 and above.<br />
<br />
===== MODSEC_11_BRUTE ===== <br />
<br />
Supplemental Brute Force Protection Ruleset<br />
<br />
Enable/Disable the supplemental web brute force attack protection rule class. This ruleset is used on systems that do not have either ASL or Atomic Protector installed, and perform the process of tracking login failures, and send a 403 error to the user when the limit is reached.<br />
<br />
'''Note:''' This works by analysing the output of the web application, and does not rely on log analysis or htaccess files. Therefore, do not use application internal compression schemes on output. For example, do not enable GZIP compression in applications such as Joomla, PHPBB, Wordpress and others, as this will make it difficult for the WAF to see the output. You can still compress the output if you use an apache module such as mod_deflate, which accomplishes the same thing and is less CPU intensive that application internal compression. '''Litespeed does not currently support this ruleset. If you require this protection with Litespeed, you must use ASL and configure ASL to setup a local WAF, via ASL, in front of Litespeed.'''<br />
<br />
'''Discussion:'''<br />
<br />
For the WAF to be able to analyze output from web applications, the WAF must be able to understand the output from the web application. Applications that compress output send this compressed output to Apache, which creates a situation where the WAF will only see compressed content. In this case, the WAF will not be able to understand it because the WAF will not decompress it.<br />
<br />
Whereas it is possible for the WAF to decompress this content, and then recompress it, this is '''extremely''' wasteful for the CPU and will unnecessarily slow the system down. Essentially the web server would be compressing the content, decompressing it, and then compressing it again. Add in two unnecessary steps, and tripling the work load. The most efficient solution is to not compress output in the application, let the WAF inspect it, and then let apache compress it. <br />
<br />
'''Inline decompression with the WAF is no longer supported and has been removed from the WAF code as this leads to poor performance due to misconfiguration of the system.'''<br />
<br />
===== MODSEC_12_BRUTE ===== <br />
<br />
Brute Force Protection Ruleset<br />
<br />
Enable/Disable the web brute force attack protection rule class. Detects attempts to brute force web applications authentication mechanisms.<br />
<br />
'''Note:''' This works by analysing the output of the web application, and does not rely on log analysis or htaccess files. Therefore, do not use application internal compression schemes on output. For example, do not enable GZIP compression in applications such as Joomla, PHPBB, Wordpress and others, as this will make it difficult for the WAF to see the output. You can still compress the output if you use an apache module such as mod_deflate, which accomplishes the same thing and is less CPU intensive that application internal compression. '''Litespeed does not currently support this ruleset. If you require this protection with Litespeed, you must use ASL and configure ASL to setup a local WAF, via ASL, in front of Litespeed.'''<br />
<br />
'''Discussion:'''<br />
<br />
For the WAF to be able to analyze output from web applications, the WAF must be able to understand the output from the web application. Applications that compress output send this compressed output to Apache, which creates a situation where the WAF will only see compressed content. In this case, the WAF will not be able to understand it because the WAF will not decompress it.<br />
<br />
Whereas it is possible for the WAF to decompress this content, and then recompress it, this is '''extremely''' wasteful for the CPU and will unnecessarily slow the system down. Essentially the web server would be compressing the content, decompressing it, and then compressing it again. Add in two unnecessary steps, and tripling the work load. The most efficient solution is to not compress output in the application, let the WAF inspect it, and then let apache compress it. <br />
<br />
'''Inline decompression with the WAF is no longer supported and has been removed from the WAF code as this leads to poor performance due to misconfiguration of the system.'''<br />
<br />
===== MODSEC_20_USERAGENTS ===== <br />
<br />
Malicious Useragents Ruleset<br />
<br />
Enable/Disable the useragents rule class. Detects known malicious or suspicious user agents.<br />
<br />
===== MODSEC_21_USERAGENTS ===== <br />
<br />
User Defined Malicious Useragents Ruleset<br />
<br />
Enable/Disable the User Defined Malicious Useragents Ruleset. This ruleset allows you to define custom useragents in the file below that you want to block:<br />
<br />
/etc/httpd/modsecurity.d/bad_agents.txt<br />
<br />
The format is one user-agent per line. '''This method does not support regular expressions, but is case insensitive.''' For example<br />
<br />
<pre><br />
Mozila 99.0<br />
Internut exploder<br />
</pre><br />
<br />
===== MODSEC_30_ANTISPAM ===== <br />
<br />
Anti-Spam Ruleset<br />
<br />
Enable/Disable the anti-spam rule class. This class contains tuned antispam rules, designed to work with all known blogs, forums, guestbooks, CMS' and other web content management systems that allow users to post content. <br />
<br />
===== MODSEC_31_ANTISPAM_URI ===== <br />
<br />
Anti-Spam URI RBL Ruleset<br />
<br />
Enable/Disable the anti-spam URI rule class. Looks up all URIs in a post against RBLs to see if its a known spam domain. As with the MODSEC_00_RBL rules, these should only be used if the server has a local fast DNS server. <br />
<br />
'''Warning: You should only use this ruleset if the ASL server has a really fast DNS server installed on the ASL server.''' <br />
<br />
This ruleset will look up every request in the DNS to see if its on a blacklist, and will not finish serving the request until the DNS server responds. This can slow down requests if the DNS server is slow. Basically, web requests will move at the speed of the DNS servers replies.<br />
<br />
If your web server is responding slowly to requests, and you have this ruleset enabled your DNS server is too slow to meet your lookup needs. You will need to either disable this ruleset, or tune your DNS server to respond to queries more quickly.<br />
<br />
===== MODSEC_50_ROOTKITS ===== <br />
<br />
Rootkit Detection Ruleset<br />
<br />
Enable/Disable the rootkit rule class. This class detects and blocks known rootkits, PHP/ASP/PERL shells, spam tools and other malicious web applications from running on the system. (These rules exist for cases where malicious software may already be installed on the system, this is a defense in depth rule set) <br />
<br />
===== MODSEC_60_RECONS ===== <br />
<br />
Reconnaissance Attacks Ruleset<br />
<br />
Enable/Disable the recon rule class. This class blocks known "google hacks" or webserver probes that look for vulnerable applications and signs of compromised systems running unauthorized shells, or unprotected applications that allow uploads which would give an attacker access to the system. <br />
<br />
===== MODSEC_61_DLP ===== <br />
<br />
Data Leak Prevention Ruleset<br />
<br />
Enable/Disable the data loss protection class. These rules detect Data Loss Search engine "hacks". These are search engine probes for sensitive files, often used by malicious parties to find sensitive information accidentally exposed on web servers.<br />
<br />
===== MODSEC_98_ADV_REDACTOR =====<br />
<br />
Advanced Malware Removal Ruleset<br />
<br />
Enable/Disable the advanced malware removal ruleset. These rules detect hidden iframes, obfuscated javascript and other potentially malicious code and remove it real time from your web pages.<br />
<br />
===== MODSEC_99_JITP ===== <br />
<br />
Just In Time Patches<br />
<br />
Enable/Disable the Just In Time Patches(JITP) rule class. Just in Time Patches. We publish JITPs daily if there is a new web application vulnerability that the 10_asl_rules.conf do not protect the system against. These are tuned rules for specific vulnerabilities in a web application. <br />
<br />
===== MODSEC_99_REDACTOR ===== <br />
<br />
Malicious Output Removal Ruleset<br />
<br />
Enable/Disable the automatic malicious/hidden iframe and malware removal rule class. Automatically removes malicious code from web pages, such as hidden iframes, encoded javascript and other malicious code. <br />
<br />
===== MODSEC_99_MALWARE_OUTPUT ===== <br />
<br />
Malicious Output Detector<br />
<br />
Enable/Disable the malware output rule class.<br />
<br />
===== MODSEC_99_SCANNER ===== <br />
<br />
Web Malware Upload Scanner<br />
<br />
Malicious code upload scanner. Enable this to scan web uploads for malicious code.<br />
<br />
===== MODSEC_99_ADV_SCANNER =====<br />
<br />
Advanced Malware Upload Scanner<br />
<br />
This enables the advanced malware upload scanner rule class. This uses fuzzy hashes to detect similiar malware.<br />
<br />
= Rule Manager =<br />
<br />
The Rule manager can be used to configure individual WAF rules, such as what response the system such take for that rule, if an email or GUI alert should be presented, and so on. To access the rule manager please follow this process:<br />
<br />
Step 1) Log into the ASL GUI<br />
<br />
Step 2) Click the "Configuration" tab.<br />
<br />
Step 3) Select "Rule Management"<br />
<br />
This will bring up the rule management screen. There are two tabs on this screen:<br />
<br />
Global: This sets global features for all the rules<br />
<br />
Rules: This presents all the individual rules, and options to configure that rule specifically.<br />
<br />
== Global Options ==<br />
<br />
If you change a setting on this screen, you must click the "Update" button for the setting changes to take effect.<br />
<br />
The follow settings are available in the Global setting screen:<br />
<br />
=== Email to === <br />
<br />
This sets the email address to send alerts to. The default is $EMAIL which inherits the global email address set in the ASL Configuration screen. If you want to use the same email address you set when you configured when you install ASL leave this setting as "$EMAIL". Otherwise, change this to the email address you want rule alerts sent to.<br />
<br />
=== Email From ===<br />
<br />
Set this to the From: line you want to use for the emailed alerts. Available variables are $HOSTNAME is is populated by the servers fully qualified hostname, and $EMAIL which is set in the ASL Configuration screen. The default is usually effective for most users.<br />
<br />
=== Max Emails per hour ===<br />
<br />
This sets a limit on the maximum number of emails the system will sent to the Email to: address. This basically "queues up" alerts. If events occur after the Max Emails per hour limit has been reached, then those alerts will be held until the next hour and will be grouped together in a single email sent the next hour.<br />
<br />
If you want alerts to be sent as they occur, and not to be queued up, set this to 9999.<br />
<br />
=== Active Response ===<br />
<br />
This sets whether of not ASL will block the source of the attack, by implementing a firewall rule for the source of the attack. (Which may be a temporary shun, or a permanent shun depending on the setting below "Shun Timeout")<br />
<br />
=== Shun Timeout ===<br />
<br />
This tells ASL if the firewall block, or "shun", should be temporary or permanent. Once the Shun Time (described below) has been reached the source IP address will be allowed to connect again. The ASL Configuration settings also allow for advanced options for this, such as multiplers that cause sources to be shunned for longer periods of time as more attacks are detected from the source.<br />
<br />
=== Shun Time ===<br />
<br />
Timeout period is in seconds. This sets the maximum amount of time a source address will be blocked by ASL/<br />
<br />
If Shun Timeout is set to no, the "shun" is permanent and this option is ignored.<br />
<br />
=== Rules ===<br />
<br />
The Rules Manager has two tabs:<br />
<br />
==== HIDS ====<br />
<br />
This contains all the Rules for HIDS. For documentation on the HIDS please see the [[ASL HIDS]] documentation page.<br />
<br />
==== WAF ====<br />
<br />
This contains all the Rules for the WAF. There are two columns on this tab, the left column contains the current rule sub classes, and the screen on the right shows all rules that match your current filter selections. The window on the right is populated by selecting either a subclass of rules, or by typing in search criteria in the boxes at the top of the screen. <br />
<br />
If you select a rule sub class, for example "adult-spam" that will pull up all the rules in the class on the right hand side of the screen.<br />
<br />
Or you can search for specific rules by using the filter bar at the top of the screen. The filter options are:<br />
<br />
Category: This is another way to select a rule subclass, this is optional, you do not have to select a rule class. If you leave this in either the default, or you set this to (any) your filter will apply to all the WAF rules. <br />
<br />
Level: Rules have different levels, depending on severity. Some rules are only informational, some indicate suspicious activity and others are full blown attacks. A higher number is a high severity or importance, and a lower number is a lower severity or importance. This filter is optional, you do not need to select a level if you do not want to filter by level. If you leave the default your filter will apply to all levels.<br />
<br />
Search: This allows you to search by any thing in the rule, its name, ID, etc. If you hit enter in this field it will start the search. <br />
<br />
When you have finished with your filter criteria, just click the "filter button" or hit enter in the search field.<br />
<br />
=== Configuring specific rules ===<br />
<br />
Once you have the rule manager open, and have pulled up a rule you want to modify just click on the down arrow next to the rules ID to open the rules options. <br />
<br />
===== Rule Options =====<br />
<br />
For WAF rules the following options are available:<br />
<br />
<br />
====== Disabled ======<br />
<br />
Setting this "yes" globally disables the rule. If you want to disable a rule for a specific domain or FQDN see the Vhost option below.<br />
<br />
====== Severity ======<br />
<br />
This sets the severity level for the event. This allows you to set rules to be lower or higher priority which will effect:<br />
<br />
1. How they are displayed in the GUI<br />
<br />
2. Whether they are shunned or not (a minimum severity level can be set in ASL to control if an event is important enough to block the source IP address, please see the [[ASL Configuration]] documentation for these settings.<br />
<br />
3. If an email alert is sent. A minimum severity level can be set in ASL to control if an event is important enough to send an email alert, please see the [[ASL Configuration]] documentation for these settings.<br />
<br />
====== Active Response ======<br />
<br />
This sets if the system should perform any active response actions against the source IP address. This option is ignored if Active Response is disabled in the Global options.<br />
<br />
====== Email ======<br />
<br />
This sets if the event will generate an email alert. Keep in mind that the event must also be above the minimum level set in the [[ASL Configuration]].<br />
<br />
====== Logging ======<br />
<br />
This sets if the event will be displayed, at all, in the ASL GUI. Setting this to off "silences" the event in the ASL GUI. It does not prevent the event from being logged to the systems logs.<br />
<br />
====== Vhost settings ======<br />
<br />
This subpanel allows you to set domain or FQDN specific settings for a rule. For example, if you want a rule to other behave per its defaults, but want to change its behavior for a specific domain you can set that domain here.<br />
<br />
Currently this is limited to disabling the rule for the domain. In the future this will be expanded to allow other options for the rule as with the global settings.<br />
<br />
Simply type in the domain name in the text box on the right, select "yes" and click add.<br />
<br />
=== Rule Tuning ===<br />
<br />
Please see the [[Mod_security]] page.<br />
<br />
= Events =<br />
<br />
WAF events are displayed in the [[ASL Events]] window. Please see the [[ASL Events]] page for usage information.<br />
<br />
= Configuring web servers to use the T-WAF =<br />
<br />
This section provides courtesy instructions about how to configure a remote web server to work with the T-WAF, so that the remote web server reports the correct client IP address and not the IP address for the T-WAF server.<br />
<br />
This can also be used with local web services. For local apache servers, we do not recommend you use the T-WAF. Instead, make sure you are using the embedded mode explained at the beginning of this article. The WAF will integrate natively with Apache 2.x, and is highly recommended for that platform.<br />
<br />
== Apache ==<br />
<br />
Note: If you are using embedded mode (which is the default) you do not need to do this. You will only need to do this if you are using the T-WAF to proxy traffic to a remote apache server. If you have a local apache server that ASL is installed on, install modsecurity locally.<br />
<br />
For remote apache servers, to setup Apache to report the clients IP when using the T-WAF follow this process:<br />
<br />
Step 1) Install mod_rpaf<br />
<br />
http://stderr.net/apache/rpaf/<br />
<br />
Step 2) Add this to your remote servers apache configuration<br />
<br />
<pre><br />
LoadModule rpaf_module path/to/mod_rpaf-2.0.so<br />
RPAFenable On<br />
RPAFsethostname On<br />
RPAFproxy_ips <IP FOR THE ASL SERVER><br />
RPAFheader X-Forwarded-For<br />
</pre><br />
<br />
Change the IP in this line:<br />
<br />
RPAFproxy_ips <IP FOR THE ASL SERVER><br />
<br />
To the IP for your ASL server. For example, if the ASL servers IP address is 1.2.3.4 this line will look like this:<br />
<br />
RPAFproxy_ips 1.2.3.4<br />
<br />
Step 3) Restart the remote apache server<br />
<br />
== Litespeed ==<br />
<br />
To setup Litespeed to report the correct IP address of the client when using the T-WAF follow these instructions:<br />
<br />
Step 1) Log into the LiteSpeed Web Admin Console<br />
<br />
Step 2) Under Configuration, enable the option "Use Client IP in Header".<br />
<br />
Step 3) Restart Litespeed<br />
<br />
== Nginx ==<br />
<br />
Step 1) Edit your nginx.conf file and add the following to your http section:<br />
<br />
<pre><br />
http {<br />
set_real_ip_from 127.0.0.1/32;<br />
set_real_ip_from <YOUR SERVERS IP>/32;<br />
set_real_ip_from <YOUR SERVERS OTHER IPS>/32;<br />
real_ip_header CF-Connecting-IP;<br />
</pre><br />
<br />
Replace <YOUR SERVERS IP> with your servers IP(s). For example, if your server had the IPs 1.2.3.4, 1.2.3.5 and 1.2.3.6 your configuration would look like this:<br />
<br />
<pre><br />
set_real_ip_from 127.0.0.1/32;<br />
set_real_ip_from 1.2.3.4/32;<br />
set_real_ip_from 1.2.3.5/32;<br />
set_real_ip_from 1.2.3.6/32;<br />
real_ip_header CF-Connecting-IP;<br />
</pre><br />
<br />
<br />
Step 2) Restart nginx.</div>Mshinnhttps://wiki.atomicorp.com/wiki/index.php/ASL_WAFASL WAF2022-07-01T22:23:08Z<p>Mshinn: /* MODSEC_11_DLP */</p>
<hr />
<div>= Introduction =<br />
<br />
The ASL WAF has two non-exclusive modes operation:<br />
<br />
1) Embedded mode<br />
<br />
2) Transparent/Proxy mode (T-WAF)<br />
<br />
== Embedded mode ==<br />
<br />
Embedded mode works with Apache 2.x. ASL will install a special module in Apache to give it native WAF protection capabilities. This installation will occur when ASL is installed.<br />
<br />
== Proxy mode (T-WAF) ==<br />
<br />
Proxy mode or the Transparent WAF (T-WAF) system allows ASL to protect any HTTP and/or HTTPS service, either a local server (such as when using a web server that does not support embedded mode) or a remove server.<br />
<br />
= Configuration =<br />
<br />
The ASL WAF is initially configured during the install of ASL. If Apache is installed on the system, ASL will attempt to install the embedded WAF module. If Apache is installed on the system via package management, then this will occur automatically and you will not need to configure the WAF further to protect an installed Apache instance. <br />
<br />
Once ASL is installed, if you need to do so, you can configure the WAF through three parts of the ASL GUI:<br />
<br />
== WAF Tab ==<br />
<br />
This tab is used to setup the WAF. There are three types of WAF you can configure:<br />
<br />
=== embedded ===<br />
<br />
The embedded WAF is an apache module that is installed on any local Apache installations. This should be setup by default, if you are running apache on the system and a [https://www.atomicorp.com/wiki/index.php/ASL_FAQ#Apache supported version and build of Apache].<br />
<br />
=== local ===<br />
<br />
Note: You do not need to setup a local WAF for package managed installs of apache. ASL will detect if a package managed version of Apache is installed, and will install the WAF module into apache [https://www.atomicorp.com/wiki/index.php/ASL_WAF#embedded embedded mode], as described above. For custom apache installs, please follow these directions.<br />
<br />
This type of WAF is used to protect any local HTTP and/or HTTPS services that may be running on the system itself, where the embedded WAF module can not be used. For example, if the system was running a tomcat or litespeed web server, which do not support the embedded WAF module, or a control panel that uses it own web server (such as Plesk, Cpanel, Webmin, and others). You can configure a WAF to protect these services.<br />
<br />
To setup a local WAF simply follow these steps:<br />
<br />
Step 1) Log into the ASL GUI<br />
<br />
Step 2) Click the WAF tab<br />
<br />
Step 3) Select WAF Config<br />
<br />
This will pull up the WAF Config window, which will show the existing WAFs.<br />
<br />
Step 4) Click "Enable T-WAF". If you see "Disable T-WAF" this option has already been enabled.<br />
<br />
Step 5) Click "Add"<br />
<br />
This will will pull up the "Add WAF Config" window.<br />
<br />
Step 6) Click on the "Add protection for" drop down. Select "local"<br />
<br />
This will present you with two options:<br />
<br />
Local Port: Type in the local HTTP/HTTPS port you wish to protect. Only type in one port number.<br />
<br />
Note: Check if you have any embedded WAFs installed on the system before you do this. If you have an embedded WAF already installed on port 80, as should occur if you have Apache installed (and its package managed), then enabling the T-WAF in front of Apache would create a loop. Its not necessary to put a WAF in front of a service that is protected via embedded mode.<br />
<br />
SSL: Select this if the service you wish to protect is SSL based.<br />
<br />
If you select SSL, then you will see this additional options:<br />
<br />
Path to SSL Certificate: Provide the filesystem path to the SSL certificate for this service.<br />
<br />
Path to SSL Key file: Provide the filesystem path to the SSL key file for this service.<br />
<br />
Step 7) Then click Save<br />
<br />
Note: You do not need to reconfigure your web server to use a different port, ASL will transparently intercept the packets to your web server based on the port you configure above. If you change your web servers port, ASL will not intercept packets to that port.<br />
<br />
=== remote ===<br />
<br />
'''Note: You need a [https://www.atomicorp.com/amember/cart/index/index?c=9 reverse proxy ASL license] to use this feature. This feature will not work without a reverse proxy license.'''<br />
<br />
This type of WAF is used to protect any remote HTTP and/or HTTPS services that are not running on the system itself. For example, if you have a remote webserver you wish to protect, you can configure a WAF to protect these services. The remote WAF can support two proxy modes: domain based and IP based.<br />
<br />
==== name based remote ====<br />
<br />
Domain based or name nased WAFs allow you to use a single IP address on the WAF, and to direct WAF requests to different backend servers depending on their domain or full qualified domain name, or even to specific URL.<br />
<br />
==== IP based remote ====<br />
<br />
IP based WAFs allow you to redirect all traffic to an IP address on WAF to a specific destination host or URL.<br />
<br />
==== Setting up a remote WAF ====<br />
<br />
To setup a remote WAF simply follow these steps:<br />
<br />
Step 1) Log into the ASL GUI<br />
<br />
Step 2) Click the WAF tab<br />
<br />
Step 3) Select WAF Config<br />
<br />
This will pull up the WAF Config window, which will show the existing WAFs.<br />
<br />
Step 4) Click "Enable T-WAF". If you see "Disable T-WAF" this option has already been enabled.<br />
<br />
Step 5) Click "Add"<br />
<br />
This will will pull up the "Add WAF Config" window.<br />
<br />
Step 6) Click on the "Add protection for" drop down. Select "remote"<br />
<br />
This will present you with a dropdown options to setup the WAF as either domain based or IP based.<br />
<br />
Step 7) If you select name based you will be presented with these options:<br />
<br />
Domain Name: Enter the domain name or full qualified domain you wish to use. For example, if you want the WAF to handle traffic for intranet.example.com enter that FQDN in this box.<br />
<br />
Local Url: Enter the local URL, if any, that the WAF should expect from the client to direct this connection to the remote host. The default of / is usually correct if you are forwarding all traffic for an FQDN or domain. If you only want the WAF to pass on specific requests for specific URLs, enter them here. <br />
<br />
Destination: Enter the full URL you want the WAF to use as the destination server. Make sure you have DNS or /etc/hosts entries for this, otherwise the WAF will not be able to find the destination. This should also not be the same thing as "Domain Name:". You can also use https:// URLs here.<br />
<br />
Remote Port: Type in the remote port for the backend server the WAF will be sending requests to.<br />
<br />
SSL: Select SSL if you wish to accept SSL connections to the WAF. If you select this you will be presented with these additional options:<br />
<br />
Path to SSL Certificate: Provide the filesystem path to the SSL certificate for this service.<br />
<br />
Path to SSL Key file: Provide the filesystem path to the SSL key file for this service.<br />
<br />
Skip to step 8<br />
<br />
Step 7) If you select IP based you will be presented with these options<br />
<br />
IP Address: Enter the IP address you want the WAF to listen on (you can set multiple IPs by adding additional remote WAFs). For example, if you want the WAF to redirect all traffic on IP address 1.2.3.4 to internal.example.com, type in 1.2.3.4.<br />
<br />
Local Url: Enter the local URL, if any, that the WAF should expect from the client to direct this connection to the remote host. The default of / is usually correct if you are forwarding all traffic for an FQDN or domain. If you only want the WAF to pass on specific requests for specific URLs, enter them here. <br />
<br />
Destination: Enter the full URL you want the WAF to use as the destination server. Make sure you have DNS or /etc/hosts entries for this, otherwise the WAF will not be able to find the destination. This should also not be the same thing as "Domain Name:". You can also use https:// here.<br />
<br />
Remote Port: Type in the remote port for the backend server the WAF will be sending requests to.<br />
<br />
SSL: Select SSL if you wish to accept SSL connections to the WAF. If you select this you will be presented with these additional options:<br />
<br />
Path to SSL Certificate: Provide the filesystem path to the SSL certificate for this service.<br />
<br />
Path to SSL Key file: Provide the filesystem path to the SSL key file for this service.<br />
<br />
Step 8) Then click Save<br />
<br />
== SSL/TLS ==<br />
<br />
If you select SSL for either the local or remote WAF options, your SSL certificates and keys must be in an Apache compatible format to be imported by the T-WAF.<br />
<br />
== ASL Configuration Settings ==<br />
<br />
The WAFs settings are contained under the Configuration tab. To Configure the WAF follow this process:<br />
<br />
Step 1) Log into the ASL GUI<br />
<br />
Step 2) Click on the Settings Tab<br />
<br />
Step 3) Select the "ASL Configuration" sub menu<br />
<br />
Step 4) Scroll down to the "Web Application Firewall" configuration section. The following options are available:<br />
<br />
=== MODSEC_ENABLED ===<br />
<br />
This setting Enables/Disables the entire WAF system. This is the only supported method for disabling the WAF in ASL. Uninstalling mod_security and the use of third party methods to remove modsecurity will not work if this setting is still configured to enable the WAF. This setting is specifically designed to ensure that the WAF is not disabled accidentally by a third party product.<br />
<br />
=== WAF_ENGINE ===<br />
<br />
Set the WAF engine mode, there are three modes:<br />
<br />
On - this tells the WAF to detect and block attacks.<br />
<br />
DetectionOnly - this tells the WAF to only detect and report attacks, but not to block them.<br />
<br />
Off - Disables the WAF.<br />
<br />
=== WAF_ENABLED ===<br />
<br />
Enable/Disable Tortix WAF proxy. The tortix waf module, this module can process local or remote services through the Tortix Web Application Firewall (T-WAF) . (Default: Off)<br />
<br />
'''Note: This option is deprecated in ASL 4.'''<br />
<br />
=== WAF_CHROOTDIR ===<br />
<br />
Configures the directory path that will be used to jail the web server process. (For the embedded WAF modules only). This lets you put the local apache instance into a chroot jail.<br />
<br />
=== WAF_READSTATELIMIT ===<br />
<br />
Sets the limit of the number of connections from the same IP address that can be in the Read state for the WAF. This helps to prevent "slow" DOS attacks. For example, if this was set to "5" a single IP would only be able to keep 5 connections in a busy state with the web server at a single time.<br />
<br />
ASL 3 Default: 10<br />
<br />
ASL 4 Default: 100<br />
<br />
=== Write State Limit ===<br />
<br />
WAF_WRITESTATELIMIT: Sets the limit of the number of connections from the same IP address that can be in the Write state for the WAF. This helps to prevent "slow" DOS attacks. For example, if this was set to "5" a single IP would only be able to keep 5 connections in a busy state with the web server at a single time.<br />
<br />
(Default: 100)<br />
<br />
Note: This option is only available in ASL 4 and up.<br />
<br />
=== WAF_SECREQUESTBODYNOFILESLIMIT ===<br />
<br />
(Default: 1048576) Configures the maximum request body size the WAF modules will accept for buffering. There is a hard limit of 1GB. This is not a limit on file sizes sent through the WAF, just request body sizes.<br />
<br />
=== WAF_SECREQUESTBODYINMEMORYLIMIT ===<br />
<br />
(Default: 131072) Configures the maximum request body size the WAF modules will store in memory. There is a hard limit of 1GB. The default of 128 MB is generally sufficient for any site.<br />
<br />
=== WAF_DEFAULT_ACTION ===<br />
<br />
Configures the block policy, deny the request or redirect the client to a landing page. <br />
<br />
=== WAF_REDIRECT_URL ===<br />
<br />
Used for WAF_DEFAULT_ACTION of "redirect". This is the URL to redirect blocked pages. This must include http:// or https:// in the URL.<br />
<br />
Example:<br />
<br />
https://%{server_name}:30000/blocked.php?eventid=%{eventid}<br />
<br />
You can use variables in the URL. They must be represented in this format:<br />
<br />
<pre>%{variable_name}</pre><br />
<br />
'''Important Note:''' If you have [https://www.atomicorp.com/wiki/index.php/ASL_Configuration#OSSEC_ACTIVE_RESPONSE OSSEC_ACTIVE_RESPONSE] enabled, then redirects will not work as the systems firewall will still block the user. You must disable OSSEC_ACTIVE_RESPONSE to use redirects.<br />
<br />
==== Supported Variables ====<br />
<br />
Currently supported variables are listed below. As new variables are supported, we will add them to the documentation here. <br />
<br />
===== server_name =====<br />
<br />
This is the value the client sent in the Host: header, which would be the FQDN the client accessed.<br />
<br />
==== ruleid ====<br />
<br />
The rule ID for the rule that was triggered.<br />
<br />
===== unique_id =====<br />
<br />
The unique ID for each event recorded by the WAF.<br />
<br />
The variable UNIQUE_ID is set to the identifier for each request. The UNIQUE_ID environment variable is constructed by encoding the 112-bit (32-bit IP address, 32 bit pid, 32 bit time stamp, 16 bit counter) quadruple using the alphabet [A-Za-z0-9@-] in a manner similar to MIME base64 encoding, producing 19 characters.<br />
<br />
===== remote_addr =====<br />
<br />
The client IP address.<br />
<br />
===== server_port =====<br />
<br />
This variable contains the local port of the webserver that the request was received on.<br />
<br />
==== Experimental Variables ====<br />
<br />
These are additional variables that should be considered experimental, and are available in the engine, but are not currently supported. They require newer versions of modsecurity, which may not be available in the stable channel.<br />
<br />
===== auth_type =====<br />
<br />
This variable holds the authentication method used to validate a user, if any of the methods built into HTTP are used. In a reverse-proxy deployment, this information will not be available if the authentication is handled in the backend web server. <br />
<br />
===== remote_user =====<br />
<br />
This variable holds the username of the authenticated user. If there are no password access controls in place (Basic or Digest authentication), then this variable will be empty. <br />
<br />
===== time =====<br />
<br />
This variable holds a formatted string representing the time (hour:minute:second). <br />
<br />
===== time_day =====<br />
<br />
This variable holds the current date (1–31). <br />
<br />
===== time_epoch =====<br />
<br />
This variable holds the time in seconds since 1970. <br />
<br />
===== time_hour =====<br />
<br />
This variable holds the current hour value (0–23). <br />
<br />
===== time_min =====<br />
<br />
This variable holds the current minute value (0–59).<br />
<br />
===== time_mon =====<br />
<br />
This variable holds the current month value (0–11).<br />
<br />
===== time_sec =====<br />
<br />
This variable holds the current second value (0–59). <br />
<br />
===== time_wday =====<br />
<br />
This variable holds the current weekday value (0–6).<br />
<br />
===== time_year =====<br />
<br />
This variable holds the current four-digit year value. <br />
<br />
===== response_status =====<br />
<br />
This variable holds the HTTP response status code.<br />
<br />
===== request_protocol =====<br />
<br />
This variable holds the request method used in the transaction.<br />
<br />
===== useragent_ip =====<br />
<br />
This variable is created when running modsecurity with apache 2.4 and will contain the client ip address set by mod_remoteip in proxied connections. Requires mod_remoteip to be installed, and Apache 2.4.<br />
<br />
=== Intercept on error===<br />
<br />
WAF_SECINTERCEPTONERROR: Configures how to respond when rule processing fails. [Default: on]<br />
<br />
===Analyze response body===<br />
<br />
WAF_SECRESPONSEBODYACCESS: Configures whether response bodies are to be buffer and analysed or not. [Default: on]<br />
<br />
=== MODSEC_SERVERSIG ===<br />
<br />
Field returned when a remote host queries what kind of web server this is. This can be used to hide what kind of server is running on the system, or what the WAFs are protecting.<br />
<br />
=== MODSEC_UPLOADDIR ===<br />
<br />
Configures the directory where intercepted files will be stored. If the WAF is configured to scan uploads, and this is set to On, then any malicious files the WAF detects will be stored in this directory on the server. <br />
<br />
=== MODSEC_KEEPFILES ===<br />
<br />
Configures whether or not the intercepted files will be kept after transaction is processed. It is recommended you set to this off.<br />
<br />
=== MODSEC_LOGTYPE ===<br />
<br />
Configures the type of audit logging mechanism to be used. Concurrent - audit log entries will be stored in separate files, one for each transaction. Serial - all audit log entries will be stored in the main audit logging file. The default is Concurrent, which is both faster and more reliable and works with ASL Gui. Serial logging is for legacy purposes and should not be enabled.<br />
<br />
=== MODSEC_LOGFILE ===<br />
<br />
The name of the log file that is used to store audit record headers. Do not change this unless you know what you are doing. It is generally not necessary to change this setting.<br />
<br />
=== MODSEC_LOGELEMENT ===<br />
<br />
Defines which part of each transaction are going to be recorded in audit log. Do not change the defaults unless you know what you are doing, this may break the GUI and active response systems.<br />
<br />
Available audit log parts:<br />
<br />
A: Audit log header (mandatory).<br />
<br />
B: Request headers.<br />
<br />
C: Request body (present only if the request body exists and ModSecurity is configured to intercept it).<br />
<br />
D: Reserved for intermediary response headers; not implemented yet.<br />
<br />
E: Intermediary response body (present only if ModSecurity is configured to intercept response bodies, and if the audit log engine is configured to record it). Intermediary response body is the same as the actual response body unless ModSecurity intercepts the intermediary response body, in which case the actual response body will contain the error message (either the Apache default error message, or the ErrorDocument page).<br />
<br />
F: Final response headers (excluding the Date and Server headers, which are always added by Apache in the late stage of content delivery).<br />
<br />
G: Reserved for the actual response body; not implemented yet.<br />
<br />
H: Audit log trailer.<br />
<br />
I: This part is a replacement for part C. It will log the same data as C in all cases except when multipart/form-data encoding in used. In this case, it will log a fake application/x-www-form-urlencoded body that contains the information about parameters but not about the files. This is handy if you don’t want to have (often large) files stored in your audit logs.<br />
<br />
J: This part contains information about the files uploaded using multipart/form-data encoding.<br />
<br />
K: This part contains a full list of every rule that matched (one per line) in the order they were matched. The rules are fully qualified and will thus show inherited actions and default operators. <br />
<br />
Z: Final boundary, signifies the end of the entry (mandatory). <br />
<br />
=== MODSEC_REQMEMLIMIT ===<br />
<br />
Configures the maximum request body size ModSecurity will store in memory. The default are adequate for most sites, you should not change this unless you know what you are doing.<br />
<br />
=== MODSEC_DEBUGLOG ===<br />
<br />
Enable/Disable the ModSecurity debug log file. The debug log is located in /var/log/httpd/modsec_debug.log Enabling this will incur a substantial performance penalty on the system. You should not enable this on a production system, and only if you are debugging modsecurity rules.<br />
<br />
Most users will want to leave this disabled.<br />
<br />
=== MODSEC_CLEAN_ALERT ===<br />
<br />
Number of days to retain mod_security alert data. The WAF will store the actual full requests of any intercepted attacks, to make it possible for you to investigate them and to report these to us, either for further investigation, false positives or for other forensics needs. The default is to keep these for 30 days.<br />
<br />
Audit log events are kept in this directory by default:<br />
<br />
/var/asl/data/audit/<br />
<br />
=== MODSEC_DATADIR ===<br />
<br />
Path where persistent data (e.g. IP address data, session data, etc) is to be stored.<br />
<br />
=== MODSEC_AUDITDIR ===<br />
<br />
'''Warning: This setting is unsupported'''<br />
<br />
Defines the path to the audit log files. Used only when Concurrent mode is configured.<br />
<br />
=== MODSEC_TMPDIR ===<br />
<br />
Configures the directory where temporary files will be created.<br />
<br />
Note: If this is changed form the default of /tmp, the directory must be writable by apache, which means depending on how you have configured apache by whatever users the web application may be running as. For example, if you use suphp, then the web application will run as a specific user. The directory must be writable by that user. In that case, you will need to either create a group that all your users belong to and make sure that group can write to that directory, or you will need to make that directory world writable. We also recommend you set the sticky bit on the directory. The simplest solution is to set the directories permissions thusly:<br />
<br />
For example, if you change this directory to /var/asl/mod_sec_tmp, these permissions should work generically in all cases:<br />
<br />
chmod ogu+rwx /var/asl/mod_sec_tmp<br />
<br />
chmod o+t /var/asl/mod_sec_tmp<br />
<br />
=== MODSEC_RESPONSEBODYLIMIT ===<br />
<br />
Configures the maximum response body size that will be accepted for buffering.<br />
<br />
=== MODSEC_RESPONSEBODYLIMITACTION ===<br />
<br />
Controls what happens once a response body limit, configured with SecResponseBodyLimit, is encountered. There are two options:<br />
<br />
ProcessPartial: Scan the response up to the limit and stop scanning when the limit is reached, but send the rest of the response.<br />
<br />
Reject: If the response is greater than the Limit, reject the response entirely.<br />
<br />
=== MODSEC_REQUESTBODYLIMIT === <br />
<br />
This sets the maximum size for a request body in bytes. The default is 134217728 bytes.<br />
<br />
Anything over the limit will be rejected with status code 413 (Request Entity Too Large). There is a hard limit of 1 GB. <br />
<br />
==== Ruleset Settings ====<br />
<br />
These allow you to enable/disable entire Rulesets and classes of rules. If you want to configure a specific rule, use the Rule Manager.<br />
<br />
===== Crawler Protector =====<br />
<br />
This unique feature of [[ASL]] protects not only your system, but also your search engine rankings. Unlike other security products, ASL can automatically and securely detect real search engine crawlers and prevent your system from accidentally blocking them. It can also detect when attackers are trying to pretend to be search engines, in hopes of getting around your security systems, and can safely block them, without blocking the real crawlers!<br />
<br />
<br />
====== WAF_LUA_00_SEARCHENGINE ======<br />
<br />
This will protect your page rank with search engine crawlers, prevent search engines from being blocked and will also block attackers pretending to be search engine crawlers. It can securely determine if a bot is legitimate, or a forgery.<br />
<br />
Default: disabled<br />
<br />
'''Note: This ruleset will only perform this function if a client claims to be a search engine, and is much faster than the legacy system and does not require that apache be configured with HostNameLookups Double. While this is significantly faster than looking up the A and PTR records for all FQDNS, this ruleset should only be used if the ASL server has a [[local DNS resolver]] server installed on the ASL server.''' You can use a remote resolver, but a local resolver will be faster and more reliable.<br />
<br />
These rules require a locally installed DNS server for maximum performance. It is not recommended you enable these rules without a local DNS server installed on this server. <br />
<br />
Requires ASL 4.0.11 and up.<br />
<br />
====== Legacy system ======<br />
<br />
If you are using a version of modsecurity prior to 2.9.0 then you may want to use the legacy options below. Do not use the legacy options with 2.9.0 and above.<br />
<br />
======= MODSEC_00_SEARCHENGINE =======<br />
<br />
'''NOTE: This setting is deprecated and unsupported. Users should use the Lua method above.'''<br />
<br />
Bogus Search Engine Ruleset<br />
<br />
This ruleset will detect search engine crawlers, as well as attackers pretending to be search engine crawlers. It can securely determine if a bot is legitimate, or a forgery.<br />
<br />
Default: disabled<br />
<br />
'''Note: You should only use this ruleset if the ASL server has a [[local DNS resolver]] server installed on the ASL server.''' You can use a remote resolver, but a local resolver will be faster and more reliable.<br />
<br />
These rules require a locally installed DNS server for maximum performance. It is not recommended you enable these rules without a local DNS server installed on this server. (If you do not know if you have a DNS server installed on this server, do not enable these rules). Apache must also be configured with "HostnameLookups Double". ASL will attempt to configure HostnameLookups Double, but on non-standard systems, such as source build Apache installs and third party Apache installations this may not occur automatically. If you find that Apache is not resolving IP addresses, check to make sure HostnameLookups Double is configured for Apache.<br />
<br />
Note: These are legacy rules, and should not be used with modsecurity 2.9.x You should use these rules instead:<br />
<br />
http://wiki.atomicorp.com/wiki/index.php?title=ASL_WAF#WAF_LUA_00_SEARCHENGINE<br />
<br />
======= MODSEC_00_AUTOWHITELIST_SEARCHENGINE =======<br />
<br />
'''NOTE: This setting is deprecated and unsupported. Users should use the Lua method above.'''<br />
<br />
Autowhitelist Search Engine Ruleset<br />
<br />
This ruleset will automatically, and securely, whitelist search engine crawlers to prevent them from being blocked accidentally. This will protect your page rank with search engine crawlers.<br />
<br />
NOTE: This ruleset requires the MODSEC_00_SEARCENGINE setting to be enabled for this to work.<br />
<br />
Default: disabled<br />
<br />
Note: These are legacy rules, and should not be used with modsecurity 2.9.x You should use these rules instead:<br />
<br />
http://wiki.atomicorp.com/wiki/index.php?title=ASL_WAF#WAF_LUA_00_SEARCHENGINE<br />
<br />
'''Warning: You should only use this ruleset if the ASL server has a fast [[local DNS resolver]] server installed on the ASL server.'''<br />
<br />
===== MODSEC_00_WHITELIST =====<br />
<br />
Whitelist Ruleset<br />
<br />
Enable/Disable application of the whitelist '''for the WAF'''. <br />
<br />
''By default whitelisting does not apply to the WAF.''<br />
<br />
Note: enabling this will bypass *ALL* security checks for hosts on the whitelist '''for the WAF.'''<br />
<br />
Default: off<br />
<br />
By default, this is not enabled. <br />
<br />
ASL can respond to attacks in several different ways. The two that relate to the WAF are:<br />
<br />
*blocking<br />
*shunning<br />
<br />
Blocking is when ASL stops a single attack, and does not take any further action. <br />
<br />
Shunning is when ASL both block the single attack, and implement a firewall rule to block any further attacks from the same IP.<br />
<br />
ASL is configured to use the whitelist to prevent shunning by default, for IPs on the whitelist, but still to block attacks from that IP. This helps to prevent attacks from trusted sources, but prevents accidentally firewall rules when false positives occur. We do not recommend you disable blocking for trusted IPs. If you have a false positive, report it to us. Enabling this option tells ASL to totally ignore everything from the IPs on the whitelist, which includes not generating any alerts on this source and not to block anything. Which means if you do have a real attack from a trusted IP, you will not idea its occurred and theres nothing ASL can do to stop it.<br />
<br />
We dont recommend you you use this unless you know you can completely and totally trust every host on your whitelist every time. <br />
<br />
Most users will not need to enable this.<br />
<br />
Warning: We do not recommend you include your servers IP on this whitelist if you have a shared hosting server. Whitelisting localhost (127.0.0.1) and your local servers IP(s) from the WAF will means that local users can launch attacks against the server and against other domains on the server which will be neither detected nor prevented. If you have a rule that is being triggered by a local script, please report it as a false positive if it is a false positive, and if not, this may be an actual attack on your system or a poorly developed application. If you have a false positive from a whitelisted IP, please report it to us. Whitelisting in general is extremely dangerous and attackers know that users do this, which is why they target desktops and other trusted systems. If they can get access to these trusted systems, they can usually gain unfetered access to everything that users desktop, mobile device, laptop or other trusted system can access.<br />
<br />
Note: This ruleset requires this file to exist:<br />
<br />
/etc/asl/whitelist<br />
<br />
The format is one IP or CIDR per line. For example:<br />
<br />
<pre><br />
1.2.3.4<br />
10.0.0.0/8<br />
</pre><br />
<br />
=====MODSEC_00_BLACKLIST=====<br />
<br />
Blacklist Ruleset<br />
<br />
Enable/Disable application of the blacklist '''for the WAF'''. <br />
<br />
''By default blacklist is accomplished at Layer 3, and this ruleset is not necessary for most systems. This ruleset is only necessary if your configuration does not allow you to block attackers at Layer 3, such as when the system is behind a layer 7 proxy or load balancer.''<br />
<br />
Note: enabling this will block all IPs on the users custom blacklist '''for the WAF.'''<br />
<br />
Default: off<br />
<br />
ASL can respond to attacks in several different ways. The two that relate to the WAF are:<br />
<br />
*blocking<br />
*shunning<br />
<br />
Blocking is when ASL stops a single attack, and does not take any further action. <br />
<br />
Shunning is when ASL both blocks the single attack, and implements a layer 3 firewall rule to block any further attacks from the same IP.<br />
<br />
ASL is configured to use the blacklist to block all IPs at layer 3. It is not configured by default to do this at layer 7, the WAF, as this is generally not necessary for most systems. Most users will not need to enable this.<br />
<br />
Note: This ruleset requires this file to exist:<br />
<br />
/etc/asl/blacklist<br />
<br />
The format is one IP or CIDR per line. For example:<br />
<br />
<pre><br />
1.2.3.4<br />
10.0.0.0/8<br />
</pre><br />
<br />
Requires ASL 4.0.15 and up.<br />
<br />
===== MODSEC_00_THREAT =====<br />
<br />
Threat Intelligence System<br />
<br />
Enabling this allows your system to use Atomicorp Threat Intelligence system to block knownn attackers.<br />
<br />
'''Important: It is highly recommended you enable these rules only with a local DNS resolver installed and configured on the system. (If you do not know if you have a local DNS resolver installed and configured on your system, do not enable these rules until you have confirmed that you do).''' Please see this article for information on [[Local DNS resolver]]s.<br />
<br />
Note: hosts on the whitelist are automatically excluded from being blocked by this ruleset.<br />
<br />
===== MODSEC_00_ANTIEVASION =====<br />
<br />
Antievasion Ruleset<br />
<br />
Enable/Disable the antievasion rule class. This ruleset prevents attacks that try to bypass the WAF itself.<br />
<br />
===== MODSEC_00_STRICT ===== <br />
<br />
Strict Multiform Ruleset<br />
<br />
Enable/Disable the strict multiform checks rule class. This ruleset enforces strict adherence RFCs for multiform messages, strictly enforces allowed types and implements enhanced checks on inputs. This prevents advanced attacks that may try to bypass the WAF, or involve more complex evasion attacks. <br />
<br />
Note: Broken applications and clients that do not adhere to RFCs will not be able to send multiform to the system if you enable this. This not a false positive, these clients and applications are broken. If you are unfortunately stuck with these, you will have to disable this.<br />
<br />
===== MODSEC_00_RBL ===== <br />
<br />
RBL Ruleset<br />
<br />
Enable/Disable Real-time Black List (RBL) rule class. Currently this uses the [http://www.spamhaus.org/xbl/ Spamhaus XBL] which is operated by the Spamhaus project. This RBL is not operated or controlled by Atomicorp. Please contact Spamhaus if you have issues with the IPs on this RBL, or disable this option.<br />
<br />
'''Default: off'''<br />
<br />
'''Warning: You should only use this ruleset if the ASL server has a really fast DNS server installed on the ASL server.''' <br />
<br />
This ruleset will look up every request in the DNS to see if its on a blacklist, and will not finish serving the request until the DNS server responds. This can slow down requests if the DNS server is slow. Basically, web requests will move at the speed of the DNS servers replies.<br />
<br />
If your web server is responding slowly to requests, and you have this ruleset enabled your DNS server is too slow to meet your lookup needs. You will need to either disable this ruleset, or tune your DNS server to respond to queries more quickly.<br />
<br />
===== MODSEC_00_AE_RULES =====<br />
<br />
'''Anti-Evasion Protection system'''<br />
<br />
Antievasion Ruleset/MODSEC_00_ANTIEVASION: Enable/Disable the antievasion rule class. This ruleset prevents attacks that try to bypass the WAF itself.<br />
<br />
===== MODSEC_01_RULES ===== <br />
<br />
Advanced Antievasion Ruleset<br />
<br />
Enable/Disable the advanced antievasion protection rule class. This ruleset prevents attacks that try to bypass the WAF itself or can be used to trick applications into parsing data in ways that may compromise the application.<br />
<br />
===== MODSEC_01_APP_RULES =====<br />
<br />
This is a special ruleset that most users will never need. Please see this article to see if this ruleset applies to you:<br />
<br />
[[WAF_rule_families#01_asl_rules_special.conf]]<br />
<br />
Default:no<br />
<br />
Note: Do not enable this ruleset unless you know what you are doing.<br />
<br />
===== MODSEC_01_DOMAIN_BLOCKS =====<br />
<br />
MODSEC_01_DOMAIN_BLOCKS<br />
<br />
Enable/Disable user defined custom domain blocking class. This ruleset blocks connections from a user defined list of domains when DNS records exist that match the incoming IP (This allows you to block hosts based on their DNS names), and also blocks referrers that contain that domain name. <br />
<br />
[Default: no]<br />
<br />
In the ASL gui, click on the ASL tab, then select Blocking, and then the Domains tab. Domains or FQDNs are defined, one per line. Matching is by string, regular expressions are not supported. Therefore, example.com will also match anotherexample.com. If you want to limit the domain you will need to use a delimiter, as in the example, such as:<br />
<br />
.example.com<br />
<br />
Which will only match on FQDNs that include .example.com, and in the previous example would not match on anotherexample.com.<br />
<br />
Note: Available in ASL 4.0.1 and up. This works by comparing the forward and reverse DNS records, if they do not match the rule will not match.<br />
<br />
===== MODSEC_03_DOS ===== <br />
<br />
Denial of Service Protection<br />
<br />
Enable/Disable the Denial of Services protection rule class. This ruleset prevents the so-called "slowaris" Denial of Service attacks, as well as "fast" DOS attacks. DDOS attacks can not be mitigated on the host itself. <br />
<br />
''Note: Some fastcgi implementations, specifically cpanel, require this to be disabled.''<br />
<br />
===== MODSEC_06_HONEYPOT =====<br />
<br />
Custom User Defined Honeypot Ruleset<br />
<br />
Enable/Disable the Custom User Defined Honeypot Ruleset. This ruleset allows you to define custom files, directories or a combination of the two in the file below that you want to block access to:<br />
<br />
/etc/httpd/modsecurity.d/honeypot-files.txt<br />
<br />
The format is one rentry per line. '''This method does not support regular expressions, but is case insensitive.''' For example:<br />
<br />
<pre><br />
/backups/admin.php<br />
/wp-config.php<br />
/admin/secret<br />
</pre><br />
<br />
===== MODSEC_10_ANTIMALWARE ===== <br />
<br />
Anti-Malware Ruleset<br />
<br />
Enable/Disable the anti-malware rule class. This will look at any requests to the system for known malware domains and indicators of malware injection requests (this does not do the same thing as the MODSEC_99_SCANNER class, which will inspect uploads for malware).<br />
<br />
===== MODSEC_10_RULES ===== <br />
<br />
Generic Attack Ruleset<br />
<br />
Enable/Disable the core rule class. This class contains the core generic rules, which will look for things like SQLi, XSS, CSRF, recursion, code injection, command injection, XML attacks and other generic attack patterns. You should always leave this class enabled.<br />
<br />
===== MODSEC_11_ADV_RULES ===== <br />
<br />
Advanced Attack Ruleset<br />
<br />
Enable/Disable the advanced protection rule class. This class contains advanced rules.<br />
<br />
===== MODSEC_11_DLP ===== <br />
<br />
Data Loss Protection Ruleset<br />
<br />
Enable/Disable the data loss protection rule class. This will detect certain Data Loss events, such as credit card information being sent or errors messages from applications that may reveal sensitive information or that the system or application is vulnerable to particular attack.<br />
<br />
Additional types of data and errors this ruleset can detect in the output:<br />
<br />
# Credit Card Numbers <br />
# SSN numbers<br />
# Application Errors/Debug information that may leak sensitive data from:<br />
* Mysql<br />
* Postgres<br />
* MS-SQL<br />
* Oracle DB<br />
* hsqldb<br />
* SQLite<br />
* Informix<br />
* max DB<br />
* IBM DB2<br />
* EMC<br />
* ODBC<br />
* Jet DB<br />
* Access DB<br />
* Wordpress<br />
<br />
===== MODSEC_12_ADV_XSS_RULES =====<br />
<br />
Advanced Cross Scripting Protection (AXSSP)<br />
<br />
This is the advanced Cross Site Scripting (XSS) protection rule set. It performs deep level inspections of web requests and responses to look for potential XSS attacks. <br />
<br />
Note: This requires EL 6 and above.<br />
<br />
===== MODSEC_11_BRUTE ===== <br />
<br />
Supplemental Brute Force Protection Ruleset<br />
<br />
Enable/Disable the supplemental web brute force attack protection rule class. This ruleset is used on systems that do not have either ASL or Atomic Protector installed, and perform the process of tracking login failures, and send a 403 error to the user when the limit is reached.<br />
<br />
'''Note:''' This works by analysing the output of the web application, and does not rely on log analysis or htaccess files. Therefore, do not use application internal compression schemes on output. For example, do not enable GZIP compression in applications such as Joomla, PHPBB, Wordpress and others, as this will make it difficult for the WAF to see the output. You can still compress the output if you use an apache module such as mod_deflate, which accomplishes the same thing and is less CPU intensive that application internal compression. '''Litespeed does not currently support this ruleset. If you require this protection with Litespeed, you must use ASL and configure ASL to setup a local WAF, via ASL, in front of Litespeed.'''<br />
<br />
'''Discussion:'''<br />
<br />
For the WAF to be able to analyze output from web applications, the WAF must be able to understand the output from the web application. Applications that compress output send this compressed output to Apache, which creates a situation where the WAF will only see compressed content. In this case, the WAF will not be able to understand it because the WAF will not decompress it.<br />
<br />
Whereas it is possible for the WAF to decompress this content, and then recompress it, this is '''extremely''' wasteful for the CPU and will unnecessarily slow the system down. Essentially the web server would be compressing the content, decompressing it, and then compressing it again. Add in two unnecessary steps, and tripling the work load. The most efficient solution is to not compress output in the application, let the WAF inspect it, and then let apache compress it. <br />
<br />
'''Inline decompression with the WAF is no longer supported and has been removed from the WAF code as this leads to poor performance due to misconfiguration of the system.'''<br />
<br />
===== MODSEC_12_BRUTE ===== <br />
<br />
Brute Force Protection Ruleset<br />
<br />
Enable/Disable the web brute force attack protection rule class. Detects attempts to brute force web applications authentication mechanisms.<br />
<br />
'''Note:''' This works by analysing the output of the web application, and does not rely on log analysis or htaccess files. Therefore, do not use application internal compression schemes on output. For example, do not enable GZIP compression in applications such as Joomla, PHPBB, Wordpress and others, as this will make it difficult for the WAF to see the output. You can still compress the output if you use an apache module such as mod_deflate, which accomplishes the same thing and is less CPU intensive that application internal compression. '''Litespeed does not currently support this ruleset. If you require this protection with Litespeed, you must use ASL and configure ASL to setup a local WAF, via ASL, in front of Litespeed.'''<br />
<br />
'''Discussion:'''<br />
<br />
For the WAF to be able to analyze output from web applications, the WAF must be able to understand the output from the web application. Applications that compress output send this compressed output to Apache, which creates a situation where the WAF will only see compressed content. In this case, the WAF will not be able to understand it because the WAF will not decompress it.<br />
<br />
Whereas it is possible for the WAF to decompress this content, and then recompress it, this is '''extremely''' wasteful for the CPU and will unnecessarily slow the system down. Essentially the web server would be compressing the content, decompressing it, and then compressing it again. Add in two unnecessary steps, and tripling the work load. The most efficient solution is to not compress output in the application, let the WAF inspect it, and then let apache compress it. <br />
<br />
'''Inline decompression with the WAF is no longer supported and has been removed from the WAF code as this leads to poor performance due to misconfiguration of the system.'''<br />
<br />
===== MODSEC_20_USERAGENTS ===== <br />
<br />
Malicious Useragents Ruleset<br />
<br />
Enable/Disable the useragents rule class. Detects known malicious or suspicious user agents.<br />
<br />
===== MODSEC_21_USERAGENTS ===== <br />
<br />
User Defined Malicious Useragents Ruleset<br />
<br />
Enable/Disable the User Defined Malicious Useragents Ruleset. This ruleset allows you to define custom useragents in the file below that you want to block:<br />
<br />
/etc/httpd/modsecurity.d/bad_agents.txt<br />
<br />
The format is one user-agent per line. '''This method does not support regular expressions, but is case insensitive.''' For example<br />
<br />
<pre><br />
Mozila 99.0<br />
Internut exploder<br />
</pre><br />
<br />
===== MODSEC_30_ANTISPAM ===== <br />
<br />
Anti-Spam Ruleset<br />
<br />
Enable/Disable the anti-spam rule class. This class contains tuned antispam rules, designed to work with all known blogs, forums, guestbooks, CMS' and other web content management systems that allow users to post content. <br />
<br />
===== MODSEC_31_ANTISPAM_URI ===== <br />
<br />
Anti-Spam URI RBL Ruleset<br />
<br />
Enable/Disable the anti-spam URI rule class. Looks up all URIs in a post against RBLs to see if its a known spam domain. As with the MODSEC_00_RBL rules, these should only be used if the server has a local fast DNS server. <br />
<br />
'''Warning: You should only use this ruleset if the ASL server has a really fast DNS server installed on the ASL server.''' <br />
<br />
This ruleset will look up every request in the DNS to see if its on a blacklist, and will not finish serving the request until the DNS server responds. This can slow down requests if the DNS server is slow. Basically, web requests will move at the speed of the DNS servers replies.<br />
<br />
If your web server is responding slowly to requests, and you have this ruleset enabled your DNS server is too slow to meet your lookup needs. You will need to either disable this ruleset, or tune your DNS server to respond to queries more quickly.<br />
<br />
===== MODSEC_50_ROOTKITS ===== <br />
<br />
Rootkit Detection Ruleset<br />
<br />
Enable/Disable the rootkit rule class. This class detects and blocks known rootkits, PHP/ASP/PERL shells, spam tools and other malicious web applications from running on the system. (These rules exist for cases where malicious software may already be installed on the system, this is a defense in depth rule set) <br />
<br />
===== MODSEC_60_RECONS ===== <br />
<br />
Reconnaissance Attacks Ruleset<br />
<br />
Enable/Disable the recon rule class. This class blocks known "google hacks" or webserver probes that look for vulnerable applications and signs of compromised systems running unauthorized shells, or unprotected applications that allow uploads which would give an attacker access to the system. <br />
<br />
===== MODSEC_61_DLP ===== <br />
<br />
Data Leak Prevention Ruleset<br />
<br />
Enable/Disable the data loss protection class. These rules detect Data Loss Search engine "hacks". These are search engine probes for sensitive files, often used by malicious parties to find sensitive information accidentally exposed on web servers.<br />
<br />
===== MODSEC_98_ADV_REDACTOR =====<br />
<br />
Advanced Malware Removal Ruleset<br />
<br />
Enable/Disable the advanced malware removal ruleset. These rules detect hidden iframes, obfuscated javascript and other potentially malicious code and remove it real time from your web pages.<br />
<br />
===== MODSEC_99_JITP ===== <br />
<br />
Just In Time Patches<br />
<br />
Enable/Disable the Just In Time Patches(JITP) rule class. Just in Time Patches. We publish JITPs daily if there is a new web application vulnerability that the 10_asl_rules.conf do not protect the system against. These are tuned rules for specific vulnerabilities in a web application. <br />
<br />
===== MODSEC_99_REDACTOR ===== <br />
<br />
Malicious Output Removal Ruleset<br />
<br />
Enable/Disable the automatic malicious/hidden iframe and malware removal rule class. Automatically removes malicious code from web pages, such as hidden iframes, encoded javascript and other malicious code. <br />
<br />
===== MODSEC_99_MALWARE_OUTPUT ===== <br />
<br />
Malicious Output Detector<br />
<br />
Enable/Disable the malware output rule class.<br />
<br />
===== MODSEC_99_SCANNER ===== <br />
<br />
Web Malware Upload Scanner<br />
<br />
Malicious code upload scanner. Enable this to scan web uploads for malicious code.<br />
<br />
===== MODSEC_99_ADV_SCANNER =====<br />
<br />
Advanced Malware Upload Scanner<br />
<br />
This enables the advanced malware upload scanner rule class. This uses fuzzy hashes to detect similiar malware.<br />
<br />
= Rule Manager =<br />
<br />
The Rule manager can be used to configure individual WAF rules, such as what response the system such take for that rule, if an email or GUI alert should be presented, and so on. To access the rule manager please follow this process:<br />
<br />
Step 1) Log into the ASL GUI<br />
<br />
Step 2) Click the "Configuration" tab.<br />
<br />
Step 3) Select "Rule Management"<br />
<br />
This will bring up the rule management screen. There are two tabs on this screen:<br />
<br />
Global: This sets global features for all the rules<br />
<br />
Rules: This presents all the individual rules, and options to configure that rule specifically.<br />
<br />
== Global Options ==<br />
<br />
If you change a setting on this screen, you must click the "Update" button for the setting changes to take effect.<br />
<br />
The follow settings are available in the Global setting screen:<br />
<br />
=== Email to === <br />
<br />
This sets the email address to send alerts to. The default is $EMAIL which inherits the global email address set in the ASL Configuration screen. If you want to use the same email address you set when you configured when you install ASL leave this setting as "$EMAIL". Otherwise, change this to the email address you want rule alerts sent to.<br />
<br />
=== Email From ===<br />
<br />
Set this to the From: line you want to use for the emailed alerts. Available variables are $HOSTNAME is is populated by the servers fully qualified hostname, and $EMAIL which is set in the ASL Configuration screen. The default is usually effective for most users.<br />
<br />
=== Max Emails per hour ===<br />
<br />
This sets a limit on the maximum number of emails the system will sent to the Email to: address. This basically "queues up" alerts. If events occur after the Max Emails per hour limit has been reached, then those alerts will be held until the next hour and will be grouped together in a single email sent the next hour.<br />
<br />
If you want alerts to be sent as they occur, and not to be queued up, set this to 9999.<br />
<br />
=== Active Response ===<br />
<br />
This sets whether of not ASL will block the source of the attack, by implementing a firewall rule for the source of the attack. (Which may be a temporary shun, or a permanent shun depending on the setting below "Shun Timeout")<br />
<br />
=== Shun Timeout ===<br />
<br />
This tells ASL if the firewall block, or "shun", should be temporary or permanent. Once the Shun Time (described below) has been reached the source IP address will be allowed to connect again. The ASL Configuration settings also allow for advanced options for this, such as multiplers that cause sources to be shunned for longer periods of time as more attacks are detected from the source.<br />
<br />
=== Shun Time ===<br />
<br />
Timeout period is in seconds. This sets the maximum amount of time a source address will be blocked by ASL/<br />
<br />
If Shun Timeout is set to no, the "shun" is permanent and this option is ignored.<br />
<br />
=== Rules ===<br />
<br />
The Rules Manager has two tabs:<br />
<br />
==== HIDS ====<br />
<br />
This contains all the Rules for HIDS. For documentation on the HIDS please see the [[ASL HIDS]] documentation page.<br />
<br />
==== WAF ====<br />
<br />
This contains all the Rules for the WAF. There are two columns on this tab, the left column contains the current rule sub classes, and the screen on the right shows all rules that match your current filter selections. The window on the right is populated by selecting either a subclass of rules, or by typing in search criteria in the boxes at the top of the screen. <br />
<br />
If you select a rule sub class, for example "adult-spam" that will pull up all the rules in the class on the right hand side of the screen.<br />
<br />
Or you can search for specific rules by using the filter bar at the top of the screen. The filter options are:<br />
<br />
Category: This is another way to select a rule subclass, this is optional, you do not have to select a rule class. If you leave this in either the default, or you set this to (any) your filter will apply to all the WAF rules. <br />
<br />
Level: Rules have different levels, depending on severity. Some rules are only informational, some indicate suspicious activity and others are full blown attacks. A higher number is a high severity or importance, and a lower number is a lower severity or importance. This filter is optional, you do not need to select a level if you do not want to filter by level. If you leave the default your filter will apply to all levels.<br />
<br />
Search: This allows you to search by any thing in the rule, its name, ID, etc. If you hit enter in this field it will start the search. <br />
<br />
When you have finished with your filter criteria, just click the "filter button" or hit enter in the search field.<br />
<br />
=== Configuring specific rules ===<br />
<br />
Once you have the rule manager open, and have pulled up a rule you want to modify just click on the down arrow next to the rules ID to open the rules options. <br />
<br />
===== Rule Options =====<br />
<br />
For WAF rules the following options are available:<br />
<br />
<br />
====== Disabled ======<br />
<br />
Setting this "yes" globally disables the rule. If you want to disable a rule for a specific domain or FQDN see the Vhost option below.<br />
<br />
====== Severity ======<br />
<br />
This sets the severity level for the event. This allows you to set rules to be lower or higher priority which will effect:<br />
<br />
1. How they are displayed in the GUI<br />
<br />
2. Whether they are shunned or not (a minimum severity level can be set in ASL to control if an event is important enough to block the source IP address, please see the [[ASL Configuration]] documentation for these settings.<br />
<br />
3. If an email alert is sent. A minimum severity level can be set in ASL to control if an event is important enough to send an email alert, please see the [[ASL Configuration]] documentation for these settings.<br />
<br />
====== Active Response ======<br />
<br />
This sets if the system should perform any active response actions against the source IP address. This option is ignored if Active Response is disabled in the Global options.<br />
<br />
====== Email ======<br />
<br />
This sets if the event will generate an email alert. Keep in mind that the event must also be above the minimum level set in the [[ASL Configuration]].<br />
<br />
====== Logging ======<br />
<br />
This sets if the event will be displayed, at all, in the ASL GUI. Setting this to off "silences" the event in the ASL GUI. It does not prevent the event from being logged to the systems logs.<br />
<br />
====== Vhost settings ======<br />
<br />
This subpanel allows you to set domain or FQDN specific settings for a rule. For example, if you want a rule to other behave per its defaults, but want to change its behavior for a specific domain you can set that domain here.<br />
<br />
Currently this is limited to disabling the rule for the domain. In the future this will be expanded to allow other options for the rule as with the global settings.<br />
<br />
Simply type in the domain name in the text box on the right, select "yes" and click add.<br />
<br />
=== Rule Tuning ===<br />
<br />
Please see the [[Mod_security]] page.<br />
<br />
= Events =<br />
<br />
WAF events are displayed in the [[ASL Events]] window. Please see the [[ASL Events]] page for usage information.<br />
<br />
= Configuring web servers to use the T-WAF =<br />
<br />
This section provides courtesy instructions about how to configure a remote web server to work with the T-WAF, so that the remote web server reports the correct client IP address and not the IP address for the T-WAF server.<br />
<br />
This can also be used with local web services. For local apache servers, we do not recommend you use the T-WAF. Instead, make sure you are using the embedded mode explained at the beginning of this article. The WAF will integrate natively with Apache 2.x, and is highly recommended for that platform.<br />
<br />
== Apache ==<br />
<br />
Note: If you are using embedded mode (which is the default) you do not need to do this. You will only need to do this if you are using the T-WAF to proxy traffic to a remote apache server. If you have a local apache server that ASL is installed on, install modsecurity locally.<br />
<br />
For remote apache servers, to setup Apache to report the clients IP when using the T-WAF follow this process:<br />
<br />
Step 1) Install mod_rpaf<br />
<br />
http://stderr.net/apache/rpaf/<br />
<br />
Step 2) Add this to your remote servers apache configuration<br />
<br />
<pre><br />
LoadModule rpaf_module path/to/mod_rpaf-2.0.so<br />
RPAFenable On<br />
RPAFsethostname On<br />
RPAFproxy_ips <IP FOR THE ASL SERVER><br />
RPAFheader X-Forwarded-For<br />
</pre><br />
<br />
Change the IP in this line:<br />
<br />
RPAFproxy_ips <IP FOR THE ASL SERVER><br />
<br />
To the IP for your ASL server. For example, if the ASL servers IP address is 1.2.3.4 this line will look like this:<br />
<br />
RPAFproxy_ips 1.2.3.4<br />
<br />
Step 3) Restart the remote apache server<br />
<br />
== Litespeed ==<br />
<br />
To setup Litespeed to report the correct IP address of the client when using the T-WAF follow these instructions:<br />
<br />
Step 1) Log into the LiteSpeed Web Admin Console<br />
<br />
Step 2) Under Configuration, enable the option "Use Client IP in Header".<br />
<br />
Step 3) Restart Litespeed<br />
<br />
== Nginx ==<br />
<br />
Step 1) Edit your nginx.conf file and add the following to your http section:<br />
<br />
<pre><br />
http {<br />
set_real_ip_from 127.0.0.1/32;<br />
set_real_ip_from <YOUR SERVERS IP>/32;<br />
set_real_ip_from <YOUR SERVERS OTHER IPS>/32;<br />
real_ip_header CF-Connecting-IP;<br />
</pre><br />
<br />
Replace <YOUR SERVERS IP> with your servers IP(s). For example, if your server had the IPs 1.2.3.4, 1.2.3.5 and 1.2.3.6 your configuration would look like this:<br />
<br />
<pre><br />
set_real_ip_from 127.0.0.1/32;<br />
set_real_ip_from 1.2.3.4/32;<br />
set_real_ip_from 1.2.3.5/32;<br />
set_real_ip_from 1.2.3.6/32;<br />
real_ip_header CF-Connecting-IP;<br />
</pre><br />
<br />
<br />
Step 2) Restart nginx.</div>Mshinnhttps://wiki.atomicorp.com/wiki/index.php/ASL_WAFASL WAF2022-07-01T22:19:56Z<p>Mshinn: /* MODSEC_11_DLP */</p>
<hr />
<div>= Introduction =<br />
<br />
The ASL WAF has two non-exclusive modes operation:<br />
<br />
1) Embedded mode<br />
<br />
2) Transparent/Proxy mode (T-WAF)<br />
<br />
== Embedded mode ==<br />
<br />
Embedded mode works with Apache 2.x. ASL will install a special module in Apache to give it native WAF protection capabilities. This installation will occur when ASL is installed.<br />
<br />
== Proxy mode (T-WAF) ==<br />
<br />
Proxy mode or the Transparent WAF (T-WAF) system allows ASL to protect any HTTP and/or HTTPS service, either a local server (such as when using a web server that does not support embedded mode) or a remove server.<br />
<br />
= Configuration =<br />
<br />
The ASL WAF is initially configured during the install of ASL. If Apache is installed on the system, ASL will attempt to install the embedded WAF module. If Apache is installed on the system via package management, then this will occur automatically and you will not need to configure the WAF further to protect an installed Apache instance. <br />
<br />
Once ASL is installed, if you need to do so, you can configure the WAF through three parts of the ASL GUI:<br />
<br />
== WAF Tab ==<br />
<br />
This tab is used to setup the WAF. There are three types of WAF you can configure:<br />
<br />
=== embedded ===<br />
<br />
The embedded WAF is an apache module that is installed on any local Apache installations. This should be setup by default, if you are running apache on the system and a [https://www.atomicorp.com/wiki/index.php/ASL_FAQ#Apache supported version and build of Apache].<br />
<br />
=== local ===<br />
<br />
Note: You do not need to setup a local WAF for package managed installs of apache. ASL will detect if a package managed version of Apache is installed, and will install the WAF module into apache [https://www.atomicorp.com/wiki/index.php/ASL_WAF#embedded embedded mode], as described above. For custom apache installs, please follow these directions.<br />
<br />
This type of WAF is used to protect any local HTTP and/or HTTPS services that may be running on the system itself, where the embedded WAF module can not be used. For example, if the system was running a tomcat or litespeed web server, which do not support the embedded WAF module, or a control panel that uses it own web server (such as Plesk, Cpanel, Webmin, and others). You can configure a WAF to protect these services.<br />
<br />
To setup a local WAF simply follow these steps:<br />
<br />
Step 1) Log into the ASL GUI<br />
<br />
Step 2) Click the WAF tab<br />
<br />
Step 3) Select WAF Config<br />
<br />
This will pull up the WAF Config window, which will show the existing WAFs.<br />
<br />
Step 4) Click "Enable T-WAF". If you see "Disable T-WAF" this option has already been enabled.<br />
<br />
Step 5) Click "Add"<br />
<br />
This will will pull up the "Add WAF Config" window.<br />
<br />
Step 6) Click on the "Add protection for" drop down. Select "local"<br />
<br />
This will present you with two options:<br />
<br />
Local Port: Type in the local HTTP/HTTPS port you wish to protect. Only type in one port number.<br />
<br />
Note: Check if you have any embedded WAFs installed on the system before you do this. If you have an embedded WAF already installed on port 80, as should occur if you have Apache installed (and its package managed), then enabling the T-WAF in front of Apache would create a loop. Its not necessary to put a WAF in front of a service that is protected via embedded mode.<br />
<br />
SSL: Select this if the service you wish to protect is SSL based.<br />
<br />
If you select SSL, then you will see this additional options:<br />
<br />
Path to SSL Certificate: Provide the filesystem path to the SSL certificate for this service.<br />
<br />
Path to SSL Key file: Provide the filesystem path to the SSL key file for this service.<br />
<br />
Step 7) Then click Save<br />
<br />
Note: You do not need to reconfigure your web server to use a different port, ASL will transparently intercept the packets to your web server based on the port you configure above. If you change your web servers port, ASL will not intercept packets to that port.<br />
<br />
=== remote ===<br />
<br />
'''Note: You need a [https://www.atomicorp.com/amember/cart/index/index?c=9 reverse proxy ASL license] to use this feature. This feature will not work without a reverse proxy license.'''<br />
<br />
This type of WAF is used to protect any remote HTTP and/or HTTPS services that are not running on the system itself. For example, if you have a remote webserver you wish to protect, you can configure a WAF to protect these services. The remote WAF can support two proxy modes: domain based and IP based.<br />
<br />
==== name based remote ====<br />
<br />
Domain based or name nased WAFs allow you to use a single IP address on the WAF, and to direct WAF requests to different backend servers depending on their domain or full qualified domain name, or even to specific URL.<br />
<br />
==== IP based remote ====<br />
<br />
IP based WAFs allow you to redirect all traffic to an IP address on WAF to a specific destination host or URL.<br />
<br />
==== Setting up a remote WAF ====<br />
<br />
To setup a remote WAF simply follow these steps:<br />
<br />
Step 1) Log into the ASL GUI<br />
<br />
Step 2) Click the WAF tab<br />
<br />
Step 3) Select WAF Config<br />
<br />
This will pull up the WAF Config window, which will show the existing WAFs.<br />
<br />
Step 4) Click "Enable T-WAF". If you see "Disable T-WAF" this option has already been enabled.<br />
<br />
Step 5) Click "Add"<br />
<br />
This will will pull up the "Add WAF Config" window.<br />
<br />
Step 6) Click on the "Add protection for" drop down. Select "remote"<br />
<br />
This will present you with a dropdown options to setup the WAF as either domain based or IP based.<br />
<br />
Step 7) If you select name based you will be presented with these options:<br />
<br />
Domain Name: Enter the domain name or full qualified domain you wish to use. For example, if you want the WAF to handle traffic for intranet.example.com enter that FQDN in this box.<br />
<br />
Local Url: Enter the local URL, if any, that the WAF should expect from the client to direct this connection to the remote host. The default of / is usually correct if you are forwarding all traffic for an FQDN or domain. If you only want the WAF to pass on specific requests for specific URLs, enter them here. <br />
<br />
Destination: Enter the full URL you want the WAF to use as the destination server. Make sure you have DNS or /etc/hosts entries for this, otherwise the WAF will not be able to find the destination. This should also not be the same thing as "Domain Name:". You can also use https:// URLs here.<br />
<br />
Remote Port: Type in the remote port for the backend server the WAF will be sending requests to.<br />
<br />
SSL: Select SSL if you wish to accept SSL connections to the WAF. If you select this you will be presented with these additional options:<br />
<br />
Path to SSL Certificate: Provide the filesystem path to the SSL certificate for this service.<br />
<br />
Path to SSL Key file: Provide the filesystem path to the SSL key file for this service.<br />
<br />
Skip to step 8<br />
<br />
Step 7) If you select IP based you will be presented with these options<br />
<br />
IP Address: Enter the IP address you want the WAF to listen on (you can set multiple IPs by adding additional remote WAFs). For example, if you want the WAF to redirect all traffic on IP address 1.2.3.4 to internal.example.com, type in 1.2.3.4.<br />
<br />
Local Url: Enter the local URL, if any, that the WAF should expect from the client to direct this connection to the remote host. The default of / is usually correct if you are forwarding all traffic for an FQDN or domain. If you only want the WAF to pass on specific requests for specific URLs, enter them here. <br />
<br />
Destination: Enter the full URL you want the WAF to use as the destination server. Make sure you have DNS or /etc/hosts entries for this, otherwise the WAF will not be able to find the destination. This should also not be the same thing as "Domain Name:". You can also use https:// here.<br />
<br />
Remote Port: Type in the remote port for the backend server the WAF will be sending requests to.<br />
<br />
SSL: Select SSL if you wish to accept SSL connections to the WAF. If you select this you will be presented with these additional options:<br />
<br />
Path to SSL Certificate: Provide the filesystem path to the SSL certificate for this service.<br />
<br />
Path to SSL Key file: Provide the filesystem path to the SSL key file for this service.<br />
<br />
Step 8) Then click Save<br />
<br />
== SSL/TLS ==<br />
<br />
If you select SSL for either the local or remote WAF options, your SSL certificates and keys must be in an Apache compatible format to be imported by the T-WAF.<br />
<br />
== ASL Configuration Settings ==<br />
<br />
The WAFs settings are contained under the Configuration tab. To Configure the WAF follow this process:<br />
<br />
Step 1) Log into the ASL GUI<br />
<br />
Step 2) Click on the Settings Tab<br />
<br />
Step 3) Select the "ASL Configuration" sub menu<br />
<br />
Step 4) Scroll down to the "Web Application Firewall" configuration section. The following options are available:<br />
<br />
=== MODSEC_ENABLED ===<br />
<br />
This setting Enables/Disables the entire WAF system. This is the only supported method for disabling the WAF in ASL. Uninstalling mod_security and the use of third party methods to remove modsecurity will not work if this setting is still configured to enable the WAF. This setting is specifically designed to ensure that the WAF is not disabled accidentally by a third party product.<br />
<br />
=== WAF_ENGINE ===<br />
<br />
Set the WAF engine mode, there are three modes:<br />
<br />
On - this tells the WAF to detect and block attacks.<br />
<br />
DetectionOnly - this tells the WAF to only detect and report attacks, but not to block them.<br />
<br />
Off - Disables the WAF.<br />
<br />
=== WAF_ENABLED ===<br />
<br />
Enable/Disable Tortix WAF proxy. The tortix waf module, this module can process local or remote services through the Tortix Web Application Firewall (T-WAF) . (Default: Off)<br />
<br />
'''Note: This option is deprecated in ASL 4.'''<br />
<br />
=== WAF_CHROOTDIR ===<br />
<br />
Configures the directory path that will be used to jail the web server process. (For the embedded WAF modules only). This lets you put the local apache instance into a chroot jail.<br />
<br />
=== WAF_READSTATELIMIT ===<br />
<br />
Sets the limit of the number of connections from the same IP address that can be in the Read state for the WAF. This helps to prevent "slow" DOS attacks. For example, if this was set to "5" a single IP would only be able to keep 5 connections in a busy state with the web server at a single time.<br />
<br />
ASL 3 Default: 10<br />
<br />
ASL 4 Default: 100<br />
<br />
=== Write State Limit ===<br />
<br />
WAF_WRITESTATELIMIT: Sets the limit of the number of connections from the same IP address that can be in the Write state for the WAF. This helps to prevent "slow" DOS attacks. For example, if this was set to "5" a single IP would only be able to keep 5 connections in a busy state with the web server at a single time.<br />
<br />
(Default: 100)<br />
<br />
Note: This option is only available in ASL 4 and up.<br />
<br />
=== WAF_SECREQUESTBODYNOFILESLIMIT ===<br />
<br />
(Default: 1048576) Configures the maximum request body size the WAF modules will accept for buffering. There is a hard limit of 1GB. This is not a limit on file sizes sent through the WAF, just request body sizes.<br />
<br />
=== WAF_SECREQUESTBODYINMEMORYLIMIT ===<br />
<br />
(Default: 131072) Configures the maximum request body size the WAF modules will store in memory. There is a hard limit of 1GB. The default of 128 MB is generally sufficient for any site.<br />
<br />
=== WAF_DEFAULT_ACTION ===<br />
<br />
Configures the block policy, deny the request or redirect the client to a landing page. <br />
<br />
=== WAF_REDIRECT_URL ===<br />
<br />
Used for WAF_DEFAULT_ACTION of "redirect". This is the URL to redirect blocked pages. This must include http:// or https:// in the URL.<br />
<br />
Example:<br />
<br />
https://%{server_name}:30000/blocked.php?eventid=%{eventid}<br />
<br />
You can use variables in the URL. They must be represented in this format:<br />
<br />
<pre>%{variable_name}</pre><br />
<br />
'''Important Note:''' If you have [https://www.atomicorp.com/wiki/index.php/ASL_Configuration#OSSEC_ACTIVE_RESPONSE OSSEC_ACTIVE_RESPONSE] enabled, then redirects will not work as the systems firewall will still block the user. You must disable OSSEC_ACTIVE_RESPONSE to use redirects.<br />
<br />
==== Supported Variables ====<br />
<br />
Currently supported variables are listed below. As new variables are supported, we will add them to the documentation here. <br />
<br />
===== server_name =====<br />
<br />
This is the value the client sent in the Host: header, which would be the FQDN the client accessed.<br />
<br />
==== ruleid ====<br />
<br />
The rule ID for the rule that was triggered.<br />
<br />
===== unique_id =====<br />
<br />
The unique ID for each event recorded by the WAF.<br />
<br />
The variable UNIQUE_ID is set to the identifier for each request. The UNIQUE_ID environment variable is constructed by encoding the 112-bit (32-bit IP address, 32 bit pid, 32 bit time stamp, 16 bit counter) quadruple using the alphabet [A-Za-z0-9@-] in a manner similar to MIME base64 encoding, producing 19 characters.<br />
<br />
===== remote_addr =====<br />
<br />
The client IP address.<br />
<br />
===== server_port =====<br />
<br />
This variable contains the local port of the webserver that the request was received on.<br />
<br />
==== Experimental Variables ====<br />
<br />
These are additional variables that should be considered experimental, and are available in the engine, but are not currently supported. They require newer versions of modsecurity, which may not be available in the stable channel.<br />
<br />
===== auth_type =====<br />
<br />
This variable holds the authentication method used to validate a user, if any of the methods built into HTTP are used. In a reverse-proxy deployment, this information will not be available if the authentication is handled in the backend web server. <br />
<br />
===== remote_user =====<br />
<br />
This variable holds the username of the authenticated user. If there are no password access controls in place (Basic or Digest authentication), then this variable will be empty. <br />
<br />
===== time =====<br />
<br />
This variable holds a formatted string representing the time (hour:minute:second). <br />
<br />
===== time_day =====<br />
<br />
This variable holds the current date (1–31). <br />
<br />
===== time_epoch =====<br />
<br />
This variable holds the time in seconds since 1970. <br />
<br />
===== time_hour =====<br />
<br />
This variable holds the current hour value (0–23). <br />
<br />
===== time_min =====<br />
<br />
This variable holds the current minute value (0–59).<br />
<br />
===== time_mon =====<br />
<br />
This variable holds the current month value (0–11).<br />
<br />
===== time_sec =====<br />
<br />
This variable holds the current second value (0–59). <br />
<br />
===== time_wday =====<br />
<br />
This variable holds the current weekday value (0–6).<br />
<br />
===== time_year =====<br />
<br />
This variable holds the current four-digit year value. <br />
<br />
===== response_status =====<br />
<br />
This variable holds the HTTP response status code.<br />
<br />
===== request_protocol =====<br />
<br />
This variable holds the request method used in the transaction.<br />
<br />
===== useragent_ip =====<br />
<br />
This variable is created when running modsecurity with apache 2.4 and will contain the client ip address set by mod_remoteip in proxied connections. Requires mod_remoteip to be installed, and Apache 2.4.<br />
<br />
=== Intercept on error===<br />
<br />
WAF_SECINTERCEPTONERROR: Configures how to respond when rule processing fails. [Default: on]<br />
<br />
===Analyze response body===<br />
<br />
WAF_SECRESPONSEBODYACCESS: Configures whether response bodies are to be buffer and analysed or not. [Default: on]<br />
<br />
=== MODSEC_SERVERSIG ===<br />
<br />
Field returned when a remote host queries what kind of web server this is. This can be used to hide what kind of server is running on the system, or what the WAFs are protecting.<br />
<br />
=== MODSEC_UPLOADDIR ===<br />
<br />
Configures the directory where intercepted files will be stored. If the WAF is configured to scan uploads, and this is set to On, then any malicious files the WAF detects will be stored in this directory on the server. <br />
<br />
=== MODSEC_KEEPFILES ===<br />
<br />
Configures whether or not the intercepted files will be kept after transaction is processed. It is recommended you set to this off.<br />
<br />
=== MODSEC_LOGTYPE ===<br />
<br />
Configures the type of audit logging mechanism to be used. Concurrent - audit log entries will be stored in separate files, one for each transaction. Serial - all audit log entries will be stored in the main audit logging file. The default is Concurrent, which is both faster and more reliable and works with ASL Gui. Serial logging is for legacy purposes and should not be enabled.<br />
<br />
=== MODSEC_LOGFILE ===<br />
<br />
The name of the log file that is used to store audit record headers. Do not change this unless you know what you are doing. It is generally not necessary to change this setting.<br />
<br />
=== MODSEC_LOGELEMENT ===<br />
<br />
Defines which part of each transaction are going to be recorded in audit log. Do not change the defaults unless you know what you are doing, this may break the GUI and active response systems.<br />
<br />
Available audit log parts:<br />
<br />
A: Audit log header (mandatory).<br />
<br />
B: Request headers.<br />
<br />
C: Request body (present only if the request body exists and ModSecurity is configured to intercept it).<br />
<br />
D: Reserved for intermediary response headers; not implemented yet.<br />
<br />
E: Intermediary response body (present only if ModSecurity is configured to intercept response bodies, and if the audit log engine is configured to record it). Intermediary response body is the same as the actual response body unless ModSecurity intercepts the intermediary response body, in which case the actual response body will contain the error message (either the Apache default error message, or the ErrorDocument page).<br />
<br />
F: Final response headers (excluding the Date and Server headers, which are always added by Apache in the late stage of content delivery).<br />
<br />
G: Reserved for the actual response body; not implemented yet.<br />
<br />
H: Audit log trailer.<br />
<br />
I: This part is a replacement for part C. It will log the same data as C in all cases except when multipart/form-data encoding in used. In this case, it will log a fake application/x-www-form-urlencoded body that contains the information about parameters but not about the files. This is handy if you don’t want to have (often large) files stored in your audit logs.<br />
<br />
J: This part contains information about the files uploaded using multipart/form-data encoding.<br />
<br />
K: This part contains a full list of every rule that matched (one per line) in the order they were matched. The rules are fully qualified and will thus show inherited actions and default operators. <br />
<br />
Z: Final boundary, signifies the end of the entry (mandatory). <br />
<br />
=== MODSEC_REQMEMLIMIT ===<br />
<br />
Configures the maximum request body size ModSecurity will store in memory. The default are adequate for most sites, you should not change this unless you know what you are doing.<br />
<br />
=== MODSEC_DEBUGLOG ===<br />
<br />
Enable/Disable the ModSecurity debug log file. The debug log is located in /var/log/httpd/modsec_debug.log Enabling this will incur a substantial performance penalty on the system. You should not enable this on a production system, and only if you are debugging modsecurity rules.<br />
<br />
Most users will want to leave this disabled.<br />
<br />
=== MODSEC_CLEAN_ALERT ===<br />
<br />
Number of days to retain mod_security alert data. The WAF will store the actual full requests of any intercepted attacks, to make it possible for you to investigate them and to report these to us, either for further investigation, false positives or for other forensics needs. The default is to keep these for 30 days.<br />
<br />
Audit log events are kept in this directory by default:<br />
<br />
/var/asl/data/audit/<br />
<br />
=== MODSEC_DATADIR ===<br />
<br />
Path where persistent data (e.g. IP address data, session data, etc) is to be stored.<br />
<br />
=== MODSEC_AUDITDIR ===<br />
<br />
'''Warning: This setting is unsupported'''<br />
<br />
Defines the path to the audit log files. Used only when Concurrent mode is configured.<br />
<br />
=== MODSEC_TMPDIR ===<br />
<br />
Configures the directory where temporary files will be created.<br />
<br />
Note: If this is changed form the default of /tmp, the directory must be writable by apache, which means depending on how you have configured apache by whatever users the web application may be running as. For example, if you use suphp, then the web application will run as a specific user. The directory must be writable by that user. In that case, you will need to either create a group that all your users belong to and make sure that group can write to that directory, or you will need to make that directory world writable. We also recommend you set the sticky bit on the directory. The simplest solution is to set the directories permissions thusly:<br />
<br />
For example, if you change this directory to /var/asl/mod_sec_tmp, these permissions should work generically in all cases:<br />
<br />
chmod ogu+rwx /var/asl/mod_sec_tmp<br />
<br />
chmod o+t /var/asl/mod_sec_tmp<br />
<br />
=== MODSEC_RESPONSEBODYLIMIT ===<br />
<br />
Configures the maximum response body size that will be accepted for buffering.<br />
<br />
=== MODSEC_RESPONSEBODYLIMITACTION ===<br />
<br />
Controls what happens once a response body limit, configured with SecResponseBodyLimit, is encountered. There are two options:<br />
<br />
ProcessPartial: Scan the response up to the limit and stop scanning when the limit is reached, but send the rest of the response.<br />
<br />
Reject: If the response is greater than the Limit, reject the response entirely.<br />
<br />
=== MODSEC_REQUESTBODYLIMIT === <br />
<br />
This sets the maximum size for a request body in bytes. The default is 134217728 bytes.<br />
<br />
Anything over the limit will be rejected with status code 413 (Request Entity Too Large). There is a hard limit of 1 GB. <br />
<br />
==== Ruleset Settings ====<br />
<br />
These allow you to enable/disable entire Rulesets and classes of rules. If you want to configure a specific rule, use the Rule Manager.<br />
<br />
===== Crawler Protector =====<br />
<br />
This unique feature of [[ASL]] protects not only your system, but also your search engine rankings. Unlike other security products, ASL can automatically and securely detect real search engine crawlers and prevent your system from accidentally blocking them. It can also detect when attackers are trying to pretend to be search engines, in hopes of getting around your security systems, and can safely block them, without blocking the real crawlers!<br />
<br />
<br />
====== WAF_LUA_00_SEARCHENGINE ======<br />
<br />
This will protect your page rank with search engine crawlers, prevent search engines from being blocked and will also block attackers pretending to be search engine crawlers. It can securely determine if a bot is legitimate, or a forgery.<br />
<br />
Default: disabled<br />
<br />
'''Note: This ruleset will only perform this function if a client claims to be a search engine, and is much faster than the legacy system and does not require that apache be configured with HostNameLookups Double. While this is significantly faster than looking up the A and PTR records for all FQDNS, this ruleset should only be used if the ASL server has a [[local DNS resolver]] server installed on the ASL server.''' You can use a remote resolver, but a local resolver will be faster and more reliable.<br />
<br />
These rules require a locally installed DNS server for maximum performance. It is not recommended you enable these rules without a local DNS server installed on this server. <br />
<br />
Requires ASL 4.0.11 and up.<br />
<br />
====== Legacy system ======<br />
<br />
If you are using a version of modsecurity prior to 2.9.0 then you may want to use the legacy options below. Do not use the legacy options with 2.9.0 and above.<br />
<br />
======= MODSEC_00_SEARCHENGINE =======<br />
<br />
'''NOTE: This setting is deprecated and unsupported. Users should use the Lua method above.'''<br />
<br />
Bogus Search Engine Ruleset<br />
<br />
This ruleset will detect search engine crawlers, as well as attackers pretending to be search engine crawlers. It can securely determine if a bot is legitimate, or a forgery.<br />
<br />
Default: disabled<br />
<br />
'''Note: You should only use this ruleset if the ASL server has a [[local DNS resolver]] server installed on the ASL server.''' You can use a remote resolver, but a local resolver will be faster and more reliable.<br />
<br />
These rules require a locally installed DNS server for maximum performance. It is not recommended you enable these rules without a local DNS server installed on this server. (If you do not know if you have a DNS server installed on this server, do not enable these rules). Apache must also be configured with "HostnameLookups Double". ASL will attempt to configure HostnameLookups Double, but on non-standard systems, such as source build Apache installs and third party Apache installations this may not occur automatically. If you find that Apache is not resolving IP addresses, check to make sure HostnameLookups Double is configured for Apache.<br />
<br />
Note: These are legacy rules, and should not be used with modsecurity 2.9.x You should use these rules instead:<br />
<br />
http://wiki.atomicorp.com/wiki/index.php?title=ASL_WAF#WAF_LUA_00_SEARCHENGINE<br />
<br />
======= MODSEC_00_AUTOWHITELIST_SEARCHENGINE =======<br />
<br />
'''NOTE: This setting is deprecated and unsupported. Users should use the Lua method above.'''<br />
<br />
Autowhitelist Search Engine Ruleset<br />
<br />
This ruleset will automatically, and securely, whitelist search engine crawlers to prevent them from being blocked accidentally. This will protect your page rank with search engine crawlers.<br />
<br />
NOTE: This ruleset requires the MODSEC_00_SEARCENGINE setting to be enabled for this to work.<br />
<br />
Default: disabled<br />
<br />
Note: These are legacy rules, and should not be used with modsecurity 2.9.x You should use these rules instead:<br />
<br />
http://wiki.atomicorp.com/wiki/index.php?title=ASL_WAF#WAF_LUA_00_SEARCHENGINE<br />
<br />
'''Warning: You should only use this ruleset if the ASL server has a fast [[local DNS resolver]] server installed on the ASL server.'''<br />
<br />
===== MODSEC_00_WHITELIST =====<br />
<br />
Whitelist Ruleset<br />
<br />
Enable/Disable application of the whitelist '''for the WAF'''. <br />
<br />
''By default whitelisting does not apply to the WAF.''<br />
<br />
Note: enabling this will bypass *ALL* security checks for hosts on the whitelist '''for the WAF.'''<br />
<br />
Default: off<br />
<br />
By default, this is not enabled. <br />
<br />
ASL can respond to attacks in several different ways. The two that relate to the WAF are:<br />
<br />
*blocking<br />
*shunning<br />
<br />
Blocking is when ASL stops a single attack, and does not take any further action. <br />
<br />
Shunning is when ASL both block the single attack, and implement a firewall rule to block any further attacks from the same IP.<br />
<br />
ASL is configured to use the whitelist to prevent shunning by default, for IPs on the whitelist, but still to block attacks from that IP. This helps to prevent attacks from trusted sources, but prevents accidentally firewall rules when false positives occur. We do not recommend you disable blocking for trusted IPs. If you have a false positive, report it to us. Enabling this option tells ASL to totally ignore everything from the IPs on the whitelist, which includes not generating any alerts on this source and not to block anything. Which means if you do have a real attack from a trusted IP, you will not idea its occurred and theres nothing ASL can do to stop it.<br />
<br />
We dont recommend you you use this unless you know you can completely and totally trust every host on your whitelist every time. <br />
<br />
Most users will not need to enable this.<br />
<br />
Warning: We do not recommend you include your servers IP on this whitelist if you have a shared hosting server. Whitelisting localhost (127.0.0.1) and your local servers IP(s) from the WAF will means that local users can launch attacks against the server and against other domains on the server which will be neither detected nor prevented. If you have a rule that is being triggered by a local script, please report it as a false positive if it is a false positive, and if not, this may be an actual attack on your system or a poorly developed application. If you have a false positive from a whitelisted IP, please report it to us. Whitelisting in general is extremely dangerous and attackers know that users do this, which is why they target desktops and other trusted systems. If they can get access to these trusted systems, they can usually gain unfetered access to everything that users desktop, mobile device, laptop or other trusted system can access.<br />
<br />
Note: This ruleset requires this file to exist:<br />
<br />
/etc/asl/whitelist<br />
<br />
The format is one IP or CIDR per line. For example:<br />
<br />
<pre><br />
1.2.3.4<br />
10.0.0.0/8<br />
</pre><br />
<br />
=====MODSEC_00_BLACKLIST=====<br />
<br />
Blacklist Ruleset<br />
<br />
Enable/Disable application of the blacklist '''for the WAF'''. <br />
<br />
''By default blacklist is accomplished at Layer 3, and this ruleset is not necessary for most systems. This ruleset is only necessary if your configuration does not allow you to block attackers at Layer 3, such as when the system is behind a layer 7 proxy or load balancer.''<br />
<br />
Note: enabling this will block all IPs on the users custom blacklist '''for the WAF.'''<br />
<br />
Default: off<br />
<br />
ASL can respond to attacks in several different ways. The two that relate to the WAF are:<br />
<br />
*blocking<br />
*shunning<br />
<br />
Blocking is when ASL stops a single attack, and does not take any further action. <br />
<br />
Shunning is when ASL both blocks the single attack, and implements a layer 3 firewall rule to block any further attacks from the same IP.<br />
<br />
ASL is configured to use the blacklist to block all IPs at layer 3. It is not configured by default to do this at layer 7, the WAF, as this is generally not necessary for most systems. Most users will not need to enable this.<br />
<br />
Note: This ruleset requires this file to exist:<br />
<br />
/etc/asl/blacklist<br />
<br />
The format is one IP or CIDR per line. For example:<br />
<br />
<pre><br />
1.2.3.4<br />
10.0.0.0/8<br />
</pre><br />
<br />
Requires ASL 4.0.15 and up.<br />
<br />
===== MODSEC_00_THREAT =====<br />
<br />
Threat Intelligence System<br />
<br />
Enabling this allows your system to use Atomicorp Threat Intelligence system to block knownn attackers.<br />
<br />
'''Important: It is highly recommended you enable these rules only with a local DNS resolver installed and configured on the system. (If you do not know if you have a local DNS resolver installed and configured on your system, do not enable these rules until you have confirmed that you do).''' Please see this article for information on [[Local DNS resolver]]s.<br />
<br />
Note: hosts on the whitelist are automatically excluded from being blocked by this ruleset.<br />
<br />
===== MODSEC_00_ANTIEVASION =====<br />
<br />
Antievasion Ruleset<br />
<br />
Enable/Disable the antievasion rule class. This ruleset prevents attacks that try to bypass the WAF itself.<br />
<br />
===== MODSEC_00_STRICT ===== <br />
<br />
Strict Multiform Ruleset<br />
<br />
Enable/Disable the strict multiform checks rule class. This ruleset enforces strict adherence RFCs for multiform messages, strictly enforces allowed types and implements enhanced checks on inputs. This prevents advanced attacks that may try to bypass the WAF, or involve more complex evasion attacks. <br />
<br />
Note: Broken applications and clients that do not adhere to RFCs will not be able to send multiform to the system if you enable this. This not a false positive, these clients and applications are broken. If you are unfortunately stuck with these, you will have to disable this.<br />
<br />
===== MODSEC_00_RBL ===== <br />
<br />
RBL Ruleset<br />
<br />
Enable/Disable Real-time Black List (RBL) rule class. Currently this uses the [http://www.spamhaus.org/xbl/ Spamhaus XBL] which is operated by the Spamhaus project. This RBL is not operated or controlled by Atomicorp. Please contact Spamhaus if you have issues with the IPs on this RBL, or disable this option.<br />
<br />
'''Default: off'''<br />
<br />
'''Warning: You should only use this ruleset if the ASL server has a really fast DNS server installed on the ASL server.''' <br />
<br />
This ruleset will look up every request in the DNS to see if its on a blacklist, and will not finish serving the request until the DNS server responds. This can slow down requests if the DNS server is slow. Basically, web requests will move at the speed of the DNS servers replies.<br />
<br />
If your web server is responding slowly to requests, and you have this ruleset enabled your DNS server is too slow to meet your lookup needs. You will need to either disable this ruleset, or tune your DNS server to respond to queries more quickly.<br />
<br />
===== MODSEC_00_AE_RULES =====<br />
<br />
'''Anti-Evasion Protection system'''<br />
<br />
Antievasion Ruleset/MODSEC_00_ANTIEVASION: Enable/Disable the antievasion rule class. This ruleset prevents attacks that try to bypass the WAF itself.<br />
<br />
===== MODSEC_01_RULES ===== <br />
<br />
Advanced Antievasion Ruleset<br />
<br />
Enable/Disable the advanced antievasion protection rule class. This ruleset prevents attacks that try to bypass the WAF itself or can be used to trick applications into parsing data in ways that may compromise the application.<br />
<br />
===== MODSEC_01_APP_RULES =====<br />
<br />
This is a special ruleset that most users will never need. Please see this article to see if this ruleset applies to you:<br />
<br />
[[WAF_rule_families#01_asl_rules_special.conf]]<br />
<br />
Default:no<br />
<br />
Note: Do not enable this ruleset unless you know what you are doing.<br />
<br />
===== MODSEC_01_DOMAIN_BLOCKS =====<br />
<br />
MODSEC_01_DOMAIN_BLOCKS<br />
<br />
Enable/Disable user defined custom domain blocking class. This ruleset blocks connections from a user defined list of domains when DNS records exist that match the incoming IP (This allows you to block hosts based on their DNS names), and also blocks referrers that contain that domain name. <br />
<br />
[Default: no]<br />
<br />
In the ASL gui, click on the ASL tab, then select Blocking, and then the Domains tab. Domains or FQDNs are defined, one per line. Matching is by string, regular expressions are not supported. Therefore, example.com will also match anotherexample.com. If you want to limit the domain you will need to use a delimiter, as in the example, such as:<br />
<br />
.example.com<br />
<br />
Which will only match on FQDNs that include .example.com, and in the previous example would not match on anotherexample.com.<br />
<br />
Note: Available in ASL 4.0.1 and up. This works by comparing the forward and reverse DNS records, if they do not match the rule will not match.<br />
<br />
===== MODSEC_03_DOS ===== <br />
<br />
Denial of Service Protection<br />
<br />
Enable/Disable the Denial of Services protection rule class. This ruleset prevents the so-called "slowaris" Denial of Service attacks, as well as "fast" DOS attacks. DDOS attacks can not be mitigated on the host itself. <br />
<br />
''Note: Some fastcgi implementations, specifically cpanel, require this to be disabled.''<br />
<br />
===== MODSEC_06_HONEYPOT =====<br />
<br />
Custom User Defined Honeypot Ruleset<br />
<br />
Enable/Disable the Custom User Defined Honeypot Ruleset. This ruleset allows you to define custom files, directories or a combination of the two in the file below that you want to block access to:<br />
<br />
/etc/httpd/modsecurity.d/honeypot-files.txt<br />
<br />
The format is one rentry per line. '''This method does not support regular expressions, but is case insensitive.''' For example:<br />
<br />
<pre><br />
/backups/admin.php<br />
/wp-config.php<br />
/admin/secret<br />
</pre><br />
<br />
===== MODSEC_10_ANTIMALWARE ===== <br />
<br />
Anti-Malware Ruleset<br />
<br />
Enable/Disable the anti-malware rule class. This will look at any requests to the system for known malware domains and indicators of malware injection requests (this does not do the same thing as the MODSEC_99_SCANNER class, which will inspect uploads for malware).<br />
<br />
===== MODSEC_10_RULES ===== <br />
<br />
Generic Attack Ruleset<br />
<br />
Enable/Disable the core rule class. This class contains the core generic rules, which will look for things like SQLi, XSS, CSRF, recursion, code injection, command injection, XML attacks and other generic attack patterns. You should always leave this class enabled.<br />
<br />
===== MODSEC_11_ADV_RULES ===== <br />
<br />
Advanced Attack Ruleset<br />
<br />
Enable/Disable the advanced protection rule class. This class contains advanced rules.<br />
<br />
===== MODSEC_11_DLP ===== <br />
<br />
Data Loss Protection Ruleset<br />
<br />
Enable/Disable the data loss protection rule class. This will detect certain Data Loss events, such as credit card information being sent or errors messages from applications that may reveal sensitive information or that the system or application is vulnerable to particular attack.<br />
<br />
Types of data this ruleset can detect in the output:<br />
<br />
# Credit Card Numbers <br />
# SSN numbers<br />
# Debug information from:<br />
<br />
===== MODSEC_12_ADV_XSS_RULES =====<br />
<br />
Advanced Cross Scripting Protection (AXSSP)<br />
<br />
This is the advanced Cross Site Scripting (XSS) protection rule set. It performs deep level inspections of web requests and responses to look for potential XSS attacks. <br />
<br />
Note: This requires EL 6 and above.<br />
<br />
===== MODSEC_11_BRUTE ===== <br />
<br />
Supplemental Brute Force Protection Ruleset<br />
<br />
Enable/Disable the supplemental web brute force attack protection rule class. This ruleset is used on systems that do not have either ASL or Atomic Protector installed, and perform the process of tracking login failures, and send a 403 error to the user when the limit is reached.<br />
<br />
'''Note:''' This works by analysing the output of the web application, and does not rely on log analysis or htaccess files. Therefore, do not use application internal compression schemes on output. For example, do not enable GZIP compression in applications such as Joomla, PHPBB, Wordpress and others, as this will make it difficult for the WAF to see the output. You can still compress the output if you use an apache module such as mod_deflate, which accomplishes the same thing and is less CPU intensive that application internal compression. '''Litespeed does not currently support this ruleset. If you require this protection with Litespeed, you must use ASL and configure ASL to setup a local WAF, via ASL, in front of Litespeed.'''<br />
<br />
'''Discussion:'''<br />
<br />
For the WAF to be able to analyze output from web applications, the WAF must be able to understand the output from the web application. Applications that compress output send this compressed output to Apache, which creates a situation where the WAF will only see compressed content. In this case, the WAF will not be able to understand it because the WAF will not decompress it.<br />
<br />
Whereas it is possible for the WAF to decompress this content, and then recompress it, this is '''extremely''' wasteful for the CPU and will unnecessarily slow the system down. Essentially the web server would be compressing the content, decompressing it, and then compressing it again. Add in two unnecessary steps, and tripling the work load. The most efficient solution is to not compress output in the application, let the WAF inspect it, and then let apache compress it. <br />
<br />
'''Inline decompression with the WAF is no longer supported and has been removed from the WAF code as this leads to poor performance due to misconfiguration of the system.'''<br />
<br />
===== MODSEC_12_BRUTE ===== <br />
<br />
Brute Force Protection Ruleset<br />
<br />
Enable/Disable the web brute force attack protection rule class. Detects attempts to brute force web applications authentication mechanisms.<br />
<br />
'''Note:''' This works by analysing the output of the web application, and does not rely on log analysis or htaccess files. Therefore, do not use application internal compression schemes on output. For example, do not enable GZIP compression in applications such as Joomla, PHPBB, Wordpress and others, as this will make it difficult for the WAF to see the output. You can still compress the output if you use an apache module such as mod_deflate, which accomplishes the same thing and is less CPU intensive that application internal compression. '''Litespeed does not currently support this ruleset. If you require this protection with Litespeed, you must use ASL and configure ASL to setup a local WAF, via ASL, in front of Litespeed.'''<br />
<br />
'''Discussion:'''<br />
<br />
For the WAF to be able to analyze output from web applications, the WAF must be able to understand the output from the web application. Applications that compress output send this compressed output to Apache, which creates a situation where the WAF will only see compressed content. In this case, the WAF will not be able to understand it because the WAF will not decompress it.<br />
<br />
Whereas it is possible for the WAF to decompress this content, and then recompress it, this is '''extremely''' wasteful for the CPU and will unnecessarily slow the system down. Essentially the web server would be compressing the content, decompressing it, and then compressing it again. Add in two unnecessary steps, and tripling the work load. The most efficient solution is to not compress output in the application, let the WAF inspect it, and then let apache compress it. <br />
<br />
'''Inline decompression with the WAF is no longer supported and has been removed from the WAF code as this leads to poor performance due to misconfiguration of the system.'''<br />
<br />
===== MODSEC_20_USERAGENTS ===== <br />
<br />
Malicious Useragents Ruleset<br />
<br />
Enable/Disable the useragents rule class. Detects known malicious or suspicious user agents.<br />
<br />
===== MODSEC_21_USERAGENTS ===== <br />
<br />
User Defined Malicious Useragents Ruleset<br />
<br />
Enable/Disable the User Defined Malicious Useragents Ruleset. This ruleset allows you to define custom useragents in the file below that you want to block:<br />
<br />
/etc/httpd/modsecurity.d/bad_agents.txt<br />
<br />
The format is one user-agent per line. '''This method does not support regular expressions, but is case insensitive.''' For example<br />
<br />
<pre><br />
Mozila 99.0<br />
Internut exploder<br />
</pre><br />
<br />
===== MODSEC_30_ANTISPAM ===== <br />
<br />
Anti-Spam Ruleset<br />
<br />
Enable/Disable the anti-spam rule class. This class contains tuned antispam rules, designed to work with all known blogs, forums, guestbooks, CMS' and other web content management systems that allow users to post content. <br />
<br />
===== MODSEC_31_ANTISPAM_URI ===== <br />
<br />
Anti-Spam URI RBL Ruleset<br />
<br />
Enable/Disable the anti-spam URI rule class. Looks up all URIs in a post against RBLs to see if its a known spam domain. As with the MODSEC_00_RBL rules, these should only be used if the server has a local fast DNS server. <br />
<br />
'''Warning: You should only use this ruleset if the ASL server has a really fast DNS server installed on the ASL server.''' <br />
<br />
This ruleset will look up every request in the DNS to see if its on a blacklist, and will not finish serving the request until the DNS server responds. This can slow down requests if the DNS server is slow. Basically, web requests will move at the speed of the DNS servers replies.<br />
<br />
If your web server is responding slowly to requests, and you have this ruleset enabled your DNS server is too slow to meet your lookup needs. You will need to either disable this ruleset, or tune your DNS server to respond to queries more quickly.<br />
<br />
===== MODSEC_50_ROOTKITS ===== <br />
<br />
Rootkit Detection Ruleset<br />
<br />
Enable/Disable the rootkit rule class. This class detects and blocks known rootkits, PHP/ASP/PERL shells, spam tools and other malicious web applications from running on the system. (These rules exist for cases where malicious software may already be installed on the system, this is a defense in depth rule set) <br />
<br />
===== MODSEC_60_RECONS ===== <br />
<br />
Reconnaissance Attacks Ruleset<br />
<br />
Enable/Disable the recon rule class. This class blocks known "google hacks" or webserver probes that look for vulnerable applications and signs of compromised systems running unauthorized shells, or unprotected applications that allow uploads which would give an attacker access to the system. <br />
<br />
===== MODSEC_61_DLP ===== <br />
<br />
Data Leak Prevention Ruleset<br />
<br />
Enable/Disable the data loss protection class. These rules detect Data Loss Search engine "hacks". These are search engine probes for sensitive files, often used by malicious parties to find sensitive information accidentally exposed on web servers.<br />
<br />
===== MODSEC_98_ADV_REDACTOR =====<br />
<br />
Advanced Malware Removal Ruleset<br />
<br />
Enable/Disable the advanced malware removal ruleset. These rules detect hidden iframes, obfuscated javascript and other potentially malicious code and remove it real time from your web pages.<br />
<br />
===== MODSEC_99_JITP ===== <br />
<br />
Just In Time Patches<br />
<br />
Enable/Disable the Just In Time Patches(JITP) rule class. Just in Time Patches. We publish JITPs daily if there is a new web application vulnerability that the 10_asl_rules.conf do not protect the system against. These are tuned rules for specific vulnerabilities in a web application. <br />
<br />
===== MODSEC_99_REDACTOR ===== <br />
<br />
Malicious Output Removal Ruleset<br />
<br />
Enable/Disable the automatic malicious/hidden iframe and malware removal rule class. Automatically removes malicious code from web pages, such as hidden iframes, encoded javascript and other malicious code. <br />
<br />
===== MODSEC_99_MALWARE_OUTPUT ===== <br />
<br />
Malicious Output Detector<br />
<br />
Enable/Disable the malware output rule class.<br />
<br />
===== MODSEC_99_SCANNER ===== <br />
<br />
Web Malware Upload Scanner<br />
<br />
Malicious code upload scanner. Enable this to scan web uploads for malicious code.<br />
<br />
===== MODSEC_99_ADV_SCANNER =====<br />
<br />
Advanced Malware Upload Scanner<br />
<br />
This enables the advanced malware upload scanner rule class. This uses fuzzy hashes to detect similiar malware.<br />
<br />
= Rule Manager =<br />
<br />
The Rule manager can be used to configure individual WAF rules, such as what response the system such take for that rule, if an email or GUI alert should be presented, and so on. To access the rule manager please follow this process:<br />
<br />
Step 1) Log into the ASL GUI<br />
<br />
Step 2) Click the "Configuration" tab.<br />
<br />
Step 3) Select "Rule Management"<br />
<br />
This will bring up the rule management screen. There are two tabs on this screen:<br />
<br />
Global: This sets global features for all the rules<br />
<br />
Rules: This presents all the individual rules, and options to configure that rule specifically.<br />
<br />
== Global Options ==<br />
<br />
If you change a setting on this screen, you must click the "Update" button for the setting changes to take effect.<br />
<br />
The follow settings are available in the Global setting screen:<br />
<br />
=== Email to === <br />
<br />
This sets the email address to send alerts to. The default is $EMAIL which inherits the global email address set in the ASL Configuration screen. If you want to use the same email address you set when you configured when you install ASL leave this setting as "$EMAIL". Otherwise, change this to the email address you want rule alerts sent to.<br />
<br />
=== Email From ===<br />
<br />
Set this to the From: line you want to use for the emailed alerts. Available variables are $HOSTNAME is is populated by the servers fully qualified hostname, and $EMAIL which is set in the ASL Configuration screen. The default is usually effective for most users.<br />
<br />
=== Max Emails per hour ===<br />
<br />
This sets a limit on the maximum number of emails the system will sent to the Email to: address. This basically "queues up" alerts. If events occur after the Max Emails per hour limit has been reached, then those alerts will be held until the next hour and will be grouped together in a single email sent the next hour.<br />
<br />
If you want alerts to be sent as they occur, and not to be queued up, set this to 9999.<br />
<br />
=== Active Response ===<br />
<br />
This sets whether of not ASL will block the source of the attack, by implementing a firewall rule for the source of the attack. (Which may be a temporary shun, or a permanent shun depending on the setting below "Shun Timeout")<br />
<br />
=== Shun Timeout ===<br />
<br />
This tells ASL if the firewall block, or "shun", should be temporary or permanent. Once the Shun Time (described below) has been reached the source IP address will be allowed to connect again. The ASL Configuration settings also allow for advanced options for this, such as multiplers that cause sources to be shunned for longer periods of time as more attacks are detected from the source.<br />
<br />
=== Shun Time ===<br />
<br />
Timeout period is in seconds. This sets the maximum amount of time a source address will be blocked by ASL/<br />
<br />
If Shun Timeout is set to no, the "shun" is permanent and this option is ignored.<br />
<br />
=== Rules ===<br />
<br />
The Rules Manager has two tabs:<br />
<br />
==== HIDS ====<br />
<br />
This contains all the Rules for HIDS. For documentation on the HIDS please see the [[ASL HIDS]] documentation page.<br />
<br />
==== WAF ====<br />
<br />
This contains all the Rules for the WAF. There are two columns on this tab, the left column contains the current rule sub classes, and the screen on the right shows all rules that match your current filter selections. The window on the right is populated by selecting either a subclass of rules, or by typing in search criteria in the boxes at the top of the screen. <br />
<br />
If you select a rule sub class, for example "adult-spam" that will pull up all the rules in the class on the right hand side of the screen.<br />
<br />
Or you can search for specific rules by using the filter bar at the top of the screen. The filter options are:<br />
<br />
Category: This is another way to select a rule subclass, this is optional, you do not have to select a rule class. If you leave this in either the default, or you set this to (any) your filter will apply to all the WAF rules. <br />
<br />
Level: Rules have different levels, depending on severity. Some rules are only informational, some indicate suspicious activity and others are full blown attacks. A higher number is a high severity or importance, and a lower number is a lower severity or importance. This filter is optional, you do not need to select a level if you do not want to filter by level. If you leave the default your filter will apply to all levels.<br />
<br />
Search: This allows you to search by any thing in the rule, its name, ID, etc. If you hit enter in this field it will start the search. <br />
<br />
When you have finished with your filter criteria, just click the "filter button" or hit enter in the search field.<br />
<br />
=== Configuring specific rules ===<br />
<br />
Once you have the rule manager open, and have pulled up a rule you want to modify just click on the down arrow next to the rules ID to open the rules options. <br />
<br />
===== Rule Options =====<br />
<br />
For WAF rules the following options are available:<br />
<br />
<br />
====== Disabled ======<br />
<br />
Setting this "yes" globally disables the rule. If you want to disable a rule for a specific domain or FQDN see the Vhost option below.<br />
<br />
====== Severity ======<br />
<br />
This sets the severity level for the event. This allows you to set rules to be lower or higher priority which will effect:<br />
<br />
1. How they are displayed in the GUI<br />
<br />
2. Whether they are shunned or not (a minimum severity level can be set in ASL to control if an event is important enough to block the source IP address, please see the [[ASL Configuration]] documentation for these settings.<br />
<br />
3. If an email alert is sent. A minimum severity level can be set in ASL to control if an event is important enough to send an email alert, please see the [[ASL Configuration]] documentation for these settings.<br />
<br />
====== Active Response ======<br />
<br />
This sets if the system should perform any active response actions against the source IP address. This option is ignored if Active Response is disabled in the Global options.<br />
<br />
====== Email ======<br />
<br />
This sets if the event will generate an email alert. Keep in mind that the event must also be above the minimum level set in the [[ASL Configuration]].<br />
<br />
====== Logging ======<br />
<br />
This sets if the event will be displayed, at all, in the ASL GUI. Setting this to off "silences" the event in the ASL GUI. It does not prevent the event from being logged to the systems logs.<br />
<br />
====== Vhost settings ======<br />
<br />
This subpanel allows you to set domain or FQDN specific settings for a rule. For example, if you want a rule to other behave per its defaults, but want to change its behavior for a specific domain you can set that domain here.<br />
<br />
Currently this is limited to disabling the rule for the domain. In the future this will be expanded to allow other options for the rule as with the global settings.<br />
<br />
Simply type in the domain name in the text box on the right, select "yes" and click add.<br />
<br />
=== Rule Tuning ===<br />
<br />
Please see the [[Mod_security]] page.<br />
<br />
= Events =<br />
<br />
WAF events are displayed in the [[ASL Events]] window. Please see the [[ASL Events]] page for usage information.<br />
<br />
= Configuring web servers to use the T-WAF =<br />
<br />
This section provides courtesy instructions about how to configure a remote web server to work with the T-WAF, so that the remote web server reports the correct client IP address and not the IP address for the T-WAF server.<br />
<br />
This can also be used with local web services. For local apache servers, we do not recommend you use the T-WAF. Instead, make sure you are using the embedded mode explained at the beginning of this article. The WAF will integrate natively with Apache 2.x, and is highly recommended for that platform.<br />
<br />
== Apache ==<br />
<br />
Note: If you are using embedded mode (which is the default) you do not need to do this. You will only need to do this if you are using the T-WAF to proxy traffic to a remote apache server. If you have a local apache server that ASL is installed on, install modsecurity locally.<br />
<br />
For remote apache servers, to setup Apache to report the clients IP when using the T-WAF follow this process:<br />
<br />
Step 1) Install mod_rpaf<br />
<br />
http://stderr.net/apache/rpaf/<br />
<br />
Step 2) Add this to your remote servers apache configuration<br />
<br />
<pre><br />
LoadModule rpaf_module path/to/mod_rpaf-2.0.so<br />
RPAFenable On<br />
RPAFsethostname On<br />
RPAFproxy_ips <IP FOR THE ASL SERVER><br />
RPAFheader X-Forwarded-For<br />
</pre><br />
<br />
Change the IP in this line:<br />
<br />
RPAFproxy_ips <IP FOR THE ASL SERVER><br />
<br />
To the IP for your ASL server. For example, if the ASL servers IP address is 1.2.3.4 this line will look like this:<br />
<br />
RPAFproxy_ips 1.2.3.4<br />
<br />
Step 3) Restart the remote apache server<br />
<br />
== Litespeed ==<br />
<br />
To setup Litespeed to report the correct IP address of the client when using the T-WAF follow these instructions:<br />
<br />
Step 1) Log into the LiteSpeed Web Admin Console<br />
<br />
Step 2) Under Configuration, enable the option "Use Client IP in Header".<br />
<br />
Step 3) Restart Litespeed<br />
<br />
== Nginx ==<br />
<br />
Step 1) Edit your nginx.conf file and add the following to your http section:<br />
<br />
<pre><br />
http {<br />
set_real_ip_from 127.0.0.1/32;<br />
set_real_ip_from <YOUR SERVERS IP>/32;<br />
set_real_ip_from <YOUR SERVERS OTHER IPS>/32;<br />
real_ip_header CF-Connecting-IP;<br />
</pre><br />
<br />
Replace <YOUR SERVERS IP> with your servers IP(s). For example, if your server had the IPs 1.2.3.4, 1.2.3.5 and 1.2.3.6 your configuration would look like this:<br />
<br />
<pre><br />
set_real_ip_from 127.0.0.1/32;<br />
set_real_ip_from 1.2.3.4/32;<br />
set_real_ip_from 1.2.3.5/32;<br />
set_real_ip_from 1.2.3.6/32;<br />
real_ip_header CF-Connecting-IP;<br />
</pre><br />
<br />
<br />
Step 2) Restart nginx.</div>Mshinnhttps://wiki.atomicorp.com/wiki/index.php/ASL_WAFASL WAF2022-07-01T22:19:39Z<p>Mshinn: /* MODSEC_11_DLP */</p>
<hr />
<div>= Introduction =<br />
<br />
The ASL WAF has two non-exclusive modes operation:<br />
<br />
1) Embedded mode<br />
<br />
2) Transparent/Proxy mode (T-WAF)<br />
<br />
== Embedded mode ==<br />
<br />
Embedded mode works with Apache 2.x. ASL will install a special module in Apache to give it native WAF protection capabilities. This installation will occur when ASL is installed.<br />
<br />
== Proxy mode (T-WAF) ==<br />
<br />
Proxy mode or the Transparent WAF (T-WAF) system allows ASL to protect any HTTP and/or HTTPS service, either a local server (such as when using a web server that does not support embedded mode) or a remove server.<br />
<br />
= Configuration =<br />
<br />
The ASL WAF is initially configured during the install of ASL. If Apache is installed on the system, ASL will attempt to install the embedded WAF module. If Apache is installed on the system via package management, then this will occur automatically and you will not need to configure the WAF further to protect an installed Apache instance. <br />
<br />
Once ASL is installed, if you need to do so, you can configure the WAF through three parts of the ASL GUI:<br />
<br />
== WAF Tab ==<br />
<br />
This tab is used to setup the WAF. There are three types of WAF you can configure:<br />
<br />
=== embedded ===<br />
<br />
The embedded WAF is an apache module that is installed on any local Apache installations. This should be setup by default, if you are running apache on the system and a [https://www.atomicorp.com/wiki/index.php/ASL_FAQ#Apache supported version and build of Apache].<br />
<br />
=== local ===<br />
<br />
Note: You do not need to setup a local WAF for package managed installs of apache. ASL will detect if a package managed version of Apache is installed, and will install the WAF module into apache [https://www.atomicorp.com/wiki/index.php/ASL_WAF#embedded embedded mode], as described above. For custom apache installs, please follow these directions.<br />
<br />
This type of WAF is used to protect any local HTTP and/or HTTPS services that may be running on the system itself, where the embedded WAF module can not be used. For example, if the system was running a tomcat or litespeed web server, which do not support the embedded WAF module, or a control panel that uses it own web server (such as Plesk, Cpanel, Webmin, and others). You can configure a WAF to protect these services.<br />
<br />
To setup a local WAF simply follow these steps:<br />
<br />
Step 1) Log into the ASL GUI<br />
<br />
Step 2) Click the WAF tab<br />
<br />
Step 3) Select WAF Config<br />
<br />
This will pull up the WAF Config window, which will show the existing WAFs.<br />
<br />
Step 4) Click "Enable T-WAF". If you see "Disable T-WAF" this option has already been enabled.<br />
<br />
Step 5) Click "Add"<br />
<br />
This will will pull up the "Add WAF Config" window.<br />
<br />
Step 6) Click on the "Add protection for" drop down. Select "local"<br />
<br />
This will present you with two options:<br />
<br />
Local Port: Type in the local HTTP/HTTPS port you wish to protect. Only type in one port number.<br />
<br />
Note: Check if you have any embedded WAFs installed on the system before you do this. If you have an embedded WAF already installed on port 80, as should occur if you have Apache installed (and its package managed), then enabling the T-WAF in front of Apache would create a loop. Its not necessary to put a WAF in front of a service that is protected via embedded mode.<br />
<br />
SSL: Select this if the service you wish to protect is SSL based.<br />
<br />
If you select SSL, then you will see this additional options:<br />
<br />
Path to SSL Certificate: Provide the filesystem path to the SSL certificate for this service.<br />
<br />
Path to SSL Key file: Provide the filesystem path to the SSL key file for this service.<br />
<br />
Step 7) Then click Save<br />
<br />
Note: You do not need to reconfigure your web server to use a different port, ASL will transparently intercept the packets to your web server based on the port you configure above. If you change your web servers port, ASL will not intercept packets to that port.<br />
<br />
=== remote ===<br />
<br />
'''Note: You need a [https://www.atomicorp.com/amember/cart/index/index?c=9 reverse proxy ASL license] to use this feature. This feature will not work without a reverse proxy license.'''<br />
<br />
This type of WAF is used to protect any remote HTTP and/or HTTPS services that are not running on the system itself. For example, if you have a remote webserver you wish to protect, you can configure a WAF to protect these services. The remote WAF can support two proxy modes: domain based and IP based.<br />
<br />
==== name based remote ====<br />
<br />
Domain based or name nased WAFs allow you to use a single IP address on the WAF, and to direct WAF requests to different backend servers depending on their domain or full qualified domain name, or even to specific URL.<br />
<br />
==== IP based remote ====<br />
<br />
IP based WAFs allow you to redirect all traffic to an IP address on WAF to a specific destination host or URL.<br />
<br />
==== Setting up a remote WAF ====<br />
<br />
To setup a remote WAF simply follow these steps:<br />
<br />
Step 1) Log into the ASL GUI<br />
<br />
Step 2) Click the WAF tab<br />
<br />
Step 3) Select WAF Config<br />
<br />
This will pull up the WAF Config window, which will show the existing WAFs.<br />
<br />
Step 4) Click "Enable T-WAF". If you see "Disable T-WAF" this option has already been enabled.<br />
<br />
Step 5) Click "Add"<br />
<br />
This will will pull up the "Add WAF Config" window.<br />
<br />
Step 6) Click on the "Add protection for" drop down. Select "remote"<br />
<br />
This will present you with a dropdown options to setup the WAF as either domain based or IP based.<br />
<br />
Step 7) If you select name based you will be presented with these options:<br />
<br />
Domain Name: Enter the domain name or full qualified domain you wish to use. For example, if you want the WAF to handle traffic for intranet.example.com enter that FQDN in this box.<br />
<br />
Local Url: Enter the local URL, if any, that the WAF should expect from the client to direct this connection to the remote host. The default of / is usually correct if you are forwarding all traffic for an FQDN or domain. If you only want the WAF to pass on specific requests for specific URLs, enter them here. <br />
<br />
Destination: Enter the full URL you want the WAF to use as the destination server. Make sure you have DNS or /etc/hosts entries for this, otherwise the WAF will not be able to find the destination. This should also not be the same thing as "Domain Name:". You can also use https:// URLs here.<br />
<br />
Remote Port: Type in the remote port for the backend server the WAF will be sending requests to.<br />
<br />
SSL: Select SSL if you wish to accept SSL connections to the WAF. If you select this you will be presented with these additional options:<br />
<br />
Path to SSL Certificate: Provide the filesystem path to the SSL certificate for this service.<br />
<br />
Path to SSL Key file: Provide the filesystem path to the SSL key file for this service.<br />
<br />
Skip to step 8<br />
<br />
Step 7) If you select IP based you will be presented with these options<br />
<br />
IP Address: Enter the IP address you want the WAF to listen on (you can set multiple IPs by adding additional remote WAFs). For example, if you want the WAF to redirect all traffic on IP address 1.2.3.4 to internal.example.com, type in 1.2.3.4.<br />
<br />
Local Url: Enter the local URL, if any, that the WAF should expect from the client to direct this connection to the remote host. The default of / is usually correct if you are forwarding all traffic for an FQDN or domain. If you only want the WAF to pass on specific requests for specific URLs, enter them here. <br />
<br />
Destination: Enter the full URL you want the WAF to use as the destination server. Make sure you have DNS or /etc/hosts entries for this, otherwise the WAF will not be able to find the destination. This should also not be the same thing as "Domain Name:". You can also use https:// here.<br />
<br />
Remote Port: Type in the remote port for the backend server the WAF will be sending requests to.<br />
<br />
SSL: Select SSL if you wish to accept SSL connections to the WAF. If you select this you will be presented with these additional options:<br />
<br />
Path to SSL Certificate: Provide the filesystem path to the SSL certificate for this service.<br />
<br />
Path to SSL Key file: Provide the filesystem path to the SSL key file for this service.<br />
<br />
Step 8) Then click Save<br />
<br />
== SSL/TLS ==<br />
<br />
If you select SSL for either the local or remote WAF options, your SSL certificates and keys must be in an Apache compatible format to be imported by the T-WAF.<br />
<br />
== ASL Configuration Settings ==<br />
<br />
The WAFs settings are contained under the Configuration tab. To Configure the WAF follow this process:<br />
<br />
Step 1) Log into the ASL GUI<br />
<br />
Step 2) Click on the Settings Tab<br />
<br />
Step 3) Select the "ASL Configuration" sub menu<br />
<br />
Step 4) Scroll down to the "Web Application Firewall" configuration section. The following options are available:<br />
<br />
=== MODSEC_ENABLED ===<br />
<br />
This setting Enables/Disables the entire WAF system. This is the only supported method for disabling the WAF in ASL. Uninstalling mod_security and the use of third party methods to remove modsecurity will not work if this setting is still configured to enable the WAF. This setting is specifically designed to ensure that the WAF is not disabled accidentally by a third party product.<br />
<br />
=== WAF_ENGINE ===<br />
<br />
Set the WAF engine mode, there are three modes:<br />
<br />
On - this tells the WAF to detect and block attacks.<br />
<br />
DetectionOnly - this tells the WAF to only detect and report attacks, but not to block them.<br />
<br />
Off - Disables the WAF.<br />
<br />
=== WAF_ENABLED ===<br />
<br />
Enable/Disable Tortix WAF proxy. The tortix waf module, this module can process local or remote services through the Tortix Web Application Firewall (T-WAF) . (Default: Off)<br />
<br />
'''Note: This option is deprecated in ASL 4.'''<br />
<br />
=== WAF_CHROOTDIR ===<br />
<br />
Configures the directory path that will be used to jail the web server process. (For the embedded WAF modules only). This lets you put the local apache instance into a chroot jail.<br />
<br />
=== WAF_READSTATELIMIT ===<br />
<br />
Sets the limit of the number of connections from the same IP address that can be in the Read state for the WAF. This helps to prevent "slow" DOS attacks. For example, if this was set to "5" a single IP would only be able to keep 5 connections in a busy state with the web server at a single time.<br />
<br />
ASL 3 Default: 10<br />
<br />
ASL 4 Default: 100<br />
<br />
=== Write State Limit ===<br />
<br />
WAF_WRITESTATELIMIT: Sets the limit of the number of connections from the same IP address that can be in the Write state for the WAF. This helps to prevent "slow" DOS attacks. For example, if this was set to "5" a single IP would only be able to keep 5 connections in a busy state with the web server at a single time.<br />
<br />
(Default: 100)<br />
<br />
Note: This option is only available in ASL 4 and up.<br />
<br />
=== WAF_SECREQUESTBODYNOFILESLIMIT ===<br />
<br />
(Default: 1048576) Configures the maximum request body size the WAF modules will accept for buffering. There is a hard limit of 1GB. This is not a limit on file sizes sent through the WAF, just request body sizes.<br />
<br />
=== WAF_SECREQUESTBODYINMEMORYLIMIT ===<br />
<br />
(Default: 131072) Configures the maximum request body size the WAF modules will store in memory. There is a hard limit of 1GB. The default of 128 MB is generally sufficient for any site.<br />
<br />
=== WAF_DEFAULT_ACTION ===<br />
<br />
Configures the block policy, deny the request or redirect the client to a landing page. <br />
<br />
=== WAF_REDIRECT_URL ===<br />
<br />
Used for WAF_DEFAULT_ACTION of "redirect". This is the URL to redirect blocked pages. This must include http:// or https:// in the URL.<br />
<br />
Example:<br />
<br />
https://%{server_name}:30000/blocked.php?eventid=%{eventid}<br />
<br />
You can use variables in the URL. They must be represented in this format:<br />
<br />
<pre>%{variable_name}</pre><br />
<br />
'''Important Note:''' If you have [https://www.atomicorp.com/wiki/index.php/ASL_Configuration#OSSEC_ACTIVE_RESPONSE OSSEC_ACTIVE_RESPONSE] enabled, then redirects will not work as the systems firewall will still block the user. You must disable OSSEC_ACTIVE_RESPONSE to use redirects.<br />
<br />
==== Supported Variables ====<br />
<br />
Currently supported variables are listed below. As new variables are supported, we will add them to the documentation here. <br />
<br />
===== server_name =====<br />
<br />
This is the value the client sent in the Host: header, which would be the FQDN the client accessed.<br />
<br />
==== ruleid ====<br />
<br />
The rule ID for the rule that was triggered.<br />
<br />
===== unique_id =====<br />
<br />
The unique ID for each event recorded by the WAF.<br />
<br />
The variable UNIQUE_ID is set to the identifier for each request. The UNIQUE_ID environment variable is constructed by encoding the 112-bit (32-bit IP address, 32 bit pid, 32 bit time stamp, 16 bit counter) quadruple using the alphabet [A-Za-z0-9@-] in a manner similar to MIME base64 encoding, producing 19 characters.<br />
<br />
===== remote_addr =====<br />
<br />
The client IP address.<br />
<br />
===== server_port =====<br />
<br />
This variable contains the local port of the webserver that the request was received on.<br />
<br />
==== Experimental Variables ====<br />
<br />
These are additional variables that should be considered experimental, and are available in the engine, but are not currently supported. They require newer versions of modsecurity, which may not be available in the stable channel.<br />
<br />
===== auth_type =====<br />
<br />
This variable holds the authentication method used to validate a user, if any of the methods built into HTTP are used. In a reverse-proxy deployment, this information will not be available if the authentication is handled in the backend web server. <br />
<br />
===== remote_user =====<br />
<br />
This variable holds the username of the authenticated user. If there are no password access controls in place (Basic or Digest authentication), then this variable will be empty. <br />
<br />
===== time =====<br />
<br />
This variable holds a formatted string representing the time (hour:minute:second). <br />
<br />
===== time_day =====<br />
<br />
This variable holds the current date (1–31). <br />
<br />
===== time_epoch =====<br />
<br />
This variable holds the time in seconds since 1970. <br />
<br />
===== time_hour =====<br />
<br />
This variable holds the current hour value (0–23). <br />
<br />
===== time_min =====<br />
<br />
This variable holds the current minute value (0–59).<br />
<br />
===== time_mon =====<br />
<br />
This variable holds the current month value (0–11).<br />
<br />
===== time_sec =====<br />
<br />
This variable holds the current second value (0–59). <br />
<br />
===== time_wday =====<br />
<br />
This variable holds the current weekday value (0–6).<br />
<br />
===== time_year =====<br />
<br />
This variable holds the current four-digit year value. <br />
<br />
===== response_status =====<br />
<br />
This variable holds the HTTP response status code.<br />
<br />
===== request_protocol =====<br />
<br />
This variable holds the request method used in the transaction.<br />
<br />
===== useragent_ip =====<br />
<br />
This variable is created when running modsecurity with apache 2.4 and will contain the client ip address set by mod_remoteip in proxied connections. Requires mod_remoteip to be installed, and Apache 2.4.<br />
<br />
=== Intercept on error===<br />
<br />
WAF_SECINTERCEPTONERROR: Configures how to respond when rule processing fails. [Default: on]<br />
<br />
===Analyze response body===<br />
<br />
WAF_SECRESPONSEBODYACCESS: Configures whether response bodies are to be buffer and analysed or not. [Default: on]<br />
<br />
=== MODSEC_SERVERSIG ===<br />
<br />
Field returned when a remote host queries what kind of web server this is. This can be used to hide what kind of server is running on the system, or what the WAFs are protecting.<br />
<br />
=== MODSEC_UPLOADDIR ===<br />
<br />
Configures the directory where intercepted files will be stored. If the WAF is configured to scan uploads, and this is set to On, then any malicious files the WAF detects will be stored in this directory on the server. <br />
<br />
=== MODSEC_KEEPFILES ===<br />
<br />
Configures whether or not the intercepted files will be kept after transaction is processed. It is recommended you set to this off.<br />
<br />
=== MODSEC_LOGTYPE ===<br />
<br />
Configures the type of audit logging mechanism to be used. Concurrent - audit log entries will be stored in separate files, one for each transaction. Serial - all audit log entries will be stored in the main audit logging file. The default is Concurrent, which is both faster and more reliable and works with ASL Gui. Serial logging is for legacy purposes and should not be enabled.<br />
<br />
=== MODSEC_LOGFILE ===<br />
<br />
The name of the log file that is used to store audit record headers. Do not change this unless you know what you are doing. It is generally not necessary to change this setting.<br />
<br />
=== MODSEC_LOGELEMENT ===<br />
<br />
Defines which part of each transaction are going to be recorded in audit log. Do not change the defaults unless you know what you are doing, this may break the GUI and active response systems.<br />
<br />
Available audit log parts:<br />
<br />
A: Audit log header (mandatory).<br />
<br />
B: Request headers.<br />
<br />
C: Request body (present only if the request body exists and ModSecurity is configured to intercept it).<br />
<br />
D: Reserved for intermediary response headers; not implemented yet.<br />
<br />
E: Intermediary response body (present only if ModSecurity is configured to intercept response bodies, and if the audit log engine is configured to record it). Intermediary response body is the same as the actual response body unless ModSecurity intercepts the intermediary response body, in which case the actual response body will contain the error message (either the Apache default error message, or the ErrorDocument page).<br />
<br />
F: Final response headers (excluding the Date and Server headers, which are always added by Apache in the late stage of content delivery).<br />
<br />
G: Reserved for the actual response body; not implemented yet.<br />
<br />
H: Audit log trailer.<br />
<br />
I: This part is a replacement for part C. It will log the same data as C in all cases except when multipart/form-data encoding in used. In this case, it will log a fake application/x-www-form-urlencoded body that contains the information about parameters but not about the files. This is handy if you don’t want to have (often large) files stored in your audit logs.<br />
<br />
J: This part contains information about the files uploaded using multipart/form-data encoding.<br />
<br />
K: This part contains a full list of every rule that matched (one per line) in the order they were matched. The rules are fully qualified and will thus show inherited actions and default operators. <br />
<br />
Z: Final boundary, signifies the end of the entry (mandatory). <br />
<br />
=== MODSEC_REQMEMLIMIT ===<br />
<br />
Configures the maximum request body size ModSecurity will store in memory. The default are adequate for most sites, you should not change this unless you know what you are doing.<br />
<br />
=== MODSEC_DEBUGLOG ===<br />
<br />
Enable/Disable the ModSecurity debug log file. The debug log is located in /var/log/httpd/modsec_debug.log Enabling this will incur a substantial performance penalty on the system. You should not enable this on a production system, and only if you are debugging modsecurity rules.<br />
<br />
Most users will want to leave this disabled.<br />
<br />
=== MODSEC_CLEAN_ALERT ===<br />
<br />
Number of days to retain mod_security alert data. The WAF will store the actual full requests of any intercepted attacks, to make it possible for you to investigate them and to report these to us, either for further investigation, false positives or for other forensics needs. The default is to keep these for 30 days.<br />
<br />
Audit log events are kept in this directory by default:<br />
<br />
/var/asl/data/audit/<br />
<br />
=== MODSEC_DATADIR ===<br />
<br />
Path where persistent data (e.g. IP address data, session data, etc) is to be stored.<br />
<br />
=== MODSEC_AUDITDIR ===<br />
<br />
'''Warning: This setting is unsupported'''<br />
<br />
Defines the path to the audit log files. Used only when Concurrent mode is configured.<br />
<br />
=== MODSEC_TMPDIR ===<br />
<br />
Configures the directory where temporary files will be created.<br />
<br />
Note: If this is changed form the default of /tmp, the directory must be writable by apache, which means depending on how you have configured apache by whatever users the web application may be running as. For example, if you use suphp, then the web application will run as a specific user. The directory must be writable by that user. In that case, you will need to either create a group that all your users belong to and make sure that group can write to that directory, or you will need to make that directory world writable. We also recommend you set the sticky bit on the directory. The simplest solution is to set the directories permissions thusly:<br />
<br />
For example, if you change this directory to /var/asl/mod_sec_tmp, these permissions should work generically in all cases:<br />
<br />
chmod ogu+rwx /var/asl/mod_sec_tmp<br />
<br />
chmod o+t /var/asl/mod_sec_tmp<br />
<br />
=== MODSEC_RESPONSEBODYLIMIT ===<br />
<br />
Configures the maximum response body size that will be accepted for buffering.<br />
<br />
=== MODSEC_RESPONSEBODYLIMITACTION ===<br />
<br />
Controls what happens once a response body limit, configured with SecResponseBodyLimit, is encountered. There are two options:<br />
<br />
ProcessPartial: Scan the response up to the limit and stop scanning when the limit is reached, but send the rest of the response.<br />
<br />
Reject: If the response is greater than the Limit, reject the response entirely.<br />
<br />
=== MODSEC_REQUESTBODYLIMIT === <br />
<br />
This sets the maximum size for a request body in bytes. The default is 134217728 bytes.<br />
<br />
Anything over the limit will be rejected with status code 413 (Request Entity Too Large). There is a hard limit of 1 GB. <br />
<br />
==== Ruleset Settings ====<br />
<br />
These allow you to enable/disable entire Rulesets and classes of rules. If you want to configure a specific rule, use the Rule Manager.<br />
<br />
===== Crawler Protector =====<br />
<br />
This unique feature of [[ASL]] protects not only your system, but also your search engine rankings. Unlike other security products, ASL can automatically and securely detect real search engine crawlers and prevent your system from accidentally blocking them. It can also detect when attackers are trying to pretend to be search engines, in hopes of getting around your security systems, and can safely block them, without blocking the real crawlers!<br />
<br />
<br />
====== WAF_LUA_00_SEARCHENGINE ======<br />
<br />
This will protect your page rank with search engine crawlers, prevent search engines from being blocked and will also block attackers pretending to be search engine crawlers. It can securely determine if a bot is legitimate, or a forgery.<br />
<br />
Default: disabled<br />
<br />
'''Note: This ruleset will only perform this function if a client claims to be a search engine, and is much faster than the legacy system and does not require that apache be configured with HostNameLookups Double. While this is significantly faster than looking up the A and PTR records for all FQDNS, this ruleset should only be used if the ASL server has a [[local DNS resolver]] server installed on the ASL server.''' You can use a remote resolver, but a local resolver will be faster and more reliable.<br />
<br />
These rules require a locally installed DNS server for maximum performance. It is not recommended you enable these rules without a local DNS server installed on this server. <br />
<br />
Requires ASL 4.0.11 and up.<br />
<br />
====== Legacy system ======<br />
<br />
If you are using a version of modsecurity prior to 2.9.0 then you may want to use the legacy options below. Do not use the legacy options with 2.9.0 and above.<br />
<br />
======= MODSEC_00_SEARCHENGINE =======<br />
<br />
'''NOTE: This setting is deprecated and unsupported. Users should use the Lua method above.'''<br />
<br />
Bogus Search Engine Ruleset<br />
<br />
This ruleset will detect search engine crawlers, as well as attackers pretending to be search engine crawlers. It can securely determine if a bot is legitimate, or a forgery.<br />
<br />
Default: disabled<br />
<br />
'''Note: You should only use this ruleset if the ASL server has a [[local DNS resolver]] server installed on the ASL server.''' You can use a remote resolver, but a local resolver will be faster and more reliable.<br />
<br />
These rules require a locally installed DNS server for maximum performance. It is not recommended you enable these rules without a local DNS server installed on this server. (If you do not know if you have a DNS server installed on this server, do not enable these rules). Apache must also be configured with "HostnameLookups Double". ASL will attempt to configure HostnameLookups Double, but on non-standard systems, such as source build Apache installs and third party Apache installations this may not occur automatically. If you find that Apache is not resolving IP addresses, check to make sure HostnameLookups Double is configured for Apache.<br />
<br />
Note: These are legacy rules, and should not be used with modsecurity 2.9.x You should use these rules instead:<br />
<br />
http://wiki.atomicorp.com/wiki/index.php?title=ASL_WAF#WAF_LUA_00_SEARCHENGINE<br />
<br />
======= MODSEC_00_AUTOWHITELIST_SEARCHENGINE =======<br />
<br />
'''NOTE: This setting is deprecated and unsupported. Users should use the Lua method above.'''<br />
<br />
Autowhitelist Search Engine Ruleset<br />
<br />
This ruleset will automatically, and securely, whitelist search engine crawlers to prevent them from being blocked accidentally. This will protect your page rank with search engine crawlers.<br />
<br />
NOTE: This ruleset requires the MODSEC_00_SEARCENGINE setting to be enabled for this to work.<br />
<br />
Default: disabled<br />
<br />
Note: These are legacy rules, and should not be used with modsecurity 2.9.x You should use these rules instead:<br />
<br />
http://wiki.atomicorp.com/wiki/index.php?title=ASL_WAF#WAF_LUA_00_SEARCHENGINE<br />
<br />
'''Warning: You should only use this ruleset if the ASL server has a fast [[local DNS resolver]] server installed on the ASL server.'''<br />
<br />
===== MODSEC_00_WHITELIST =====<br />
<br />
Whitelist Ruleset<br />
<br />
Enable/Disable application of the whitelist '''for the WAF'''. <br />
<br />
''By default whitelisting does not apply to the WAF.''<br />
<br />
Note: enabling this will bypass *ALL* security checks for hosts on the whitelist '''for the WAF.'''<br />
<br />
Default: off<br />
<br />
By default, this is not enabled. <br />
<br />
ASL can respond to attacks in several different ways. The two that relate to the WAF are:<br />
<br />
*blocking<br />
*shunning<br />
<br />
Blocking is when ASL stops a single attack, and does not take any further action. <br />
<br />
Shunning is when ASL both block the single attack, and implement a firewall rule to block any further attacks from the same IP.<br />
<br />
ASL is configured to use the whitelist to prevent shunning by default, for IPs on the whitelist, but still to block attacks from that IP. This helps to prevent attacks from trusted sources, but prevents accidentally firewall rules when false positives occur. We do not recommend you disable blocking for trusted IPs. If you have a false positive, report it to us. Enabling this option tells ASL to totally ignore everything from the IPs on the whitelist, which includes not generating any alerts on this source and not to block anything. Which means if you do have a real attack from a trusted IP, you will not idea its occurred and theres nothing ASL can do to stop it.<br />
<br />
We dont recommend you you use this unless you know you can completely and totally trust every host on your whitelist every time. <br />
<br />
Most users will not need to enable this.<br />
<br />
Warning: We do not recommend you include your servers IP on this whitelist if you have a shared hosting server. Whitelisting localhost (127.0.0.1) and your local servers IP(s) from the WAF will means that local users can launch attacks against the server and against other domains on the server which will be neither detected nor prevented. If you have a rule that is being triggered by a local script, please report it as a false positive if it is a false positive, and if not, this may be an actual attack on your system or a poorly developed application. If you have a false positive from a whitelisted IP, please report it to us. Whitelisting in general is extremely dangerous and attackers know that users do this, which is why they target desktops and other trusted systems. If they can get access to these trusted systems, they can usually gain unfetered access to everything that users desktop, mobile device, laptop or other trusted system can access.<br />
<br />
Note: This ruleset requires this file to exist:<br />
<br />
/etc/asl/whitelist<br />
<br />
The format is one IP or CIDR per line. For example:<br />
<br />
<pre><br />
1.2.3.4<br />
10.0.0.0/8<br />
</pre><br />
<br />
=====MODSEC_00_BLACKLIST=====<br />
<br />
Blacklist Ruleset<br />
<br />
Enable/Disable application of the blacklist '''for the WAF'''. <br />
<br />
''By default blacklist is accomplished at Layer 3, and this ruleset is not necessary for most systems. This ruleset is only necessary if your configuration does not allow you to block attackers at Layer 3, such as when the system is behind a layer 7 proxy or load balancer.''<br />
<br />
Note: enabling this will block all IPs on the users custom blacklist '''for the WAF.'''<br />
<br />
Default: off<br />
<br />
ASL can respond to attacks in several different ways. The two that relate to the WAF are:<br />
<br />
*blocking<br />
*shunning<br />
<br />
Blocking is when ASL stops a single attack, and does not take any further action. <br />
<br />
Shunning is when ASL both blocks the single attack, and implements a layer 3 firewall rule to block any further attacks from the same IP.<br />
<br />
ASL is configured to use the blacklist to block all IPs at layer 3. It is not configured by default to do this at layer 7, the WAF, as this is generally not necessary for most systems. Most users will not need to enable this.<br />
<br />
Note: This ruleset requires this file to exist:<br />
<br />
/etc/asl/blacklist<br />
<br />
The format is one IP or CIDR per line. For example:<br />
<br />
<pre><br />
1.2.3.4<br />
10.0.0.0/8<br />
</pre><br />
<br />
Requires ASL 4.0.15 and up.<br />
<br />
===== MODSEC_00_THREAT =====<br />
<br />
Threat Intelligence System<br />
<br />
Enabling this allows your system to use Atomicorp Threat Intelligence system to block knownn attackers.<br />
<br />
'''Important: It is highly recommended you enable these rules only with a local DNS resolver installed and configured on the system. (If you do not know if you have a local DNS resolver installed and configured on your system, do not enable these rules until you have confirmed that you do).''' Please see this article for information on [[Local DNS resolver]]s.<br />
<br />
Note: hosts on the whitelist are automatically excluded from being blocked by this ruleset.<br />
<br />
===== MODSEC_00_ANTIEVASION =====<br />
<br />
Antievasion Ruleset<br />
<br />
Enable/Disable the antievasion rule class. This ruleset prevents attacks that try to bypass the WAF itself.<br />
<br />
===== MODSEC_00_STRICT ===== <br />
<br />
Strict Multiform Ruleset<br />
<br />
Enable/Disable the strict multiform checks rule class. This ruleset enforces strict adherence RFCs for multiform messages, strictly enforces allowed types and implements enhanced checks on inputs. This prevents advanced attacks that may try to bypass the WAF, or involve more complex evasion attacks. <br />
<br />
Note: Broken applications and clients that do not adhere to RFCs will not be able to send multiform to the system if you enable this. This not a false positive, these clients and applications are broken. If you are unfortunately stuck with these, you will have to disable this.<br />
<br />
===== MODSEC_00_RBL ===== <br />
<br />
RBL Ruleset<br />
<br />
Enable/Disable Real-time Black List (RBL) rule class. Currently this uses the [http://www.spamhaus.org/xbl/ Spamhaus XBL] which is operated by the Spamhaus project. This RBL is not operated or controlled by Atomicorp. Please contact Spamhaus if you have issues with the IPs on this RBL, or disable this option.<br />
<br />
'''Default: off'''<br />
<br />
'''Warning: You should only use this ruleset if the ASL server has a really fast DNS server installed on the ASL server.''' <br />
<br />
This ruleset will look up every request in the DNS to see if its on a blacklist, and will not finish serving the request until the DNS server responds. This can slow down requests if the DNS server is slow. Basically, web requests will move at the speed of the DNS servers replies.<br />
<br />
If your web server is responding slowly to requests, and you have this ruleset enabled your DNS server is too slow to meet your lookup needs. You will need to either disable this ruleset, or tune your DNS server to respond to queries more quickly.<br />
<br />
===== MODSEC_00_AE_RULES =====<br />
<br />
'''Anti-Evasion Protection system'''<br />
<br />
Antievasion Ruleset/MODSEC_00_ANTIEVASION: Enable/Disable the antievasion rule class. This ruleset prevents attacks that try to bypass the WAF itself.<br />
<br />
===== MODSEC_01_RULES ===== <br />
<br />
Advanced Antievasion Ruleset<br />
<br />
Enable/Disable the advanced antievasion protection rule class. This ruleset prevents attacks that try to bypass the WAF itself or can be used to trick applications into parsing data in ways that may compromise the application.<br />
<br />
===== MODSEC_01_APP_RULES =====<br />
<br />
This is a special ruleset that most users will never need. Please see this article to see if this ruleset applies to you:<br />
<br />
[[WAF_rule_families#01_asl_rules_special.conf]]<br />
<br />
Default:no<br />
<br />
Note: Do not enable this ruleset unless you know what you are doing.<br />
<br />
===== MODSEC_01_DOMAIN_BLOCKS =====<br />
<br />
MODSEC_01_DOMAIN_BLOCKS<br />
<br />
Enable/Disable user defined custom domain blocking class. This ruleset blocks connections from a user defined list of domains when DNS records exist that match the incoming IP (This allows you to block hosts based on their DNS names), and also blocks referrers that contain that domain name. <br />
<br />
[Default: no]<br />
<br />
In the ASL gui, click on the ASL tab, then select Blocking, and then the Domains tab. Domains or FQDNs are defined, one per line. Matching is by string, regular expressions are not supported. Therefore, example.com will also match anotherexample.com. If you want to limit the domain you will need to use a delimiter, as in the example, such as:<br />
<br />
.example.com<br />
<br />
Which will only match on FQDNs that include .example.com, and in the previous example would not match on anotherexample.com.<br />
<br />
Note: Available in ASL 4.0.1 and up. This works by comparing the forward and reverse DNS records, if they do not match the rule will not match.<br />
<br />
===== MODSEC_03_DOS ===== <br />
<br />
Denial of Service Protection<br />
<br />
Enable/Disable the Denial of Services protection rule class. This ruleset prevents the so-called "slowaris" Denial of Service attacks, as well as "fast" DOS attacks. DDOS attacks can not be mitigated on the host itself. <br />
<br />
''Note: Some fastcgi implementations, specifically cpanel, require this to be disabled.''<br />
<br />
===== MODSEC_06_HONEYPOT =====<br />
<br />
Custom User Defined Honeypot Ruleset<br />
<br />
Enable/Disable the Custom User Defined Honeypot Ruleset. This ruleset allows you to define custom files, directories or a combination of the two in the file below that you want to block access to:<br />
<br />
/etc/httpd/modsecurity.d/honeypot-files.txt<br />
<br />
The format is one rentry per line. '''This method does not support regular expressions, but is case insensitive.''' For example:<br />
<br />
<pre><br />
/backups/admin.php<br />
/wp-config.php<br />
/admin/secret<br />
</pre><br />
<br />
===== MODSEC_10_ANTIMALWARE ===== <br />
<br />
Anti-Malware Ruleset<br />
<br />
Enable/Disable the anti-malware rule class. This will look at any requests to the system for known malware domains and indicators of malware injection requests (this does not do the same thing as the MODSEC_99_SCANNER class, which will inspect uploads for malware).<br />
<br />
===== MODSEC_10_RULES ===== <br />
<br />
Generic Attack Ruleset<br />
<br />
Enable/Disable the core rule class. This class contains the core generic rules, which will look for things like SQLi, XSS, CSRF, recursion, code injection, command injection, XML attacks and other generic attack patterns. You should always leave this class enabled.<br />
<br />
===== MODSEC_11_ADV_RULES ===== <br />
<br />
Advanced Attack Ruleset<br />
<br />
Enable/Disable the advanced protection rule class. This class contains advanced rules.<br />
<br />
===== MODSEC_11_DLP ===== <br />
<br />
Data Loss Protection Ruleset<br />
<br />
Enable/Disable the data loss protection rule class. This will detect certain Data Loss events, such as credit card information being sent or errors messages from applications that may reveal sensitive information or that the system or application is vulnerable to particular attack.<br />
<br />
Types of data this ruleset can detect in the output:<br />
<br />
1. Credit Card Numbers <br />
2. SSN numbers<br />
3. Debug information from:<br />
<br />
===== MODSEC_12_ADV_XSS_RULES =====<br />
<br />
Advanced Cross Scripting Protection (AXSSP)<br />
<br />
This is the advanced Cross Site Scripting (XSS) protection rule set. It performs deep level inspections of web requests and responses to look for potential XSS attacks. <br />
<br />
Note: This requires EL 6 and above.<br />
<br />
===== MODSEC_11_BRUTE ===== <br />
<br />
Supplemental Brute Force Protection Ruleset<br />
<br />
Enable/Disable the supplemental web brute force attack protection rule class. This ruleset is used on systems that do not have either ASL or Atomic Protector installed, and perform the process of tracking login failures, and send a 403 error to the user when the limit is reached.<br />
<br />
'''Note:''' This works by analysing the output of the web application, and does not rely on log analysis or htaccess files. Therefore, do not use application internal compression schemes on output. For example, do not enable GZIP compression in applications such as Joomla, PHPBB, Wordpress and others, as this will make it difficult for the WAF to see the output. You can still compress the output if you use an apache module such as mod_deflate, which accomplishes the same thing and is less CPU intensive that application internal compression. '''Litespeed does not currently support this ruleset. If you require this protection with Litespeed, you must use ASL and configure ASL to setup a local WAF, via ASL, in front of Litespeed.'''<br />
<br />
'''Discussion:'''<br />
<br />
For the WAF to be able to analyze output from web applications, the WAF must be able to understand the output from the web application. Applications that compress output send this compressed output to Apache, which creates a situation where the WAF will only see compressed content. In this case, the WAF will not be able to understand it because the WAF will not decompress it.<br />
<br />
Whereas it is possible for the WAF to decompress this content, and then recompress it, this is '''extremely''' wasteful for the CPU and will unnecessarily slow the system down. Essentially the web server would be compressing the content, decompressing it, and then compressing it again. Add in two unnecessary steps, and tripling the work load. The most efficient solution is to not compress output in the application, let the WAF inspect it, and then let apache compress it. <br />
<br />
'''Inline decompression with the WAF is no longer supported and has been removed from the WAF code as this leads to poor performance due to misconfiguration of the system.'''<br />
<br />
===== MODSEC_12_BRUTE ===== <br />
<br />
Brute Force Protection Ruleset<br />
<br />
Enable/Disable the web brute force attack protection rule class. Detects attempts to brute force web applications authentication mechanisms.<br />
<br />
'''Note:''' This works by analysing the output of the web application, and does not rely on log analysis or htaccess files. Therefore, do not use application internal compression schemes on output. For example, do not enable GZIP compression in applications such as Joomla, PHPBB, Wordpress and others, as this will make it difficult for the WAF to see the output. You can still compress the output if you use an apache module such as mod_deflate, which accomplishes the same thing and is less CPU intensive that application internal compression. '''Litespeed does not currently support this ruleset. If you require this protection with Litespeed, you must use ASL and configure ASL to setup a local WAF, via ASL, in front of Litespeed.'''<br />
<br />
'''Discussion:'''<br />
<br />
For the WAF to be able to analyze output from web applications, the WAF must be able to understand the output from the web application. Applications that compress output send this compressed output to Apache, which creates a situation where the WAF will only see compressed content. In this case, the WAF will not be able to understand it because the WAF will not decompress it.<br />
<br />
Whereas it is possible for the WAF to decompress this content, and then recompress it, this is '''extremely''' wasteful for the CPU and will unnecessarily slow the system down. Essentially the web server would be compressing the content, decompressing it, and then compressing it again. Add in two unnecessary steps, and tripling the work load. The most efficient solution is to not compress output in the application, let the WAF inspect it, and then let apache compress it. <br />
<br />
'''Inline decompression with the WAF is no longer supported and has been removed from the WAF code as this leads to poor performance due to misconfiguration of the system.'''<br />
<br />
===== MODSEC_20_USERAGENTS ===== <br />
<br />
Malicious Useragents Ruleset<br />
<br />
Enable/Disable the useragents rule class. Detects known malicious or suspicious user agents.<br />
<br />
===== MODSEC_21_USERAGENTS ===== <br />
<br />
User Defined Malicious Useragents Ruleset<br />
<br />
Enable/Disable the User Defined Malicious Useragents Ruleset. This ruleset allows you to define custom useragents in the file below that you want to block:<br />
<br />
/etc/httpd/modsecurity.d/bad_agents.txt<br />
<br />
The format is one user-agent per line. '''This method does not support regular expressions, but is case insensitive.''' For example<br />
<br />
<pre><br />
Mozila 99.0<br />
Internut exploder<br />
</pre><br />
<br />
===== MODSEC_30_ANTISPAM ===== <br />
<br />
Anti-Spam Ruleset<br />
<br />
Enable/Disable the anti-spam rule class. This class contains tuned antispam rules, designed to work with all known blogs, forums, guestbooks, CMS' and other web content management systems that allow users to post content. <br />
<br />
===== MODSEC_31_ANTISPAM_URI ===== <br />
<br />
Anti-Spam URI RBL Ruleset<br />
<br />
Enable/Disable the anti-spam URI rule class. Looks up all URIs in a post against RBLs to see if its a known spam domain. As with the MODSEC_00_RBL rules, these should only be used if the server has a local fast DNS server. <br />
<br />
'''Warning: You should only use this ruleset if the ASL server has a really fast DNS server installed on the ASL server.''' <br />
<br />
This ruleset will look up every request in the DNS to see if its on a blacklist, and will not finish serving the request until the DNS server responds. This can slow down requests if the DNS server is slow. Basically, web requests will move at the speed of the DNS servers replies.<br />
<br />
If your web server is responding slowly to requests, and you have this ruleset enabled your DNS server is too slow to meet your lookup needs. You will need to either disable this ruleset, or tune your DNS server to respond to queries more quickly.<br />
<br />
===== MODSEC_50_ROOTKITS ===== <br />
<br />
Rootkit Detection Ruleset<br />
<br />
Enable/Disable the rootkit rule class. This class detects and blocks known rootkits, PHP/ASP/PERL shells, spam tools and other malicious web applications from running on the system. (These rules exist for cases where malicious software may already be installed on the system, this is a defense in depth rule set) <br />
<br />
===== MODSEC_60_RECONS ===== <br />
<br />
Reconnaissance Attacks Ruleset<br />
<br />
Enable/Disable the recon rule class. This class blocks known "google hacks" or webserver probes that look for vulnerable applications and signs of compromised systems running unauthorized shells, or unprotected applications that allow uploads which would give an attacker access to the system. <br />
<br />
===== MODSEC_61_DLP ===== <br />
<br />
Data Leak Prevention Ruleset<br />
<br />
Enable/Disable the data loss protection class. These rules detect Data Loss Search engine "hacks". These are search engine probes for sensitive files, often used by malicious parties to find sensitive information accidentally exposed on web servers.<br />
<br />
===== MODSEC_98_ADV_REDACTOR =====<br />
<br />
Advanced Malware Removal Ruleset<br />
<br />
Enable/Disable the advanced malware removal ruleset. These rules detect hidden iframes, obfuscated javascript and other potentially malicious code and remove it real time from your web pages.<br />
<br />
===== MODSEC_99_JITP ===== <br />
<br />
Just In Time Patches<br />
<br />
Enable/Disable the Just In Time Patches(JITP) rule class. Just in Time Patches. We publish JITPs daily if there is a new web application vulnerability that the 10_asl_rules.conf do not protect the system against. These are tuned rules for specific vulnerabilities in a web application. <br />
<br />
===== MODSEC_99_REDACTOR ===== <br />
<br />
Malicious Output Removal Ruleset<br />
<br />
Enable/Disable the automatic malicious/hidden iframe and malware removal rule class. Automatically removes malicious code from web pages, such as hidden iframes, encoded javascript and other malicious code. <br />
<br />
===== MODSEC_99_MALWARE_OUTPUT ===== <br />
<br />
Malicious Output Detector<br />
<br />
Enable/Disable the malware output rule class.<br />
<br />
===== MODSEC_99_SCANNER ===== <br />
<br />
Web Malware Upload Scanner<br />
<br />
Malicious code upload scanner. Enable this to scan web uploads for malicious code.<br />
<br />
===== MODSEC_99_ADV_SCANNER =====<br />
<br />
Advanced Malware Upload Scanner<br />
<br />
This enables the advanced malware upload scanner rule class. This uses fuzzy hashes to detect similiar malware.<br />
<br />
= Rule Manager =<br />
<br />
The Rule manager can be used to configure individual WAF rules, such as what response the system such take for that rule, if an email or GUI alert should be presented, and so on. To access the rule manager please follow this process:<br />
<br />
Step 1) Log into the ASL GUI<br />
<br />
Step 2) Click the "Configuration" tab.<br />
<br />
Step 3) Select "Rule Management"<br />
<br />
This will bring up the rule management screen. There are two tabs on this screen:<br />
<br />
Global: This sets global features for all the rules<br />
<br />
Rules: This presents all the individual rules, and options to configure that rule specifically.<br />
<br />
== Global Options ==<br />
<br />
If you change a setting on this screen, you must click the "Update" button for the setting changes to take effect.<br />
<br />
The follow settings are available in the Global setting screen:<br />
<br />
=== Email to === <br />
<br />
This sets the email address to send alerts to. The default is $EMAIL which inherits the global email address set in the ASL Configuration screen. If you want to use the same email address you set when you configured when you install ASL leave this setting as "$EMAIL". Otherwise, change this to the email address you want rule alerts sent to.<br />
<br />
=== Email From ===<br />
<br />
Set this to the From: line you want to use for the emailed alerts. Available variables are $HOSTNAME is is populated by the servers fully qualified hostname, and $EMAIL which is set in the ASL Configuration screen. The default is usually effective for most users.<br />
<br />
=== Max Emails per hour ===<br />
<br />
This sets a limit on the maximum number of emails the system will sent to the Email to: address. This basically "queues up" alerts. If events occur after the Max Emails per hour limit has been reached, then those alerts will be held until the next hour and will be grouped together in a single email sent the next hour.<br />
<br />
If you want alerts to be sent as they occur, and not to be queued up, set this to 9999.<br />
<br />
=== Active Response ===<br />
<br />
This sets whether of not ASL will block the source of the attack, by implementing a firewall rule for the source of the attack. (Which may be a temporary shun, or a permanent shun depending on the setting below "Shun Timeout")<br />
<br />
=== Shun Timeout ===<br />
<br />
This tells ASL if the firewall block, or "shun", should be temporary or permanent. Once the Shun Time (described below) has been reached the source IP address will be allowed to connect again. The ASL Configuration settings also allow for advanced options for this, such as multiplers that cause sources to be shunned for longer periods of time as more attacks are detected from the source.<br />
<br />
=== Shun Time ===<br />
<br />
Timeout period is in seconds. This sets the maximum amount of time a source address will be blocked by ASL/<br />
<br />
If Shun Timeout is set to no, the "shun" is permanent and this option is ignored.<br />
<br />
=== Rules ===<br />
<br />
The Rules Manager has two tabs:<br />
<br />
==== HIDS ====<br />
<br />
This contains all the Rules for HIDS. For documentation on the HIDS please see the [[ASL HIDS]] documentation page.<br />
<br />
==== WAF ====<br />
<br />
This contains all the Rules for the WAF. There are two columns on this tab, the left column contains the current rule sub classes, and the screen on the right shows all rules that match your current filter selections. The window on the right is populated by selecting either a subclass of rules, or by typing in search criteria in the boxes at the top of the screen. <br />
<br />
If you select a rule sub class, for example "adult-spam" that will pull up all the rules in the class on the right hand side of the screen.<br />
<br />
Or you can search for specific rules by using the filter bar at the top of the screen. The filter options are:<br />
<br />
Category: This is another way to select a rule subclass, this is optional, you do not have to select a rule class. If you leave this in either the default, or you set this to (any) your filter will apply to all the WAF rules. <br />
<br />
Level: Rules have different levels, depending on severity. Some rules are only informational, some indicate suspicious activity and others are full blown attacks. A higher number is a high severity or importance, and a lower number is a lower severity or importance. This filter is optional, you do not need to select a level if you do not want to filter by level. If you leave the default your filter will apply to all levels.<br />
<br />
Search: This allows you to search by any thing in the rule, its name, ID, etc. If you hit enter in this field it will start the search. <br />
<br />
When you have finished with your filter criteria, just click the "filter button" or hit enter in the search field.<br />
<br />
=== Configuring specific rules ===<br />
<br />
Once you have the rule manager open, and have pulled up a rule you want to modify just click on the down arrow next to the rules ID to open the rules options. <br />
<br />
===== Rule Options =====<br />
<br />
For WAF rules the following options are available:<br />
<br />
<br />
====== Disabled ======<br />
<br />
Setting this "yes" globally disables the rule. If you want to disable a rule for a specific domain or FQDN see the Vhost option below.<br />
<br />
====== Severity ======<br />
<br />
This sets the severity level for the event. This allows you to set rules to be lower or higher priority which will effect:<br />
<br />
1. How they are displayed in the GUI<br />
<br />
2. Whether they are shunned or not (a minimum severity level can be set in ASL to control if an event is important enough to block the source IP address, please see the [[ASL Configuration]] documentation for these settings.<br />
<br />
3. If an email alert is sent. A minimum severity level can be set in ASL to control if an event is important enough to send an email alert, please see the [[ASL Configuration]] documentation for these settings.<br />
<br />
====== Active Response ======<br />
<br />
This sets if the system should perform any active response actions against the source IP address. This option is ignored if Active Response is disabled in the Global options.<br />
<br />
====== Email ======<br />
<br />
This sets if the event will generate an email alert. Keep in mind that the event must also be above the minimum level set in the [[ASL Configuration]].<br />
<br />
====== Logging ======<br />
<br />
This sets if the event will be displayed, at all, in the ASL GUI. Setting this to off "silences" the event in the ASL GUI. It does not prevent the event from being logged to the systems logs.<br />
<br />
====== Vhost settings ======<br />
<br />
This subpanel allows you to set domain or FQDN specific settings for a rule. For example, if you want a rule to other behave per its defaults, but want to change its behavior for a specific domain you can set that domain here.<br />
<br />
Currently this is limited to disabling the rule for the domain. In the future this will be expanded to allow other options for the rule as with the global settings.<br />
<br />
Simply type in the domain name in the text box on the right, select "yes" and click add.<br />
<br />
=== Rule Tuning ===<br />
<br />
Please see the [[Mod_security]] page.<br />
<br />
= Events =<br />
<br />
WAF events are displayed in the [[ASL Events]] window. Please see the [[ASL Events]] page for usage information.<br />
<br />
= Configuring web servers to use the T-WAF =<br />
<br />
This section provides courtesy instructions about how to configure a remote web server to work with the T-WAF, so that the remote web server reports the correct client IP address and not the IP address for the T-WAF server.<br />
<br />
This can also be used with local web services. For local apache servers, we do not recommend you use the T-WAF. Instead, make sure you are using the embedded mode explained at the beginning of this article. The WAF will integrate natively with Apache 2.x, and is highly recommended for that platform.<br />
<br />
== Apache ==<br />
<br />
Note: If you are using embedded mode (which is the default) you do not need to do this. You will only need to do this if you are using the T-WAF to proxy traffic to a remote apache server. If you have a local apache server that ASL is installed on, install modsecurity locally.<br />
<br />
For remote apache servers, to setup Apache to report the clients IP when using the T-WAF follow this process:<br />
<br />
Step 1) Install mod_rpaf<br />
<br />
http://stderr.net/apache/rpaf/<br />
<br />
Step 2) Add this to your remote servers apache configuration<br />
<br />
<pre><br />
LoadModule rpaf_module path/to/mod_rpaf-2.0.so<br />
RPAFenable On<br />
RPAFsethostname On<br />
RPAFproxy_ips <IP FOR THE ASL SERVER><br />
RPAFheader X-Forwarded-For<br />
</pre><br />
<br />
Change the IP in this line:<br />
<br />
RPAFproxy_ips <IP FOR THE ASL SERVER><br />
<br />
To the IP for your ASL server. For example, if the ASL servers IP address is 1.2.3.4 this line will look like this:<br />
<br />
RPAFproxy_ips 1.2.3.4<br />
<br />
Step 3) Restart the remote apache server<br />
<br />
== Litespeed ==<br />
<br />
To setup Litespeed to report the correct IP address of the client when using the T-WAF follow these instructions:<br />
<br />
Step 1) Log into the LiteSpeed Web Admin Console<br />
<br />
Step 2) Under Configuration, enable the option "Use Client IP in Header".<br />
<br />
Step 3) Restart Litespeed<br />
<br />
== Nginx ==<br />
<br />
Step 1) Edit your nginx.conf file and add the following to your http section:<br />
<br />
<pre><br />
http {<br />
set_real_ip_from 127.0.0.1/32;<br />
set_real_ip_from <YOUR SERVERS IP>/32;<br />
set_real_ip_from <YOUR SERVERS OTHER IPS>/32;<br />
real_ip_header CF-Connecting-IP;<br />
</pre><br />
<br />
Replace <YOUR SERVERS IP> with your servers IP(s). For example, if your server had the IPs 1.2.3.4, 1.2.3.5 and 1.2.3.6 your configuration would look like this:<br />
<br />
<pre><br />
set_real_ip_from 127.0.0.1/32;<br />
set_real_ip_from 1.2.3.4/32;<br />
set_real_ip_from 1.2.3.5/32;<br />
set_real_ip_from 1.2.3.6/32;<br />
real_ip_header CF-Connecting-IP;<br />
</pre><br />
<br />
<br />
Step 2) Restart nginx.</div>Mshinnhttps://wiki.atomicorp.com/wiki/index.php/Atomic_ModSecurity_RulesAtomic ModSecurity Rules2022-05-06T17:33:28Z<p>Mshinn: /* Step 3: Set permissions for directories */</p>
<hr />
<div>[[Atomic Secured Linux]] includes modsecurity, and the Real Time GotRoot.com/Atomicorp Modsecurity Rules. These docs are for users that do not have [[ASL]].<br />
<br />
'''ASL will install and configure modsecurity, and provides a powerful and easy use to GUI to manage all of this for you. If you don't have ASL, [https://www.atomicorp.com/amember/cart/index/index?c=1 upgrade to ASL today!]'''<br />
<br />
= '''About the rules''' =<br />
<br />
The gotroot.com rules are written by us - we are the gotroot guys. Same great rules, same team, ten years of writing modsecurity rules and still going strong! GotRoot is our Information Assurance lab and [http://www.atomicorp.com Atomicorp] is the product arm of [http://www.progllc.com Prometheus Global] (the parent company for both). So when you get the gotroot.com rules from atomicorp.com or gotroot.com - you're getting the same rules from the same people that created, write and maintain them. In the future we will be merging the gotroot.com, atomicrocketturtle and atomicorp websites into the atomicorp.com website.<br />
<br />
We publish two versions of the rules:<br />
<br />
'''RealTime Rules:''' The latest and greatest version of the rules, with all the performance enhancements, new security features and bug fixes released by us on a daily basis. These rules are fully supported and are recommended for production use.<br />
<br />
'''Free/Delayed Rules:''' A delayed subset of the Advanced rules.<br />
<br />
Installation of the rules assumes a certain level of comfort with configuring apache. If you are not comfortable with configuring apache, you should contact someone that is, or use our [[Atomic Secured Linux]] product which does this automatically for you, and does not require you to configure apache.<br />
<br />
== Getting the rules ==<br />
<br />
[https://www.atomicorp.com/amember/cart/index/index?c=6 Click here] to get the Atomicorp ModSecurity Rules.<br />
<br />
== '''Atomic ModSecurity Rules Frequently Asked Questions''' ==<br />
<br />
Please see the [[Atomic ModSecurity Rules FAQ]] wiki page.<br />
<br />
== '''Real Time Rule Support''' ==<br />
<br />
If you have a subscription to the real time rules, you can request email support by sending an email to:<br />
<br />
support@atomicorp.com<br />
<br />
The Customer Support Forums are located here:<br />
<br />
[http://www.atomicorp.com/forums Customer Support Forums]<br />
<br />
And the Custom Support Portal is located here (you can submit bug reports and open cases through the portal):<br />
<br />
[https://www.atomicorp.com/portal Customer Support Portal]<br />
<br />
== '''Licenses''' ==<br />
<br />
The Real Time Atomic ModSecurity Rules are licensed by the server. You can order licenses from the online store at the link below:<br />
<br />
[https://www.atomicorp.com/amember/cart/index/index?c=6 Online Store]<br />
<br />
If you require additional licenses please log into the [https://www.atomicorp.com/support/license-manager.html AtomiCorp License Manager]. You can add additional systems there, you can control your payment methods and you can also sign up to become an affiliate.<br />
<br />
=== License Terms and Conditions ===<br />
<br />
Purchase of an Atomicorp ModSecurity rule license entitles the purchaser to access and download from the Atomicorp Repository to a single IP address within the time period of the license. A separate license is required for each dedicated server/host or VPS that the rule set is installed upon or is protecting.<br />
<br />
Atomicorp ModSecurity rules installed upon a Reverse Proxy WAF appliance/server requires a separate license. Please contact Atomicorp support for details.<br />
<br />
The rule set cannot be copied, mirrored, or reproduced under protection of US and International copyright laws.<br />
<br />
Use of the rule set is limited to the time period of the license. If the license period of a rule set expires, it must must removed from its installed server and no longer used. Atomicorp reserves the right to track and enforce license compliance of the Atomicorp Modsecurity rule sets.<br />
<br />
Agreement to these terms and conditions and the Atomicorp [https://atomicorp.com/eula.html End User License Agreement] is required to download and use the Atomicorp ModSecurity rules.<br />
<br />
== Important Information about the Rules ==<br />
<br />
=== Minimum Version of Modsecurity Required to use the rules ===<br />
<br />
The rules are supported with the following versions of Modsecurity:<br />
<br />
<br />
* 2.9.3<br />
<br />
We recommend customers use our modsecurity builds, as they are tested to ensure all features work correctly. Third party builds may not include the correct libraries, may cause problems with your web server, including crashes and may disable or incorrectly enable features in modsecurity that can cause unpredictable behavior or failure of rules to process correctly.<br />
<br />
If you need a solution to keep the rules and modsecurity up to date and in sync with your version of modsecurity automatically, please use [[aum]] or [[ASL]] which will do this for you automatically.<br />
<br />
==== What versions of modsecurity do the rules work with ====<br />
<br />
They work with both modsecurity 2.9.x, and modsecurity 3.x.<br />
<br />
=== What does each rule family do? ===<br />
<br />
Please see the [[modsecurity_rule_families]] documents.<br />
<br />
= Installation =<br />
<br />
== Easy One Step Installation ==<br />
<br />
<br />
<br />
===== Full Management Suite =====<br />
<br />
Install [[ASL]]. This installs everything: modsecurity, all the rules, the GUI, rule manager and all ASL components, plus it includes the subscription to the real time rules.<br />
<br />
ASL will automatically download and keep your rules up to date, and will ensure that modsecurity stays up to date so your system can support the latest rules. ASL also provides you with a full security management suite, which will allow you to manage, edit and configure your rules through a web console. It will also protect you from uploaded malware, brute force attacks, DOS attacks, rootkits and many other threats that a WAF can not protect you from.<br />
<br />
A full list of ASLs features is available at the URL below:<br />
<br />
https://www.atomicorp.com/products/asl.html<br />
<br />
===== Just a downloader =====<br />
<br />
We also provide an automated rule updater and modsecurity installation tool, called [[aum]]. You can read more about it on the [[aum]] page. You can install it by running these commands as root:<br />
<br />
Step 1) Install [[aum]]<br />
<br />
''wget -q -O - https://updates.atomicorp.com/installers/aum |bash''<br />
<br />
Step 2) Configure [[aum]]<br />
<br />
''aum configure''<br />
<br />
Step 3) Tell [[aum]] to install the rules<br />
<br />
''aum upgrade''<br />
<br />
You can read more about aum on the [[aum]] documentation page.<br />
<br />
Note: This capability is included in [[ASL]]. ASL users do not need to install aum, its already included.<br />
<br />
== (Optional) Do It Yourself Installation ==<br />
<br />
Note: A manual installation is not necessary if you have [[ASL]] installed. ASL will configure and install modsecurity, and the rules, automatically. This is also not necessary if you are using our new AUM software to handle rule download and installation.<br />
<br />
=== Linux ===<br />
<br />
==== Step 1: Download ModSecurity ====<br />
<br />
Binaries:<br />
<br />
[http://updates.atomicorp.com/channels/atomic/ Install modsecurity from the Atomicorp software repository]<br />
<br />
Source Code:<br />
<br />
[http://updates.atomicorp.com/channels/atomic/ Install modsecurity from the Atomicorp software repository]<br />
<br />
Please note that the rules are only supported with the version of modsecurity [http://wiki.atomicorp.com/wiki/index.php/Atomic_ModSecurity_Rules#Minimum_Version_of_Modsecurity_Required_to_use_the_rules identified in this section of the wiki.]<br />
<br />
Note: Please contact us before using a third party or source build of modsecurity. Its critical modsecurity be built correctly to work with the rules.<br />
<br />
==== Step 2: Set up and configure directories ====<br />
<br />
Create the following directories as root:<br />
<br />
mkdir /etc/httpd/modsecurity.d<br />
mkdir /var/asl<br />
mkdir /var/asl/tmp<br />
mkdir /var/asl/data<br />
mkdir /var/asl/data/msa<br />
mkdir /var/asl/data/audit<br />
mkdir /var/asl/data/suspicious<br />
<br />
==== Step 3: Set permissions for directories ====<br />
<br />
Set the following permissions on the directories you just created. In this example these directories are set to be owned by "apache" and the group "apache", which is standard on a normal Centos or RHEL system. However some control panels configure apache to run as a different user, such as nobody, or http. <br />
<br />
To determine what user this is, check your system to see what user your webserver uses. You can use this command to find the user:<br />
<br />
ps auxwww | grep httpd<br />
<br />
The output will look similar to this:<br />
<br />
(RHEL/Centos example with or without Plesk)<br />
<br />
root 26755 0.0 4.3 430752 86432 ? Ss 04:30 0:01 /usr/sbin/httpd<br />
'''apache''' 26908 0.0 3.7 300564 75076 ? S 04:30 0:00 /usr/sbin/httpd<br />
'''apache''' 26909 0.1 5.5 495812 112084 ? S 04:30 0:37 /usr/sbin/httpd<br />
'''apache''' 26910 0.0 5.3 495424 106672 ? S 04:30 0:23 /usr/sbin/httpd<br />
'''apache''' 26911 0.1 5.7 495892 114368 ? S 04:30 0:57 /usr/sbin/httpd<br />
'''apache''' 26912 0.1 5.7 496056 114440 ? S 04:30 0:52 /usr/sbin/httpd<br />
'''apache''' 26913 0.1 5.5 496604 110692 ? S 04:30 0:57 /usr/sbin/httpd<br />
'''apache''' 26914 0.0 5.7 499324 116236 ? S 04:30 0:16 /usr/sbin/httpd<br />
'''apache''' 26915 0.2 5.5 493600 112192 ? S 04:30 1:09 /usr/sbin/httpd<br />
'''apache''' 26916 0.1 6.4 513760 129992 ? S 04:30 0:30 /usr/sbin/httpd<br />
<br />
In this example the user in bold is "apache" (this may be different for your system). This is the user you will want to set the directory permissions to (as in the example below):<br />
<br />
chown apache.apache /var/asl/data/msa<br />
chown apache.apache /var/asl/data/audit<br />
chown apache.apache /var/asl/data/suspicious<br />
chmod o-rx -R /var/asl/data/*<br />
chmod ug+rwx -R /var/asl/data/*<br />
<br />
(RHEL/Centos example with Cpanel)<br />
<br />
root 20594 86.8 3.1 255148 181232 ? Ss 11:39 0:04 /usr/local/apache/bin/httpd -k restart<br />
root 20611 0.0 3.1 255060 179596 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20612 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20613 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20614 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20615 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20616 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
<br />
In this example from a Centos system running Cpanel the user is "nobody", so you would want to use these commands:<br />
<br />
chown nobody.nobody /var/asl/data/msa<br />
chown nobody.nobody /var/asl/data/audit<br />
chown nobody.nobody /var/asl/data/suspicious<br />
chmod o-rx -R /var/asl/data/*<br />
chmod ug+rwx -R /var/asl/data/*<br />
<br />
==== Step 4: (Optional) Create rule updater directories ====<br />
These directories must as be created if you use optional rules updater. Create these directories as root and they only need to be accessed by root:<br />
<br />
mkdir /var/asl/updates<br />
mkdir /var/asl/rules/<br />
mkdir /var/asl/rules/clamav<br />
<br />
==== Step 5: Create the whitelist file ====<br />
<br />
Create this file:<br />
<br />
touch /etc/asl/whitelist<br />
<br />
This file contains a list of IPs you want to exclude from ALL rules. That means those IPs can do anything to your system - so be very very careful about what IPs you add to this list. This is a dangerous thing to do. The format of the file is a single IP, per line. <br />
<br />
Cpanel users should skip to the notes at the bottom of this page for special additional actions for cpanel systems. All other users should continue with these instructions.<br />
<br />
==== Step 6: Configure your webserver ====<br />
<br />
===== nginx =====<br />
<br />
===== Step 6a: configure nginx to load modsecurity =====<br />
<br />
====== nginx proxying to a backend ======<br />
<br />
If you are using nginx as a frontend to another webserver, then add the following directives to your nginx.conf file.<br />
<br />
<pre><br />
location / {<br />
ModSecurityEnabled on;<br />
ModSecurityConfig modsecurity.conf;<br />
proxy_pass http://localhost:8080;<br />
proxy_read_timeout 180s;<br />
}<br />
<br />
</pre><br />
<br />
Change "localhost:8011" to the server you are proxying nginx to, and change 8080 to the portnumber for that server. For example, if you are running apache on port 8088 on localhost the line would be:<br />
<br />
proxy_pass http://localhost:8088;<br />
<br />
====== nginx standalone ======<br />
<br />
If you are only using nginx, and not using it as a frontend to another web server then you want to use this configuration:<br />
<br />
<pre><br />
location / {<br />
ModSecurityEnabled on;<br />
ModSecurityConfig modsecurity.conf;<br />
}<br />
</pre><br />
<br />
===== Apache =====<br />
<br />
===== Step 6a: configure apache to load modsecurity =====<br />
<br />
You then need to tell apache to load modsecurity. Depending on your apache configuration, apache should be configured to include configuration files. If you have a setting like this in your apache config:<br />
<br />
Include conf.d/*.conf<br />
<br />
Then you are setup to load external configuration files. If you do not have this setup, its highly recommend you add this. This installation guide is written for this type of configuration. Loading mod_security occurs by including a modsecurity configuration file in that directory. We recommend you name the name 00_modsecurity.conf to ensure it runs first. Its vitally important that modsecurity load before other modules, otherwise attacks can occur before modsecurity scans them and some attacks can be missed.<br />
<br />
An example 00_modsecurity.conf file that works with our files is included here:<br />
<br />
LoadModule security2_module modules/mod_security2.so<br />
LoadModule unique_id_module modules/mod_unique_id.so<br />
<IfModule mod_security2.c><br />
Include modsecurity.d/tortix_waf.conf<br />
</IfModule><br />
<br />
Install this file in your conf.d directory. On a standard RHEL or Centos system that directory is located here:<br />
<br />
/etc/httpd/conf.d/<br />
<br />
=== Step 7: Configure modsecurity ===<br />
<br />
You then need to configure modsecurity. This is done via the an apache configuration file. In this example, we will create the file "tortix_waf.conf". Here is an example file that works with our rules:<br />
<br />
SecRuleEngine On<br />
SecRequestBodyAccess On<br />
SecResponseBodyAccess On<br />
SecResponseBodyMimeType (null) text/html text/plain text/xml<br />
SecResponseBodyLimit 2621440<br />
SecServerSignature Apache<br />
SecComponentSignature 200911012341<br />
SecUploadDir /var/asl/data/suspicious<br />
SecUploadKeepFiles Off<br />
SecAuditEngine RelevantOnly<br />
SecAuditLogRelevantStatus "^(?:5|4(?!04))"<br />
SecAuditLogType Concurrent<br />
SecAuditLog logs/audit_log<br />
[[SecAuditLogParts]] ABIFHZ<br />
SecArgumentSeparator "&" <br />
SecCookieFormat 0<br />
SecRequestBodyInMemoryLimit 131072<br />
SecDataDir /var/asl/data/msa<br />
SecTmpDir /tmp<br />
SecAuditLogStorageDir /var/asl/data/audit<br />
SecResponseBodyLimitAction ProcessPartial<br />
SecAuditLogDirMode 0770<br />
SecPcreMatchLimit 250000 <br />
SecPcreMatchLimitRecursion 250000<br />
<br />
You will want to install this file in your modsecurity.d directory, which is located here if you follow the instructions above:<br />
<br />
/etc/httpd/modsecurity.d<br />
<br />
==== tortix_waf.conf ====<br />
<br />
You can also download an example version of the modsecurity configuration file from here:<br />
<br />
https://www.atomicorp.com/installer/tortix_waf.conf<br />
<br />
[[ASL]] will automatically generate this file depending on your needs. If you are not using ASL, you will need to modify this configuration file to suit your system and modsecurity requirements.<br />
<br />
==== Step 8: Download the ModSecurity Rules ====<br />
<br />
See the [[Downloading Rules]] page.<br />
<br />
==== Step 9: Install the rules ====<br />
<br />
==== Remove any previous installations of rules ====<br />
<br />
If you have installed our delayed rules, you will need to make sure you have deleted them. You will not want to have any older versions of the rules installed.<br />
<br />
Also, if you have installed any third party modsecurity rules, you will want to make sure they are using rule id's that are assigned to them. The modsecurity project assigns ranges to the rule id's modsecurity uses. Modsecurity requires a unique id for each rule, otherwise you will get an error like this:<br />
<br />
ModSecurity: Found another rule with the same id<br />
<br />
This means either that someone else is using the same rule id's assigned to our ruleset by the modsecurity project (our official range is 300000-399999), or you have loaded our rules twice.<br />
<br />
==== Installation ====<br />
<br />
Download the rules to a temporary directory using your favorite download tool. Extract the rules:<br />
<br />
tar zxvf /var/asl/updates/modsec-200911012341.tar.gz<br />
<br />
Then copy each of the ASL rule files you wish to use into /etc/httpd/modsecurity.d. Do not copy all of the rule files, you will need to select rule files that are appropriate for your system. Or simply use [[aum]] or [[ASL]] to do this for you automatically.<br />
<br />
If you are using cpanel, please see the notes at the bottom of this page, cpanel does not use the standard locations for apache configuration files.<br />
<br />
Finally, load the rules. '''Make sure you specify only those rule files that are appropriate for your system.''' For example:<br />
<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/99_asl_jitp.conf<br />
<br />
'''Warning: You should NOT include all the rules. There are rulesets, documented above, that replace other rulesets and are incompatible with each other.'''<br />
<br />
===== Recommend minimum rulesets =====<br />
<br />
====== apache ======<br />
<br />
The recommended ''minimum ruleset'' to load is:<br />
<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_0_global.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_antimalware.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/11_asl_adv_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/20_asl_useragents.conf<br />
Include /full/path/to/your/rules/modsecurity.d/30_asl_antispam.conf<br />
Include /full/path/to/your/rules/modsecurity.d/50_asl_rootkits.conf<br />
Include /full/path/to/your/rules/modsecurity.d/60_asl_recons.conf<br />
Include /full/path/to/your/rules/modsecurity.d/61_asl_recons_dlp.conf<br />
Include /full/path/to/your/rules/modsecurity.d/99_asl_jitp.conf<br />
<br />
If you have modsecurity 2.9.0 and up installed, you should also load additional rule files and should use this ruleset:<br />
<br />
Include /full/path/to/your/rules/modsecurity.d/000_asl_threat_intelligence.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_zz_strict.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_0_global.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_z_antievasion.conf<br />
Include /full/path/to/your/rules/modsecurity.d/01_asl_content.conf<br />
Include /full/path/to/your/rules/modsecurity.d/01_asl_content_z.conf<br />
Include /full/path/to/your/rules/modsecurity.d/03_asl_dos.conf<br />
Include /full/path/to/your/rules/modsecurity.d/09_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_antimalware.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/11_asl_adv_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/11_asl_data_loss.conf<br />
Include /full/path/to/your/rules/modsecurity.d/12_asl_adv_xss_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/20_asl_useragents.conf<br />
Include /full/path/to/your/rules/modsecurity.d/30_asl_antispam.conf<br />
Include /full/path/to/your/rules/modsecurity.d/50_asl_rootkits.conf<br />
Include /full/path/to/your/rules/modsecurity.d/51_asl_rootkits.conf<br />
Include /full/path/to/your/rules/modsecurity.d/60_asl_recons.conf<br />
Include /full/path/to/your/rules/modsecurity.d/61_asl_recons_dlp.conf<br />
Include /full/path/to/your/rules/modsecurity.d/99_asl_jitp.conf<br />
Include /full/path/to/your/rules/modsecurity.d/98_asl_adv_redactor.conf<br />
<br />
If you have a [[Local DNS resolver]] setup and properly configured on your system, and you are using modsecurity 2.9.0 and up we also recommend these additional rulesets:<br />
<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_z_searchengines.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_z_aa_threat_intelligence.conf<br />
Include /full/path/to/your/rules/modsecurity.d/99_asl_zzzz_threat_intelligence.conf<br />
<br />
Note: Some of these rulesets are designed to work with advanced security management systems such as [[ASL]] and may not work completely without an advanced management system.<br />
<br />
====== nginx ======<br />
<br />
The same rulesets as apache will work with nginx.<br />
<br />
====== litespeed ======<br />
<br />
[[Litespeed]] has a proprietary implementation of mod_security. It does not support all the features that mod_security with apache, IIS and nginx does. Therefore, you can not use all the rulesets with Litespeed, as Litespeed does not support those features of mod_security. The following rulesets are recommended with Litespeed:<br />
<br />
The recommended ''minimum ruleset'' to load is:<br />
<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_0_global.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_antimalware.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/11_asl_adv_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/20_asl_useragents.conf<br />
Include /full/path/to/your/rules/modsecurity.d/30_asl_antispam.conf<br />
Include /full/path/to/your/rules/modsecurity.d/50_asl_rootkits.conf<br />
Include /full/path/to/your/rules/modsecurity.d/60_asl_recons.conf<br />
Include /full/path/to/your/rules/modsecurity.d/61_asl_recons_dlp.conf<br />
Include /full/path/to/your/rules/modsecurity.d/99_asl_jitp.conf<br />
<br />
If you require more advanced protection, you should also load additional rule files and should use this ruleset:<br />
<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_zz_strict.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_x_searchengines.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_y_searchengines.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_0_global.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_z_antievasion.conf<br />
Include /full/path/to/your/rules/modsecurity.d/01_asl_content.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_zz_strict.conf<br />
Include /full/path/to/your/rules/modsecurity.d/03_asl_dos.conf<br />
Include /full/path/to/your/rules/modsecurity.d/09_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_antimalware.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/11_asl_adv_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/11_asl_data_loss.conf<br />
Include /full/path/to/your/rules/modsecurity.d/12_asl_adv_xss_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/20_asl_useragents.conf<br />
Include /full/path/to/your/rules/modsecurity.d/30_asl_antispam.conf<br />
Include /full/path/to/your/rules/modsecurity.d/50_asl_rootkits.conf<br />
Include /full/path/to/your/rules/modsecurity.d/51_asl_rootkits.conf<br />
Include /full/path/to/your/rules/modsecurity.d/60_asl_recons.conf<br />
Include /full/path/to/your/rules/modsecurity.d/61_asl_recons_dlp.conf<br />
Include /full/path/to/your/rules/modsecurity.d/99_asl_jitp.conf<br />
<br />
<br />
Note: [[Litespeed]] does not support content inspection (outbound rules), or lua based rules. Therefore, the following rulesets Litespeed does not support, and loading them will have no effect on the system:<br />
<br />
<br />
00_asl_z_searchengines.conf<br />
00_asl_z_aa_threat_intelligence.conf<br />
12_asl_brute.conf<br />
98_asl_adv_redactor.conf<br />
99_asl_zzzz_threat_intelligence.conf<br />
<br />
Note: Some of these rulesets are designed to work with advanced security management systems such as [[ASL]] and may not work completely without an advanced management system.<br />
<br />
===== Notes on Scanner ruleset =====<br />
<br />
NOTE: If you use this file:<br />
<br />
05_asl_scanner.conf<br />
<br />
Or this file:<br />
<br />
99_asl_scanner.conf<br />
<br />
[[ASL]] includes malware upload scanning, rules subscriptions do not.<br />
<br />
If you wish to use this ruleset, and you are not using [[ASL]], then you will need to create a script to pass the files to clamd and read the result. Make sure you have clamd installed and configured correctly to list on a TCP port, or if you use a socket, make sure apache can read/write to this socket or as a last resort, run clamd as root. Using this file will force all web uploads on your system to go thru clamav to look for malware, viruses, etc. If you dont need that, then you can leave this config file out. <br />
<br />
Real time malware upload protection is included in [[ASL]] and uses a faster method than the older style modsecurity scripting method above. So if you need realtime malware upload protection (for web, FTP, or even realtime), then upgrade to [[ASL]] which includes highspeed malware upload protection, full support, automatic and hassle free installation. ASL also protects against any form of upload of malware, including HTTP, HTTPS, SSH and FTP uploads and includes our real-time malware detection and prevention system which will detect and block any malicious software running on the system in realtime. This is just one of the many many features of [[ASL]].<br />
<br />
==== Step 10: Test your web server ====<br />
===== Test nginx =====<br />
<br />
nginx -t -c <NGINX_CONFIG_FILE><br />
<br />
Where NGINX_CONFIG_FILE is your nginx.conf file.<br />
<br />
===== Test Apache =====<br />
<br />
Before restarting apache we recommend you test your configuration by running apache with the "configtest" command. On a standard system you can do this by calling your apache init file like this:<br />
<br />
/etc/init.d/httpd configtest<br />
<br />
If you get errors, check to see that you don't have some extraneous configuration files installed.<br />
<br />
===== Testing to see if the rules are loaded =====<br />
'''<br />
Step 1)''' (for non [[ASL]] systems)<br />
<br />
Make sure you have the rules installed exactly as described on this page. This test may not work if you have not followed these instructions. (If you used ASL to setup your WAF, and you have not installed any third party tools that configure, install or manage modsecurity then your rules are installed correctly and you do not need to review the instructions on this page. If you have manually altered your modsecurity configuration then you will need to review this entire article. Manual modifications of ASL modsecurity configurations are not supported.)<br />
<br />
'''Step 2) Make sure all rules are enabled'''<br />
<br />
'''Ensure that you do not have any of our rules disabled.''' This test assumes you do not have any rules disabled, that you are not whitelisting the source of this test and that your have the Atomicorp rules loaded.<br />
<br />
'''Step 3) Test from a non-whitelisted system''' <br />
<br />
Make sure you do not have the system you are performing this from is whitelisted<br />
<br />
For example, cpanels default modsecurity configuration will configure modsecurity to ignore everything from 127.0.0.1, or from the system itself. So if you perform the test above from the server itself, and you have not removed this cpanel whitelist, then this test will not work.<br />
<br />
'''Step 4) Run the test'''<br />
<br />
On the system where the rules are installed run this command (this assumes you have wget installed, '''127.0.0.1 is NOT whitelisted''' and a web server is listening on 127.0.0.1):<br />
<br />
''wget http://localhost/foo.php?foo=http://www.example.com''<br />
<br />
If the test worked, should get a 403 error if the rules are loaded, which will look similar to this:<br />
<br />
<pre><br />
--2010-05-27 20:12:25-- http://localhost/foo.php?foo=http://www.example.com<br />
Resolving localhost... 127.0.0.1<br />
Connecting to localhost|127.0.0.1|:80... connected.<br />
HTTP request sent, awaiting response... 403 Forbidden<br />
2010-05-27 20:12:25 ERROR 403: Forbidden.<br />
</pre><br />
<br />
If you do not get a 403 error, the test did not work.<br />
<br />
You can also use your browser to test the rules by going to a URL similar to this:<br />
<br />
http://YOUR_HOST/foo.php?foo=http://www.example.com<br />
<br />
Remember to replace YOUR_HOST with the actual HOSTNAME or IP of the server.<br />
<br />
If the rules are properly loaded, you should get a 403 error, if you do not get a 403 error, the rules are not loaded correctly and you need to check your configuration to ensure that you have followed the instructions above correctly.<br />
<br />
If you get a 403 error from the command line and a 404 error from the browser, check to make sure the computer you are testing the browser from is not whitelisted on the server.<br />
<br />
Note: If you do not have wget installed, then you will need to install it or a similar tool to run this test from a Linux or UNIX based system. If you are using Windows, you can use a similar tool or your browser.<br />
<br />
====== What to do if you do not get a 403 error ======<br />
<br />
If you get a different error, such as a 404 error or a 5xx series error check your configuration. The following are common causes of this:<br />
<br />
'''1) You have rules disabled'''<br />
<br />
Make sure you do not have any rules disabled.<br />
<br />
'''2) Your IP is whitelisted'''<br />
<br />
There is a rule whitelisting the system you are conducting this test from. Whitelisting tells the WAF to ignore everything from that source.<br />
<br />
For example, cpanels default modsecurity configuration will configure modsecurity to ignore everything from 127.0.0.1, or from the system itself. So if you perform the test above from the server itself, and you have not removed this cpanel whitelist, then you will not get a 403 error. More than likely you will get a 404 error. The solution is to remove any whitelists from your system.<br />
<br />
Note: Whitelisting the server itself can open a hole in your security. You should not whitelist localhost or the servers own IP address, particularly if you have multi users on the system. This is both unnecessary, and doing so will allow any users on the system to carry out attacks on other domains on the system unimpeded. Make sure you do not have any rules like that, this opens a very large hole in your system.<br />
<br />
'''3) Local error message is different'''<br />
<br />
You or someone else may have configured your system to use a different error message. Check your configuration, and make sure it exactly matches the ones on this wiki. IF you are using kind of plugin that does not return a 403 when a connection is rejected, and you must use this, then you will need to manually check your mod_security logs to see if your test is being rejected by modsecurity. If it is, then your rules are working correctly and you can ignore the error code.<br />
<br />
'''4) Third party addons''' <br />
<br />
You have third party rules or addons installed with your modsecurity configuration that are changing the responses. Remove all third party addons, and make sure your configuration exactly matches the instructions on this page<br />
<br />
'''5) Insecurely configured apache'''<br />
<br />
Some control panels are known to disable modsecurity on localhost, and on the systems IP addresses. These highly insecure control panels essentially disable modsecurity if an attacker connects to the systems IP address. This of course leaves your system wide open to attack, and if you are unlucky enough to be using one of these control panels we recommend you report this to your control panel vendor as a serious vulnerability. If they are unwilling to fix it, then we recommend you find a more security concious control panel vendor.<br />
<br />
Example:<br />
<br />
We have seen some control panels that configure modsecurity to be disabled in the /etc/httpd/conf/httpd.conf file for all the local IPs on the system. <br />
<br />
<pre><br />
<VirtualHost <LOCAL IP ADDRESS>:80 127.0.0.1:80 *><br />
<IfModule mod_security2.c><br />
SecRuleEngine Off<br />
</IfModule><br />
</pre><br />
<br />
If your control panel has this vulnerability, you can remove this, but its very possible the control panel will simply open this hole in your system again. We highly recommend you report this vulnerability to your control panel vendor, and if they are unwilling to fix this vulnerability that you find a more security concious control panel vendor.<br />
<br />
'''6) You arent loading the rules'''<br />
<br />
This is common with custom configurations. Check to make sure your webserver is configured to load the rules. Keep mind that modsecurity will still generate generic messages even though the rules are not loaded. For example, if all you see are events like this:<br />
<br />
<pre><br />
--70c19f31-A--<br />
[01/Jan/2013:11:19:13 --0300] roiKIi6Ni3EKFZSKpSUs2iEb 1.2.3.4 34978 5.6.7.8 80<br />
--70c19f31-B--<br />
HEAD / HTTP/1.1<br />
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) <br />
<br />
Accept: */*<br />
<br />
--70c19f31-F--<br />
HTTP/1.1 403 Forbidden<br />
X-Powered-By: PHP/5.4.20<br />
Expires: Thu, 19 Jan 2001 02:12:00 GMT<br />
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0<br />
Pragma: no-cache<br />
Connection: close<br />
Content-Type: text/html<br />
<br />
--70c19f31-H--<br />
Stopwatch: 1383338363503919 358184 (- - -)<br />
Stopwatch2: 1383338363503919 358184; combined=2144, p1=37, p2=2053, p3=0, p4=0, p5=53, sr=0, sw=1, l=0, gc=0<br />
Producer: ModSecurity for Apache/2.7.5 ( http://www.modsecurity.org/).<br />
Server: Apache<br />
Engine-Mode: "ENABLED"<br />
<br />
--70c19f31-Z--<br />
</pre><br />
<br />
In this example, no rule is being triggered, but modsecurity is logging a basic 403 error. It will do this if the modsecurity configuration is loaded, but not the rules. So if you see this happening on your system, and you have ruled out all other issues in this list, it means your custom configuration isnt loading the rules.<br />
<br />
[[ASL]] will automatically configure modsecurity correctly. So if you are having problems configuring modsecurity yourself, then we recommend you use [[ASL]] to setup modsecurity for you.<br />
<br />
=== Windows ===<br />
<br />
Please see the [[modsecurity iis]] page.<br />
<br />
== Automated rules updates ==<br />
<br />
Please see the [[ASL]] page for installation instructions.<br />
<br />
= Tuning the Rules/Disabling Rules =<br />
<br />
== Disabling Rules ==<br />
<br />
See the [[mod_security]] page for details.<br />
<br />
== Tuning the Rules ==<br />
<br />
See the [[mod_security]] page for details.<br />
<br />
== Troubleshoot the Rules ==<br />
<br />
See the [[Atomicorp WAF Rules Troubleshooting]] page for details.<br />
<br />
== Reporting False Positives ==<br />
<br />
See the [[Reporting False Positives]] page for details.<br />
<br />
= Notes =<br />
<br />
== Special notes for CPANEL users not using ASL ==<br />
<br />
The Atomicorp Modsecurity rules work great with Cpanel, right out of the box. To use them with Cpanel either install [[ASL]], or manually install modsecurity and make a few changes to the mod_security configuration that comes with cpanel and then you are all set!<br />
<br />
=== Installing modsecurity in cpanel ===<br />
<br />
'''Option 1) Simplest and most powerful solution'''<br />
<br />
Install [[ASL]]. This will install modsecurity, configure it and will install the rule and event management GUI available in [[ASL]]<br />
<br />
Option 2) Install just the rules<br />
<br />
=== Manually Configuring modsecurity with cpanel ===<br />
<br />
These are additional considerations for installing modsecurity with cpanel. Please read this entire page, as well as this section if you are installing modsecurity with cpanel (even if you already have modsecurity install with cpanel).<br />
<br />
We recommend if you are using cPanel that you follow this advice, as cpanel includes a very minimal configuration for modsecurity that does not include all of the required and optimal settings documented here. Our settings will make your server faster, and more importantly more secure. If you use mod_security with Cpanel you must add these additional settings to experience the full feature set of mod_security.<br />
<br />
==== Step 1 ====<br />
<br />
Make sure you have read this entire document and have setup all the require directories details above.<br />
<br />
==== Step 2: Configure directory permissions ====<br />
<br />
Cpanel also does not run apache as a standard user (such as apache) but as the older non-privileged user "nobody". You will need to ensure then that the work directories that mod_security uses are owned by the user that Cpanel runs apache as. To find this out you can run this command as root:<br />
<br />
ps auxwww | grep httpd<br />
<br />
root 20594 86.8 3.1 255148 181232 ? Ss 11:39 0:04 /usr/local/apache/bin/httpd -k restart<br />
root 20611 0.0 3.1 255060 179596 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20612 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20613 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20614 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20615 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20616 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
<br />
In this example from a Centos system running Cpanel the user is "nobody", so you would want to use these commands to configure the modsecurity work directories for a system where apache is running as "nobody": <br />
<br />
mkdir /var/asl<br />
mkdir /var/asl/data/<br />
mkdir /var/asl/data/msa<br />
mkdir /var/asl/data/audit<br />
mkdir /var/asl/data/suspicious<br />
chown nobody.nobody /var/asl/data/msa<br />
chown nobody.nobody /var/asl/data/audit<br />
chown nobody.nobody /var/asl/data/suspicious<br />
chmod o-rx -R /var/asl/data/*<br />
chmod ug+rwx -R /var/asl/data/*<br />
<br />
==== Step 3: Install modsecurity ====<br />
<br />
Please see the current minimum version required at the link below:<br />
<br />
https://www.atomicorp.com/wiki/index.php/Atomic_ModSecurity_Rules#Minimum_Version_of_Modsecurity_Required_to_use_the_rules<br />
<br />
==== Step 4: Configure cpanel ====<br />
<br />
Make a small change to the cpanel modsecurity configuration. A typical cpanel modsec2.conf configuration file looks like this:<br />
<br />
LoadFile /opt/xml2/lib/libxml2.so<br />
LoadFile /opt/lua/lib/liblua.so<br />
LoadModule security2_module modules/mod_security2.so<br />
<IfModule mod_security2.c><br />
SecRuleEngine On<br />
# See http://www.modsecurity.org/documentation/ModSecurity-Migration-Matrix.pdf<br />
# "Add the rules that will do exactly the same as the directives"<br />
# SecFilterCheckURLEncoding On<br />
# SecFilterForceByteRange 0 255<br />
SecAuditEngine RelevantOnly<br />
SecAuditLog logs/modsec_audit.log<br />
SecDebugLog logs/modsec_debug_log<br />
SecDebugLogLevel 0<br />
SecDefaultAction "phase:2,deny,log,status:403"<br />
Include "/usr/local/apache/conf/modsec2.user.conf"<br />
</IfModule><br />
<br />
Because cpanel will overwrite this configuration, you need to modify your user configuration file. You will want to setup your user configuration file (/usr/local/apache/conf/modsec2.user.conf) as in the example below. This is the recommended configuration and the '''minimum''' recommended rule sets that are designed to work with cpanel without [[ASL]] installed. Please be sure to read this entire page for information about additional rules that you may also want to use with cpanel.<br />
<br />
SecRequestBodyAccess On<br />
SecAuditLogType Concurrent<br />
SecResponseBodyAccess On<br />
SecResponseBodyMimeType (null) text/html text/plain text/xml<br />
SecResponseBodyLimit 2621440<br />
SecAuditLogRelevantStatus "^(?:5|4(?!04))"<br />
SecServerSignature Apache<br />
SecUploadDir /var/asl/data/suspicious<br />
SecUploadKeepFiles Off<br />
SecAuditLogParts ABIFHZ<br />
SecArgumentSeparator "&"<br />
SecCookieFormat 0<br />
SecRequestBodyInMemoryLimit 131072<br />
SecDataDir /var/asl/data/msa<br />
SecTmpDir /tmp<br />
SecAuditLogStorageDir /var/asl/data/audit<br />
SecResponseBodyLimitAction ProcessPartial<br />
<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_z_antievasion.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_zz_strict.conf<br />
Include /full/path/to/your/rules/modsecurity.d/09_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_antimalware.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/11_asl_adv_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/20_asl_useragents.conf<br />
Include /full/path/to/your/rules/modsecurity.d/30_asl_antispam.conf<br />
Include /full/path/to/your/rules/modsecurity.d/50_asl_rootkits.conf<br />
Include /full/path/to/your/rules/modsecurity.d/60_asl_recons.conf<br />
Include /full/path/to/your/rules/modsecurity.d/61_asl_recons_dlp.conf<br />
Include /full/path/to/your/rules/modsecurity.d/99_asl_jitp.conf<br />
<br />
If you want to load just some of the rules, make sure you specify only those rule files. The default list above is the recommended and supported rulesets with cpanel. Do not use the other asl rulesets with cpanel, those other rules either use other apache modules (such as mod_sed) or ASL specific features that require [[ASL]].<br />
<br />
'''Make sure you have all of the settings on this page to use modsecurity with cpanel correctly, failing to do that will make it impossible for us to support you and modsecurity will not as quickly or correctly exposing your system to attack and slowing it down.'''<br />
<br />
==== Step 5: Install mod_uniqueid ====<br />
<br />
Cpanel users will need to manually verify that the mod_unique_id module is loaded by cpanel's apache. It should be loaded by default, but check your cpanel configuration to be sure.<br />
<br />
==== Step 6: Install the rules ====<br />
<br />
===== Automatic Rule Updater =====<br />
<br />
[[aum]] -u<br />
<br />
===== Manually install the rules =====<br />
<br />
See the [https://www.atomicorp.com/wiki/index.php/Atomic_ModSecurity_Rules#Step_8:_Download_the_ModSecurity_Rules Downloading rules] section above.<br />
<br />
==== Step 7: Restart Apache ====<br />
<br />
Restart apache, enjoy your new secure web server!<br />
<br />
==== Optional Steps ====<br />
<br />
===== Malware Scanner =====<br />
<br />
The malware scanner is included in [[ASL]], it is not included in the rules or rule subscriptions. Therefore, if you use this file:<br />
<br />
05_asl_scanner.conf<br />
<br />
Or this:<br />
<br />
99_asl_scanner.conf<br />
<br />
You will need to include your own scanner, and will need to make sure you have clamd installed and configured correctly to listen on a TCP port, or if you use a socket, make sure apache can read/write to this socket or as a last resort, run clamd as root. Using this file forces all web uploads on your system to go thru clamav to look for malware, viruses, etc. If you dont need that, then you can leave this config file out.<br />
<br />
<br />
==== Cpanel Error Messages ====<br />
<br />
==== modsecparse.pl ====<br />
<br />
'''This is a third party tool not provided by, or supported by Atomicorp.''' If you use this tool, it apparently does not work with the new fast concurrent logging system in modsecurity. The concurrent logging system is much faster, will speed up apache and is less resource intensive that the older serial method. <br />
<br />
However, if you use this tool you must use the slower serial logging method, as it does not support the faster concurrent method. To use this tool, change the SecAuditLogType setting from "Concurrent" to "Serial":<br />
<br />
SecAuditLogType Serial<br />
<br />
'''Keep in mind that this logging method is much slower, may slow down apache and is not supported.''' This performance impact is not caused by the rules. Serial logging is much slower than concurrent logging. Therefore we do not recommend you use this logging method or any tools that require it. There are lots of modsecurity log readers that can use the concurrent logging method, such as [[ASL]] and we encourage you to explore using one of those modern tools instead.<br />
<br />
==== Serial logging ====<br />
<br />
===== Discussion =====<br />
<br />
Serial logging is the older slower depreacted logging method modsecurity original used many years ago. This logging method would log the entire event in a single file. As a result, it would slow apache down because each event needed to wait for the previous event to finish writing before it could write to the log file. Events stack up and slow apache down. This incurs a significant performance penalty on apache, and of course a better method was devised for modsecurity to address this performance issue. The solution is the concurrent logging method. This generates a unique event file for each log event, logging the events data to that file instead of trying to jam tons of data into a single file, and thereby slowing down apache. All modern modsecurity log viewing tools support the concurrent method.<br />
<br />
The concurrent logging system is much faster, will speed up apache and is less resource intensive that the older serial method. This method is highly recommended over the slow serial logging method.<br />
<br />
===== Configuration =====<br />
<br />
====== aum ======<br />
<br />
If you want to use the old slower serial logging method, and you are using aum, change this setting in /etc/asl/config:<br />
<br />
MODSEC_LOGTYPE="Concurrent"<br />
<br />
<br />
To:<br />
<br />
MODSEC_LOGTYPE="Serial"<br />
<br />
<br />
And then run:<br />
<br />
aum -uf<br />
<br />
====== non-aum systems ======<br />
<br />
If you want to use the old slower serial logging method change the SecAuditLogType setting from "Concurrent" to "Serial":<br />
<br />
SecAuditLogType Serial<br />
<br />
'''Warning: Serial logging is much slower than concurrent logging and will slow down apache.''' Any performance impact is not caused by the rules. <br />
<br />
Therefore we do not recommend you use this logging method or any tools that require it. There are lots of modsecurity log readers that can use the fast concurrent logging method, such as [[ASL]] and we encourage you to explore using one of those modern tools instead of a tool that requires the slower and performance degrading serial logging method.<br />
<br />
If you change your system to the slower Serial method, you may also want to change the logfile name you are using for your modsecurity logs. You can do that by changing this option in your configuration:<br />
<br />
SecAuditLog logs/audit_log</div>Mshinnhttps://wiki.atomicorp.com/wiki/index.php/Atomic_ModSecurity_RulesAtomic ModSecurity Rules2022-05-06T17:32:54Z<p>Mshinn: /* Step 2: Set up and configure directories */</p>
<hr />
<div>[[Atomic Secured Linux]] includes modsecurity, and the Real Time GotRoot.com/Atomicorp Modsecurity Rules. These docs are for users that do not have [[ASL]].<br />
<br />
'''ASL will install and configure modsecurity, and provides a powerful and easy use to GUI to manage all of this for you. If you don't have ASL, [https://www.atomicorp.com/amember/cart/index/index?c=1 upgrade to ASL today!]'''<br />
<br />
= '''About the rules''' =<br />
<br />
The gotroot.com rules are written by us - we are the gotroot guys. Same great rules, same team, ten years of writing modsecurity rules and still going strong! GotRoot is our Information Assurance lab and [http://www.atomicorp.com Atomicorp] is the product arm of [http://www.progllc.com Prometheus Global] (the parent company for both). So when you get the gotroot.com rules from atomicorp.com or gotroot.com - you're getting the same rules from the same people that created, write and maintain them. In the future we will be merging the gotroot.com, atomicrocketturtle and atomicorp websites into the atomicorp.com website.<br />
<br />
We publish two versions of the rules:<br />
<br />
'''RealTime Rules:''' The latest and greatest version of the rules, with all the performance enhancements, new security features and bug fixes released by us on a daily basis. These rules are fully supported and are recommended for production use.<br />
<br />
'''Free/Delayed Rules:''' A delayed subset of the Advanced rules.<br />
<br />
Installation of the rules assumes a certain level of comfort with configuring apache. If you are not comfortable with configuring apache, you should contact someone that is, or use our [[Atomic Secured Linux]] product which does this automatically for you, and does not require you to configure apache.<br />
<br />
== Getting the rules ==<br />
<br />
[https://www.atomicorp.com/amember/cart/index/index?c=6 Click here] to get the Atomicorp ModSecurity Rules.<br />
<br />
== '''Atomic ModSecurity Rules Frequently Asked Questions''' ==<br />
<br />
Please see the [[Atomic ModSecurity Rules FAQ]] wiki page.<br />
<br />
== '''Real Time Rule Support''' ==<br />
<br />
If you have a subscription to the real time rules, you can request email support by sending an email to:<br />
<br />
support@atomicorp.com<br />
<br />
The Customer Support Forums are located here:<br />
<br />
[http://www.atomicorp.com/forums Customer Support Forums]<br />
<br />
And the Custom Support Portal is located here (you can submit bug reports and open cases through the portal):<br />
<br />
[https://www.atomicorp.com/portal Customer Support Portal]<br />
<br />
== '''Licenses''' ==<br />
<br />
The Real Time Atomic ModSecurity Rules are licensed by the server. You can order licenses from the online store at the link below:<br />
<br />
[https://www.atomicorp.com/amember/cart/index/index?c=6 Online Store]<br />
<br />
If you require additional licenses please log into the [https://www.atomicorp.com/support/license-manager.html AtomiCorp License Manager]. You can add additional systems there, you can control your payment methods and you can also sign up to become an affiliate.<br />
<br />
=== License Terms and Conditions ===<br />
<br />
Purchase of an Atomicorp ModSecurity rule license entitles the purchaser to access and download from the Atomicorp Repository to a single IP address within the time period of the license. A separate license is required for each dedicated server/host or VPS that the rule set is installed upon or is protecting.<br />
<br />
Atomicorp ModSecurity rules installed upon a Reverse Proxy WAF appliance/server requires a separate license. Please contact Atomicorp support for details.<br />
<br />
The rule set cannot be copied, mirrored, or reproduced under protection of US and International copyright laws.<br />
<br />
Use of the rule set is limited to the time period of the license. If the license period of a rule set expires, it must must removed from its installed server and no longer used. Atomicorp reserves the right to track and enforce license compliance of the Atomicorp Modsecurity rule sets.<br />
<br />
Agreement to these terms and conditions and the Atomicorp [https://atomicorp.com/eula.html End User License Agreement] is required to download and use the Atomicorp ModSecurity rules.<br />
<br />
== Important Information about the Rules ==<br />
<br />
=== Minimum Version of Modsecurity Required to use the rules ===<br />
<br />
The rules are supported with the following versions of Modsecurity:<br />
<br />
<br />
* 2.9.3<br />
<br />
We recommend customers use our modsecurity builds, as they are tested to ensure all features work correctly. Third party builds may not include the correct libraries, may cause problems with your web server, including crashes and may disable or incorrectly enable features in modsecurity that can cause unpredictable behavior or failure of rules to process correctly.<br />
<br />
If you need a solution to keep the rules and modsecurity up to date and in sync with your version of modsecurity automatically, please use [[aum]] or [[ASL]] which will do this for you automatically.<br />
<br />
==== What versions of modsecurity do the rules work with ====<br />
<br />
They work with both modsecurity 2.9.x, and modsecurity 3.x.<br />
<br />
=== What does each rule family do? ===<br />
<br />
Please see the [[modsecurity_rule_families]] documents.<br />
<br />
= Installation =<br />
<br />
== Easy One Step Installation ==<br />
<br />
<br />
<br />
===== Full Management Suite =====<br />
<br />
Install [[ASL]]. This installs everything: modsecurity, all the rules, the GUI, rule manager and all ASL components, plus it includes the subscription to the real time rules.<br />
<br />
ASL will automatically download and keep your rules up to date, and will ensure that modsecurity stays up to date so your system can support the latest rules. ASL also provides you with a full security management suite, which will allow you to manage, edit and configure your rules through a web console. It will also protect you from uploaded malware, brute force attacks, DOS attacks, rootkits and many other threats that a WAF can not protect you from.<br />
<br />
A full list of ASLs features is available at the URL below:<br />
<br />
https://www.atomicorp.com/products/asl.html<br />
<br />
===== Just a downloader =====<br />
<br />
We also provide an automated rule updater and modsecurity installation tool, called [[aum]]. You can read more about it on the [[aum]] page. You can install it by running these commands as root:<br />
<br />
Step 1) Install [[aum]]<br />
<br />
''wget -q -O - https://updates.atomicorp.com/installers/aum |bash''<br />
<br />
Step 2) Configure [[aum]]<br />
<br />
''aum configure''<br />
<br />
Step 3) Tell [[aum]] to install the rules<br />
<br />
''aum upgrade''<br />
<br />
You can read more about aum on the [[aum]] documentation page.<br />
<br />
Note: This capability is included in [[ASL]]. ASL users do not need to install aum, its already included.<br />
<br />
== (Optional) Do It Yourself Installation ==<br />
<br />
Note: A manual installation is not necessary if you have [[ASL]] installed. ASL will configure and install modsecurity, and the rules, automatically. This is also not necessary if you are using our new AUM software to handle rule download and installation.<br />
<br />
=== Linux ===<br />
<br />
==== Step 1: Download ModSecurity ====<br />
<br />
Binaries:<br />
<br />
[http://updates.atomicorp.com/channels/atomic/ Install modsecurity from the Atomicorp software repository]<br />
<br />
Source Code:<br />
<br />
[http://updates.atomicorp.com/channels/atomic/ Install modsecurity from the Atomicorp software repository]<br />
<br />
Please note that the rules are only supported with the version of modsecurity [http://wiki.atomicorp.com/wiki/index.php/Atomic_ModSecurity_Rules#Minimum_Version_of_Modsecurity_Required_to_use_the_rules identified in this section of the wiki.]<br />
<br />
Note: Please contact us before using a third party or source build of modsecurity. Its critical modsecurity be built correctly to work with the rules.<br />
<br />
==== Step 2: Set up and configure directories ====<br />
<br />
Create the following directories as root:<br />
<br />
mkdir /etc/httpd/modsecurity.d<br />
mkdir /var/asl<br />
mkdir /var/asl/tmp<br />
mkdir /var/asl/data<br />
mkdir /var/asl/data/msa<br />
mkdir /var/asl/data/audit<br />
mkdir /var/asl/data/suspicious<br />
<br />
==== Step 3: Set permissions for directories ====<br />
<br />
Set the following permissions on the directories you just created. In this example these directories are set to be owned by "apache" and the group "apache", which is standard on a normal Centos or RHEL system. However some control panels configure apache to run as a different user, such as nobody, or http. <br />
<br />
To determine what use this is, check your system to see what user your webserver uses. You can use this command to find the user:<br />
<br />
ps auxwww | grep httpd<br />
<br />
The output will look similar to this:<br />
<br />
(RHEL/Centos example with or without Plesk)<br />
<br />
root 26755 0.0 4.3 430752 86432 ? Ss 04:30 0:01 /usr/sbin/httpd<br />
'''apache''' 26908 0.0 3.7 300564 75076 ? S 04:30 0:00 /usr/sbin/httpd<br />
'''apache''' 26909 0.1 5.5 495812 112084 ? S 04:30 0:37 /usr/sbin/httpd<br />
'''apache''' 26910 0.0 5.3 495424 106672 ? S 04:30 0:23 /usr/sbin/httpd<br />
'''apache''' 26911 0.1 5.7 495892 114368 ? S 04:30 0:57 /usr/sbin/httpd<br />
'''apache''' 26912 0.1 5.7 496056 114440 ? S 04:30 0:52 /usr/sbin/httpd<br />
'''apache''' 26913 0.1 5.5 496604 110692 ? S 04:30 0:57 /usr/sbin/httpd<br />
'''apache''' 26914 0.0 5.7 499324 116236 ? S 04:30 0:16 /usr/sbin/httpd<br />
'''apache''' 26915 0.2 5.5 493600 112192 ? S 04:30 1:09 /usr/sbin/httpd<br />
'''apache''' 26916 0.1 6.4 513760 129992 ? S 04:30 0:30 /usr/sbin/httpd<br />
<br />
In this example the user in bold is "apache" (this may be different for your system). This is the user you will want to set the directory permissions to (as in the example below):<br />
<br />
chown apache.apache /var/asl/data/msa<br />
chown apache.apache /var/asl/data/audit<br />
chown apache.apache /var/asl/data/suspicious<br />
chmod o-rx -R /var/asl/data/*<br />
chmod ug+rwx -R /var/asl/data/*<br />
<br />
(RHEL/Centos example with Cpanel)<br />
<br />
root 20594 86.8 3.1 255148 181232 ? Ss 11:39 0:04 /usr/local/apache/bin/httpd -k restart<br />
root 20611 0.0 3.1 255060 179596 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20612 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20613 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20614 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20615 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20616 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
<br />
In this example from a Centos system running Cpanel the user is "nobody", so you would want to use these commands:<br />
<br />
chown nobody.nobody /var/asl/data/msa<br />
chown nobody.nobody /var/asl/data/audit<br />
chown nobody.nobody /var/asl/data/suspicious<br />
chmod o-rx -R /var/asl/data/*<br />
chmod ug+rwx -R /var/asl/data/*<br />
<br />
==== Step 4: (Optional) Create rule updater directories ====<br />
These directories must as be created if you use optional rules updater. Create these directories as root and they only need to be accessed by root:<br />
<br />
mkdir /var/asl/updates<br />
mkdir /var/asl/rules/<br />
mkdir /var/asl/rules/clamav<br />
<br />
==== Step 5: Create the whitelist file ====<br />
<br />
Create this file:<br />
<br />
touch /etc/asl/whitelist<br />
<br />
This file contains a list of IPs you want to exclude from ALL rules. That means those IPs can do anything to your system - so be very very careful about what IPs you add to this list. This is a dangerous thing to do. The format of the file is a single IP, per line. <br />
<br />
Cpanel users should skip to the notes at the bottom of this page for special additional actions for cpanel systems. All other users should continue with these instructions.<br />
<br />
==== Step 6: Configure your webserver ====<br />
<br />
===== nginx =====<br />
<br />
===== Step 6a: configure nginx to load modsecurity =====<br />
<br />
====== nginx proxying to a backend ======<br />
<br />
If you are using nginx as a frontend to another webserver, then add the following directives to your nginx.conf file.<br />
<br />
<pre><br />
location / {<br />
ModSecurityEnabled on;<br />
ModSecurityConfig modsecurity.conf;<br />
proxy_pass http://localhost:8080;<br />
proxy_read_timeout 180s;<br />
}<br />
<br />
</pre><br />
<br />
Change "localhost:8011" to the server you are proxying nginx to, and change 8080 to the portnumber for that server. For example, if you are running apache on port 8088 on localhost the line would be:<br />
<br />
proxy_pass http://localhost:8088;<br />
<br />
====== nginx standalone ======<br />
<br />
If you are only using nginx, and not using it as a frontend to another web server then you want to use this configuration:<br />
<br />
<pre><br />
location / {<br />
ModSecurityEnabled on;<br />
ModSecurityConfig modsecurity.conf;<br />
}<br />
</pre><br />
<br />
===== Apache =====<br />
<br />
===== Step 6a: configure apache to load modsecurity =====<br />
<br />
You then need to tell apache to load modsecurity. Depending on your apache configuration, apache should be configured to include configuration files. If you have a setting like this in your apache config:<br />
<br />
Include conf.d/*.conf<br />
<br />
Then you are setup to load external configuration files. If you do not have this setup, its highly recommend you add this. This installation guide is written for this type of configuration. Loading mod_security occurs by including a modsecurity configuration file in that directory. We recommend you name the name 00_modsecurity.conf to ensure it runs first. Its vitally important that modsecurity load before other modules, otherwise attacks can occur before modsecurity scans them and some attacks can be missed.<br />
<br />
An example 00_modsecurity.conf file that works with our files is included here:<br />
<br />
LoadModule security2_module modules/mod_security2.so<br />
LoadModule unique_id_module modules/mod_unique_id.so<br />
<IfModule mod_security2.c><br />
Include modsecurity.d/tortix_waf.conf<br />
</IfModule><br />
<br />
Install this file in your conf.d directory. On a standard RHEL or Centos system that directory is located here:<br />
<br />
/etc/httpd/conf.d/<br />
<br />
=== Step 7: Configure modsecurity ===<br />
<br />
You then need to configure modsecurity. This is done via the an apache configuration file. In this example, we will create the file "tortix_waf.conf". Here is an example file that works with our rules:<br />
<br />
SecRuleEngine On<br />
SecRequestBodyAccess On<br />
SecResponseBodyAccess On<br />
SecResponseBodyMimeType (null) text/html text/plain text/xml<br />
SecResponseBodyLimit 2621440<br />
SecServerSignature Apache<br />
SecComponentSignature 200911012341<br />
SecUploadDir /var/asl/data/suspicious<br />
SecUploadKeepFiles Off<br />
SecAuditEngine RelevantOnly<br />
SecAuditLogRelevantStatus "^(?:5|4(?!04))"<br />
SecAuditLogType Concurrent<br />
SecAuditLog logs/audit_log<br />
[[SecAuditLogParts]] ABIFHZ<br />
SecArgumentSeparator "&" <br />
SecCookieFormat 0<br />
SecRequestBodyInMemoryLimit 131072<br />
SecDataDir /var/asl/data/msa<br />
SecTmpDir /tmp<br />
SecAuditLogStorageDir /var/asl/data/audit<br />
SecResponseBodyLimitAction ProcessPartial<br />
SecAuditLogDirMode 0770<br />
SecPcreMatchLimit 250000 <br />
SecPcreMatchLimitRecursion 250000<br />
<br />
You will want to install this file in your modsecurity.d directory, which is located here if you follow the instructions above:<br />
<br />
/etc/httpd/modsecurity.d<br />
<br />
==== tortix_waf.conf ====<br />
<br />
You can also download an example version of the modsecurity configuration file from here:<br />
<br />
https://www.atomicorp.com/installer/tortix_waf.conf<br />
<br />
[[ASL]] will automatically generate this file depending on your needs. If you are not using ASL, you will need to modify this configuration file to suit your system and modsecurity requirements.<br />
<br />
==== Step 8: Download the ModSecurity Rules ====<br />
<br />
See the [[Downloading Rules]] page.<br />
<br />
==== Step 9: Install the rules ====<br />
<br />
==== Remove any previous installations of rules ====<br />
<br />
If you have installed our delayed rules, you will need to make sure you have deleted them. You will not want to have any older versions of the rules installed.<br />
<br />
Also, if you have installed any third party modsecurity rules, you will want to make sure they are using rule id's that are assigned to them. The modsecurity project assigns ranges to the rule id's modsecurity uses. Modsecurity requires a unique id for each rule, otherwise you will get an error like this:<br />
<br />
ModSecurity: Found another rule with the same id<br />
<br />
This means either that someone else is using the same rule id's assigned to our ruleset by the modsecurity project (our official range is 300000-399999), or you have loaded our rules twice.<br />
<br />
==== Installation ====<br />
<br />
Download the rules to a temporary directory using your favorite download tool. Extract the rules:<br />
<br />
tar zxvf /var/asl/updates/modsec-200911012341.tar.gz<br />
<br />
Then copy each of the ASL rule files you wish to use into /etc/httpd/modsecurity.d. Do not copy all of the rule files, you will need to select rule files that are appropriate for your system. Or simply use [[aum]] or [[ASL]] to do this for you automatically.<br />
<br />
If you are using cpanel, please see the notes at the bottom of this page, cpanel does not use the standard locations for apache configuration files.<br />
<br />
Finally, load the rules. '''Make sure you specify only those rule files that are appropriate for your system.''' For example:<br />
<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/99_asl_jitp.conf<br />
<br />
'''Warning: You should NOT include all the rules. There are rulesets, documented above, that replace other rulesets and are incompatible with each other.'''<br />
<br />
===== Recommend minimum rulesets =====<br />
<br />
====== apache ======<br />
<br />
The recommended ''minimum ruleset'' to load is:<br />
<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_0_global.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_antimalware.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/11_asl_adv_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/20_asl_useragents.conf<br />
Include /full/path/to/your/rules/modsecurity.d/30_asl_antispam.conf<br />
Include /full/path/to/your/rules/modsecurity.d/50_asl_rootkits.conf<br />
Include /full/path/to/your/rules/modsecurity.d/60_asl_recons.conf<br />
Include /full/path/to/your/rules/modsecurity.d/61_asl_recons_dlp.conf<br />
Include /full/path/to/your/rules/modsecurity.d/99_asl_jitp.conf<br />
<br />
If you have modsecurity 2.9.0 and up installed, you should also load additional rule files and should use this ruleset:<br />
<br />
Include /full/path/to/your/rules/modsecurity.d/000_asl_threat_intelligence.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_zz_strict.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_0_global.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_z_antievasion.conf<br />
Include /full/path/to/your/rules/modsecurity.d/01_asl_content.conf<br />
Include /full/path/to/your/rules/modsecurity.d/01_asl_content_z.conf<br />
Include /full/path/to/your/rules/modsecurity.d/03_asl_dos.conf<br />
Include /full/path/to/your/rules/modsecurity.d/09_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_antimalware.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/11_asl_adv_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/11_asl_data_loss.conf<br />
Include /full/path/to/your/rules/modsecurity.d/12_asl_adv_xss_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/20_asl_useragents.conf<br />
Include /full/path/to/your/rules/modsecurity.d/30_asl_antispam.conf<br />
Include /full/path/to/your/rules/modsecurity.d/50_asl_rootkits.conf<br />
Include /full/path/to/your/rules/modsecurity.d/51_asl_rootkits.conf<br />
Include /full/path/to/your/rules/modsecurity.d/60_asl_recons.conf<br />
Include /full/path/to/your/rules/modsecurity.d/61_asl_recons_dlp.conf<br />
Include /full/path/to/your/rules/modsecurity.d/99_asl_jitp.conf<br />
Include /full/path/to/your/rules/modsecurity.d/98_asl_adv_redactor.conf<br />
<br />
If you have a [[Local DNS resolver]] setup and properly configured on your system, and you are using modsecurity 2.9.0 and up we also recommend these additional rulesets:<br />
<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_z_searchengines.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_z_aa_threat_intelligence.conf<br />
Include /full/path/to/your/rules/modsecurity.d/99_asl_zzzz_threat_intelligence.conf<br />
<br />
Note: Some of these rulesets are designed to work with advanced security management systems such as [[ASL]] and may not work completely without an advanced management system.<br />
<br />
====== nginx ======<br />
<br />
The same rulesets as apache will work with nginx.<br />
<br />
====== litespeed ======<br />
<br />
[[Litespeed]] has a proprietary implementation of mod_security. It does not support all the features that mod_security with apache, IIS and nginx does. Therefore, you can not use all the rulesets with Litespeed, as Litespeed does not support those features of mod_security. The following rulesets are recommended with Litespeed:<br />
<br />
The recommended ''minimum ruleset'' to load is:<br />
<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_0_global.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_antimalware.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/11_asl_adv_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/20_asl_useragents.conf<br />
Include /full/path/to/your/rules/modsecurity.d/30_asl_antispam.conf<br />
Include /full/path/to/your/rules/modsecurity.d/50_asl_rootkits.conf<br />
Include /full/path/to/your/rules/modsecurity.d/60_asl_recons.conf<br />
Include /full/path/to/your/rules/modsecurity.d/61_asl_recons_dlp.conf<br />
Include /full/path/to/your/rules/modsecurity.d/99_asl_jitp.conf<br />
<br />
If you require more advanced protection, you should also load additional rule files and should use this ruleset:<br />
<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_zz_strict.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_x_searchengines.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_y_searchengines.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_0_global.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_z_antievasion.conf<br />
Include /full/path/to/your/rules/modsecurity.d/01_asl_content.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_zz_strict.conf<br />
Include /full/path/to/your/rules/modsecurity.d/03_asl_dos.conf<br />
Include /full/path/to/your/rules/modsecurity.d/09_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_antimalware.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/11_asl_adv_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/11_asl_data_loss.conf<br />
Include /full/path/to/your/rules/modsecurity.d/12_asl_adv_xss_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/20_asl_useragents.conf<br />
Include /full/path/to/your/rules/modsecurity.d/30_asl_antispam.conf<br />
Include /full/path/to/your/rules/modsecurity.d/50_asl_rootkits.conf<br />
Include /full/path/to/your/rules/modsecurity.d/51_asl_rootkits.conf<br />
Include /full/path/to/your/rules/modsecurity.d/60_asl_recons.conf<br />
Include /full/path/to/your/rules/modsecurity.d/61_asl_recons_dlp.conf<br />
Include /full/path/to/your/rules/modsecurity.d/99_asl_jitp.conf<br />
<br />
<br />
Note: [[Litespeed]] does not support content inspection (outbound rules), or lua based rules. Therefore, the following rulesets Litespeed does not support, and loading them will have no effect on the system:<br />
<br />
<br />
00_asl_z_searchengines.conf<br />
00_asl_z_aa_threat_intelligence.conf<br />
12_asl_brute.conf<br />
98_asl_adv_redactor.conf<br />
99_asl_zzzz_threat_intelligence.conf<br />
<br />
Note: Some of these rulesets are designed to work with advanced security management systems such as [[ASL]] and may not work completely without an advanced management system.<br />
<br />
===== Notes on Scanner ruleset =====<br />
<br />
NOTE: If you use this file:<br />
<br />
05_asl_scanner.conf<br />
<br />
Or this file:<br />
<br />
99_asl_scanner.conf<br />
<br />
[[ASL]] includes malware upload scanning, rules subscriptions do not.<br />
<br />
If you wish to use this ruleset, and you are not using [[ASL]], then you will need to create a script to pass the files to clamd and read the result. Make sure you have clamd installed and configured correctly to list on a TCP port, or if you use a socket, make sure apache can read/write to this socket or as a last resort, run clamd as root. Using this file will force all web uploads on your system to go thru clamav to look for malware, viruses, etc. If you dont need that, then you can leave this config file out. <br />
<br />
Real time malware upload protection is included in [[ASL]] and uses a faster method than the older style modsecurity scripting method above. So if you need realtime malware upload protection (for web, FTP, or even realtime), then upgrade to [[ASL]] which includes highspeed malware upload protection, full support, automatic and hassle free installation. ASL also protects against any form of upload of malware, including HTTP, HTTPS, SSH and FTP uploads and includes our real-time malware detection and prevention system which will detect and block any malicious software running on the system in realtime. This is just one of the many many features of [[ASL]].<br />
<br />
==== Step 10: Test your web server ====<br />
===== Test nginx =====<br />
<br />
nginx -t -c <NGINX_CONFIG_FILE><br />
<br />
Where NGINX_CONFIG_FILE is your nginx.conf file.<br />
<br />
===== Test Apache =====<br />
<br />
Before restarting apache we recommend you test your configuration by running apache with the "configtest" command. On a standard system you can do this by calling your apache init file like this:<br />
<br />
/etc/init.d/httpd configtest<br />
<br />
If you get errors, check to see that you don't have some extraneous configuration files installed.<br />
<br />
===== Testing to see if the rules are loaded =====<br />
'''<br />
Step 1)''' (for non [[ASL]] systems)<br />
<br />
Make sure you have the rules installed exactly as described on this page. This test may not work if you have not followed these instructions. (If you used ASL to setup your WAF, and you have not installed any third party tools that configure, install or manage modsecurity then your rules are installed correctly and you do not need to review the instructions on this page. If you have manually altered your modsecurity configuration then you will need to review this entire article. Manual modifications of ASL modsecurity configurations are not supported.)<br />
<br />
'''Step 2) Make sure all rules are enabled'''<br />
<br />
'''Ensure that you do not have any of our rules disabled.''' This test assumes you do not have any rules disabled, that you are not whitelisting the source of this test and that your have the Atomicorp rules loaded.<br />
<br />
'''Step 3) Test from a non-whitelisted system''' <br />
<br />
Make sure you do not have the system you are performing this from is whitelisted<br />
<br />
For example, cpanels default modsecurity configuration will configure modsecurity to ignore everything from 127.0.0.1, or from the system itself. So if you perform the test above from the server itself, and you have not removed this cpanel whitelist, then this test will not work.<br />
<br />
'''Step 4) Run the test'''<br />
<br />
On the system where the rules are installed run this command (this assumes you have wget installed, '''127.0.0.1 is NOT whitelisted''' and a web server is listening on 127.0.0.1):<br />
<br />
''wget http://localhost/foo.php?foo=http://www.example.com''<br />
<br />
If the test worked, should get a 403 error if the rules are loaded, which will look similar to this:<br />
<br />
<pre><br />
--2010-05-27 20:12:25-- http://localhost/foo.php?foo=http://www.example.com<br />
Resolving localhost... 127.0.0.1<br />
Connecting to localhost|127.0.0.1|:80... connected.<br />
HTTP request sent, awaiting response... 403 Forbidden<br />
2010-05-27 20:12:25 ERROR 403: Forbidden.<br />
</pre><br />
<br />
If you do not get a 403 error, the test did not work.<br />
<br />
You can also use your browser to test the rules by going to a URL similar to this:<br />
<br />
http://YOUR_HOST/foo.php?foo=http://www.example.com<br />
<br />
Remember to replace YOUR_HOST with the actual HOSTNAME or IP of the server.<br />
<br />
If the rules are properly loaded, you should get a 403 error, if you do not get a 403 error, the rules are not loaded correctly and you need to check your configuration to ensure that you have followed the instructions above correctly.<br />
<br />
If you get a 403 error from the command line and a 404 error from the browser, check to make sure the computer you are testing the browser from is not whitelisted on the server.<br />
<br />
Note: If you do not have wget installed, then you will need to install it or a similar tool to run this test from a Linux or UNIX based system. If you are using Windows, you can use a similar tool or your browser.<br />
<br />
====== What to do if you do not get a 403 error ======<br />
<br />
If you get a different error, such as a 404 error or a 5xx series error check your configuration. The following are common causes of this:<br />
<br />
'''1) You have rules disabled'''<br />
<br />
Make sure you do not have any rules disabled.<br />
<br />
'''2) Your IP is whitelisted'''<br />
<br />
There is a rule whitelisting the system you are conducting this test from. Whitelisting tells the WAF to ignore everything from that source.<br />
<br />
For example, cpanels default modsecurity configuration will configure modsecurity to ignore everything from 127.0.0.1, or from the system itself. So if you perform the test above from the server itself, and you have not removed this cpanel whitelist, then you will not get a 403 error. More than likely you will get a 404 error. The solution is to remove any whitelists from your system.<br />
<br />
Note: Whitelisting the server itself can open a hole in your security. You should not whitelist localhost or the servers own IP address, particularly if you have multi users on the system. This is both unnecessary, and doing so will allow any users on the system to carry out attacks on other domains on the system unimpeded. Make sure you do not have any rules like that, this opens a very large hole in your system.<br />
<br />
'''3) Local error message is different'''<br />
<br />
You or someone else may have configured your system to use a different error message. Check your configuration, and make sure it exactly matches the ones on this wiki. IF you are using kind of plugin that does not return a 403 when a connection is rejected, and you must use this, then you will need to manually check your mod_security logs to see if your test is being rejected by modsecurity. If it is, then your rules are working correctly and you can ignore the error code.<br />
<br />
'''4) Third party addons''' <br />
<br />
You have third party rules or addons installed with your modsecurity configuration that are changing the responses. Remove all third party addons, and make sure your configuration exactly matches the instructions on this page<br />
<br />
'''5) Insecurely configured apache'''<br />
<br />
Some control panels are known to disable modsecurity on localhost, and on the systems IP addresses. These highly insecure control panels essentially disable modsecurity if an attacker connects to the systems IP address. This of course leaves your system wide open to attack, and if you are unlucky enough to be using one of these control panels we recommend you report this to your control panel vendor as a serious vulnerability. If they are unwilling to fix it, then we recommend you find a more security concious control panel vendor.<br />
<br />
Example:<br />
<br />
We have seen some control panels that configure modsecurity to be disabled in the /etc/httpd/conf/httpd.conf file for all the local IPs on the system. <br />
<br />
<pre><br />
<VirtualHost <LOCAL IP ADDRESS>:80 127.0.0.1:80 *><br />
<IfModule mod_security2.c><br />
SecRuleEngine Off<br />
</IfModule><br />
</pre><br />
<br />
If your control panel has this vulnerability, you can remove this, but its very possible the control panel will simply open this hole in your system again. We highly recommend you report this vulnerability to your control panel vendor, and if they are unwilling to fix this vulnerability that you find a more security concious control panel vendor.<br />
<br />
'''6) You arent loading the rules'''<br />
<br />
This is common with custom configurations. Check to make sure your webserver is configured to load the rules. Keep mind that modsecurity will still generate generic messages even though the rules are not loaded. For example, if all you see are events like this:<br />
<br />
<pre><br />
--70c19f31-A--<br />
[01/Jan/2013:11:19:13 --0300] roiKIi6Ni3EKFZSKpSUs2iEb 1.2.3.4 34978 5.6.7.8 80<br />
--70c19f31-B--<br />
HEAD / HTTP/1.1<br />
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) <br />
<br />
Accept: */*<br />
<br />
--70c19f31-F--<br />
HTTP/1.1 403 Forbidden<br />
X-Powered-By: PHP/5.4.20<br />
Expires: Thu, 19 Jan 2001 02:12:00 GMT<br />
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0<br />
Pragma: no-cache<br />
Connection: close<br />
Content-Type: text/html<br />
<br />
--70c19f31-H--<br />
Stopwatch: 1383338363503919 358184 (- - -)<br />
Stopwatch2: 1383338363503919 358184; combined=2144, p1=37, p2=2053, p3=0, p4=0, p5=53, sr=0, sw=1, l=0, gc=0<br />
Producer: ModSecurity for Apache/2.7.5 ( http://www.modsecurity.org/).<br />
Server: Apache<br />
Engine-Mode: "ENABLED"<br />
<br />
--70c19f31-Z--<br />
</pre><br />
<br />
In this example, no rule is being triggered, but modsecurity is logging a basic 403 error. It will do this if the modsecurity configuration is loaded, but not the rules. So if you see this happening on your system, and you have ruled out all other issues in this list, it means your custom configuration isnt loading the rules.<br />
<br />
[[ASL]] will automatically configure modsecurity correctly. So if you are having problems configuring modsecurity yourself, then we recommend you use [[ASL]] to setup modsecurity for you.<br />
<br />
=== Windows ===<br />
<br />
Please see the [[modsecurity iis]] page.<br />
<br />
== Automated rules updates ==<br />
<br />
Please see the [[ASL]] page for installation instructions.<br />
<br />
= Tuning the Rules/Disabling Rules =<br />
<br />
== Disabling Rules ==<br />
<br />
See the [[mod_security]] page for details.<br />
<br />
== Tuning the Rules ==<br />
<br />
See the [[mod_security]] page for details.<br />
<br />
== Troubleshoot the Rules ==<br />
<br />
See the [[Atomicorp WAF Rules Troubleshooting]] page for details.<br />
<br />
== Reporting False Positives ==<br />
<br />
See the [[Reporting False Positives]] page for details.<br />
<br />
= Notes =<br />
<br />
== Special notes for CPANEL users not using ASL ==<br />
<br />
The Atomicorp Modsecurity rules work great with Cpanel, right out of the box. To use them with Cpanel either install [[ASL]], or manually install modsecurity and make a few changes to the mod_security configuration that comes with cpanel and then you are all set!<br />
<br />
=== Installing modsecurity in cpanel ===<br />
<br />
'''Option 1) Simplest and most powerful solution'''<br />
<br />
Install [[ASL]]. This will install modsecurity, configure it and will install the rule and event management GUI available in [[ASL]]<br />
<br />
Option 2) Install just the rules<br />
<br />
=== Manually Configuring modsecurity with cpanel ===<br />
<br />
These are additional considerations for installing modsecurity with cpanel. Please read this entire page, as well as this section if you are installing modsecurity with cpanel (even if you already have modsecurity install with cpanel).<br />
<br />
We recommend if you are using cPanel that you follow this advice, as cpanel includes a very minimal configuration for modsecurity that does not include all of the required and optimal settings documented here. Our settings will make your server faster, and more importantly more secure. If you use mod_security with Cpanel you must add these additional settings to experience the full feature set of mod_security.<br />
<br />
==== Step 1 ====<br />
<br />
Make sure you have read this entire document and have setup all the require directories details above.<br />
<br />
==== Step 2: Configure directory permissions ====<br />
<br />
Cpanel also does not run apache as a standard user (such as apache) but as the older non-privileged user "nobody". You will need to ensure then that the work directories that mod_security uses are owned by the user that Cpanel runs apache as. To find this out you can run this command as root:<br />
<br />
ps auxwww | grep httpd<br />
<br />
root 20594 86.8 3.1 255148 181232 ? Ss 11:39 0:04 /usr/local/apache/bin/httpd -k restart<br />
root 20611 0.0 3.1 255060 179596 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20612 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20613 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20614 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20615 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
'''nobody''' 20616 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart<br />
<br />
In this example from a Centos system running Cpanel the user is "nobody", so you would want to use these commands to configure the modsecurity work directories for a system where apache is running as "nobody": <br />
<br />
mkdir /var/asl<br />
mkdir /var/asl/data/<br />
mkdir /var/asl/data/msa<br />
mkdir /var/asl/data/audit<br />
mkdir /var/asl/data/suspicious<br />
chown nobody.nobody /var/asl/data/msa<br />
chown nobody.nobody /var/asl/data/audit<br />
chown nobody.nobody /var/asl/data/suspicious<br />
chmod o-rx -R /var/asl/data/*<br />
chmod ug+rwx -R /var/asl/data/*<br />
<br />
==== Step 3: Install modsecurity ====<br />
<br />
Please see the current minimum version required at the link below:<br />
<br />
https://www.atomicorp.com/wiki/index.php/Atomic_ModSecurity_Rules#Minimum_Version_of_Modsecurity_Required_to_use_the_rules<br />
<br />
==== Step 4: Configure cpanel ====<br />
<br />
Make a small change to the cpanel modsecurity configuration. A typical cpanel modsec2.conf configuration file looks like this:<br />
<br />
LoadFile /opt/xml2/lib/libxml2.so<br />
LoadFile /opt/lua/lib/liblua.so<br />
LoadModule security2_module modules/mod_security2.so<br />
<IfModule mod_security2.c><br />
SecRuleEngine On<br />
# See http://www.modsecurity.org/documentation/ModSecurity-Migration-Matrix.pdf<br />
# "Add the rules that will do exactly the same as the directives"<br />
# SecFilterCheckURLEncoding On<br />
# SecFilterForceByteRange 0 255<br />
SecAuditEngine RelevantOnly<br />
SecAuditLog logs/modsec_audit.log<br />
SecDebugLog logs/modsec_debug_log<br />
SecDebugLogLevel 0<br />
SecDefaultAction "phase:2,deny,log,status:403"<br />
Include "/usr/local/apache/conf/modsec2.user.conf"<br />
</IfModule><br />
<br />
Because cpanel will overwrite this configuration, you need to modify your user configuration file. You will want to setup your user configuration file (/usr/local/apache/conf/modsec2.user.conf) as in the example below. This is the recommended configuration and the '''minimum''' recommended rule sets that are designed to work with cpanel without [[ASL]] installed. Please be sure to read this entire page for information about additional rules that you may also want to use with cpanel.<br />
<br />
SecRequestBodyAccess On<br />
SecAuditLogType Concurrent<br />
SecResponseBodyAccess On<br />
SecResponseBodyMimeType (null) text/html text/plain text/xml<br />
SecResponseBodyLimit 2621440<br />
SecAuditLogRelevantStatus "^(?:5|4(?!04))"<br />
SecServerSignature Apache<br />
SecUploadDir /var/asl/data/suspicious<br />
SecUploadKeepFiles Off<br />
SecAuditLogParts ABIFHZ<br />
SecArgumentSeparator "&"<br />
SecCookieFormat 0<br />
SecRequestBodyInMemoryLimit 131072<br />
SecDataDir /var/asl/data/msa<br />
SecTmpDir /tmp<br />
SecAuditLogStorageDir /var/asl/data/audit<br />
SecResponseBodyLimitAction ProcessPartial<br />
<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_z_antievasion.conf<br />
Include /full/path/to/your/rules/modsecurity.d/00_asl_zz_strict.conf<br />
Include /full/path/to/your/rules/modsecurity.d/09_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_antimalware.conf<br />
Include /full/path/to/your/rules/modsecurity.d/10_asl_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/11_asl_adv_rules.conf<br />
Include /full/path/to/your/rules/modsecurity.d/20_asl_useragents.conf<br />
Include /full/path/to/your/rules/modsecurity.d/30_asl_antispam.conf<br />
Include /full/path/to/your/rules/modsecurity.d/50_asl_rootkits.conf<br />
Include /full/path/to/your/rules/modsecurity.d/60_asl_recons.conf<br />
Include /full/path/to/your/rules/modsecurity.d/61_asl_recons_dlp.conf<br />
Include /full/path/to/your/rules/modsecurity.d/99_asl_jitp.conf<br />
<br />
If you want to load just some of the rules, make sure you specify only those rule files. The default list above is the recommended and supported rulesets with cpanel. Do not use the other asl rulesets with cpanel, those other rules either use other apache modules (such as mod_sed) or ASL specific features that require [[ASL]].<br />
<br />
'''Make sure you have all of the settings on this page to use modsecurity with cpanel correctly, failing to do that will make it impossible for us to support you and modsecurity will not as quickly or correctly exposing your system to attack and slowing it down.'''<br />
<br />
==== Step 5: Install mod_uniqueid ====<br />
<br />
Cpanel users will need to manually verify that the mod_unique_id module is loaded by cpanel's apache. It should be loaded by default, but check your cpanel configuration to be sure.<br />
<br />
==== Step 6: Install the rules ====<br />
<br />
===== Automatic Rule Updater =====<br />
<br />
[[aum]] -u<br />
<br />
===== Manually install the rules =====<br />
<br />
See the [https://www.atomicorp.com/wiki/index.php/Atomic_ModSecurity_Rules#Step_8:_Download_the_ModSecurity_Rules Downloading rules] section above.<br />
<br />
==== Step 7: Restart Apache ====<br />
<br />
Restart apache, enjoy your new secure web server!<br />
<br />
==== Optional Steps ====<br />
<br />
===== Malware Scanner =====<br />
<br />
The malware scanner is included in [[ASL]], it is not included in the rules or rule subscriptions. Therefore, if you use this file:<br />
<br />
05_asl_scanner.conf<br />
<br />
Or this:<br />
<br />
99_asl_scanner.conf<br />
<br />
You will need to include your own scanner, and will need to make sure you have clamd installed and configured correctly to listen on a TCP port, or if you use a socket, make sure apache can read/write to this socket or as a last resort, run clamd as root. Using this file forces all web uploads on your system to go thru clamav to look for malware, viruses, etc. If you dont need that, then you can leave this config file out.<br />
<br />
<br />
==== Cpanel Error Messages ====<br />
<br />
==== modsecparse.pl ====<br />
<br />
'''This is a third party tool not provided by, or supported by Atomicorp.''' If you use this tool, it apparently does not work with the new fast concurrent logging system in modsecurity. The concurrent logging system is much faster, will speed up apache and is less resource intensive that the older serial method. <br />
<br />
However, if you use this tool you must use the slower serial logging method, as it does not support the faster concurrent method. To use this tool, change the SecAuditLogType setting from "Concurrent" to "Serial":<br />
<br />
SecAuditLogType Serial<br />
<br />
'''Keep in mind that this logging method is much slower, may slow down apache and is not supported.''' This performance impact is not caused by the rules. Serial logging is much slower than concurrent logging. Therefore we do not recommend you use this logging method or any tools that require it. There are lots of modsecurity log readers that can use the concurrent logging method, such as [[ASL]] and we encourage you to explore using one of those modern tools instead.<br />
<br />
==== Serial logging ====<br />
<br />
===== Discussion =====<br />
<br />
Serial logging is the older slower depreacted logging method modsecurity original used many years ago. This logging method would log the entire event in a single file. As a result, it would slow apache down because each event needed to wait for the previous event to finish writing before it could write to the log file. Events stack up and slow apache down. This incurs a significant performance penalty on apache, and of course a better method was devised for modsecurity to address this performance issue. The solution is the concurrent logging method. This generates a unique event file for each log event, logging the events data to that file instead of trying to jam tons of data into a single file, and thereby slowing down apache. All modern modsecurity log viewing tools support the concurrent method.<br />
<br />
The concurrent logging system is much faster, will speed up apache and is less resource intensive that the older serial method. This method is highly recommended over the slow serial logging method.<br />
<br />
===== Configuration =====<br />
<br />
====== aum ======<br />
<br />
If you want to use the old slower serial logging method, and you are using aum, change this setting in /etc/asl/config:<br />
<br />
MODSEC_LOGTYPE="Concurrent"<br />
<br />
<br />
To:<br />
<br />
MODSEC_LOGTYPE="Serial"<br />
<br />
<br />
And then run:<br />
<br />
aum -uf<br />
<br />
====== non-aum systems ======<br />
<br />
If you want to use the old slower serial logging method change the SecAuditLogType setting from "Concurrent" to "Serial":<br />
<br />
SecAuditLogType Serial<br />
<br />
'''Warning: Serial logging is much slower than concurrent logging and will slow down apache.''' Any performance impact is not caused by the rules. <br />
<br />
Therefore we do not recommend you use this logging method or any tools that require it. There are lots of modsecurity log readers that can use the fast concurrent logging method, such as [[ASL]] and we encourage you to explore using one of those modern tools instead of a tool that requires the slower and performance degrading serial logging method.<br />
<br />
If you change your system to the slower Serial method, you may also want to change the logfile name you are using for your modsecurity logs. You can do that by changing this option in your configuration:<br />
<br />
SecAuditLog logs/audit_log</div>Mshinnhttps://wiki.atomicorp.com/wiki/index.php/ProxyProxy2022-04-01T18:52:07Z<p>Mshinn: /* Cloudflare nginx guidance */</p>
<hr />
<div>= Introduction =<br />
<br />
If you use a proxy (including reverse proxies, UTM appliances, application layer firewalls, etc.) or CDN solution in front of an ASL or mod_security protected system, you must configure your web server to understand the actual source of the clients connection, and not the proxy or CDNs source IP. By default, web servers will correctly treat the CDN/proxies IP address as the source IP. Thats because the connection is coming from the CDN or proxy, and not from the actual client. <br />
<br />
This will of course cause all sorts of problems with any WAF, and is something you must correct to use a WAF with your CDN/proxy correctly. Otherwise your WAF will block the proxy/CDN and not the actual attacker! Because there are so many different kinds of proxies and CDNs, this is something you will have to configure for your system and proxy/CDN of choice. <br />
<br />
All reputable proxy and CDN vendors will be able to provide you with an official solution for using their proxy with your web server. Contact your proxy or CDN provider for support. The section below are provided as a courtesy to our customers to help them setup their systems, and to provide links to these vendors where they are known.<br />
<br />
If you are unable to do this yourself, please contact us and we'll put a quote together for you from our professional services group.<br />
<br />
= Discussion =<br />
<br />
== What is a proxy ==<br />
<br />
Note: All CDNs use proxies.<br />
<br />
What is a proxy? In short, its basically another web server, configured to make requests to another web server. Much like giving someone a "proxy vote", a proxy server requests the web page on behalf of the actual client. The actual client never connects to the actual web server, only the proxy does. So the web server is only ever communicating with the proxy, and will only see traffic from the proxy, as well as the IP address of the proxy, and not the client.<br />
<br />
== Proxy's and WAFs ==<br />
<br />
When used with a WAF, like mod_security, a proxy will request traffic on behalf of the client. The client never communicates with the WAF. The WAF then inspects the request for attacks. For example, when the proxy passes traffic to apache, it will make the requests to apache '''using the proxies IP address, and not the actual clients IP address.''' Again, this is because the proxy is the system connecting to the WAF, not the client. This is where the term "proxy" comes from, its acting as a proxy for the actual client.<br />
<br />
The WAF will then detect and report attacks as having come from the proxy, which is the actual source of the attack (its the proxy thats actually attacking the system). This is because the attack is in fact coming from the proxy, as far as your web server is concerned. <br />
<br />
== X-Forwarded-For headers ==<br />
<br />
To address this, any decent proxy will pass on the actual source of the connection sent to the proxy server using a '''custom untrusted unverified header''' in the web request. And this is where the problems start from a security perspective. These proxy servers use what is referred to as "a forwarding header" to pass on this information, for example the X-Forwarded-For header. The format of this header differs from vendor to vendor, and some require special software be installed with your web server to make use of this header. There is no generic solution for this issue.<br />
<br />
The biggest security problem is that this header can be forged, and therefore should never ever be blindly trusted. There is no way for your web server to know if this header is valid, or if the connection even came from a proxy. <br />
<br />
All client side headers can in fact be forged. The key to using this header is to only trust specific sources that use these headers. In nearly ever case, that will be only be the proxy server, and you must restrict the use of this header otherwise. Do not blindly trusted "forwarding" headers. Attackers forge them all the time, and they can not be trusted. The only way to make "trusted" use of these headers is to only trust specific trusted hosts that send these headers, and to reject them for any other source. A better solution is to block all web traffic to your server except from your CDN or proxy server(s). For example, if you proxy traffic to apache, you should block any other traffic to apache so that it can only come from the proxy server.<br />
<br />
To blindly trust these headers, you must configure your web server for the specific proxy solution you are using. Failure to do this will result in certain rule sets, such as the Crawler Protector and RBL rules, to not work correctly and if you blindly trust the forwarded-for headers you will be opening your system up to compromise.<br />
<br />
= Security Warnings when using Proxies =<br />
<br />
As previously mentioned, all headers sent from a client can be forged and should never be trusted. This includes the X-Forwarded-For header. Therefore if you do use a proxy/CDN solution we highly recommend you block all other traffic to your web server except from this proxy/CDN if you are blindly trusting client headers, for example the "forwarded for" headers proxies use. If you can not do this, then you will need to use a software add on to your web server that can restrict which hosts can send headers that will be blindly trusted, and which will not. This will allow you to trust these headers when your proxy/CDN sends them, but not any other source. '''Failure to do this can result in compromise of your server.'''<br />
<br />
Secondly, improper use of a proxy can result in the proxy server being shunned by the active response system. It will also cause rules such as RBL rules, and the Crawler protector rules to not function properly (as the actual source of the connection will be reported by Apache as the proxy and not the actual clients IP). It is the users responsibility to work with their proxy vendor to properly configure their web server to report the actual source of the connection, and not the proxy servers IP. By default web servers will report the proxy servers IP, and not the clients IP, because thats whats actually connecting to the server. If you have not made any modifications to your web server, then it is not setup correctly to work with a proxy/CDN.<br />
<br />
Each proxy vendor does this in a different way, and it is not possible to provide guidance for all potential proxy solutions. Please contact your proxy vendor for support with configuring your web server to report the actual source IP address, and not the proxy servers.<br />
<br />
Note: Some proxy modules for apache do not handle IPv6 correctly. If you find that you have this problem with IPv6 enabled, please report this issue to your proxy module vendor. If you do not need to use IPv6, disabling IPv6 may resolve your problem, as some modules are known to break IPv4 as well when IPv6 is enabled (e.g. mod_rpaf).<br />
<br />
= Guidance =<br />
<br />
'''Note: The following information is provided as a courtesy to our customers. Contact your Proxy vendor for instructions about how to setup your web server with their proxy solution.''' <br />
<br />
== Specific Vendors ==<br />
<br />
=== CloudFlare ===<br />
<br />
Please contact CloudFlare for official support with their solution. This information is provied as a courtesy. You must configure your server when using Cloudflare to log the actual clients IP in your logs, and not the Cloudflare proxy servers IP. By default your web server will not do this. Failure to do so will result in shunning of the Cloudflare proxy servers, and will prevent rules such as the Crawler Protector and RBL rules from working correctly. <br />
<br />
The following links are provided as a courtesy and in no way should be construed as supported by Atomicorp. Contact CloudFlare for instructions on setting up Apache to work with their solution.<br />
<br />
==== Cloudflare generic guidance ====<br />
<br />
http://www.cloudflare.com/resources-downloads<br />
<br />
https://www.cloudflare.com/support<br />
<br />
==== Cloudflare apache guidance ====<br />
<br />
https://support.cloudflare.com/hc/en-us/articles/200170786#C5XWe97z77b3XZV<br />
<br />
== Generic Guidance ==<br />
<br />
Note: This section is provided as a courtesy. While its not possible to cover every possible configuration, build and version of these web servers we have tried to provide complete guidance for the below web servers. If you are unable to setup your web server to work with a front end proxy please contact us and we'll have our professional services team put together a quote to get your custom environment working to meet your requirements.<br />
<br />
=== Generic Nginx guidance ===<br />
<br />
If you are using another proxy with nginx, this guidance may be helpful. You will need to ensure that you setup nginx correctly yourself for this condition, not all proxies work the same and this guidance may not work for your proxy solution. <br />
<br />
nginx must be configured to report the actual IP of the connecting host. When nginx is placed behind a proxy it will only "see" the IP of the proxy in front of it, which will break a lot of things as the actual source of the connection will be hidden to nginx. For example, DNS based WAF rules will not work correctly, and shuns may result in shuns of your proxy server, this includes the Crawler Protector rules, RBL rules, and Spam URI rules amongst others. Shunning will also not work correctly as the proxy IP address will be detected as the source of the attack.<br />
<br />
Therefore, to make this work correctly you will want to use a module with nginx that can automatically determine what the actual IP address is from the headers the proxy is passing to apache and will change the source information in apaches logs. The best place to find out what module(s) to use is from your proxy vendor. Some vendors require special proprietary modules to work with their proxy. You will also want to use a module that will automatically restrict the use of the "forwarded for" headers to a trusted set of sources, as discussed above, and to reject all other sources. Using a module like this restores nginx to its "normal" behavior, where nginx will report the actual source of the attack (and connection, which is helpful for log analysis tool) and not the proxies IP address(es). <br />
<br />
The http_realip module is one example of a module that may help you to do this. Please check with your proxy vendor for assistance with the right tools to use, this module is neither provided by or supported by Atomicorp and may or may not provide what you need for your proxy solution. You can get the module from the URL below:<br />
<br />
http://nginx.org/en/docs/http/ngx_http_realip_module.html<br />
<br />
Instructions for its installation are available at the URL above. You will want to make sure that all of your nginx logs are logging the actual clients IP, and NOT the IP of the proxy server as the source.<br />
<br />
<br />
=== Generic Apache Guidance ===<br />
<br />
If you are using another proxy with Apache, this guidance may be helpful. You will need to ensure that you setup Apache correctly yourself for this condition, not all proxies work the same and this guidance may not work for your proxy solution. <br />
<br />
Apache must be configured to report the actual IP of the connecting host. When Apache is placed behind a proxy it will only "see" the IP of the proxy in front of it, which will break a lot of things as the actual source of the connection will be hidden to Apache. For example, DNS based WAF rules will not work correctly, and shuns may result in shuns of your proxy server, this includes the Crawler Protector rules, RBL rules, and Spam URI rules amongst others. Shunning will also not work correctly as the proxy IP address will be detected as the source of the attack.<br />
<br />
Therefore, to make this work correctly you will want to use a module with apache that can automatically determine what the actual IP address is from the headers the proxy is passing to apache and will change the source information in apaches logs. The best place to find out what module(s) to use is from your proxy vendor. Some vendors require special proprietary modules to work with their proxy. You will also want to use a module that will automatically restrict the use of the "forwarded for" headers to a trusted set of sources, as discussed above, and to reject all other sources. Using a module like this restores apache to its "normal" behavior, where apache will report the actual source of the attack (and connection, which is helpful for log analysis tool) and not the proxies IP address(es). <br />
<br />
The mod_rpaf module is one example of a module that may help you to do this. Please check with your proxy vendor for assistance with the right tools to use, this module is neither provided by or supported by Atomicorp and may or may not provide what you need for your proxy solution. You can get the module from the URL below:<br />
<br />
https://github.com/gnif/mod_rpaf<br />
<br />
Instructions for its installation are available at the URL above. You will want to make sure that all of your apache logs are logging the actual clients IP, and NOT the IP of the proxy server as the source.<br />
<br />
Here is a reference configuration for mod_rapf with Apache, again check with your proxy vendor as this reference is based on a local proxy that uses the referenced headers, and this configuration may not work with all proxies.<br />
<br />
<pre><br />
<IfModule mod_rpaf-2.0.c><br />
RPAFenable On<br />
RPAFsethostname On<br />
RPAFproxy_ips 127.0.0.1<br />
RPAFheader X-Forwarded-For<br />
</IfModule><br />
</pre><br />
<br />
==== ipv6 and mod_rpaf====<br />
<br />
'''Important Note:''' some versions of mod_rpaf are known to have a bug that causes them to work incorrectly if you have the ipv6 protocol enabled on your system. Some versions of mod_rpaf provided with Plesk are known to have this bug. Other vendors builds may also have this bug.<br />
<br />
'''This will occur even if ipv6 is not configured for an interface''', but only if the ipv6 kernel module is loaded. Apache will detect that the system supports ipv6, if the kernel ipv6 module is loaded, and will pass this onto its modules. This bug in the third party mod_rpaf module, when ipv6 is enabled, will cause mod_rpaf to not pass on the actual FQDN for the IP address to apache. In those cases, rules that rely on this will fail to work correctly. If you have the ipv6 module loaded into your kernel, you will want to try unloading it if you find that mod_rpaf is not working correctly. If this resolves this issue for your system, please report this bug in the version of mod_rpaf you are using to your OS or control panel vendor.<br />
<br />
You can disable ipv6 on boot by adding the following to /etc/sysctl.conf:<br />
<br />
net.ipv6.conf.all.disable_ipv6 = 1<br />
<br />
net.ipv6.conf.default.disable_ipv6 = 1<br />
<br />
To disable in the running system:<br />
<br />
echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6<br />
<br />
echo 1 > /proc/sys/net/ipv6/conf/default/disable_ipv6<br />
<br />
or<br />
<br />
sysctl -w net.ipv6.conf.all.disable_ipv6=1<br />
<br />
sysctl -w net.ipv6.conf.default.disable_ipv6=1<br />
<br />
You will need to restart apache and nginx once you have made this change.<br />
<br />
= Precautions =<br />
<br />
== Layer 3 Firewalls ==<br />
<br />
When traffic comes from a proxy, attacks also come from the proxy, itself. That is to say, the attacker isnt actually connecting to your system, the proxy is. This means that you cant block the actual attackers IP on your server with a layer 3 firewall, because the attackers IP never connects to your server only the proxy. With [[ASL]], we try to help with this by allowing you apply your custom blacklists at layer 7 with this option:<br />
<br />
http://wiki.atomicorp.com/wiki/index.php/ASL_WAF#MODSEC_00_BLACKLIST<br />
<br />
Additionally, we support sending IP block requests to certain CDNs that support this capability. Please check with your CDN provider to see if they support this. Some providers limit the number of "firewall" rules you can implement on their CDN, its important to know what this limitation is as in some cases it may be too low for your needs.<br />
<br />
= FAQ =<br />
<br />
== Why doesnt ASL automatically trust the Forwarded-For header? ==<br />
<br />
Because its generated by the client, its trivial to forge and attackers send X-Forwarded-For headers all the time to trick poorly configured servers.<br />
<br />
Blindly trusting these headers would make it trivially possible for any attacker to forge any source IP. '''Under no circumstances should you ever configure your system to blindly trust this header.''' No reputable WAF trusts this header blindly. This header should only be considered "trusted" if (1) its from a known trusted source and (2) you have configured your web server to only trust this header from those trusted sources and to reject/not trust this header from any other source. <br />
<br />
This is what you will need to configure as described above to use this header in a trustworthy manner. Remember, this header is set by the client, in other words the attacker sets this header, not your web server, not the WAF. Your server has no idea if this header is valid, its up to you to configure your server to know what sources to trust, and what sources to not trust.<br />
<br />
== Why doesnt modsecurity automatically trust the Forwarded-For header? ==<br />
<br />
See above.<br />
<br />
= Troubleshooting =<br />
<br />
== HostnameLookups ==<br />
<br />
If you are using any of the Crawler Protector rules (https://www.atomicorp.com/wiki/index.php/ASL_WAF#Crawler_Protector), then you must ensure apache is configured with this setting:<br />
<br />
HostnameLookups Double<br />
<br />
Some control panels are known to disable this setting, and doing so will cause Crawler Protector rules to fail to work correctly, causing them not to detect search engine crawlers correctly.<br />
<br />
== IPv6 ==<br />
<br />
See this article:<br />
<br />
https://www.atomicorp.com/wiki/index.php/Proxy#ipv6_and_mod_rpaf</div>Mshinnhttps://wiki.atomicorp.com/wiki/index.php/ProxyProxy2022-04-01T18:51:57Z<p>Mshinn: /* Cloudflare IIS guidance */</p>
<hr />
<div>= Introduction =<br />
<br />
If you use a proxy (including reverse proxies, UTM appliances, application layer firewalls, etc.) or CDN solution in front of an ASL or mod_security protected system, you must configure your web server to understand the actual source of the clients connection, and not the proxy or CDNs source IP. By default, web servers will correctly treat the CDN/proxies IP address as the source IP. Thats because the connection is coming from the CDN or proxy, and not from the actual client. <br />
<br />
This will of course cause all sorts of problems with any WAF, and is something you must correct to use a WAF with your CDN/proxy correctly. Otherwise your WAF will block the proxy/CDN and not the actual attacker! Because there are so many different kinds of proxies and CDNs, this is something you will have to configure for your system and proxy/CDN of choice. <br />
<br />
All reputable proxy and CDN vendors will be able to provide you with an official solution for using their proxy with your web server. Contact your proxy or CDN provider for support. The section below are provided as a courtesy to our customers to help them setup their systems, and to provide links to these vendors where they are known.<br />
<br />
If you are unable to do this yourself, please contact us and we'll put a quote together for you from our professional services group.<br />
<br />
= Discussion =<br />
<br />
== What is a proxy ==<br />
<br />
Note: All CDNs use proxies.<br />
<br />
What is a proxy? In short, its basically another web server, configured to make requests to another web server. Much like giving someone a "proxy vote", a proxy server requests the web page on behalf of the actual client. The actual client never connects to the actual web server, only the proxy does. So the web server is only ever communicating with the proxy, and will only see traffic from the proxy, as well as the IP address of the proxy, and not the client.<br />
<br />
== Proxy's and WAFs ==<br />
<br />
When used with a WAF, like mod_security, a proxy will request traffic on behalf of the client. The client never communicates with the WAF. The WAF then inspects the request for attacks. For example, when the proxy passes traffic to apache, it will make the requests to apache '''using the proxies IP address, and not the actual clients IP address.''' Again, this is because the proxy is the system connecting to the WAF, not the client. This is where the term "proxy" comes from, its acting as a proxy for the actual client.<br />
<br />
The WAF will then detect and report attacks as having come from the proxy, which is the actual source of the attack (its the proxy thats actually attacking the system). This is because the attack is in fact coming from the proxy, as far as your web server is concerned. <br />
<br />
== X-Forwarded-For headers ==<br />
<br />
To address this, any decent proxy will pass on the actual source of the connection sent to the proxy server using a '''custom untrusted unverified header''' in the web request. And this is where the problems start from a security perspective. These proxy servers use what is referred to as "a forwarding header" to pass on this information, for example the X-Forwarded-For header. The format of this header differs from vendor to vendor, and some require special software be installed with your web server to make use of this header. There is no generic solution for this issue.<br />
<br />
The biggest security problem is that this header can be forged, and therefore should never ever be blindly trusted. There is no way for your web server to know if this header is valid, or if the connection even came from a proxy. <br />
<br />
All client side headers can in fact be forged. The key to using this header is to only trust specific sources that use these headers. In nearly ever case, that will be only be the proxy server, and you must restrict the use of this header otherwise. Do not blindly trusted "forwarding" headers. Attackers forge them all the time, and they can not be trusted. The only way to make "trusted" use of these headers is to only trust specific trusted hosts that send these headers, and to reject them for any other source. A better solution is to block all web traffic to your server except from your CDN or proxy server(s). For example, if you proxy traffic to apache, you should block any other traffic to apache so that it can only come from the proxy server.<br />
<br />
To blindly trust these headers, you must configure your web server for the specific proxy solution you are using. Failure to do this will result in certain rule sets, such as the Crawler Protector and RBL rules, to not work correctly and if you blindly trust the forwarded-for headers you will be opening your system up to compromise.<br />
<br />
= Security Warnings when using Proxies =<br />
<br />
As previously mentioned, all headers sent from a client can be forged and should never be trusted. This includes the X-Forwarded-For header. Therefore if you do use a proxy/CDN solution we highly recommend you block all other traffic to your web server except from this proxy/CDN if you are blindly trusting client headers, for example the "forwarded for" headers proxies use. If you can not do this, then you will need to use a software add on to your web server that can restrict which hosts can send headers that will be blindly trusted, and which will not. This will allow you to trust these headers when your proxy/CDN sends them, but not any other source. '''Failure to do this can result in compromise of your server.'''<br />
<br />
Secondly, improper use of a proxy can result in the proxy server being shunned by the active response system. It will also cause rules such as RBL rules, and the Crawler protector rules to not function properly (as the actual source of the connection will be reported by Apache as the proxy and not the actual clients IP). It is the users responsibility to work with their proxy vendor to properly configure their web server to report the actual source of the connection, and not the proxy servers IP. By default web servers will report the proxy servers IP, and not the clients IP, because thats whats actually connecting to the server. If you have not made any modifications to your web server, then it is not setup correctly to work with a proxy/CDN.<br />
<br />
Each proxy vendor does this in a different way, and it is not possible to provide guidance for all potential proxy solutions. Please contact your proxy vendor for support with configuring your web server to report the actual source IP address, and not the proxy servers.<br />
<br />
Note: Some proxy modules for apache do not handle IPv6 correctly. If you find that you have this problem with IPv6 enabled, please report this issue to your proxy module vendor. If you do not need to use IPv6, disabling IPv6 may resolve your problem, as some modules are known to break IPv4 as well when IPv6 is enabled (e.g. mod_rpaf).<br />
<br />
= Guidance =<br />
<br />
'''Note: The following information is provided as a courtesy to our customers. Contact your Proxy vendor for instructions about how to setup your web server with their proxy solution.''' <br />
<br />
== Specific Vendors ==<br />
<br />
=== CloudFlare ===<br />
<br />
Please contact CloudFlare for official support with their solution. This information is provied as a courtesy. You must configure your server when using Cloudflare to log the actual clients IP in your logs, and not the Cloudflare proxy servers IP. By default your web server will not do this. Failure to do so will result in shunning of the Cloudflare proxy servers, and will prevent rules such as the Crawler Protector and RBL rules from working correctly. <br />
<br />
The following links are provided as a courtesy and in no way should be construed as supported by Atomicorp. Contact CloudFlare for instructions on setting up Apache to work with their solution.<br />
<br />
==== Cloudflare generic guidance ====<br />
<br />
http://www.cloudflare.com/resources-downloads<br />
<br />
https://www.cloudflare.com/support<br />
<br />
==== Cloudflare apache guidance ====<br />
<br />
https://support.cloudflare.com/hc/en-us/articles/200170786#C5XWe97z77b3XZV<br />
<br />
==== Cloudflare nginx guidance ====<br />
<br />
https://support.cloudflare.com/entries/22051973-Does-CloudFlare-have-an-IP-module-for-Nginx-<br />
<br />
== Generic Guidance ==<br />
<br />
Note: This section is provided as a courtesy. While its not possible to cover every possible configuration, build and version of these web servers we have tried to provide complete guidance for the below web servers. If you are unable to setup your web server to work with a front end proxy please contact us and we'll have our professional services team put together a quote to get your custom environment working to meet your requirements.<br />
<br />
=== Generic Nginx guidance ===<br />
<br />
If you are using another proxy with nginx, this guidance may be helpful. You will need to ensure that you setup nginx correctly yourself for this condition, not all proxies work the same and this guidance may not work for your proxy solution. <br />
<br />
nginx must be configured to report the actual IP of the connecting host. When nginx is placed behind a proxy it will only "see" the IP of the proxy in front of it, which will break a lot of things as the actual source of the connection will be hidden to nginx. For example, DNS based WAF rules will not work correctly, and shuns may result in shuns of your proxy server, this includes the Crawler Protector rules, RBL rules, and Spam URI rules amongst others. Shunning will also not work correctly as the proxy IP address will be detected as the source of the attack.<br />
<br />
Therefore, to make this work correctly you will want to use a module with nginx that can automatically determine what the actual IP address is from the headers the proxy is passing to apache and will change the source information in apaches logs. The best place to find out what module(s) to use is from your proxy vendor. Some vendors require special proprietary modules to work with their proxy. You will also want to use a module that will automatically restrict the use of the "forwarded for" headers to a trusted set of sources, as discussed above, and to reject all other sources. Using a module like this restores nginx to its "normal" behavior, where nginx will report the actual source of the attack (and connection, which is helpful for log analysis tool) and not the proxies IP address(es). <br />
<br />
The http_realip module is one example of a module that may help you to do this. Please check with your proxy vendor for assistance with the right tools to use, this module is neither provided by or supported by Atomicorp and may or may not provide what you need for your proxy solution. You can get the module from the URL below:<br />
<br />
http://nginx.org/en/docs/http/ngx_http_realip_module.html<br />
<br />
Instructions for its installation are available at the URL above. You will want to make sure that all of your nginx logs are logging the actual clients IP, and NOT the IP of the proxy server as the source.<br />
<br />
<br />
=== Generic Apache Guidance ===<br />
<br />
If you are using another proxy with Apache, this guidance may be helpful. You will need to ensure that you setup Apache correctly yourself for this condition, not all proxies work the same and this guidance may not work for your proxy solution. <br />
<br />
Apache must be configured to report the actual IP of the connecting host. When Apache is placed behind a proxy it will only "see" the IP of the proxy in front of it, which will break a lot of things as the actual source of the connection will be hidden to Apache. For example, DNS based WAF rules will not work correctly, and shuns may result in shuns of your proxy server, this includes the Crawler Protector rules, RBL rules, and Spam URI rules amongst others. Shunning will also not work correctly as the proxy IP address will be detected as the source of the attack.<br />
<br />
Therefore, to make this work correctly you will want to use a module with apache that can automatically determine what the actual IP address is from the headers the proxy is passing to apache and will change the source information in apaches logs. The best place to find out what module(s) to use is from your proxy vendor. Some vendors require special proprietary modules to work with their proxy. You will also want to use a module that will automatically restrict the use of the "forwarded for" headers to a trusted set of sources, as discussed above, and to reject all other sources. Using a module like this restores apache to its "normal" behavior, where apache will report the actual source of the attack (and connection, which is helpful for log analysis tool) and not the proxies IP address(es). <br />
<br />
The mod_rpaf module is one example of a module that may help you to do this. Please check with your proxy vendor for assistance with the right tools to use, this module is neither provided by or supported by Atomicorp and may or may not provide what you need for your proxy solution. You can get the module from the URL below:<br />
<br />
https://github.com/gnif/mod_rpaf<br />
<br />
Instructions for its installation are available at the URL above. You will want to make sure that all of your apache logs are logging the actual clients IP, and NOT the IP of the proxy server as the source.<br />
<br />
Here is a reference configuration for mod_rapf with Apache, again check with your proxy vendor as this reference is based on a local proxy that uses the referenced headers, and this configuration may not work with all proxies.<br />
<br />
<pre><br />
<IfModule mod_rpaf-2.0.c><br />
RPAFenable On<br />
RPAFsethostname On<br />
RPAFproxy_ips 127.0.0.1<br />
RPAFheader X-Forwarded-For<br />
</IfModule><br />
</pre><br />
<br />
==== ipv6 and mod_rpaf====<br />
<br />
'''Important Note:''' some versions of mod_rpaf are known to have a bug that causes them to work incorrectly if you have the ipv6 protocol enabled on your system. Some versions of mod_rpaf provided with Plesk are known to have this bug. Other vendors builds may also have this bug.<br />
<br />
'''This will occur even if ipv6 is not configured for an interface''', but only if the ipv6 kernel module is loaded. Apache will detect that the system supports ipv6, if the kernel ipv6 module is loaded, and will pass this onto its modules. This bug in the third party mod_rpaf module, when ipv6 is enabled, will cause mod_rpaf to not pass on the actual FQDN for the IP address to apache. In those cases, rules that rely on this will fail to work correctly. If you have the ipv6 module loaded into your kernel, you will want to try unloading it if you find that mod_rpaf is not working correctly. If this resolves this issue for your system, please report this bug in the version of mod_rpaf you are using to your OS or control panel vendor.<br />
<br />
You can disable ipv6 on boot by adding the following to /etc/sysctl.conf:<br />
<br />
net.ipv6.conf.all.disable_ipv6 = 1<br />
<br />
net.ipv6.conf.default.disable_ipv6 = 1<br />
<br />
To disable in the running system:<br />
<br />
echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6<br />
<br />
echo 1 > /proc/sys/net/ipv6/conf/default/disable_ipv6<br />
<br />
or<br />
<br />
sysctl -w net.ipv6.conf.all.disable_ipv6=1<br />
<br />
sysctl -w net.ipv6.conf.default.disable_ipv6=1<br />
<br />
You will need to restart apache and nginx once you have made this change.<br />
<br />
= Precautions =<br />
<br />
== Layer 3 Firewalls ==<br />
<br />
When traffic comes from a proxy, attacks also come from the proxy, itself. That is to say, the attacker isnt actually connecting to your system, the proxy is. This means that you cant block the actual attackers IP on your server with a layer 3 firewall, because the attackers IP never connects to your server only the proxy. With [[ASL]], we try to help with this by allowing you apply your custom blacklists at layer 7 with this option:<br />
<br />
http://wiki.atomicorp.com/wiki/index.php/ASL_WAF#MODSEC_00_BLACKLIST<br />
<br />
Additionally, we support sending IP block requests to certain CDNs that support this capability. Please check with your CDN provider to see if they support this. Some providers limit the number of "firewall" rules you can implement on their CDN, its important to know what this limitation is as in some cases it may be too low for your needs.<br />
<br />
= FAQ =<br />
<br />
== Why doesnt ASL automatically trust the Forwarded-For header? ==<br />
<br />
Because its generated by the client, its trivial to forge and attackers send X-Forwarded-For headers all the time to trick poorly configured servers.<br />
<br />
Blindly trusting these headers would make it trivially possible for any attacker to forge any source IP. '''Under no circumstances should you ever configure your system to blindly trust this header.''' No reputable WAF trusts this header blindly. This header should only be considered "trusted" if (1) its from a known trusted source and (2) you have configured your web server to only trust this header from those trusted sources and to reject/not trust this header from any other source. <br />
<br />
This is what you will need to configure as described above to use this header in a trustworthy manner. Remember, this header is set by the client, in other words the attacker sets this header, not your web server, not the WAF. Your server has no idea if this header is valid, its up to you to configure your server to know what sources to trust, and what sources to not trust.<br />
<br />
== Why doesnt modsecurity automatically trust the Forwarded-For header? ==<br />
<br />
See above.<br />
<br />
= Troubleshooting =<br />
<br />
== HostnameLookups ==<br />
<br />
If you are using any of the Crawler Protector rules (https://www.atomicorp.com/wiki/index.php/ASL_WAF#Crawler_Protector), then you must ensure apache is configured with this setting:<br />
<br />
HostnameLookups Double<br />
<br />
Some control panels are known to disable this setting, and doing so will cause Crawler Protector rules to fail to work correctly, causing them not to detect search engine crawlers correctly.<br />
<br />
== IPv6 ==<br />
<br />
See this article:<br />
<br />
https://www.atomicorp.com/wiki/index.php/Proxy#ipv6_and_mod_rpaf</div>Mshinnhttps://wiki.atomicorp.com/wiki/index.php/ProxyProxy2022-02-07T21:20:57Z<p>Mshinn: /* Cloudflare apache guidance */</p>
<hr />
<div>= Introduction =<br />
<br />
If you use a proxy (including reverse proxies, UTM appliances, application layer firewalls, etc.) or CDN solution in front of an ASL or mod_security protected system, you must configure your web server to understand the actual source of the clients connection, and not the proxy or CDNs source IP. By default, web servers will correctly treat the CDN/proxies IP address as the source IP. Thats because the connection is coming from the CDN or proxy, and not from the actual client. <br />
<br />
This will of course cause all sorts of problems with any WAF, and is something you must correct to use a WAF with your CDN/proxy correctly. Otherwise your WAF will block the proxy/CDN and not the actual attacker! Because there are so many different kinds of proxies and CDNs, this is something you will have to configure for your system and proxy/CDN of choice. <br />
<br />
All reputable proxy and CDN vendors will be able to provide you with an official solution for using their proxy with your web server. Contact your proxy or CDN provider for support. The section below are provided as a courtesy to our customers to help them setup their systems, and to provide links to these vendors where they are known.<br />
<br />
If you are unable to do this yourself, please contact us and we'll put a quote together for you from our professional services group.<br />
<br />
= Discussion =<br />
<br />
== What is a proxy ==<br />
<br />
Note: All CDNs use proxies.<br />
<br />
What is a proxy? In short, its basically another web server, configured to make requests to another web server. Much like giving someone a "proxy vote", a proxy server requests the web page on behalf of the actual client. The actual client never connects to the actual web server, only the proxy does. So the web server is only ever communicating with the proxy, and will only see traffic from the proxy, as well as the IP address of the proxy, and not the client.<br />
<br />
== Proxy's and WAFs ==<br />
<br />
When used with a WAF, like mod_security, a proxy will request traffic on behalf of the client. The client never communicates with the WAF. The WAF then inspects the request for attacks. For example, when the proxy passes traffic to apache, it will make the requests to apache '''using the proxies IP address, and not the actual clients IP address.''' Again, this is because the proxy is the system connecting to the WAF, not the client. This is where the term "proxy" comes from, its acting as a proxy for the actual client.<br />
<br />
The WAF will then detect and report attacks as having come from the proxy, which is the actual source of the attack (its the proxy thats actually attacking the system). This is because the attack is in fact coming from the proxy, as far as your web server is concerned. <br />
<br />
== X-Forwarded-For headers ==<br />
<br />
To address this, any decent proxy will pass on the actual source of the connection sent to the proxy server using a '''custom untrusted unverified header''' in the web request. And this is where the problems start from a security perspective. These proxy servers use what is referred to as "a forwarding header" to pass on this information, for example the X-Forwarded-For header. The format of this header differs from vendor to vendor, and some require special software be installed with your web server to make use of this header. There is no generic solution for this issue.<br />
<br />
The biggest security problem is that this header can be forged, and therefore should never ever be blindly trusted. There is no way for your web server to know if this header is valid, or if the connection even came from a proxy. <br />
<br />
All client side headers can in fact be forged. The key to using this header is to only trust specific sources that use these headers. In nearly ever case, that will be only be the proxy server, and you must restrict the use of this header otherwise. Do not blindly trusted "forwarding" headers. Attackers forge them all the time, and they can not be trusted. The only way to make "trusted" use of these headers is to only trust specific trusted hosts that send these headers, and to reject them for any other source. A better solution is to block all web traffic to your server except from your CDN or proxy server(s). For example, if you proxy traffic to apache, you should block any other traffic to apache so that it can only come from the proxy server.<br />
<br />
To blindly trust these headers, you must configure your web server for the specific proxy solution you are using. Failure to do this will result in certain rule sets, such as the Crawler Protector and RBL rules, to not work correctly and if you blindly trust the forwarded-for headers you will be opening your system up to compromise.<br />
<br />
= Security Warnings when using Proxies =<br />
<br />
As previously mentioned, all headers sent from a client can be forged and should never be trusted. This includes the X-Forwarded-For header. Therefore if you do use a proxy/CDN solution we highly recommend you block all other traffic to your web server except from this proxy/CDN if you are blindly trusting client headers, for example the "forwarded for" headers proxies use. If you can not do this, then you will need to use a software add on to your web server that can restrict which hosts can send headers that will be blindly trusted, and which will not. This will allow you to trust these headers when your proxy/CDN sends them, but not any other source. '''Failure to do this can result in compromise of your server.'''<br />
<br />
Secondly, improper use of a proxy can result in the proxy server being shunned by the active response system. It will also cause rules such as RBL rules, and the Crawler protector rules to not function properly (as the actual source of the connection will be reported by Apache as the proxy and not the actual clients IP). It is the users responsibility to work with their proxy vendor to properly configure their web server to report the actual source of the connection, and not the proxy servers IP. By default web servers will report the proxy servers IP, and not the clients IP, because thats whats actually connecting to the server. If you have not made any modifications to your web server, then it is not setup correctly to work with a proxy/CDN.<br />
<br />
Each proxy vendor does this in a different way, and it is not possible to provide guidance for all potential proxy solutions. Please contact your proxy vendor for support with configuring your web server to report the actual source IP address, and not the proxy servers.<br />
<br />
Note: Some proxy modules for apache do not handle IPv6 correctly. If you find that you have this problem with IPv6 enabled, please report this issue to your proxy module vendor. If you do not need to use IPv6, disabling IPv6 may resolve your problem, as some modules are known to break IPv4 as well when IPv6 is enabled (e.g. mod_rpaf).<br />
<br />
= Guidance =<br />
<br />
'''Note: The following information is provided as a courtesy to our customers. Contact your Proxy vendor for instructions about how to setup your web server with their proxy solution.''' <br />
<br />
== Specific Vendors ==<br />
<br />
=== CloudFlare ===<br />
<br />
Please contact CloudFlare for official support with their solution. This information is provied as a courtesy. You must configure your server when using Cloudflare to log the actual clients IP in your logs, and not the Cloudflare proxy servers IP. By default your web server will not do this. Failure to do so will result in shunning of the Cloudflare proxy servers, and will prevent rules such as the Crawler Protector and RBL rules from working correctly. <br />
<br />
The following links are provided as a courtesy and in no way should be construed as supported by Atomicorp. Contact CloudFlare for instructions on setting up Apache to work with their solution.<br />
<br />
==== Cloudflare generic guidance ====<br />
<br />
http://www.cloudflare.com/resources-downloads<br />
<br />
https://www.cloudflare.com/support<br />
<br />
==== Cloudflare apache guidance ====<br />
<br />
https://support.cloudflare.com/hc/en-us/articles/200170786#C5XWe97z77b3XZV<br />
<br />
==== Cloudflare IIS guidance ====<br />
<br />
https://support.cloudflare.com/entries/22041122-How-do-I-correct-visitor-IP-with-Windows-IIS7-and-IIS8-<br />
<br />
==== Cloudflare nginx guidance ====<br />
<br />
https://support.cloudflare.com/entries/22051973-Does-CloudFlare-have-an-IP-module-for-Nginx-<br />
<br />
== Generic Guidance ==<br />
<br />
Note: This section is provided as a courtesy. While its not possible to cover every possible configuration, build and version of these web servers we have tried to provide complete guidance for the below web servers. If you are unable to setup your web server to work with a front end proxy please contact us and we'll have our professional services team put together a quote to get your custom environment working to meet your requirements.<br />
<br />
=== Generic Nginx guidance ===<br />
<br />
If you are using another proxy with nginx, this guidance may be helpful. You will need to ensure that you setup nginx correctly yourself for this condition, not all proxies work the same and this guidance may not work for your proxy solution. <br />
<br />
nginx must be configured to report the actual IP of the connecting host. When nginx is placed behind a proxy it will only "see" the IP of the proxy in front of it, which will break a lot of things as the actual source of the connection will be hidden to nginx. For example, DNS based WAF rules will not work correctly, and shuns may result in shuns of your proxy server, this includes the Crawler Protector rules, RBL rules, and Spam URI rules amongst others. Shunning will also not work correctly as the proxy IP address will be detected as the source of the attack.<br />
<br />
Therefore, to make this work correctly you will want to use a module with nginx that can automatically determine what the actual IP address is from the headers the proxy is passing to apache and will change the source information in apaches logs. The best place to find out what module(s) to use is from your proxy vendor. Some vendors require special proprietary modules to work with their proxy. You will also want to use a module that will automatically restrict the use of the "forwarded for" headers to a trusted set of sources, as discussed above, and to reject all other sources. Using a module like this restores nginx to its "normal" behavior, where nginx will report the actual source of the attack (and connection, which is helpful for log analysis tool) and not the proxies IP address(es). <br />
<br />
The http_realip module is one example of a module that may help you to do this. Please check with your proxy vendor for assistance with the right tools to use, this module is neither provided by or supported by Atomicorp and may or may not provide what you need for your proxy solution. You can get the module from the URL below:<br />
<br />
http://nginx.org/en/docs/http/ngx_http_realip_module.html<br />
<br />
Instructions for its installation are available at the URL above. You will want to make sure that all of your nginx logs are logging the actual clients IP, and NOT the IP of the proxy server as the source.<br />
<br />
<br />
=== Generic Apache Guidance ===<br />
<br />
If you are using another proxy with Apache, this guidance may be helpful. You will need to ensure that you setup Apache correctly yourself for this condition, not all proxies work the same and this guidance may not work for your proxy solution. <br />
<br />
Apache must be configured to report the actual IP of the connecting host. When Apache is placed behind a proxy it will only "see" the IP of the proxy in front of it, which will break a lot of things as the actual source of the connection will be hidden to Apache. For example, DNS based WAF rules will not work correctly, and shuns may result in shuns of your proxy server, this includes the Crawler Protector rules, RBL rules, and Spam URI rules amongst others. Shunning will also not work correctly as the proxy IP address will be detected as the source of the attack.<br />
<br />
Therefore, to make this work correctly you will want to use a module with apache that can automatically determine what the actual IP address is from the headers the proxy is passing to apache and will change the source information in apaches logs. The best place to find out what module(s) to use is from your proxy vendor. Some vendors require special proprietary modules to work with their proxy. You will also want to use a module that will automatically restrict the use of the "forwarded for" headers to a trusted set of sources, as discussed above, and to reject all other sources. Using a module like this restores apache to its "normal" behavior, where apache will report the actual source of the attack (and connection, which is helpful for log analysis tool) and not the proxies IP address(es). <br />
<br />
The mod_rpaf module is one example of a module that may help you to do this. Please check with your proxy vendor for assistance with the right tools to use, this module is neither provided by or supported by Atomicorp and may or may not provide what you need for your proxy solution. You can get the module from the URL below:<br />
<br />
https://github.com/gnif/mod_rpaf<br />
<br />
Instructions for its installation are available at the URL above. You will want to make sure that all of your apache logs are logging the actual clients IP, and NOT the IP of the proxy server as the source.<br />
<br />
Here is a reference configuration for mod_rapf with Apache, again check with your proxy vendor as this reference is based on a local proxy that uses the referenced headers, and this configuration may not work with all proxies.<br />
<br />
<pre><br />
<IfModule mod_rpaf-2.0.c><br />
RPAFenable On<br />
RPAFsethostname On<br />
RPAFproxy_ips 127.0.0.1<br />
RPAFheader X-Forwarded-For<br />
</IfModule><br />
</pre><br />
<br />
==== ipv6 and mod_rpaf====<br />
<br />
'''Important Note:''' some versions of mod_rpaf are known to have a bug that causes them to work incorrectly if you have the ipv6 protocol enabled on your system. Some versions of mod_rpaf provided with Plesk are known to have this bug. Other vendors builds may also have this bug.<br />
<br />
'''This will occur even if ipv6 is not configured for an interface''', but only if the ipv6 kernel module is loaded. Apache will detect that the system supports ipv6, if the kernel ipv6 module is loaded, and will pass this onto its modules. This bug in the third party mod_rpaf module, when ipv6 is enabled, will cause mod_rpaf to not pass on the actual FQDN for the IP address to apache. In those cases, rules that rely on this will fail to work correctly. If you have the ipv6 module loaded into your kernel, you will want to try unloading it if you find that mod_rpaf is not working correctly. If this resolves this issue for your system, please report this bug in the version of mod_rpaf you are using to your OS or control panel vendor.<br />
<br />
You can disable ipv6 on boot by adding the following to /etc/sysctl.conf:<br />
<br />
net.ipv6.conf.all.disable_ipv6 = 1<br />
<br />
net.ipv6.conf.default.disable_ipv6 = 1<br />
<br />
To disable in the running system:<br />
<br />
echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6<br />
<br />
echo 1 > /proc/sys/net/ipv6/conf/default/disable_ipv6<br />
<br />
or<br />
<br />
sysctl -w net.ipv6.conf.all.disable_ipv6=1<br />
<br />
sysctl -w net.ipv6.conf.default.disable_ipv6=1<br />
<br />
You will need to restart apache and nginx once you have made this change.<br />
<br />
= Precautions =<br />
<br />
== Layer 3 Firewalls ==<br />
<br />
When traffic comes from a proxy, attacks also come from the proxy, itself. That is to say, the attacker isnt actually connecting to your system, the proxy is. This means that you cant block the actual attackers IP on your server with a layer 3 firewall, because the attackers IP never connects to your server only the proxy. With [[ASL]], we try to help with this by allowing you apply your custom blacklists at layer 7 with this option:<br />
<br />
http://wiki.atomicorp.com/wiki/index.php/ASL_WAF#MODSEC_00_BLACKLIST<br />
<br />
Additionally, we support sending IP block requests to certain CDNs that support this capability. Please check with your CDN provider to see if they support this. Some providers limit the number of "firewall" rules you can implement on their CDN, its important to know what this limitation is as in some cases it may be too low for your needs.<br />
<br />
= FAQ =<br />
<br />
== Why doesnt ASL automatically trust the Forwarded-For header? ==<br />
<br />
Because its generated by the client, its trivial to forge and attackers send X-Forwarded-For headers all the time to trick poorly configured servers.<br />
<br />
Blindly trusting these headers would make it trivially possible for any attacker to forge any source IP. '''Under no circumstances should you ever configure your system to blindly trust this header.''' No reputable WAF trusts this header blindly. This header should only be considered "trusted" if (1) its from a known trusted source and (2) you have configured your web server to only trust this header from those trusted sources and to reject/not trust this header from any other source. <br />
<br />
This is what you will need to configure as described above to use this header in a trustworthy manner. Remember, this header is set by the client, in other words the attacker sets this header, not your web server, not the WAF. Your server has no idea if this header is valid, its up to you to configure your server to know what sources to trust, and what sources to not trust.<br />
<br />
== Why doesnt modsecurity automatically trust the Forwarded-For header? ==<br />
<br />
See above.<br />
<br />
= Troubleshooting =<br />
<br />
== HostnameLookups ==<br />
<br />
If you are using any of the Crawler Protector rules (https://www.atomicorp.com/wiki/index.php/ASL_WAF#Crawler_Protector), then you must ensure apache is configured with this setting:<br />
<br />
HostnameLookups Double<br />
<br />
Some control panels are known to disable this setting, and doing so will cause Crawler Protector rules to fail to work correctly, causing them not to detect search engine crawlers correctly.<br />
<br />
== IPv6 ==<br />
<br />
See this article:<br />
<br />
https://www.atomicorp.com/wiki/index.php/Proxy#ipv6_and_mod_rpaf</div>Mshinn