Assuming you have a modsecurity 2.5.12 rpm (or higher) installed from the atomic archives, you will want to create these directories as root:
Note: You are encouraged to use our rpms, any issues involving non-atomicorp builds of mod_security are not supported under rules-only subscriptions.
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
Then set the following permissions on these directories as follows
below. 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. Check your system to see
what user your system uses. You can use this command to find the user:
ps auxwww | grep httpd
(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/*
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
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.
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 do this. This installation guide is written for this type of configuration. Loading mod_security occurs by including a modsecurity.conf 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 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
Include modsecurity.d/modsecurity_crs_10_config.conf
Install this file in your conf.d directory. On a standard RHEL or Centos system that directory is located here:
/etc/httpd/conf.d/
You then need to create your modsecurity_crs_10_config.conf. Here is an example file that also 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
Note: If you are not using our mod_security rpms you will need to add these additional lines to your mod_security configuration:
SecPcreMatchLimit 100000 SecPcreMatchLimitRecursion 100000
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
You are now ready to install the rules.
Installing the rules
If you configure the rules updater, this process should be taken care of for you. If you choose to do this manually, follow the instructions below.
Download the rules to a temporary directory using your favorite download tool. Extract the rules:
Download the rules from here
http://updates.atomicorp.com/channels/rules/delayed/
tar zxvf /var/asl/updates/modsec-200911012341.tar.gz
Then copy the ASL rules into /etc/httpd/modsecurity.d:
cp modsec/* /etc/httpd/modsecurity.d/
Finally, load the rules. Make sure you have this line in your
Then make sure you have this line are the bottom of 00_modsecurity.conf, if you want to load all the rules (please read the bottom of this wiki article for what each ruleset does, you may not want to load all the rules):
Include /full/path/to/your/rules/modsecurity.d/*asl*.conf
Or if you want to load some of the rules, make sure you specify only those rule files. 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
The recommended ruleset to load is:
Include /full/path/to/your/rules/modsecurity.d/05_asl_exclude.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/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
NOTE: If you use this file:
05_asl_scanner.conf
Testing
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:
If you get errors, check to see that you don't have some extraneous files installed. You should only have these rule files:Code:/etc/init.d/httpd configtest
Code:05_asl_exclude.conf
05_asl_user_exclude.conf
10_asl_antimalware.conf
10_asl_rules.conf
11_asl_data_loss.conf
20_asl_useragents.conf
30_asl_antispam.conf
40_asl_apache2-rules.conf
50_asl_rootkits.conf
60_asl_recons.conf
61_asl_recons_dlp.conf
99_asl_jitp.conf
blacklist.txt
domain-blacklist.txt
domain-spam-whitelist.conf
malware-blacklist.txt
referer_spam.txt
sql.txt
trusted-domains.conf
whitelist.txtSpecial 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 you will need to install modsecurity and make a few changes to the mod_security configuration that comes with cpanel and then you are all set!
Installing modsecurity in cpanel
Please also check cpanels documentation for modsecurity installations, cpanel includes modsecurity as an add on, these instructions are provided here as another method of installing modsecurity. The other option is to use EasyApache with mod_security built in.
You can skip this if you already have modsecurity installed with cpanel:
Step 1.
Unfortunately you can not install modsecurity in one step using a tool like yum if you are using cpanel. cpanel does not use package management, so any package managed software is going to have problems on a cpanel system so to use modsecurity with cpanel you will need to be install it the old fashioned way, manually from source.
First install APR:
Code:tar -xzf apr-1.4.5.tar.gz
cd apr*
./configure
make
make test
make install
Step 2.
Install PCRE:
Step 3.Code:
tar -xzf pcre-8.10.tar.gz
cd pcre*
./configure
make
make test
make install
Install ModSecurity:
Step 4:Code:
tar -xzf modsecurity-apache_2.5.13.tar.gz
cd modsecurity*/apache2
./configure --with-apu=/usr/local/apache/bin/apu-1-config
make
make test
make install
Configure (see below):
Configuring modsecurity 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. If you use mod_security with Cpanel you must add these additional settings to experience the full feature set of mod_security.
Step 1. Make sure you have read this entire document and have setup all the require directories details above.
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:
Code:ps auxwww | grep httpdCode:root 20594 86.8 3.1 255148 181232 ? Ss 11:39 0:04 /usr/local/apache/bin/httpd -k restartCode:root 20611 0.0 3.1 255060 179596 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restartCode:nobody 20612 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restartCode:nobody 20613 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restartCode:nobody 20614 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restartCode:nobody 20615 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restartIn 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":Code:nobody 20616 0.0 3.1 255148 180224 ? S 11:39 0:00 /usr/local/apache/bin/httpd -k restart
[CODE][
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/*/CODE]
Step 2. Make sure you have at least version 2.5.12 of modsecurity installed. Cpanel includes its own modsecurity configuration files and its own modsecurity module. These should be able to work with our rules if they are configured correctly according to this page, and if you are using at least version 2.5.12 of modsecurity (we highly recommend you upgrade to 2.5.13).
Step 3. Make a small change to the cpanel modsecurity configuration. A typical cpanel configuration file looks like this:
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. Use of other rule sets with cpanel are not supported:Code:LoadFile /opt/xml2/lib/libxml2.so
LoadFile /opt/lua/lib/liblua.so
LoadModule security2_module modules/mod_security2.so
SecRuleEngine On
# See http://www.modsecurity.org/documenta...ion-Matrix.pdf
# "Add the rules that will do exactly the same as the directives"
# SecFilterCheckURLEncoding On
# SecFilterForceByteRange 0 255
SecAuditEngine RelevantOnly
SecAuditLog logs/modsec_audit.log
SecDebugLog logs/modsec_debug_log
SecDebugLogLevel 0
SecDefaultAction "phase:2,deny,log,status:406"
SecRule REMOTE_ADDR "^127.0.0.1$" nolog,allow
Include "/usr/local/apache/conf/modsec2.user.conf"
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.Code:SecRequestBodyAccess On
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
SecPcreMatchLimit 50000
SecPcreMatchLimitRecursion 5000
Include /usr/local/apache/conf/modsec_rules/05_asl_exclude.conf
Include /usr/local/apache/conf/modsec_rules/10_asl_antimalware.conf
Include /usr/local/apache/conf/modsec_rules/10_asl_rules.conf
Include /usr/local/apache/conf/modsec_rules/11_asl_data_loss.conf
Include /usr/local/apache/conf/modsec_rules/20_asl_useragents.conf
Include /usr/local/apache/conf/modsec_rules/30_asl_antispam.conf
Include /usr/local/apache/conf/modsec_rules/50_asl_rootkits.conf
Include /usr/local/apache/conf/modsec_rules/60_asl_recons.conf
Include /usr/local/apache/conf/modsec_rules/61_asl_recons_dlp.conf
Include /usr/local/apache/conf/modsec_rules/99_asl_jitp.conf
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.
Step 4. 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. Run asl-lite to install and update the rules:
asl-lite -u
Step 6. Restart apache, enjoy your new secure web server!
Optional Steps:
NOTE: If you use this file:
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.Code:05_asl_scanner.conf
Cpanel Notes:
If you are using CPanel and get an error like this:
Rule execution error - PCRE limits exceeded (-8): (null).
To fix this error you need to do the following:
1. Add to your PHP.INI the following commands
2. And make sure your MODSEC2.USER.CONF file contains following commands:Code:pcre.backtrack_limit = 50000
pcre.recursion_limit = 50000
Code:SecPcreMatchLimit 5000 SecPcreMatchLimitRecursion 5000
Testing to see if the rules are loaded
Step 1) 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.
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/Gotroot rules loaded.
Step 3) 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):
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
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.
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
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. 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.
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
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.
