Latest revision as of 16:30, 6 October 2022

Atomic Secured Linux includes modsecurity, and the Real Time GotRoot.com/Atomicorp Modsecurity Rules. These docs are for users that do not have ASL.

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, upgrade to ASL today!

[edit] About the rules

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 Atomicorp is the product arm of 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.

We publish two versions of the rules:

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.

Free/Delayed Rules: A delayed subset of the Advanced rules.

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.

[edit] Getting the rules

Click here to get the Atomicorp ModSecurity Rules.

[edit] Atomic ModSecurity Rules Frequently Asked Questions

Please see the Atomic ModSecurity Rules FAQ wiki page.

[edit] Real Time Rule Support

If you have a subscription to the real time rules, you can request email support by sending an email to:

support@atomicorp.com

The Customer Support Forums are located here:

Customer Support Forums

And the Custom Support Portal is located here (you can submit bug reports and open cases through the portal):

Customer Support Portal

[edit] Licenses

The Real Time Atomic ModSecurity Rules are licensed by the server. You can order licenses from the online store at the link below:

Online Store

If you require additional licenses please log into the 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.

[edit] License Terms and Conditions

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.

Atomicorp ModSecurity rules installed upon a Reverse Proxy WAF appliance/server requires a separate license. Please contact Atomicorp support for details.

The rule set cannot be copied, mirrored, or reproduced under protection of US and International copyright laws.

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.

Agreement to these terms and conditions and the Atomicorp End User License Agreement is required to download and use the Atomicorp ModSecurity rules.

[edit] Important Information about the Rules

[edit] Minimum Version of Modsecurity Required to use the rules

The rules are supported with the following versions of Modsecurity:

2.9.3

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.

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.

[edit] What versions of modsecurity do the rules work with

They work with both modsecurity 2.9.x, and modsecurity 3.x.

[edit] What does each rule family do?

Please see the modsecurity_rule_families documents.

[edit] Installation

[edit] Easy One Step Installation

[edit] Full Management Suite

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.

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.

A full list of ASLs features is available at the URL below:

https://www.atomicorp.com/products/asl.html

[edit] Just a downloader

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:

Step 1) Install aum

wget -q -O - https://updates.atomicorp.com/installers/aum |bash

Step 2) Configure aum

aum configure

Step 3) Tell aum to install the rules

aum upgrade

You can read more about aum on the aum documentation page.

Note: This capability is included in ASL. ASL users do not need to install aum, its already included.

[edit] (Optional) Do It Yourself Installation

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.

[edit] Linux

[edit] Step 1: Download ModSecurity

Binaries:

Install modsecurity from the Atomicorp software repository

Source Code:

Install modsecurity from the Atomicorp software repository

Please note that the rules are only supported with the version of modsecurity identified in this section of the wiki.

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.

[edit] Step 2: Set up and configure directories

Create the following directories as root:

 mkdir /etc/httpd/modsecurity.d
 mkdir /var/asl
 mkdir /var/asl/tmp
 mkdir /var/asl/data
 mkdir /var/asl/data/msa
 mkdir /var/asl/data/audit
 mkdir /var/asl/data/suspicious

[edit] Step 3: Set permissions for directories

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.

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:

 ps auxwww | grep httpd

The output will look similar to this:

