Atomic ModSecurity Rules
Atomic Secured Linux includes the Real Time GotRoot.com/Atomicorp Modsecurity Rules.
If you are an Atomic Secured Linux (ASL) subscriber, you do not need this subscription - its included. ASL will automatically configure mod_security and manage all of this for you. Upgrade to ASL today!
These docs are targeted at users that need to configure the rules for non-ASL environments.
About the rules
The gotroot.com rules are written by us - we are the gotroot guys. Same great rules, same team. gotroot.com 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 subset of the realtime rules, which are based on older versions of the rules and are released several times a year. These rules are not supported.
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.
Atomic ModSecurity Rules Frequently Asked Questions
Please see the Atomic ModSecurity Rules FAQ wiki page.
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 (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):
And the Custom Support Portal is located here (you can submit bug reports and open cases through the portal):
You will need to request a portal account the first time you access the portal. Support accounts are issued manually by checking the status of a customers account and the process may take some time if the office is closed. In the future, the process will be completely automated when a new sign up occurs.
ModSecurity 2.5 download
If you are running ASL - do not manually install modsecurity. ASL will install modsecurity for you, and always use the modsecurity rpms we include with ASL.
You can also build modsecurity from source. We do not support source installs of modsecurity or third party builds of modsecurity. To download the source for modsecurity please visit this website:
http://sourceforge.net/projects/mod-security/
ModSecurity Rules download
If you have not already setup a subscription for the RealTime feed, you can do so here:
Once your account is setup, you can download the Real Time rules from here:
For other users, you can download the Free Delayed/Unsupported feed below. Keep in mind the Delayed feed is released 90 days after the realtime feed (that includes any fixes).
Delayed/Unsupported Feed Download
If you want to try out Atomic Secured Linux (ASL) on a trial basis, just sign up for a 30 day free trial here.
The differences between the Real Time and Delayed Feeds
Real Time Rules
The Real Time feed is available via subscription, it includes the latest updates we produce on a daily basis, they are faster, more complete and contain any fixes we're put out. We also update the real-time rules on a daily basis. The Real Time feed comes with support to help you with any issues you may experience with the rules, including fixing false positives and addressing false negatives. When false positives are reported to us we generally get an update out the same day. So no more hassles working with modsecurity if you use the Real Time feed! Seriously, no hassles, no tuning, no experts required - just tell us and we'll get it working for you. What could be easier?
The Real Time feed also comes with an unsupported rules updater. It works for most systems, but because every system differs we can't know for sure if it will work with your modsecurity setup. If you need support for a rules updater then you are encouraged to upgrade to the full Atomic Secured Linux package which includes a fully intergrated automatic rules updater, rules management tools, SIM, web based GUI, real time malware prevention, the strongest kernel security on the market, FTP and web malware protection, built in vulnerability scanner/auto-fix system and more!
Delayed Rules
The Delayed Feed is a subset of the Real Time feed and is released on a delayed schedule of at least 90 days. It does not include all of the performance enhancements of the Real Time rules or any support.
Note: Atomic Secured Linux includes the Real Time feed.
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.
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.
You can run the Free/Delayed rules on as many systems as you like.
Setting up modsecurity 2.5.x
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
The output will look similiar 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 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/*
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 <IfModule mod_security2.c> Include modsecurity.d/modsecurity_crs_10_config.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/
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:
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
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. You will also to setup the scanner script, written in PERL, which you can download here:
Setup of this tool is not supported in the rules subscription. You will need to install it on your system and ensure that it is working with your apache setup.
Real time malware upload protection is supported in ASL. So if you need realtime malware upload protection (for web, FTP, or even realtime), then upgrade to ASL which highspeed malware upload protection, full support, automatic and hassle free installation, and also protects against HTTP, SSH and FTP uploads and includes our real-time malware detection and prevention system amongst the many features of ASL.
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:
/etc/init.d/httpd configtest
If you get errors, check to see that you don't have some extraneous files installed. You should only have these rule files:
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.txt
Rule Updater
ASL users: DO NOT USE THIS. YOU DO NOT NEED IT. ASL DOES THIS FOR YOU. INSTALLING ASL-LITE WILL BREAK YOUR SETUP.
ASL automatically updates rules.
Installing Rule Updater
ASL Lite is a free lightweight rule updater project designed specifically as an atomicorp.com mod_security rule downloader for custom apache environments, control panel software like cpanel and directadmin, or non-apache/mixed web server implementations. ASL Lite supports a guided dialog similar to the standard asl configuration, that allows for the definition of custom commands for restarting web services, location of configuration files, and use via cron.
ASL Lite is available in the Atomic channel and currently works with RPM based Linux distributions such as Redhat, Centos and Fedora:
wget -q -O - http://www.atomicorp.com/installers/atomic |sh
yum install asl-lite
You can also download it from the following page:
http://www.atomicorp.com/downloads.html
ASL Lite will ultimately replace the "Rules-Only" subscription, however it is optional now. You do not need it to download the rules, but you are encouraged to use it. It is currently available for RHEL 4/5, CentOS 4/5, and Fedora 6-12. Other operating systems can be added upon request.
To install ASL Lite:
1) Add the atomic repository
wget -q -O - http://www.atomicorp.com/installers/atomic |sh
2) Install asl-lite and its support packages
yum install asl-lite
3) Configure ASL lite with your username/password, set path information, configured rules, and restart commands
asl-lite -c
4) Update your ruleset:
asl-lite -u
ASL users: DO NOT USE THIS. YOU DO NOT NEED IT AND WILL BREAK YOUR SETUP. ASL DOES THIS FOR YOUR AUTOMATICALLY.
Uninstalling rule-updater
ASL users: DO NOT USE THIS. YOU DO NOT NEED IT AND WILL BREAK YOUR SETUP. ASL DOES THIS FOR YOUR AUTOMATICALLY.
If your system uses package management, run this command as root:
yum remove asl-lite
If your system does not use package management, there is no automated uninstall, you will need to manually remove asl-lite. The default location for asl-lite is:
/var/asl/bin/asl-lite
Note: This will not disable the rules, or disable modsecurity. To disable the rules, you will need to remove those Atomicorp rules you manually installed. To disable modsecurity, you will also need to remove your modsecurity configuration if you wish to disable the modsecurity.
asl-lite does not configure either of these, if you have a modsecurity configuration, and you are not using ASL, then someone set this up manually for you.
Tuning the Rules/Disabling Rules
See the mod_security page for details.
Troubleshoot the Rules
See the Atomicorp WAF Rules Troubleshooting page for details.
Reporting False Positives
See the Reporting False Positives page for details.
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 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:
wget http://mirror.metrocast.net/apache//apr/apr-1.4.2.tar.gz tar -xzf apr-1.4.2.tar.gz cd apr* ./configure make make test make install
Step 2.
Install PCRE:
wget ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/pcre-8.10.tar.gz tar -xzf pcre-8.10.tar.gz cd pcre* ./configure make make test make install
Step 3.
Install ModSecurity:
wget http://www.modsecurity.org/download/modsecurity-apache_2.5.13.tar.gz 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
Step 4:
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:
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":
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/*
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:
LoadFile /opt/xml2/lib/libxml2.so LoadFile /opt/lua/lib/liblua.so LoadModule security2_module modules/mod_security2.so <IfModule mod_security2.c> SecRuleEngine On # See http://www.modsecurity.org/documentation/ModSecurity-Migration-Matrix.pdf # "Add the rules that will do exactly the same as the directives" # SecFilterCheckURLEncoding On # SecFilterForceByteRange 0 255 SecAuditEngine RelevantOnly SecAuditLog logs/modsec_audit.log SecDebugLog logs/modsec_debug_log SecDebugLogLevel 0 SecDefaultAction "phase:2,deny,log,status:406" SecRule REMOTE_ADDR "^127.0.0.1$" nolog,allow Include "/usr/local/apache/conf/modsec2.user.conf" </IfModule>
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:
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
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.
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:
05_asl_scanner.conf
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.
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:
pcre.backtrack_limit = 50000 pcre.recursion_limit = 50000
2. And make sure your MODSEC2.USER.CONF file contains following commands:
SecPcreMatchLimit 5000 SecPcreMatchLimitRecursion 5000
You may have to increase this limit for your systems needs if you continue to get the PCRE error.
Testing to see if the rules are loaded
Note: This test assumes you do not have any rules disabled and that your have the Atomicorp/Gotroot rules loaded.
Here is an easy test to know for sure. On the system where the rules are installed run this command (this assumes you have wget installed):
wget http://localhost/foo.php?foo=http://fakeattacker.com
You 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://fakeattacker.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 have wget installed, then you will need to install it or a similar tool. You can also use your browser to test the rules by going to this URL:
http://YOUR_HOST/foo.php?foo=http://fakeattacker.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 and you need to check your configuration to ensure that you have followed the instructions above correctly.
What does each rule family do?
The Atomicorp/Gotroot rules are broken into families - we recommend you load all the rule families. They work well together, and its safe to use all the rules on a box. We run every rule on our boxes and have been since we first started publishing them over five years ago.
00_asl_0_global.conf
This is a global variable file, it is only used if you have modsecurity 2.5.13 and above installed. If you are using cpanel, you do not want to load this until cpanel releases a 2.5.13 modsecurity update.
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. 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.
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.
00_asl_whitelist.conf
Allows you to whitelist hosts from the WAF.
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.
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.
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.
11_asl_adv_rules.conf
These are advanced rules, and can only be used with modsecurity 2.5.13 and above. If you are using cpanel, you do not want to load this until cpanel releases a 2.5.13 modsecurity update as these rules will not load correctly with older versions of modsecurity.
11_asl_data_loss.conf
Experimental data leakage rules. Looks for credit card numbers and other potentially sensitive information leaking from the system.
20_asl_useragents.conf
Looks for malicious or suspicious user agents and known patterns of malicious activity.
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.
30_asl_antispam_advanced.conf
(Not released yet) These are advanced spam rules. They require modsecurity 2.5.13 and up.
30_asl_antispam_referrer.conf
Rules to block referrer spam.
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 rootkits, PHP/ASP/PERL shells, spam tools and other malicious web applications from running on the system. (These rules exist for cases where malicious software may already be installed on the system, this is a defense in depth rule set)
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.
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.
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.
99_asl_exclude.conf
Post exclude 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.
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.
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.
リンク
- セキュリティ関連ツール のトップページへ
- security sub Wiki のトップページへ
