Aum configuration

MODSEC_ENABLED

This setting Enables/Disables the entire WAF system. This is the only supported method for disabling the WAF in ASL. Uninstalling mod_security and the use of third party methods to remove modsecurity will not work if this setting is still configured to enable the WAF. This setting is specifically designed to ensure that the WAF is not disabled accidentally by a third party product.

WAF_ENGINE

Set the WAF engine mode, there are three modes:

On - this tells the WAF to detect and block attacks.

DetectionOnly - this tells the WAF to only detect and report attacks, but not to block them.

Off - Disables the WAF.

WAF_ENABLED

Enable/Disable Tortix WAF proxy (ASL users only). The tortix waf module, this module can process local or remote services through the Tortix Web Application Firewall (T-WAF) . (Default: Off)

WAF_READSTATELIMIT

Sets the limit of the number of connections from the same IP address that can be in the Read state for the WAF. This helps to prevent "slow" DOS attacks. For example, if this was set to "5" a single IP would only be able to keep 5 connections in a busy state with the web server at a single time.

Write State Limit

WAF_WRITESTATELIMIT: Sets the limit of the number of connections from the same IP address that can be in the Write state for the WAF. This helps to prevent "slow" DOS attacks. For example, if this was set to "5" a single IP would only be able to keep 5 connections in a busy state with the web server at a single time.

(Default: 100)

Note: This option is only available in ASL 4 and up.

WAF_SECREQUESTBODYNOFILESLIMIT

(Default: 1048576) Configures the maximum request body size the WAF modules will accept for buffering. There is a hard limit of 1GB. This is not a limit on file sizes sent through the WAF, just request body sizes.

WAF_SECREQUESTBODYINMEMORYLIMIT

(Default: 131072) Configures the maximum request body size the WAF modules will store in memory. There is a hard limit of 1GB. The default of 128 MB is generally sufficient for any site.

WAF_DEFAULT_ACTION

Configures the block policy, deny the request or redirect the client to a landing page.

Ruleset Settings

These allow you to enable/disable entire Rulesets and classes of rules. For ASL users, if you want to configure a specific rule, use the ASL Rule Manager.

For aum users, you will need to make changes to this configuration file:

/etc/asl/config

Once you make any changes to this file, run this command as root to apply your configuration changes:

aum -uf

Crawler Protector

This unique feature of ASL and our modsecurity rules protects not only your system, but also your search engine rankings. Unlike other security products, this automatically and securely detects real search engine crawlers and prevents modsecurity from accidentally blocking them (ASL will also prevent firewall rules from blocking search engines). It can also detect when attackers are trying to pretend to be search engines, in hopes of getting around your security systems, and can safely block them, without blocking the real crawlers!

WAF_LUA_00_SEARCHENGINE

This will protect your page rank with search engine crawlers and will also block attackers pretending to be search engine crawlers. It can securely determine if a bot is legitimate, or a forgery.

Default: disabled

Note: This ruleset will only perform this function if a client claims to be a search engine, and is much faster than the legacy system and does not require that apache be configured with HostNameLookups Double. While this is significantly faster than looking up the A and PTR records for all FQDNS, this ruleset should only be used if the ASL server has a local DNS resolver server installed on the ASL server. You can use a remote resolver, but a local resolver will be faster and more reliable.

These rules require a locally installed DNS server for maximum performance. It is not recommended you enable these rules without a local DNS server installed on this server.

Requires modsecurity 2.9.0 from Atomicorp with supporting libraries.

Legacy system

If you are using a version of modsecurity prior to 2.9.0 then you may want to use the legacy options below. Do not use the legacy options with 2.9.0 and above.

= MODSEC_00_SEARCHENGINE =

Bogus Search Engine Ruleset

This ruleset will detect search engine crawlers, as well as attackers pretending to be search engine crawlers. It can securely determine if a bot is legitimate, or a forgery.

Default: disabled

Note: You should only use this ruleset if the ASL server has a local DNS resolver server installed on the ASL server. You can use a remote resolver, but a local resolver will be faster and more reliable.