(RHEL/Centos example with or without Plesk)

 root     26755  0.0  4.3 430752 86432 ?        Ss   04:30   0:01 /usr/sbin/httpd
 apache   26908  0.0  3.7 300564 75076 ?        S    04:30   0:00 /usr/sbin/httpd
 apache   26909  0.1  5.5 495812 112084 ?       S    04:30   0:37 /usr/sbin/httpd
 apache   26910  0.0  5.3 495424 106672 ?       S    04:30   0:23 /usr/sbin/httpd
 apache   26911  0.1  5.7 495892 114368 ?       S    04:30   0:57 /usr/sbin/httpd
 apache   26912  0.1  5.7 496056 114440 ?       S    04:30   0:52 /usr/sbin/httpd
 apache   26913  0.1  5.5 496604 110692 ?       S    04:30   0:57 /usr/sbin/httpd
 apache   26914  0.0  5.7 499324 116236 ?       S    04:30   0:16 /usr/sbin/httpd
 apache   26915  0.2  5.5 493600 112192 ?       S    04:30   1:09 /usr/sbin/httpd
 apache   26916  0.1  6.4 513760 129992 ?       S    04:30   0:30 /usr/sbin/httpd

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):

 chown apache.apache /var/asl/data/msa
 chown apache.apache /var/asl/data/audit
 chown apache.apache /var/asl/data/suspicious
 chmod o-rx -R /var/asl/data/*
 chmod ug+rwx -R /var/asl/data/*

(RHEL/Centos example with Cpanel)

 root     20594 86.8  3.1 255148 181232 ?       Ss   11:39   0:04 /usr/local/apache/bin/httpd -k restart
 root     20611  0.0  3.1 255060 179596 ?       S    11:39   0:00 /usr/local/apache/bin/httpd -k restart
 nobody   20612  0.0  3.1 255148 180224 ?       S    11:39   0:00 /usr/local/apache/bin/httpd -k restart
 nobody   20613  0.0  3.1 255148 180224 ?       S    11:39   0:00 /usr/local/apache/bin/httpd -k restart
 nobody   20614  0.0  3.1 255148 180224 ?       S    11:39   0:00 /usr/local/apache/bin/httpd -k restart
 nobody   20615  0.0  3.1 255148 180224 ?       S    11:39   0:00 /usr/local/apache/bin/httpd -k restart
 nobody   20616  0.0  3.1 255148 180224 ?       S    11:39   0:00 /usr/local/apache/bin/httpd -k restart

In this example from a Centos system running Cpanel the user is "nobody", so you would want to use these commands:

 chown nobody.nobody /var/asl/data/msa
 chown nobody.nobody /var/asl/data/audit
 chown nobody.nobody /var/asl/data/suspicious
 chmod o-rx -R /var/asl/data/*
 chmod ug+rwx -R /var/asl/data/*

[edit] Step 4: (Optional) Create rule updater directories

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:

 mkdir /var/asl/updates
 mkdir /var/asl/rules/
 mkdir /var/asl/rules/clamav

[edit] Step 5: Create the whitelist file

Create this file:

 touch /etc/asl/whitelist

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.

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.

[edit] Step 6: Configure your webserver

[edit] nginx

[edit] Step 6a: configure nginx to load modsecurity

[edit] nginx proxying to a backend

If you are using nginx as a frontend to another webserver, then add the following directives to your nginx.conf file.

location / {
           ModSecurityEnabled on;
           ModSecurityConfig modsecurity.conf;
           proxy_pass http://localhost:8080;
           proxy_read_timeout 180s;
       }

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:

          proxy_pass http://localhost:8088;

[edit] nginx standalone

If you are only using nginx, and not using it as a frontend to another web server then you want to use this configuration:

location / {
ModSecurityEnabled on;
ModSecurityConfig modsecurity.conf;
}

[edit] Apache

[edit] Step 6a: configure apache to load modsecurity

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:

 Include conf.d/*.conf

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.

An example 00_modsecurity.conf file that works with our files is included here:

 LoadModule security2_module modules/mod_security2.so
 LoadModule unique_id_module modules/mod_unique_id.so
 <IfModule mod_security2.c>
 Include modsecurity.d/tortix_waf.conf
 </IfModule>

Install this file in your conf.d directory. On a standard RHEL or Centos system that directory is located here:

 /etc/httpd/conf.d/

[edit] Step 7: Configure modsecurity

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:

 SecRuleEngine On
 SecRequestBodyAccess On
 SecResponseBodyAccess On
 SecResponseBodyMimeType (null) text/html text/plain text/xml
 SecResponseBodyLimit 2621440
 SecServerSignature Apache
 SecComponentSignature 200911012341
 SecUploadDir /var/asl/data/suspicious
 SecUploadKeepFiles Off
 SecAuditEngine RelevantOnly
 SecAuditLogRelevantStatus "^(?:5|4(?!04))"
 SecAuditLogType Concurrent
 SecAuditLog logs/audit_log
 SecAuditLogParts ABIFHZ
 SecArgumentSeparator "&" 
 SecCookieFormat 0
 SecRequestBodyInMemoryLimit 131072
 SecDataDir /var/asl/data/msa
 SecTmpDir /tmp
 SecAuditLogStorageDir /var/asl/data/audit
 SecResponseBodyLimitAction ProcessPartial
 SecAuditLogDirMode 0770
 SecPcreMatchLimit 250000  
 SecPcreMatchLimitRecursion 250000

You will want to install this file in your modsecurity.d directory, which is located here if you follow the instructions above:

 /etc/httpd/modsecurity.d

[edit] tortix_waf.conf

You can also download an example version of the modsecurity configuration file from here:

https://www.atomicorp.com/installer/tortix_waf.conf

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.

[edit] Step 8: Download the ModSecurity Rules

See the Downloading Rules page.

[edit] Step 9: Install the rules

[edit] Remove any previous installations of rules

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.

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:

ModSecurity: Found another rule with the same id

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.

[edit] Installation

Download the rules to a temporary directory using your favorite download tool. Extract the rules:

 tar zxvf /var/asl/updates/modsec-200911012341.tar.gz

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.

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.

Finally, load the rules. Make sure you specify only those rule files that are appropriate for your system. For example:

Include /full/path/to/your/rules/modsecurity.d/10_asl_rules.conf
Include /full/path/to/your/rules/modsecurity.d/99_asl_jitp.conf

Warning: You should NOT include all the rules. There are rulesets, documented above, that replace other rulesets and are incompatible with each other.

[edit] Recommend minimum rulesets

[edit] apache

The recommended minimum ruleset to load is:

Include /full/path/to/your/rules/modsecurity.d/00_asl_0_global.conf
Include /full/path/to/your/rules/modsecurity.d/10_asl_antimalware.conf
Include /full/path/to/your/rules/modsecurity.d/10_asl_rules.conf
Include /full/path/to/your/rules/modsecurity.d/11_asl_adv_rules.conf
Include /full/path/to/your/rules/modsecurity.d/20_asl_useragents.conf
Include /full/path/to/your/rules/modsecurity.d/30_asl_antispam.conf
Include /full/path/to/your/rules/modsecurity.d/50_asl_rootkits.conf
Include /full/path/to/your/rules/modsecurity.d/60_asl_recons.conf
Include /full/path/to/your/rules/modsecurity.d/61_asl_recons_dlp.conf
Include /full/path/to/your/rules/modsecurity.d/99_asl_jitp.conf

If you have modsecurity 2.9.0 and up installed, you should also load additional rule files and should use this ruleset:

Include /full/path/to/your/rules/modsecurity.d/000_asl_threat_intelligence.conf
Include /full/path/to/your/rules/modsecurity.d/00_asl_zz_strict.conf
Include /full/path/to/your/rules/modsecurity.d/00_asl_0_global.conf
Include /full/path/to/your/rules/modsecurity.d/00_asl_z_antievasion.conf
Include /full/path/to/your/rules/modsecurity.d/01_asl_content.conf
Include /full/path/to/your/rules/modsecurity.d/01_asl_content_z.conf
Include /full/path/to/your/rules/modsecurity.d/03_asl_dos.conf
Include /full/path/to/your/rules/modsecurity.d/09_asl_rules.conf
Include /full/path/to/your/rules/modsecurity.d/10_asl_antimalware.conf
Include /full/path/to/your/rules/modsecurity.d/10_asl_rules.conf
Include /full/path/to/your/rules/modsecurity.d/11_asl_adv_rules.conf
Include /full/path/to/your/rules/modsecurity.d/11_asl_data_loss.conf
Include /full/path/to/your/rules/modsecurity.d/12_asl_adv_xss_rules.conf
Include /full/path/to/your/rules/modsecurity.d/20_asl_useragents.conf
Include /full/path/to/your/rules/modsecurity.d/30_asl_antispam.conf
Include /full/path/to/your/rules/modsecurity.d/50_asl_rootkits.conf
Include /full/path/to/your/rules/modsecurity.d/51_asl_rootkits.conf
Include /full/path/to/your/rules/modsecurity.d/60_asl_recons.conf
Include /full/path/to/your/rules/modsecurity.d/61_asl_recons_dlp.conf
Include /full/path/to/your/rules/modsecurity.d/99_asl_jitp.conf

Include /full/path/to/your/rules/modsecurity.d/98_asl_adv_redactor.conf

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:

Include /full/path/to/your/rules/modsecurity.d/00_asl_z_searchengines.conf
Include /full/path/to/your/rules/modsecurity.d/00_asl_z_aa_threat_intelligence.conf
Include /full/path/to/your/rules/modsecurity.d/99_asl_zzzz_threat_intelligence.conf

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.

[edit] nginx

The same rulesets as apache will work with nginx.

[edit] litespeed

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:

The recommended minimum ruleset to load is:

Include /full/path/to/your/rules/modsecurity.d/00_asl_0_global.conf
Include /full/path/to/your/rules/modsecurity.d/10_asl_antimalware.conf
Include /full/path/to/your/rules/modsecurity.d/10_asl_rules.conf
Include /full/path/to/your/rules/modsecurity.d/11_asl_adv_rules.conf
Include /full/path/to/your/rules/modsecurity.d/20_asl_useragents.conf
Include /full/path/to/your/rules/modsecurity.d/30_asl_antispam.conf
Include /full/path/to/your/rules/modsecurity.d/50_asl_rootkits.conf
Include /full/path/to/your/rules/modsecurity.d/60_asl_recons.conf
Include /full/path/to/your/rules/modsecurity.d/61_asl_recons_dlp.conf
Include /full/path/to/your/rules/modsecurity.d/99_asl_jitp.conf

If you require more advanced protection, you should also load additional rule files and should use this ruleset:

Include /full/path/to/your/rules/modsecurity.d/00_asl_zz_strict.conf
Include /full/path/to/your/rules/modsecurity.d/00_asl_z_searchengines.conf
Include /full/path/to/your/rules/modsecurity.d/00_asl_0_global.conf
Include /full/path/to/your/rules/modsecurity.d/00_asl_z_antievasion.conf
Include /full/path/to/your/rules/modsecurity.d/01_asl_content.conf
Include /full/path/to/your/rules/modsecurity.d/00_asl_zz_strict.conf
Include /full/path/to/your/rules/modsecurity.d/03_asl_dos.conf
Include /full/path/to/your/rules/modsecurity.d/09_asl_rules.conf
Include /full/path/to/your/rules/modsecurity.d/10_asl_antimalware.conf
Include /full/path/to/your/rules/modsecurity.d/10_asl_rules.conf
Include /full/path/to/your/rules/modsecurity.d/11_asl_adv_rules.conf
Include /full/path/to/your/rules/modsecurity.d/11_asl_data_loss.conf
Include /full/path/to/your/rules/modsecurity.d/12_asl_adv_xss_rules.conf
Include /full/path/to/your/rules/modsecurity.d/20_asl_useragents.conf
Include /full/path/to/your/rules/modsecurity.d/30_asl_antispam.conf
Include /full/path/to/your/rules/modsecurity.d/50_asl_rootkits.conf
Include /full/path/to/your/rules/modsecurity.d/51_asl_rootkits.conf
Include /full/path/to/your/rules/modsecurity.d/60_asl_recons.conf
Include /full/path/to/your/rules/modsecurity.d/61_asl_recons_dlp.conf
Include /full/path/to/your/rules/modsecurity.d/99_asl_jitp.conf

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:

00_asl_z_searchengines.conf
00_asl_z_aa_threat_intelligence.conf
12_asl_brute.conf
98_asl_adv_redactor.conf
99_asl_zzzz_threat_intelligence.conf

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.

[edit] Notes on Scanner ruleset

NOTE: If you use this file:

 05_asl_scanner.conf

Or this file:

 99_asl_scanner.conf

ASL includes malware upload scanning, rules subscriptions do not.

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.

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.

[edit] Step 10: Test your web server

[edit] Test nginx

nginx -t -c <NGINX_CONFIG_FILE>

Where NGINX_CONFIG_FILE is your nginx.conf file.

[edit] Test Apache

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:

 /etc/init.d/httpd configtest

If you get errors, check to see that you don't have some extraneous configuration files installed.

[edit] Testing to see if the rules are loaded

Step 1) (for non ASL systems)

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.)

Step 2) Make sure all rules are enabled

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.

Step 3) Test from a non-whitelisted system

Make sure you do not have the system you are performing this from is whitelisted

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.

Step 4) Run the test

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):

wget http://localhost/foo.php?foo=http://www.example.com

If the test worked, should get a 403 error if the rules are loaded, which will look similar to this:

--2010-05-27 20:12:25--  http://localhost/foo.php?foo=http://www.example.com
Resolving localhost... 127.0.0.1
Connecting to localhost|127.0.0.1|:80... connected.
HTTP request sent, awaiting response... 403 Forbidden
2010-05-27 20:12:25 ERROR 403: Forbidden.

If you do not get a 403 error, the test did not work.

You can also use your browser to test the rules by going to a URL similar to this:

http://YOUR_HOST/foo.php?foo=http://www.example.com

Remember to replace YOUR_HOST with the actual HOSTNAME or IP of the server.

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.

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.

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.

[edit] What to do if you do not get a 403 error

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:

1) You have rules disabled

Make sure you do not have any rules disabled.

2) Your IP is whitelisted

There is a rule whitelisting the system you are conducting this test from. Whitelisting tells the WAF to ignore everything from that source.

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.

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.

3) Local error message is different

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.

4) Third party addons

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

5) Insecurely configured apache

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.

Example:

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.

<VirtualHost <LOCAL IP ADDRESS>:80 127.0.0.1:80 *>
 <IfModule mod_security2.c>
      SecRuleEngine Off
</IfModule>

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.

6) You arent loading the rules

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:

--70c19f31-A--
[01/Jan/2013:11:19:13 --0300] roiKIi6Ni3EKFZSKpSUs2iEb 1.2.3.4 34978 5.6.7.8 80
--70c19f31-B--
HEAD / HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) 

Accept: */*

