WAF Rule Families
000000000000000000000000_asl_notconfigured.conf
This rule file should not be used.
This file is a “canary” file included in the archive to prevent users from accidentally loading all the rule files at the same. This ruleset will prevent this condition by disabling the WAF and logging a warning that the installation instructions have not been followed.
If you are getting any errors about this file and you are using a third party product that installs our rules, please contact the vendor for that product.
000_asl_threat_intelligence.conf
These rules use the Atomicorp Threat Intelligence system to detect if an IP is a known threat. These rules look for DOS, brute force, spam, known attackers and advanced threats.
Note
Requires modsecurity 2.7.7 and up.
00_asl_x_searchengines.conf
This ruleset tells the WAF to trust defined search engines, and to not block or shun them.
Note
Requires modsecurity 2.7.7 and up.
00_asl_y_searchengines.conf
This ruleset detects clients pretending to be a search engine, as well as valid search engines. You must have either Atomic Protector 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 Atomic Protector, or you will need to manually set the variable WHITELIST_SEARCH_ENGINES to “1”.
Warning: If you do not have either Atomic Protector installed, or apache configured correctly to use these rules they will not work 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.
Requires: Modsecurity 2.7.0 and up.
Excluded: Modsecurity 2.8.0. Because 2.8.0 has a serious bug in the @ipmatch code( https://github.com/SpiderLabs/ModSecurity/issues/706).
00_asl_zz_strict.conf
This enforces strict adherence to the HTTP RFCs.
Requires: Modsecurity 2.7.0 and up.
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.
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 Atomic Protector (Atomic Protector will generate this rule file) or if you are not running Atomic Protector you must manually enable the other RBLs.
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.
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.
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.
Note
Requires modsecurity 2.6.0 an up.
00_asl_blacklist.conf
Allows you to blacklist hosts or CIDRs from the WAF.
Requires: Modsecurity 2.9.0 and up.
The format is single IPs or CIDRs per line, for example:
1.2.3.4
5.6.7.0/24
8.9.0.0/16
Note
You must define your own blacklist file. The default location is /etc/asl/blacklist.
00_asl_whitelist.conf
Allows you to whitelist hosts from the WAF.
Requires: Modsecurity 2.9.0 and up.
The format is single IPs or CIDRs per line, for example:
1.2.3.4
5.6.7.0/24
8.9.0.0/16
Note
You must define your own whitelist entires. The default location is /etc/asl/whitelist. Do not use the whitelist.txt file. It is not used for this rule. We do not provide a default whitelist for these rules.
01_asl_content.conf
These rules restrict the server to known content types that the WAF can correctly decipher.
Requires: Modsecurity 2.7.0 and up.
01_asl_domain_blocks.conf
Optional ruleset that allows you to block connections from hosts, based on their DNS hostname and/or domain. This is a user defined list.
Domains and/or hostnames are stored in this file:
/etc/asl/custom-domain-blocks
The format is one entry, per line, for example:
example.com
www.hostname.some-tld
Note
You must have either Atomic Protector installed, or apache configured with “HostnameLookups Double” and a very fast local DNS server for these rules to work.
01_asl_rules_special.conf
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.
If you do not know what this means, you do not need this ruleset.
Requires: Modsecurity 2.7.0 and up.
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 Atomic Protector. Please contact your apache vendor for assistance with this issue, or use Atomic Protector which will fix your apache configuration so this error does not occur.
03_asl_dos.conf
This ruleset protects apache from slow DOS attacks. It is only supported with Apache and requires the installation of the mod_reqtimeout module. The rule is fail safe with Apache, that is if the mod_reqtimeout module is not loaded the rules also will not load into Apache.
Atomic Protector automatically ensures mod_reqtimeout is installed. If you are a rules only user please contact your Apache vendor for assistance installing this module.
Note
Requires modsecurity 2.7.7 and up.
05_asl_exclude.conf
Pre-load rule exclusion list. Turns off rules that need to be disabled early in the process. Atomic Protector 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
Deprecated.
11_asl_rules.conf
This ruleset is reserved and is not currently used.
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
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.9.1 and above.
Requires: Modsecurity 2.9.1 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_adv_xss_rules.conf
This ruleset require mod_security 2.9.0 and above.
This is the advanced Cross Site Scripting (XSS) protection rule set. It performs deep level inspections of web requests and responses to look for potential XSS attacks.
12_asl_brute.conf
This ruleset is only available with Atomic Protector or the Real Time Rules.
This ruleset detects authentication failures against all major web applications (Joomla, WordPress, MovableType, Drupal, ModX, ZenCart, OsCommerce, VBulletin, PHPBB and more).
When used with Atomic Protector, fast and “low and slow” brute force attacks can be detected and blocked in real time.
Requires: Modsecurity 2.6.8 and up.
Note
Atomic Protector 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)
Note
Atomic Protector 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 Atomic Protector 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.
This is an extra ruleset for advanced users. It applies extra inspection to the URL collection for SQL and XSS attacks beyond what a valid SQLi or XSS attack would require. It is included for some WAF testing tools that incorrectly report SQL and XSS vulnerabilities from incomplete attack payloads. This ignores the structure of the URL and may generate false positives. Disable this ruleset if you have false positives.
Requires: Modsecurity 2.9.3 and up.
This contains extra rules for Wordpress systems.
Requires: Modsecurity 2.9.3 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.
99_asl_a_redactor.conf
Atomic Protector 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 Atomic Protector.
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.
Requires: modsecurity 2.7.5 and up.
98_asl_jitp.conf
This is a special ruleset used by Atomic Protector. If you do not have Atomic Protector 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
This ruleset is reserved, and is not currently used.
99_asl_redactor.conf
Special ruleset - requires mod_sed to be loaded on the system which is included and supported in Atomic Protector - 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 Atomic Protector 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 Atomic Protector.
Note
Requires modsecurity 2.7.7 and up.
99_asl_redactor_post.conf
This ruleset detects malicious content in webpages, such as known malicious domains.
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 Atomic Protector.
99_asl_z_adv_scanner.conf
Requires Atomic Protector and modsecurity 2.9.0 and higher.
This ruleset uses a fuzzy hash to identify potentially malicious files.
Warning: This ruleset is not supported on non-Atomic Protector systems. Do not use this without Atomic Protector.
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/safethingThe 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:
SecDefaultAction "log,pass,auditlog,phase:2,t:none,t:lowercase,t:replaceNulls,t:compressWhitespace" Include modsecurity.paranoid.rules.d/15_asl_paranoid_rules.confYou must load these rules last.
Requires: Modsecurity 2.7.0 and up.
Using 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 Atomic Protector. Atomic Protector uses intelligent defense in depth, and does need this kind of ruleset to protect you. You will get a greater level of protection from Atomic Protector, without all the false positives.
Beta Rules
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.