These rules require a locally installed DNS server for maximum performance. It is not recommended you enable these rules without a local DNS server installed on this server. (If you do not know if you have a DNS server installed on this server, do not enable these rules). Apache must also be configured with "HostnameLookups Double". ASL will attempt to configure HostnameLookups Double, but on non-standard systems, such as source build Apache installs and third party Apache installations this may not occur automatically. If you find that Apache is not resolving IP addresses, check to make sure HostnameLookups Double is configured for Apache.

Requires modsecurity 2.7.7. Use WAF_LUA_00_SEARCHENGINE with modsecurity 2.9.0 and up.

= MODSEC_00_AUTOWHITELIST_SEARCHENGINE =

Autowhitelist Search Engine Ruleset

This ruleset will automatically, and securely, whitelist search engine crawlers to prevent them from being blocked accidentally. This will protect your page rank with search engine crawlers.

NOTE: This ruleset requires the MODSEC_00_SEARCENGINE setting to be enabled for this to work.

Default: disabled

Warning: You should only use this ruleset if the server has a fast local DNS resolver server installed on the ASL server.

Requires modsecurity 2.7.7. Use WAF_LUA_00_SEARCHENGINE with modsecurity 2.9.0 and up.

MODSEC_00_WHITELIST

Whitelist Ruleset

Enable/Disable application of the whitelist for the WAF.

By default whitelisting does not apply to the WAF.

Note: enabling this will bypass *ALL* security checks for hosts on the whitelist for the WAF.

Default: off

By default, this is not enabled. We dont recommend you you use this unless you know you can completely and totally trust every host on your whitelist every time. Most users will not need to enable this.

Warning: We do not recommend you include your servers IP on this whitelist if you have a shared hosting server. Whitelisting localhost (127.0.0.1) and your local servers IP(s) from the WAF will means that local users can launch attacks against the server and against other domains on the server which will be neither detected nor prevented. If you have a rule that is being triggered by a local script, please report it as a false positive if it is a false positive, and if not, this may be an actual attack on your system or a poorly developed application. If you have a false positive from a whitelisted IP, please report it to us. Whitelisting in general is extremely dangerous and attackers know that users do this, which is why they target desktops and other trusted systems. If they can get access to these trusted systems, they can usually gain unfetered access to everything that users desktop, mobile device, laptop or other trusted system can access.

Requires Modsecurity 2.7.7 or 2.9.0 and up. 2.8.0 is not supported with this ruleset as it contains a critical bug that does not support IP based rulesets.

MODSEC_00_BLACKLIST

Blacklist Ruleset

Enable/Disable application of the blacklist for the WAF.

By default blacklist is accomplished at Layer 3, and this ruleset is not necessary for most systems. This ruleset is only necessary if your configuration does not allow you to block attackers at Layer 3, such as when the system is behind a layer 7 proxy or load balancer.

Note: enabling this will block all IPs on the users custom blacklist for the WAF.

Default: off

ASL can respond to attacks in several different ways. The two that relate to the WAF are:

• blocking
• shunning

Blocking is when ASL stops a single attack, and does not take any further action.

Shunning is when ASL both blocks the single attack, and implements a layer 3 firewall rule to block any further attacks from the same IP.

ASL is configured to use the blacklist to block all IPs at layer 3. It is not configured by default to do this at layer 7, the WAF, as this is generally not necessary for most systems. Most users will not need to enable this.

Note: This ruleset requires this file to exist:

/etc/asl/blacklist

The format is one IP or CIDR per line. For example:

1.2.3.4
10.0.0.0/8

Requires Modsecurity 2.7.7 or 2.9.0 and up. 2.8.0 is not supported with this ruleset as it contains a critical bug that does not support IP based rulesets.

MODSEC_00_THREAT

Threat Intelligence System

Enabling this allows your system to use Atomicorp Threat Intelligence system to block known attackers.

It is highly recommended you enable these rules with a local DNS server installed on the server. (If you do not know if you have a DNS server installed on this server, do not enable these rules).

Please see this article for information on Local DNS resolver.

Note: hosts on the whitelist are automatically excluded from being blocked by this ruleset.

Requires modsecurity 2.7.7 and up.