--70c19f31-F--
HTTP/1.1 403 Forbidden
X-Powered-By: PHP/5.4.20
Expires: Thu, 19 Jan 2001 02:12:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Connection: close
Content-Type: text/html

--70c19f31-H--
Stopwatch: 1383338363503919 358184 (- - -)
Stopwatch2: 1383338363503919 358184; combined=2144, p1=37, p2=2053, p3=0, p4=0, p5=53, sr=0, sw=1, l=0, gc=0
Producer: ModSecurity for Apache/2.7.5 ( http://www.modsecurity.org/).
Server: Apache
Engine-Mode: "ENABLED"

--70c19f31-Z--

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.

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.

[edit] Windows

Please see the modsecurity iis page.

[edit] Automated rules updates

Please see the ASL page for installation instructions.

[edit] Tuning the Rules/Disabling Rules

[edit] Disabling Rules

See the mod_security page for details.

[edit] Tuning the Rules

See the mod_security page for details.

[edit] Troubleshoot the Rules

See the Atomicorp WAF Rules Troubleshooting page for details.

[edit] Reporting False Positives

See the Reporting False Positives page for details.

[edit] Notes

[edit] Special notes for CPANEL users not using ASL

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!

[edit] Installing modsecurity in cpanel

Option 1) Simplest and most powerful solution

Install ASL. This will install modsecurity, configure it and will install the rule and event management GUI available in ASL

Option 2) Install just the rules

[edit] Manually Configuring modsecurity with cpanel

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).

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.

[edit] Step 1

Make sure you have read this entire document and have setup all the require directories details above.

[edit] Step 2: Configure directory permissions

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:

ps auxwww | grep httpd

root     20594 86.8  3.1 255148 181232 ?       Ss   11:39   0:04 /usr/local/apache/bin/httpd -k restart
root     20611  0.0  3.1 255060 179596 ?       S    11:39   0:00 /usr/local/apache/bin/httpd -k restart
nobody   20612  0.0  3.1 255148 180224 ?       S    11:39   0:00 /usr/local/apache/bin/httpd -k restart
nobody   20613  0.0  3.1 255148 180224 ?       S    11:39   0:00 /usr/local/apache/bin/httpd -k restart
nobody   20614  0.0  3.1 255148 180224 ?       S    11:39   0:00 /usr/local/apache/bin/httpd -k restart
nobody   20615  0.0  3.1 255148 180224 ?       S    11:39   0:00 /usr/local/apache/bin/httpd -k restart
nobody   20616  0.0  3.1 255148 180224 ?       S    11:39   0:00 /usr/local/apache/bin/httpd -k restart

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":

