Difference between revisions of "WAF rule families"

Latest revision as of 16:23, 6 October 2022

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 ten years ago.

[edit] 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.

[edit] 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.

[edit] 00_asl_x_searchengines.conf

This ruleset is Deprecated

Note: this is a legacy ruleset and should only be used on platform that do not support lua, and may experience performance issues. Please use 00_asl_z_searchengines.conf instead.

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.

[edit] 00_asl_y_searchengines.conf

This ruleset is Deprecated

Note: this is a legacy ruleset and should only be used on platform that do not support lua, and may experience performance issues. Please use 00_asl_z_searchengines.conf instead.

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

Excluded: Modsecurity 2.8.0. Because 2.8.0 has a serious bug in the @ipmatch code( https://github.com/SpiderLabs/ModSecurity/issues/706).

[edit] 00_asl_z_searchengines.conf

'(Available in ASL and the real time rules only)

Note: The rules must be used with a Local DNS resolver. If you do not have a fast local DNS server (not a remote DNS server), do not use these rules. These rules perform forward and reverse lookups and require a fast local DNS server. Failure to use a local resolver will result in performance degradation, these rules may also not work at all in these cases.

This ruleset detects clients pretending to be a search engine, as well as valid search engines. You must have a very fast local DNS server to use these rules. These rules also allow you to auto-whitelist real search engines. To do this, in the /etc/asl/config set WAF_LUA_00_SEARCHENGINE to "yes"

For DIY installations, you must install the "advanced" subdirectory in your modsecurity rules directory. If you are manually extracting the rules archive files this should be created for you automatically, and will contain the actual .lua files this config file will load.

Requires: Modsecurity 2.9.3 and up.

[edit] 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.

[edit] 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.

[edit] 00_asl_rbl.conf

This rule family checks an incoming host to see if its on a third party RBL. By default only the third party 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.

[edit] 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.

[edit] 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.

Note: Requires modsecurity 2.7.7 and up.

[edit] 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.

[edit] 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 ASL installed, or apache configured with "HostnameLookups Double" and a very fast local DNS server for these rules to work.\

Note: Requires modsecurity 2.7.7 and up.

[edit] 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 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.

[edit] 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.

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

[edit] 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.

[edit] 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.

[edit] 05_asl_scanner.conf

Deprecated.

[edit] 06_asl_honeypot.conf

This ruleset lets you define URLs you want to specifically block, for example the URL of an application that may not be installed on the system. This can work as a honeypot of sorts, allowing the system to be configured to treat probes for non-existant applications as attacks. ASL has a more advanced system that can detect when URLs do not correspond to files on the system, which can be used in place of this ruleset or to augment it.

For this ruleset to work, populate the honeypot-files.txt file in the same directory as 06_asl_honeypot.conf with one URL per line. For example:

/application/not/installed/on/system
file_name_not_on_system.extension

[edit] 11_asl_rules.conf

This ruleset is reserved and is not currently used.

[edit] 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.

[edit] 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.

[edit] 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.

[edit] 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.

[edit] 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.

[edit] 11_asl_brute_enhanced.conf

Requires: Modsecurity 2.9.2 and up.

These rules are for platforms that do not have either ASL or Atomic Protector installed. These rules create the collections in modsecurity to block brute force attacks. The defaults are > 5 failures within 60 seconds.

Note: These rules are not necessary if the systen has ASL or Atomic Protector installed, and should not be used with ASL or AP.

Note 1: These rules will only work if the web server can write to the SecDataDir directory. That directory will contain sqllite databases that modsecurity will create and use to count events, without the collection modsecurity can not maintain state for composite events, like multiple login failures, and these rules will not work.

Note 2: Enable this setting in /etc/asl/config to create the collections:

https://wiki.atomicorp.com/wiki/index.php/Aum_configuration#MODSEC_00_THREAT

[edit] 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.

[edit] 12_asl_brute.conf

This ruleset is only available with ASL 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 ASL, fast and "low and slow" brute force attacks can be detected and blocked in real time.

Requires: Modsecurity 2.6.8 and up.

Note: ASL is necessary to perform active response to brute force attacks.

[edit] 13_asl_brute_enhanced.conf

Requires: Modsecurity 2.9.2 and up.

These rules are for platforms that do not have either [ASL] or Atomic Protector installed. These rules create the collections in modsecurity to block brute force attacks. The defaults are > 10 failures within 60 seconds.

Note: These rules are not necessary if the systen has ASL or Atomic Protector installed, and should not be used with ASL or AP.

Note 1: These rules will only work if the web server can write to the SecDataDir directory. That directory will contain sqllite databases that modsecurity will create and use to count events, without the collection modsecurity can not maintain state for composite events, like multiple login failures, and these rules will not work.

[edit] 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.

[edit] 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.

[edit] 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.

[edit] 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.

[edit] 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.

[edit] 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.

[edit] 51_asl_rootkits.conf

These rules look for known malware names in filenames, and URLs.

Requires: Modsecurity 2.7.0 and up.

[edit] 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.

[edit] 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.

[edit] 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.

[edit] 99_asl_exclude.conf

Post exclude rules.

[edit] 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.

[edit] 98_asl_jitp.conf

This is a special ruleset used by ASL. If you do not have ASL you can not use these rules.

[edit] 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.

[edit] 99_asl_a_redactor.conf

This ruleset is reserved, and is not currently used.

[edit] 99_asl_redactor.conf

Note: Do not enable this ruleset unless you have been instructed to do so by support.

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.

[edit] 99_asl_redactor_post.conf

This ruleset detects malicious content in webpages, such as known malicious domains.

[edit] 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.

[edit] 99_asl_z_adv_scanner.conf

Note: Requires ASL 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-ASL systems. Do not use this without ASL.

[edit] Paranoid mode rules

[edit] 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.

[edit] 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.

[edit] Beta Rules

[edit] Experimental Rules

[edit] 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.