MODSEC_00_ANTIEVASION

Antievasion Ruleset

Enable/Disable the antievasion rule class. This ruleset prevents attacks that try to bypass the WAF itself.

MODSEC_00_STRICT

Strict Multiform Ruleset

Enable/Disable the strict multiform checks rule class. This ruleset enforces strict adherence RFCs for multiform messages. This prevents advanced attacks that may try to bypass the WAF. Note: Broken applications and clients that do not adhere to RFCs will not be able to send multiform to the system if you enable this. This not a false positive, these clients and applications are broken. If you are unfortunately stuck with these, you will have to disable this.

MODSEC_00_RBL

RBL Ruleset

Enable/Disable Real-time Black List (RBL) rule class. Currently this uses the Spamhaus XBL 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.

Default: off

Warning: You should only use this ruleset if the server has a really fast DNS server installed on the server itself.

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.

MODSEC_00_AE_RULES

Anti-Evasion Protection system

Antievasion Ruleset/MODSEC_00_ANTIEVASION: Enable/Disable the antievasion rule class. This ruleset prevents attacks that try to bypass the WAF itself.

MODSEC_01_RULES

Advanced Antievasion Ruleset

Enable/Disable the advanced antievasion protection rule class. This ruleset prevents attacks that try to bypass the WAF itself or can be used to trick applications into parsing data in ways that may compromise the application.

MODSEC_01_APP_RULES

This is a special ruleset that most users will never need. Please see this article to see if this ruleset applies to you:

WAF_rule_families#01_asl_rules_special.conf

Default:no

Note: Do not enable this ruleset unless you know what you are doing.

MODSEC_01_DOMAIN_BLOCKS

MODSEC_01_DOMAIN_BLOCKS

Enable/Disable user defined custom domain blocking class. This ruleset blocks connections from a user defined list of domains. This allows you to block hosts based on their DNS names.

[Default: no]

Domains are defined, one per line, in this file:

/etc/asl/custom-domain-blocks

This file does not exist by default. The format is one domain by line, for example:

.example.com
.anotherexample.com

Matching is by string, regular expressions are not supported. Therefore, example.com will also match anotherexample.com. If you want to limit the domain you will need to use a delimiter, as in the example, such as:

.example.com

Which will only match on FQDNs that include .example.com, and in the previous example would not match on anotherexample.com.

Note: Available in modsecuritty 2.7.7 and up. This works by comparing the forward and reverse DNS records, if they do not match the rule will not match.

MODSEC_03_DOS

Denial of Service Protection

Enable/Disable the Denial of Services protection rule class. This ruleset prevents the so-called "slowaris" Denial of Service attacks, as well as "fast" DOS attacks. DDOS attacks can not be mitigated on the host itself.

Note: Some fastcgi implementations, specifically cpanel, require this to be disabled.

MODSEC_06_HONEYPOT

Custom User Defined Honeypot Ruleset

Enable/Disable the Custom User Defined Honeypot Ruleset. This ruleset allows you to define custom files, directories or a combination of the two in the file below that you want to block access to:

/etc/httpd/modsecurity.d/honeypot-files.txt

The format is one rentry per line. This method does not support regular expressions, but is case insensitive. For example:

/backups/admin.php
/wp-config.php
/admin/secret

MODSEC_10_ANTIMALWARE

Anti-Malware Ruleset

Enable/Disable the anti-malware rule class. This will look at any requests to the system for known malware domains and indicators of malware injection requests (this does not do the same thing as the MODSEC_99_SCANNER class, which will inspect uploads for malware).

MODSEC_10_RULES

Generic Attack Ruleset

Enable/Disable the core rule class. This class contains the core generic rules, which will look for things like SQLi, XSS, CSRF, recursion, code injection, command injection, XML attacks and other generic attack patterns. You should always leave this class enabled.

MODSEC_11_ADV_RULES

Advanced Attack Ruleset

Enable/Disable the advanced protection rule class. This class contains advanced rules.

MODSEC_11_BRUTE

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

MODSEC_11_DLP

Data Loss Protection Ruleset