mkdir /var/asl
mkdir /var/asl/data/
mkdir /var/asl/data/msa
mkdir /var/asl/data/audit
mkdir /var/asl/data/suspicious
chown nobody.nobody /var/asl/data/msa
chown nobody.nobody /var/asl/data/audit
chown nobody.nobody /var/asl/data/suspicious
chmod o-rx -R /var/asl/data/*
chmod ug+rwx -R /var/asl/data/*

[edit] Step 3: Install modsecurity

Please see the current minimum version required at the link below:

https://www.atomicorp.com/wiki/index.php/Atomic_ModSecurity_Rules#Minimum_Version_of_Modsecurity_Required_to_use_the_rules

[edit] Step 4: Install mod_uniqueid

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.

[edit] Step 5: Configure cpanel

A typical cpanel modsec2.conf configuration file looks like this:

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

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).

[edit] Step 5a: Remote Rules

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:

SecRemoteRulesFailAction Warn

SecRemoteRules <API Key> https://waf.atomicorp.com/rules/srr.php

Additional rule classes can be specified as follows

SecRemoteRules <API Key> https://waf.atomicorp.com/rules/srr.php?antispam,recons

A full list of rule classes is available at [1].

[edit] Step 5a: Downloadable Rules

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.

 SecRequestBodyAccess On
 SecAuditLogType Concurrent
 SecResponseBodyAccess On
 SecResponseBodyMimeType (null) text/html text/plain text/xml
 SecResponseBodyLimit 2621440
 SecAuditLogRelevantStatus "^(?:5|4(?!04))"
 SecServerSignature Apache
 SecUploadDir /var/asl/data/suspicious
 SecUploadKeepFiles Off
 SecAuditLogParts ABIFHZ
 SecArgumentSeparator "&"
 SecCookieFormat 0
 SecRequestBodyInMemoryLimit 131072
 SecDataDir /var/asl/data/msa
 SecTmpDir /tmp
 SecAuditLogStorageDir /var/asl/data/audit
 SecResponseBodyLimitAction ProcessPartial
  
Include /full/path/to/your/rules/modsecurity.d/00_asl_z_antievasion.conf
Include /full/path/to/your/rules/modsecurity.d/00_asl_zz_strict.conf
Include /full/path/to/your/rules/modsecurity.d/09_asl_rules.conf
Include /full/path/to/your/rules/modsecurity.d/10_asl_antimalware.conf
Include /full/path/to/your/rules/modsecurity.d/10_asl_rules.conf
Include /full/path/to/your/rules/modsecurity.d/11_asl_adv_rules.conf
Include /full/path/to/your/rules/modsecurity.d/20_asl_useragents.conf
Include /full/path/to/your/rules/modsecurity.d/30_asl_antispam.conf
Include /full/path/to/your/rules/modsecurity.d/50_asl_rootkits.conf
Include /full/path/to/your/rules/modsecurity.d/60_asl_recons.conf
Include /full/path/to/your/rules/modsecurity.d/61_asl_recons_dlp.conf
Include /full/path/to/your/rules/modsecurity.d/99_asl_jitp.conf

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.

Then run this command as root to install the rules:

aum -u

Or if you want to install the rules files manually, please see the Downloading rules section above.

[edit] Step 7: Restart Apache

Restart apache, enjoy your new secure web server!

[edit] Optional Steps

[edit] Malware Scanner

The malware scanner is included in ASL, it is not included in the rules or rule subscriptions. Therefore, if you use this file:

 05_asl_scanner.conf

Or this:

 99_asl_scanner.conf

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.

[edit] Cpanel Error Messages

[edit] modsecparse.pl

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.

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":

SecAuditLogType Serial

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.

[edit] Serial logging

[edit] Discussion

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.

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.

[edit] Configuration

[edit] aum

If you want to use the old slower serial logging method, and you are using aum, change this setting in /etc/asl/config:

MODSEC_LOGTYPE="Concurrent"

To:

MODSEC_LOGTYPE="Serial"

And then run:

aum -uf

[edit] non-aum systems

If you want to use the old slower serial logging method change the SecAuditLogType setting from "Concurrent" to "Serial":

SecAuditLogType Serial

Warning: Serial logging is much slower than concurrent logging and will slow down apache. Any performance impact is not caused by the rules.

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.

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:

SecAuditLog logs/audit_log

@@ Line 1: / Line 1: @@
 [[Atomic Secured Linux]] includes modsecurity, and the Real Time GotRoot.com/Atomicorp Modsecurity Rules.    These docs are for users that do not have [[ASL]].
-'''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/products.html upgrade to ASL today!]'''
+'''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!]'''
 = '''About the rules''' =
@@ Line 11: / Line 11: @@
 '''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.
-'''Free/Delayed Rules:'''  A subset of the realtime rules, which were based on older version.  This project was discontinued in October 2013.
+'''Free/Delayed Rules:'''  A delayed subset of the Advanced rules.
 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.
+== Getting the rules ==
+[https://www.atomicorp.com/amember/cart/index/index?c=6 Click here] to get the Atomicorp ModSecurity Rules.
 == '''Atomic ModSecurity Rules Frequently Asked Questions''' ==
@@ Line 25: / Line 29: @@
 support@atomicorp.com
-The Customer Support Forums are located here (you can post here, but these forums are for the labs and free rules, if you post the customer forums the support team monitors those forums regularly):
+The Customer Support Forums are located here:
 [http://www.atomicorp.com/forums Customer Support Forums]
@@ Line 35: / Line 39: @@
 == '''Licenses''' ==
-The Real Time Atomic ModSecurity Rules are licensed by the server.  For each license you can also run the rules on one Development and one QA server.
+The Real Time Atomic ModSecurity Rules are licensed by the server.  You can order licenses from the online store at the link below:
+[https://www.atomicorp.com/amember/cart/index/index?c=6 Online Store]
 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.
-== Important Information about the Rules ==
+=== License Terms and Conditions ===
-=== Minimum Version of Modsecurity Required to use the rules ===
+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.
-'''The Atomicorp modsecurity rules are written for the latest stable version of modsecurity.  Currently that is 2.7.5.'''
+Atomicorp ModSecurity rules installed upon a Reverse Proxy WAF appliance/server requires a separate license. Please contact Atomicorp support for details.
-Users of the rules should ensure that they are always using the latest stable version of modsecurity, as these updates contain important security bug fixes.  The latest stable version also includes new capabilities that are required for new attacks, and these capabilities may not be available in older versions of modsecurity. In some cases, the rules may not load in older version of modsecurity, in others these fixes may be critical to prevent evasion attacks on modsecurity itself.
+The rule set cannot be copied, mirrored, or reproduced under protection of US and International copyright laws.
-If you need a solution to keep the rules and modsecurity up to date automatically, please use [[ASL]] which will do this for you automatically.
+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.
-=== What does each rule family do?  ===
+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.
-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 almost ten years ago.
+== Important Information about the Rules ==
-====00_asl_y_searchengines.conf ====
+=== Minimum Version of Modsecurity Required to use the rules ===
-''(Available in ASL and the real time rules only)''
+The rules are supported with the following versions of Modsecurity:
-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.
-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".
+* 2.9.3
-Warning:  If you do not have either [[ASL]] installed, or apache configured correctly to use these rules they will not work correctly.
+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.
-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.
+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.
-Requires: Modsecurity 2.7.0 and up.
+==== What versions of modsecurity do the rules work with ====
-====00_asl_zz_strict.conf====
+They work with both modsecurity 2.9.x, and modsecurity 3.x.
-'''Note: Requires modsecurity 2.7.0 and higher.'''
+=== What does each rule family do?  ===
-This enforces strict adherence to the HTTP RFCs.
+Please see the [[modsecurity_rule_families]] documents.
-Requires: Modsecurity 2.7.0 and up.
+= Installation =
-====00_asl_0_global.conf====
+== Easy One Step Installation ==
-This is a global variable file, it is only used if you have modsecurity 2.5.13 and above installed.
-====00_asl_rbl.conf====
-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.
+===== Full Management Suite =====
-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.
+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.
-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.
+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.
-''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.''
+A full list of ASLs features is available at the URL below:
-Requires: Modsecurity 2.6.0 and up.
+https://www.atomicorp.com/products/asl.html
-====00_asl_whitelist.conf====
+===== Just a downloader =====
-Allows you to whitelist hosts from the WAF.
+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:
-Requires: Modsecurity 2.7.0 and up.
+Step 1) Install [[aum]]
-====01_asl_content.conf====
+''wget -q -O - https://updates.atomicorp.com/installers/aum |bash''
-These rules restrict the server to known content types that the WAF can correctly decipher.
+Step 2) Configure [[aum]]
-Requires: Modsecurity 2.7.0 and up.
+''aum configure''
-====01_asl_rules_special.conf====
+Step 3) Tell [[aum]] to install the rules
-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.
+''aum upgrade''
-Requires: Modsecurity 2.7.0 and up.
+You can read more about aum on the [[aum]] documentation page.
-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.
+Note:  This capability is included in [[ASL]].  ASL users do not need to install aum, its already included.
-====05_asl_exclude.conf====
-Pre-load rule exclusion list.  Turns off rules that need to be disabled early in the process.  ASL manages this process automatically.
-Requires: Modsecurity 2.7.0 and up.
-====00_asl_z_antievasion.conf====
-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.
-====05_asl_scanner.conf ====
-Scans all uploads to the system for malware.  The malware scanner is provided with ASL, if you are not running ASL you will need to provide your own malware scanner.  This rule set simply directs the file stream into the malware scanner and checks the results, if its tagged malware the upload will be blocked.
-====10_asl_antimalware.conf====
-Checks payload and RFI contents for known sources of malware and malware payloads and will block them.
-Requires: Modsecurity 2.6.0 and up.
-====09_asl_rules.conf====
-'''This ruleset is only supported with [[ASL]].'''  It may work without ASL, but is not supported without ASL.
-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.
-====10_asl_rules.conf ====
-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.7.5 and above.'''
-Requires: Modsecurity 2.7.5 and up.
-====11_asl_adv_rules.conf====
-These are advanced rules, and '''can only be used with modsecurity 2.7.5 and above.'''
-Requires: Modsecurity 2.7.5 and up.
-====11_asl_data_loss.conf====
-Experimental data leakage rules.  Looks for credit card numbers and other potentially sensitive information leaking from the system.
-Requires: Modsecurity 2.7.0 and up.
-====12_asl_brute.conf====
-'''This ruleset is only available with [[ASL]] or the Real Time Rules.'''
-This ruleset detects brute force attacks against all major web applications (Joomla, WordPress, MovableType, Drupal, ModX, ZenCart, OsCommerce, VBulletin, PHPBB and more).
-Requires: Modsecurity 2.6.8 and up.  [[ASL]] is necessary to perform active response to brute force attacks.
-====20_asl_useragents.conf====
-Looks for malicious or suspicious user agents and known patterns of malicious activity.  These rules require modsecurity 2.7.1 and up.
-Requires: Modsecurity 2.7.1 and up.
-====30_asl_antispam.conf====
-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.
-Requires: Modsecurity 2.6.8 and up.
-====30_asl_antispam_advanced.conf====
-(Not released yet)  These are advanced spam rules.  They require modsecurity 2.7.1 and up.
-Requires: Modsecurity 2.7.1 and up.
-====30_asl_antispam_referrer.conf====
-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).
-Requires: Modsecurity 2.6.0 and up.
-====40_asl_apache2-rules.conf====
-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.
-====50_asl_rootkits.conf====
-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)
-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.
-Requires: Modsecurity 2.7.0 and up.
-====51_asl_rootkits.conf====
-These rules look for known malware names in filenames, and URLs.
-Requires: Modsecurity 2.7.0 and up.
-====60_asl_recons.conf====
-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.
-Requires: Modsecurity 2.7.0 and up.
-====61_asl_recons_dlp.conf====
-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.
-Requires: Modsecurity 2.7.0 and up.
-====70_asl_csrf_experimental.conf====
-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.
-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.
-'''They are currently not supported and are experimental.'''
-Requires: Modsecurity 2.7.0 and up.
-====99_asl_a_redactor.conf====
-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. '''
-====99_asl_exclude.conf====
-Post exclude rules.
-====98_asl_adv_redactor.conf====
-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.
-''This ruleset is in testing, and should be considered beta quality.''
-'''Requires: modsecurity 2.7.5 and up.'''
-====98_asl_jitp.conf====
-This is a special ruleset used by [[ASL]].  If you do not have [[ASL]] you can not use these rules.
-====99_asl_jitp.conf====
-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.
-Requires: Modsecurity 2.7.0 and up.
-====99_asl_a_redactor.conf====
-[[ASL]] only rule set.  Part of the malicious code removal system.  Automatically remove 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.  This is a special ruleset that ASL uses and ASL will enable this ruleset if it needs it.  This ruleset is only supported with [[ASL]].
-====99_asl_redactor.conf====
-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]].
-====99_asl_redactor_post.conf====
-[[ASL]] only rule set.  Part of the malicious code removal system.  Automatically remove 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.  This is a special ruleset that ASL uses and ASL will enable this ruleset if it needs it.  This ruleset is only supported with [[ASL]].
-====99_asl_scanner.conf====
-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]].
-==== Paranoid mode rules ====
-===== 15_asl_paranoid_rules.conf =====
-'''Note: Do not use these rules if you have not read this section.'''
-'''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.'''
-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.
-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.
-For example, if you had a application that safely used the argument "url" to accept URLs:
-GET /application?url=http://www.example.com/safething
-The normal rules would allow this, if this was known to be safe for the application.
-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.
-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.
-Example configuration lines for the paranoid rules:
-<pre>
-SecDefaultAction "log,pass,auditlog,phase:2,t:none,t:lowercase,t:replaceNulls,t:compressWhitespace"
-Include modsecurity.paranoid.rules.d/15_asl_paranoid_rules.conf
-</pre>
-You must load these rules last.
-Requires: Modsecurity 2.7.0 and up.
-==== Using the paranoid rules ====
-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.
-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.
-'''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.'''
-= Installation =
-== Easy One Step Installation ==
-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.
-== Do It Yourself Installation ==
+== (Optional) Do It Yourself Installation ==
-Note:  A manual installation is not necessary if you have [[ASL]] installed.  ASL will configure and install modsecurity, and the rules, automatically.
+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.
-=== Step 1: Download ModSecurity ===
+=== Linux ===
-RPMs:
+==== Step 1: Download ModSecurity ====
-[http://www.atomicorp.com/channels/atomic/ Install modsecurity from the Atomicorp RPM repository]
+Binaries:
-Source:
+[http://updates.atomicorp.com/channels/atomic/ Install modsecurity from the Atomicorp software repository]
-If you wish to build modsecurity yourself, you can find it on sourceforge :
+Source Code:
-https://github.com/SpiderLabs/ModSecurity/
+[http://updates.atomicorp.com/channels/atomic/ Install modsecurity from the Atomicorp software repository]
-'''Note:  We do not provide support for source installs of modsecurity or third party builds of modsecurity.'''.
+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.]
-=== Step 2:  Set up and configure directories ===
+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.
-'''If you are you are using a standard apache installation you can skip this step.'''  If you are not using a standard apache installation, such as cpanel and source builds of apache you will need to follow this step.
+==== Step 2:  Set up and configure directories ====
 Create the following directories as root:
@@ Line 348: / Line 146: @@
    mkdir /var/asl/data/suspicious
-=== Step 3:  Set permissions for directories ===
+==== Step 3:  Set permissions for directories ====
 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.
-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:
+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:
    ps auxwww | grep httpd
@@ Line 397: / Line 195: @@
    chmod ug+rwx -R /var/asl/data/*
-=== Step 4: (Optional) Create rule updater directories ===
+==== Step 4: (Optional) Create rule updater directories ====
 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:
@@ Line 405: / Line 202: @@
    mkdir /var/asl/rules/clamav
-=== Step 5: Create the whitelist file ===
+==== Step 5: Create the whitelist file ====
 Create this file:
@@ Line 415: / Line 212: @@
 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.
-=== Step 6: Configure your webserver ===
+==== Step 6: Configure your webserver ====
-==== nginx ====
+===== nginx =====
 ===== Step 6a: configure nginx to load modsecurity =====
-Add the following directives to your nginx.conf file.
+====== nginx proxying to a backend ======
+If you are using nginx as a frontend to another webserver, then add the following directives to your nginx.conf file.
 <pre>
@@ Line 427: / Line 226: @@
             ModSecurityEnabled on;
             ModSecurityConfig modsecurity.conf;
-           ModSecurityPass @backend;
+            proxy_pass http://localhost:8080;
-       }
-location @backend {
-            proxy_pass http://localhost:8011;
             proxy_read_timeout 180s;
         }
 </pre>
-==== Apache ====
+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:
+           proxy_pass http://localhost:8088;
+====== nginx standalone ======
+If you are only using nginx, and not using it as a frontend to another web server then you want to use this configuration:
+<pre>
+location / {
+ModSecurityEnabled on;
+ModSecurityConfig modsecurity.conf;
+}
+</pre>
+===== Apache =====
 ===== Step 6a: configure apache to load modsecurity =====
@@ Line 475: / Line 286: @@
    SecAuditLogType Concurrent
    SecAuditLog logs/audit_log
-   SecAuditLogParts ABIFHZ
+   [[SecAuditLogParts]] ABIFHZ
    SecArgumentSeparator "&"
    SecCookieFormat 0
@@ Line 499: / Line 310: @@
 [[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.
-=== Step 8: Download the ModSecurity Rules ===
+==== Step 8: Download the ModSecurity Rules ====
 See the [[Downloading Rules]] page.
-=== Step 9: Install the rules ===
+==== Step 9: Install the rules ====
 ==== Remove any previous installations of rules ====
@@ Line 521: / Line 332: @@
    tar zxvf /var/asl/updates/modsec-200911012341.tar.gz
-Then copy the ASL rules into /etc/httpd/modsecurity.d:
+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.
-  cp modsec/*  /etc/httpd/modsecurity.d/
 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.
@@ Line 534: / Line 343: @@
 '''Warning: You should NOT include all the rules.  There are rulesets, documented above, that replace other rulesets and are incompatible with each other.'''
-==== Recommend minimum rulesets ====
+===== Recommend minimum rulesets =====
+====== apache ======
 The recommended ''minimum ruleset'' to load is:
+ Include /full/path/to/your/rules/modsecurity.d/00_asl_0_global.conf
   Include /full/path/to/your/rules/modsecurity.d/10_asl_antimalware.conf
   Include /full/path/to/your/rules/modsecurity.d/10_asl_rules.conf
@@ Line 548: / Line 360: @@
   Include /full/path/to/your/rules/modsecurity.d/99_asl_jitp.conf
-If you have modsecurity 2.6.3 and up installed, you should also load additional rule files and should use this ruleset:
+If you have modsecurity 2.9.0 and up installed, you should also load additional rule files and should use this ruleset:
+ Include /full/path/to/your/rules/modsecurity.d/000_asl_threat_intelligence.conf
+ Include /full/path/to/your/rules/modsecurity.d/00_asl_zz_strict.conf
+ Include /full/path/to/your/rules/modsecurity.d/00_asl_0_global.conf
+ Include /full/path/to/your/rules/modsecurity.d/00_asl_z_antievasion.conf
+ Include /full/path/to/your/rules/modsecurity.d/01_asl_content.conf
+ Include /full/path/to/your/rules/modsecurity.d/01_asl_content_z.conf
+ Include /full/path/to/your/rules/modsecurity.d/03_asl_dos.conf
+ Include /full/path/to/your/rules/modsecurity.d/09_asl_rules.conf
+ Include /full/path/to/your/rules/modsecurity.d/10_asl_antimalware.conf
+ Include /full/path/to/your/rules/modsecurity.d/10_asl_rules.conf
+ Include /full/path/to/your/rules/modsecurity.d/11_asl_adv_rules.conf
+ Include /full/path/to/your/rules/modsecurity.d/11_asl_data_loss.conf
+ Include /full/path/to/your/rules/modsecurity.d/12_asl_adv_xss_rules.conf
+ Include /full/path/to/your/rules/modsecurity.d/20_asl_useragents.conf
+ Include /full/path/to/your/rules/modsecurity.d/30_asl_antispam.conf
+ Include /full/path/to/your/rules/modsecurity.d/50_asl_rootkits.conf
+ Include /full/path/to/your/rules/modsecurity.d/51_asl_rootkits.conf
+ Include /full/path/to/your/rules/modsecurity.d/60_asl_recons.conf
+ Include /full/path/to/your/rules/modsecurity.d/61_asl_recons_dlp.conf
+ Include /full/path/to/your/rules/modsecurity.d/99_asl_jitp.conf
+Include /full/path/to/your/rules/modsecurity.d/98_asl_adv_redactor.conf
+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:
+ Include /full/path/to/your/rules/modsecurity.d/00_asl_z_searchengines.conf
+ Include /full/path/to/your/rules/modsecurity.d/00_asl_z_aa_threat_intelligence.conf
+ Include /full/path/to/your/rules/modsecurity.d/99_asl_zzzz_threat_intelligence.conf
+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.
+====== nginx ======
+The same rulesets as apache will work with nginx.
+====== litespeed ======
+[[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:
+The recommended ''minimum ruleset'' to load is:
+ Include /full/path/to/your/rules/modsecurity.d/00_asl_0_global.conf
+ Include /full/path/to/your/rules/modsecurity.d/10_asl_antimalware.conf
+ Include /full/path/to/your/rules/modsecurity.d/10_asl_rules.conf
+ Include /full/path/to/your/rules/modsecurity.d/11_asl_adv_rules.conf
+ Include /full/path/to/your/rules/modsecurity.d/20_asl_useragents.conf
+ Include /full/path/to/your/rules/modsecurity.d/30_asl_antispam.conf
+ Include /full/path/to/your/rules/modsecurity.d/50_asl_rootkits.conf
+ Include /full/path/to/your/rules/modsecurity.d/60_asl_recons.conf
+ Include /full/path/to/your/rules/modsecurity.d/61_asl_recons_dlp.conf
+ Include /full/path/to/your/rules/modsecurity.d/99_asl_jitp.conf
+If you require more advanced protection, you should also load additional rule files and should use this ruleset:
+ Include /full/path/to/your/rules/modsecurity.d/00_asl_zz_strict.conf
+ Include /full/path/to/your/rules/modsecurity.d/00_asl_z_searchengines.conf
+ Include /full/path/to/your/rules/modsecurity.d/00_asl_0_global.conf
   Include /full/path/to/your/rules/modsecurity.d/00_asl_z_antievasion.conf
+ Include /full/path/to/your/rules/modsecurity.d/01_asl_content.conf
   Include /full/path/to/your/rules/modsecurity.d/00_asl_zz_strict.conf
+ Include /full/path/to/your/rules/modsecurity.d/03_asl_dos.conf
   Include /full/path/to/your/rules/modsecurity.d/09_asl_rules.conf
   Include /full/path/to/your/rules/modsecurity.d/10_asl_antimalware.conf
   Include /full/path/to/your/rules/modsecurity.d/10_asl_rules.conf
   Include /full/path/to/your/rules/modsecurity.d/11_asl_adv_rules.conf
+ Include /full/path/to/your/rules/modsecurity.d/11_asl_data_loss.conf
+ Include /full/path/to/your/rules/modsecurity.d/12_asl_adv_xss_rules.conf
   Include /full/path/to/your/rules/modsecurity.d/20_asl_useragents.conf
   Include /full/path/to/your/rules/modsecurity.d/30_asl_antispam.conf
   Include /full/path/to/your/rules/modsecurity.d/50_asl_rootkits.conf
+ Include /full/path/to/your/rules/modsecurity.d/51_asl_rootkits.conf
   Include /full/path/to/your/rules/modsecurity.d/60_asl_recons.conf
   Include /full/path/to/your/rules/modsecurity.d/61_asl_recons_dlp.conf
   Include /full/path/to/your/rules/modsecurity.d/99_asl_jitp.conf
+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:
+_asl_z_searchengines.conf
+_asl_z_aa_threat_intelligence.conf
+_asl_brute.conf
+_asl_adv_redactor.conf
+_asl_zzzz_threat_intelligence.conf
 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.
-==== Notes on Scanner ruleset ====
+===== Notes on Scanner ruleset =====
 NOTE:  If you use this file:
@@ Line 581: / Line 464: @@
 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]].
-=== Step 10: Test your web server ===
+==== Step 10: Test your web server ====
+===== Test nginx =====
-==== Test nginx ====
 nginx -t -c <NGINX_CONFIG_FILE>
@@ Line 589: / Line 471: @@
 Where NGINX_CONFIG_FILE is your nginx.conf file.
-==== Test Apache ====
+===== Test Apache =====
 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:
@@ Line 597: / Line 479: @@
 If you get errors, check to see that you don't have some extraneous configuration files installed.
-==== Testing to see if the rules are loaded ====
+===== Testing to see if the rules are loaded =====
+'''
+Step 1)''' (for non [[ASL]] systems)
-Step 1) (for non [[ASL]] systems) 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.)
+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.)
-Step 2)  Make sure all rules are enabled
+'''Step 2)  Make sure all rules are enabled'''
 '''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.
-Step 3) Make sure you do not have the system you are performing this from is whitelisted
+'''Step 3) Test from a non-whitelisted system'''
+Make sure you do not have the system you are performing this from is whitelisted
 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.
-Step 4) Run the test
+'''Step 4) Run the test'''
-On the system where the rules are installed run this command (this assumes you have wget installed):
+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):
 ''wget http://localhost/foo.php?foo=http://www.example.com''
@@ Line 626: / Line 512: @@
 If you do not get a 403 error, the test did not work.
 You can also use your browser to test the rules by going to a URL similar to this:
 http://YOUR_HOST/foo.php?foo=http://www.example.com
+Remember to replace YOUR_HOST with the actual HOSTNAME or IP of the server.
 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.
+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.
 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.
-===== What to do if you do not get a 403 error =====
+====== What to do if you do not get a 403 error ======
 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:
@@ Line 648: / Line 539: @@
 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.
-Note: Whitelisting the server itself can open a hole in your security.  You should not whitelist localhost or the servers own IP address.  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.
+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.
 '''3) Local error message is different'''
@@ Line 710: / Line 601: @@
 [[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.
+=== Windows ===
+Please see the [[modsecurity iis]] page.
 == Automated rules updates ==
@@ Line 759: / Line 654: @@
 ====  Step 2:  Configure directory permissions ====
-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:
+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:
   ps auxwww | grep httpd
@@ Line 790: / Line 685: @@
 https://www.atomicorp.com/wiki/index.php/Atomic_ModSecurity_Rules#Minimum_Version_of_Modsecurity_Required_to_use_the_rules
-==== Step 4: Configure cpanel ====
+==== Step 4: Install mod_uniqueid ====
-Make a small change to the cpanel modsecurity configuration.  A typical cpanel modsec2.conf configuration file looks like this:
+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.
+==== Step 5: Configure cpanel ====
+A typical cpanel modsec2.conf configuration file looks like this:
    LoadFile /opt/xml2/lib/libxml2.so
@@ Line 811: / Line 710: @@
    </IfModule>
-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 rule sets that are designed to work with cpanel without [[ASL]] installed.  Use of other rule sets with cpanel, when not using [[ASL]] are not supported:
+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).
+==== Step 5a: Remote Rules ====
+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:
+''SecRemoteRulesFailAction Warn
+SecRemoteRules <API Key> https://waf.atomicorp.com/rules/srr.php''
+Additional rule classes can be specified as follows
+''SecRemoteRules <API Key> https://waf.atomicorp.com/rules/srr.php?antispam,recons''
+A full list of rule classes is available at [https://docs.atomicorp.com/gotrootModsec/remoterules.html].
+==== Step 5a: Downloadable Rules ====
+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.
    SecRequestBodyAccess On
@@ Line 831: / Line 748: @@
    SecResponseBodyLimitAction ProcessPartial
-  Include /usr/local/apache/conf/modsec_rules/10_asl_antimalware.conf
+ Include /full/path/to/your/rules/modsecurity.d/00_asl_z_antievasion.conf
-  Include /usr/local/apache/conf/modsec_rules/10_asl_rules.conf
+ Include /full/path/to/your/rules/modsecurity.d/00_asl_zz_strict.conf
-  Include /usr/local/apache/conf/modsec_rules/20_asl_useragents.conf
+ Include /full/path/to/your/rules/modsecurity.d/09_asl_rules.conf
-  Include /usr/local/apache/conf/modsec_rules/30_asl_antispam.conf
+ Include /full/path/to/your/rules/modsecurity.d/10_asl_antimalware.conf
-  Include /usr/local/apache/conf/modsec_rules/50_asl_rootkits.conf
+ Include /full/path/to/your/rules/modsecurity.d/10_asl_rules.conf
-  Include /usr/local/apache/conf/modsec_rules/60_asl_recons.conf
+ Include /full/path/to/your/rules/modsecurity.d/11_asl_adv_rules.conf
-  Include /usr/local/apache/conf/modsec_rules/99_asl_jitp.conf
+ Include /full/path/to/your/rules/modsecurity.d/20_asl_useragents.conf
+ Include /full/path/to/your/rules/modsecurity.d/30_asl_antispam.conf
+ Include /full/path/to/your/rules/modsecurity.d/50_asl_rootkits.conf
+ Include /full/path/to/your/rules/modsecurity.d/60_asl_recons.conf
+ Include /full/path/to/your/rules/modsecurity.d/61_asl_recons_dlp.conf
+ Include /full/path/to/your/rules/modsecurity.d/99_asl_jitp.conf
 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]].
-'''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.'''
+Then run this command as root to install the rules:
-==== Step 5: Install mod_uniqueid ====
+[[aum]] -u
-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.
+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.
-==== Step 6: Install the rules ====
-===== Automatic Rule Updater =====
-Run [[ASL]]:
-aum -u
-===== Manually install the rules =====
-See the [https://www.atomicorp.com/wiki/index.php/Atomic_ModSecurity_Rules#Step_8:_Download_the_ModSecurity_Rules Downloading rules] section above.
 ==== Step 7: Restart Apache ====
 Restart apache, enjoy your new secure web server!
 ==== Optional Steps ====
@@ Line 882: / Line 794: @@
 ==== modsecparse.pl ====
-'''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. Thank you for fixing the file, next time I will do what you say.
+'''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.
 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":
@@ Line 889: / Line 801: @@
 '''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.
+==== Serial logging ====
+===== Discussion =====
+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.
+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.
+===== Configuration =====
+====== aum ======
+If you want to use the old slower serial logging method, and you are using aum, change this setting in /etc/asl/config:
+MODSEC_LOGTYPE="Concurrent"
+To:
+MODSEC_LOGTYPE="Serial"
+And then run:
+aum -uf
+====== non-aum systems ======
+If you want to use the old slower serial logging method change the SecAuditLogType setting from "Concurrent" to "Serial":
+SecAuditLogType Serial
+'''Warning:  Serial logging is much slower than concurrent logging and will slow down apache.'''   Any performance impact is not caused by the rules.
+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.
+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:
+SecAuditLog logs/audit_log

Difference between revisions of "Atomic ModSecurity Rules"

Latest revision as of 16:30, 6 October 2022

Contents

[edit] About the rules

[edit] Getting the rules

[edit] Atomic ModSecurity Rules Frequently Asked Questions

[edit] Real Time Rule Support

[edit] Licenses

[edit] License Terms and Conditions

[edit] Important Information about the Rules

[edit] Minimum Version of Modsecurity Required to use the rules

[edit] What versions of modsecurity do the rules work with

[edit] What does each rule family do?

[edit] Installation

[edit] Easy One Step Installation

[edit] Full Management Suite

[edit] Just a downloader

[edit] (Optional) Do It Yourself Installation

[edit] Linux

[edit] Step 1: Download ModSecurity

[edit] Step 2: Set up and configure directories

[edit] Step 3: Set permissions for directories

[edit] Step 4: (Optional) Create rule updater directories

[edit] Step 5: Create the whitelist file

[edit] Step 6: Configure your webserver

[edit] nginx

[edit] Step 6a: configure nginx to load modsecurity

[edit] nginx proxying to a backend

[edit] nginx standalone

[edit] Apache

[edit] Step 6a: configure apache to load modsecurity

[edit] Step 7: Configure modsecurity

[edit] tortix_waf.conf

[edit] Step 8: Download the ModSecurity Rules

[edit] Step 9: Install the rules

[edit] Remove any previous installations of rules

[edit] Installation

[edit] Recommend minimum rulesets

[edit] apache

[edit] nginx

[edit] litespeed

[edit] Notes on Scanner ruleset

[edit] Step 10: Test your web server

[edit] Test nginx

[edit] Test Apache

[edit] Testing to see if the rules are loaded

[edit] What to do if you do not get a 403 error

[edit] Windows

[edit] Automated rules updates

[edit] Tuning the Rules/Disabling Rules

[edit] Disabling Rules

[edit] Tuning the Rules

[edit] Troubleshoot the Rules

[edit] Reporting False Positives

[edit] Notes

[edit] Special notes for CPANEL users not using ASL

[edit] Installing modsecurity in cpanel

[edit] Manually Configuring modsecurity with cpanel

[edit] Step 1

[edit] Step 2: Configure directory permissions

[edit] Step 3: Install modsecurity

[edit] Step 4: Install mod_uniqueid

[edit] Step 5: Configure cpanel

[edit] Step 5a: Remote Rules

[edit] Step 5a: Downloadable Rules

[edit] Step 7: Restart Apache

[edit] Optional Steps

[edit] Malware Scanner

[edit] Cpanel Error Messages

[edit] modsecparse.pl

[edit] Serial logging

[edit] Discussion

[edit] Configuration

[edit] aum

[edit] non-aum systems

Views

Personal tools

Navigation

Search

Toolbox