Difference between revisions of "WAF rule families"
(Created page with "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 r...") |
Revision as of 09:53, 27 March 2014
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.
00_asl_y_searchengines.conf
(Available in ASL and the real time rules only)
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".
Warning: If you do not have either ASL 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.
00_asl_zz_strict.conf
Note: Requires modsecurity 2.7.0 and higher.
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 ASL (ASL will generate this rule file) or if you are not running ASL 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.
Requires: Modsecurity 2.6.0 and up.
00_asl_whitelist.conf
Allows you to whitelist hosts from the WAF.
Requires: Modsecurity 2.7.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
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_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.
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 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.
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:
SecDefaultAction "log,pass,auditlog,phase:2,t:none,t:lowercase,t:replaceNulls,t:compressWhitespace" Include modsecurity.paranoid.rules.d/15_asl_paranoid_rules.conf
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.