Enable/Disable the data loss protection rule class. This will detect certain Data Loss events, such as credit card information being sent or errors messages from applications that may reveal sensitive information or that the system or application is vulnerable to particular attack.

MODSEC_12_ADV_XSS_RULES

Advanced Cross Scripting Protection (AXSSP)

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.

Note: This requires modsecurity 2.9.0 and up.

MODSEC_12_BRUTE

Brute Force Protection Ruleset

Enable/Disable the web brute force attack protection rule class. Detects attempts to brute force web applications authentication mechanisms.

This ruleset can not block repeated login failures without the use of ASL. ASL will intelligently and safely identify actual brute force and slow authentication failures.

Note: This works by analysing the output of the web application, and does not rely on log analysis or htaccess files. Therefore, do not use application internal compression schemes on output. For example, do not enable GZIP compression in applications such as Joomla, PHPBB, Wordpress and others, as this will make it difficult for the WAF to see the output. You can still compress the output if you use an apache module such as mod_deflate, which accomplishes the same thing and is less CPU intensive that application internal compression. Litespeed does not currently support this ruleset. If you require this protection with Litespeed, you must use ASL and configure ASL to setup a local WAF, via ASL, in front of Litespeed.

Discussion:

For the WAF to be able to analyze out from web applications, the WAF must be able to understand the output from the web application. Applications that compress output send this compressed output to Apache, which creates a situation where the WAF will only see compressed content. In this case, the WAF will not be able to understand it because the WAF will not decompress it.

Whereas it is possible for the WAF to decompress this content, and then recompress it, this is extremely wasteful for the CPU and will unnecessarily slow the system down. Essentially the web server would be compressing the content, decompressing it, and then compressing it again. Add in two unnecessary steps, and tripling the work load. The most efficient solution is to not compress output in the application, let the WAF inspect it, and then let apache compress it.

Inline decompression with the WAF is no longer supported and has been removed from the WAF code as this leads to poor performance due to misconfiguration of the system.

MODSEC_20_USERAGENTS

Malicious Useragents Ruleset

Enable/Disable the useragents rule class. Detects known malicious or suspicious user agents.

MODSEC_30_ANTISPAM

Anti-Spam Ruleset

Enable/Disable the anti-spam rule class. This class contains 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.

MODSEC_31_ANTISPAM_URI

Anti-Spam URI RBL Ruleset

Enable/Disable the anti-spam URI rule class. Looks up all URIs in a post against RBLs to see if its a known spam domain. As with the MODSEC_00_RBL rules, these should only be used if the server has a local fast DNS server.

Warning: You should only use this ruleset if the server has a really fast DNS server installed on the server itself.

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.

MODSEC_50_ROOTKITS

Rootkit Detection Ruleset

Enable/Disable the rootkit rule class. This class 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)

MODSEC_60_RECONS

Reconnaissance Attacks Ruleset

Enable/Disable the recon rule class. This class 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.

MODSEC_61_DLP

Data Leak Prevention Ruleset

Enable/Disable the data loss protection class. 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.

MODSEC_98_ADV_REDACTOR

Advanced Malware Removal Ruleset

Enable/Disable the advanced malware removal ruleset. These rules detect hidden iframes, obfuscated javascript and other potentially malicious code and remove it real time from your web pages.

Requires modsecurity 2.7.7 and up.

MODSEC_99_JITP

Just In Time Patches

Enable/Disable the Just In Time Patches(JITP) rule class. 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.

MODSEC_99_REDACTOR

Malicious Output Removal Ruleset

Enable/Disable the automatic malicious/hidden iframe and malware removal rule class. Automatically removes malicious code from web pages, such as hidden iframes, encoded javascript and other malicious code.

MODSEC_99_MALWARE_OUTPUT

Malicious Output Detector

Enable/Disable the malware output rule class.

MODSEC_99_SCANNER

Web Malware Upload Scanner

Malicious code upload scanner. Enable this to scan web uploads for malicious code.

Requires ASL.

MODSEC_99_ADV_SCANNER

Advanced Malware Upload Scanner

This enables the advanced malware upload scanner rule class. This uses fuzzy hashes to detect similiar malware.

Requires ASL.