Latest revision as of 18:24, 1 July 2022

[edit] Introduction

The ASL WAF has two non-exclusive modes operation:

1) Embedded mode

2) Transparent/Proxy mode (T-WAF)

[edit] Embedded mode

Embedded mode works with Apache 2.x. ASL will install a special module in Apache to give it native WAF protection capabilities. This installation will occur when ASL is installed.

[edit] Proxy mode (T-WAF)

Proxy mode or the Transparent WAF (T-WAF) system allows ASL to protect any HTTP and/or HTTPS service, either a local server (such as when using a web server that does not support embedded mode) or a remove server.

[edit] Configuration

The ASL WAF is initially configured during the install of ASL. If Apache is installed on the system, ASL will attempt to install the embedded WAF module. If Apache is installed on the system via package management, then this will occur automatically and you will not need to configure the WAF further to protect an installed Apache instance.

Once ASL is installed, if you need to do so, you can configure the WAF through three parts of the ASL GUI:

[edit] WAF Tab

This tab is used to setup the WAF. There are three types of WAF you can configure:

[edit] embedded

The embedded WAF is an apache module that is installed on any local Apache installations. This should be setup by default, if you are running apache on the system and a supported version and build of Apache.

[edit] local

Note: You do not need to setup a local WAF for package managed installs of apache. ASL will detect if a package managed version of Apache is installed, and will install the WAF module into apache embedded mode, as described above. For custom apache installs, please follow these directions.

This type of WAF is used to protect any local HTTP and/or HTTPS services that may be running on the system itself, where the embedded WAF module can not be used. For example, if the system was running a tomcat or litespeed web server, which do not support the embedded WAF module, or a control panel that uses it own web server (such as Plesk, Cpanel, Webmin, and others). You can configure a WAF to protect these services.

To setup a local WAF simply follow these steps:

Step 1) Log into the ASL GUI

Step 2) Click the WAF tab

Step 3) Select WAF Config

This will pull up the WAF Config window, which will show the existing WAFs.

Step 4) Click "Enable T-WAF". If you see "Disable T-WAF" this option has already been enabled.

Step 5) Click "Add"

This will will pull up the "Add WAF Config" window.

Step 6) Click on the "Add protection for" drop down. Select "local"

This will present you with two options:

Local Port: Type in the local HTTP/HTTPS port you wish to protect. Only type in one port number.

Note: Check if you have any embedded WAFs installed on the system before you do this. If you have an embedded WAF already installed on port 80, as should occur if you have Apache installed (and its package managed), then enabling the T-WAF in front of Apache would create a loop. Its not necessary to put a WAF in front of a service that is protected via embedded mode.

SSL: Select this if the service you wish to protect is SSL based.

If you select SSL, then you will see this additional options:

Path to SSL Certificate: Provide the filesystem path to the SSL certificate for this service.

Path to SSL Key file: Provide the filesystem path to the SSL key file for this service.

Step 7) Then click Save

Note: You do not need to reconfigure your web server to use a different port, ASL will transparently intercept the packets to your web server based on the port you configure above. If you change your web servers port, ASL will not intercept packets to that port.

[edit] remote

Note: You need a reverse proxy ASL license to use this feature. This feature will not work without a reverse proxy license.

This type of WAF is used to protect any remote HTTP and/or HTTPS services that are not running on the system itself. For example, if you have a remote webserver you wish to protect, you can configure a WAF to protect these services. The remote WAF can support two proxy modes: domain based and IP based.

[edit] name based remote

Domain based or name nased WAFs allow you to use a single IP address on the WAF, and to direct WAF requests to different backend servers depending on their domain or full qualified domain name, or even to specific URL.

[edit] IP based remote

IP based WAFs allow you to redirect all traffic to an IP address on WAF to a specific destination host or URL.

[edit] Setting up a remote WAF

To setup a remote WAF simply follow these steps:

Step 1) Log into the ASL GUI

Step 2) Click the WAF tab

Step 3) Select WAF Config

This will pull up the WAF Config window, which will show the existing WAFs.

Step 4) Click "Enable T-WAF". If you see "Disable T-WAF" this option has already been enabled.

Step 5) Click "Add"

This will will pull up the "Add WAF Config" window.

Step 6) Click on the "Add protection for" drop down. Select "remote"

This will present you with a dropdown options to setup the WAF as either domain based or IP based.

Step 7) If you select name based you will be presented with these options:

Domain Name: Enter the domain name or full qualified domain you wish to use. For example, if you want the WAF to handle traffic for intranet.example.com enter that FQDN in this box.

Local Url: Enter the local URL, if any, that the WAF should expect from the client to direct this connection to the remote host. The default of / is usually correct if you are forwarding all traffic for an FQDN or domain. If you only want the WAF to pass on specific requests for specific URLs, enter them here.

Destination: Enter the full URL you want the WAF to use as the destination server. Make sure you have DNS or /etc/hosts entries for this, otherwise the WAF will not be able to find the destination. This should also not be the same thing as "Domain Name:". You can also use https:// URLs here.

Remote Port: Type in the remote port for the backend server the WAF will be sending requests to.

SSL: Select SSL if you wish to accept SSL connections to the WAF. If you select this you will be presented with these additional options:

Path to SSL Certificate: Provide the filesystem path to the SSL certificate for this service.

Path to SSL Key file: Provide the filesystem path to the SSL key file for this service.

Skip to step 8

Step 7) If you select IP based you will be presented with these options

IP Address: Enter the IP address you want the WAF to listen on (you can set multiple IPs by adding additional remote WAFs). For example, if you want the WAF to redirect all traffic on IP address 1.2.3.4 to internal.example.com, type in 1.2.3.4.

Local Url: Enter the local URL, if any, that the WAF should expect from the client to direct this connection to the remote host. The default of / is usually correct if you are forwarding all traffic for an FQDN or domain. If you only want the WAF to pass on specific requests for specific URLs, enter them here.

Destination: Enter the full URL you want the WAF to use as the destination server. Make sure you have DNS or /etc/hosts entries for this, otherwise the WAF will not be able to find the destination. This should also not be the same thing as "Domain Name:". You can also use https:// here.

Remote Port: Type in the remote port for the backend server the WAF will be sending requests to.

SSL: Select SSL if you wish to accept SSL connections to the WAF. If you select this you will be presented with these additional options:

Path to SSL Certificate: Provide the filesystem path to the SSL certificate for this service.

Path to SSL Key file: Provide the filesystem path to the SSL key file for this service.

Step 8) Then click Save

[edit] SSL/TLS

If you select SSL for either the local or remote WAF options, your SSL certificates and keys must be in an Apache compatible format to be imported by the T-WAF.

[edit] ASL Configuration Settings

The WAFs settings are contained under the Configuration tab. To Configure the WAF follow this process:

Step 1) Log into the ASL GUI

Step 2) Click on the Settings Tab

Step 3) Select the "ASL Configuration" sub menu

Step 4) Scroll down to the "Web Application Firewall" configuration section. The following options are available:

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

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

[edit] WAF_ENABLED

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

Note: This option is deprecated in ASL 4.

[edit] WAF_CHROOTDIR

Configures the directory path that will be used to jail the web server process. (For the embedded WAF modules only). This lets you put the local apache instance into a chroot jail.

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

ASL 3 Default: 10

ASL 4 Default: 100

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

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

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

[edit] WAF_DEFAULT_ACTION

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

[edit] WAF_REDIRECT_URL

Used for WAF_DEFAULT_ACTION of "redirect". This is the URL to redirect blocked pages. This must include http:// or https:// in the URL.

Example:

https://%{server_name}:30000/blocked.php?eventid=%{eventid}

You can use variables in the URL. They must be represented in this format:

%{variable_name}

Important Note: If you have OSSEC_ACTIVE_RESPONSE enabled, then redirects will not work as the systems firewall will still block the user. You must disable OSSEC_ACTIVE_RESPONSE to use redirects.

[edit] Supported Variables

Currently supported variables are listed below. As new variables are supported, we will add them to the documentation here.

[edit] server_name

This is the value the client sent in the Host: header, which would be the FQDN the client accessed.

[edit] ruleid

The rule ID for the rule that was triggered.

[edit] unique_id

The unique ID for each event recorded by the WAF.

The variable UNIQUE_ID is set to the identifier for each request. The UNIQUE_ID environment variable is constructed by encoding the 112-bit (32-bit IP address, 32 bit pid, 32 bit time stamp, 16 bit counter) quadruple using the alphabet [A-Za-z0-9@-] in a manner similar to MIME base64 encoding, producing 19 characters.

[edit] remote_addr

The client IP address.

[edit] server_port

This variable contains the local port of the webserver that the request was received on.

[edit] Experimental Variables

These are additional variables that should be considered experimental, and are available in the engine, but are not currently supported. They require newer versions of modsecurity, which may not be available in the stable channel.

[edit] auth_type

This variable holds the authentication method used to validate a user, if any of the methods built into HTTP are used. In a reverse-proxy deployment, this information will not be available if the authentication is handled in the backend web server.

[edit] remote_user

This variable holds the username of the authenticated user. If there are no password access controls in place (Basic or Digest authentication), then this variable will be empty.

[edit] time

This variable holds a formatted string representing the time (hour:minute:second).

[edit] time_day

This variable holds the current date (1–31).

[edit] time_epoch

This variable holds the time in seconds since 1970.

[edit] time_hour

This variable holds the current hour value (0–23).

[edit] time_min

This variable holds the current minute value (0–59).

[edit] time_mon

This variable holds the current month value (0–11).

[edit] time_sec

This variable holds the current second value (0–59).

[edit] time_wday

This variable holds the current weekday value (0–6).

[edit] time_year

This variable holds the current four-digit year value.

[edit] response_status

This variable holds the HTTP response status code.

[edit] request_protocol

This variable holds the request method used in the transaction.

[edit] useragent_ip

This variable is created when running modsecurity with apache 2.4 and will contain the client ip address set by mod_remoteip in proxied connections. Requires mod_remoteip to be installed, and Apache 2.4.

[edit] Intercept on error

WAF_SECINTERCEPTONERROR: Configures how to respond when rule processing fails. [Default: on]

[edit] Analyze response body

WAF_SECRESPONSEBODYACCESS: Configures whether response bodies are to be buffer and analysed or not. [Default: on]

[edit] MODSEC_SERVERSIG

Field returned when a remote host queries what kind of web server this is. This can be used to hide what kind of server is running on the system, or what the WAFs are protecting.

[edit] MODSEC_UPLOADDIR

Configures the directory where intercepted files will be stored. If the WAF is configured to scan uploads, and this is set to On, then any malicious files the WAF detects will be stored in this directory on the server.

[edit] MODSEC_KEEPFILES

Configures whether or not the intercepted files will be kept after transaction is processed. It is recommended you set to this off.

[edit] MODSEC_LOGTYPE

Configures the type of audit logging mechanism to be used. Concurrent - audit log entries will be stored in separate files, one for each transaction. Serial - all audit log entries will be stored in the main audit logging file. The default is Concurrent, which is both faster and more reliable and works with ASL Gui. Serial logging is for legacy purposes and should not be enabled.

[edit] MODSEC_LOGFILE

The name of the log file that is used to store audit record headers. Do not change this unless you know what you are doing. It is generally not necessary to change this setting.

[edit] MODSEC_LOGELEMENT

Defines which part of each transaction are going to be recorded in audit log. Do not change the defaults unless you know what you are doing, this may break the GUI and active response systems.

Available audit log parts:

   A: Audit log header (mandatory).

   B: Request headers.

   C: Request body (present only if the request body exists and ModSecurity is configured to intercept it).

   D: Reserved for intermediary response headers; not implemented yet.

   E: Intermediary response body (present only if ModSecurity is configured to intercept response bodies, and if the audit log engine is configured to record it). Intermediary response body is the same as the actual response body unless ModSecurity intercepts the intermediary response body, in which case the actual response body will contain the error message (either the Apache default error message, or the ErrorDocument page).

   F: Final response headers (excluding the Date and Server headers, which are always added by Apache in the late stage of content delivery).

   G: Reserved for the actual response body; not implemented yet.

   H: Audit log trailer.

   I: This part is a replacement for part C. It will log the same data as C in all cases except when multipart/form-data encoding in used. In this case, it will log a fake application/x-www-form-urlencoded body that contains the information about parameters but not about the files. This is handy if you don’t want to have (often large) files stored in your audit logs.

   J: This part contains information about the files uploaded using multipart/form-data encoding.

   K: This part contains a full list of every rule that matched (one per line) in the order they were matched. The rules are fully qualified and will thus show inherited actions and default operators. 

   Z: Final boundary, signifies the end of the entry (mandatory). 

[edit] MODSEC_REQMEMLIMIT

Configures the maximum request body size ModSecurity will store in memory. The default are adequate for most sites, you should not change this unless you know what you are doing.

[edit] MODSEC_DEBUGLOG

Enable/Disable the ModSecurity debug log file. The debug log is located in /var/log/httpd/modsec_debug.log Enabling this will incur a substantial performance penalty on the system. You should not enable this on a production system, and only if you are debugging modsecurity rules.

Most users will want to leave this disabled.

[edit] MODSEC_CLEAN_ALERT

Number of days to retain mod_security alert data. The WAF will store the actual full requests of any intercepted attacks, to make it possible for you to investigate them and to report these to us, either for further investigation, false positives or for other forensics needs. The default is to keep these for 30 days.

Audit log events are kept in this directory by default:

/var/asl/data/audit/

[edit] MODSEC_DATADIR

Path where persistent data (e.g. IP address data, session data, etc) is to be stored.

[edit] MODSEC_AUDITDIR

Warning: This setting is unsupported

Defines the path to the audit log files. Used only when Concurrent mode is configured.

[edit] MODSEC_TMPDIR

Configures the directory where temporary files will be created.

Note: If this is changed form the default of /tmp, the directory must be writable by apache, which means depending on how you have configured apache by whatever users the web application may be running as. For example, if you use suphp, then the web application will run as a specific user. The directory must be writable by that user. In that case, you will need to either create a group that all your users belong to and make sure that group can write to that directory, or you will need to make that directory world writable. We also recommend you set the sticky bit on the directory. The simplest solution is to set the directories permissions thusly:

For example, if you change this directory to /var/asl/mod_sec_tmp, these permissions should work generically in all cases:

chmod ogu+rwx /var/asl/mod_sec_tmp

chmod o+t /var/asl/mod_sec_tmp

[edit] MODSEC_RESPONSEBODYLIMIT

Configures the maximum response body size that will be accepted for buffering.

[edit] MODSEC_RESPONSEBODYLIMITACTION

Controls what happens once a response body limit, configured with SecResponseBodyLimit, is encountered. There are two options:

ProcessPartial: Scan the response up to the limit and stop scanning when the limit is reached, but send the rest of the response.

Reject: If the response is greater than the Limit, reject the response entirely.

[edit] MODSEC_REQUESTBODYLIMIT

This sets the maximum size for a request body in bytes. The default is 134217728 bytes.

Anything over the limit will be rejected with status code 413 (Request Entity Too Large). There is a hard limit of 1 GB.

[edit] Ruleset Settings

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

[edit] Crawler Protector

This unique feature of ASL protects not only your system, but also your search engine rankings. Unlike other security products, ASL can automatically and securely detect real search engine crawlers and prevent your system from accidentally blocking them. 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!

[edit] WAF_LUA_00_SEARCHENGINE

This will protect your page rank with search engine crawlers, prevent search engines from being blocked 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 ASL 4.0.11 and up.

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

[edit] = MODSEC_00_SEARCHENGINE =

NOTE: This setting is deprecated and unsupported. Users should use the Lua method above.

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.

Note: These are legacy rules, and should not be used with modsecurity 2.9.x You should use these rules instead:

http://wiki.atomicorp.com/wiki/index.php?title=ASL_WAF#WAF_LUA_00_SEARCHENGINE

[edit] = MODSEC_00_AUTOWHITELIST_SEARCHENGINE =

NOTE: This setting is deprecated and unsupported. Users should use the Lua method above.

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

Note: These are legacy rules, and should not be used with modsecurity 2.9.x You should use these rules instead:

http://wiki.atomicorp.com/wiki/index.php?title=ASL_WAF#WAF_LUA_00_SEARCHENGINE

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

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

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 block the single attack, and implement a firewall rule to block any further attacks from the same IP.

ASL is configured to use the whitelist to prevent shunning by default, for IPs on the whitelist, but still to block attacks from that IP. This helps to prevent attacks from trusted sources, but prevents accidentally firewall rules when false positives occur. We do not recommend you disable blocking for trusted IPs. If you have a false positive, report it to us. Enabling this option tells ASL to totally ignore everything from the IPs on the whitelist, which includes not generating any alerts on this source and not to block anything. Which means if you do have a real attack from a trusted IP, you will not idea its occurred and theres nothing ASL can do to stop it.

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.

Note: This ruleset requires this file to exist:

/etc/asl/whitelist

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

1.2.3.4
10.0.0.0/8

[edit] 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 ASL 4.0.15 and up.

[edit] MODSEC_00_THREAT

Threat Intelligence System

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

Important: It is highly recommended you enable these rules only with a local DNS resolver installed and configured on the system. (If you do not know if you have a local DNS resolver installed and configured on your system, do not enable these rules until you have confirmed that you do). Please see this article for information on Local DNS resolvers.

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

[edit] MODSEC_00_ANTIEVASION

Antievasion Ruleset

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

[edit] MODSEC_00_STRICT

Strict Multiform Ruleset

Enable/Disable the strict multiform checks rule class. This ruleset enforces strict adherence RFCs for multiform messages, strictly enforces allowed types and implements enhanced checks on inputs. This prevents advanced attacks that may try to bypass the WAF, or involve more complex evasion attacks.

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.

[edit] 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 ASL server has a really fast DNS server installed on the ASL server.

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.

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

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

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

[edit] 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 when DNS records exist that match the incoming IP (This allows you to block hosts based on their DNS names), and also blocks referrers that contain that domain name.

[Default: no]

In the ASL gui, click on the ASL tab, then select Blocking, and then the Domains tab. Domains or FQDNs are defined, one per line. 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 ASL 4.0.1 and up. This works by comparing the forward and reverse DNS records, if they do not match the rule will not match.

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

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

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

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

[edit] MODSEC_11_ADV_RULES

Advanced Attack Ruleset

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

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

Additional types of data and errors this ruleset can detect in the output:

1. Credit Card Numbers
2. SSN numbers
3. Application Errors/Debug information/Sensitive Files that may leak sensitive data from:

• Mysql
• Postgres
• MS-SQL
• Oracle DB
• hsqldb
• SQLite
• Informix
• max DB
• IBM DB2
• EMC
• ODBC
• Jet DB
• Access DB
• Generic SQL errors/debug messages/info
• Wordpress

[edit] 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 EL 6 and above.

[edit] MODSEC_11_BRUTE

Supplemental Brute Force Protection Ruleset

Enable/Disable the supplemental web brute force attack protection rule class. This ruleset is used on systems that do not have either ASL or Atomic Protector installed, and perform the process of tracking login failures, and send a 403 error to the user when the limit is reached.

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

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

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

[edit] MODSEC_20_USERAGENTS

Malicious Useragents Ruleset

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

[edit] MODSEC_21_USERAGENTS

User Defined Malicious Useragents Ruleset

Enable/Disable the User Defined Malicious Useragents Ruleset. This ruleset allows you to define custom useragents in the file below that you want to block:

/etc/httpd/modsecurity.d/bad_agents.txt

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

Mozila 99.0
Internut exploder

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

[edit] 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 ASL server has a really fast DNS server installed on the ASL server.

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.

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

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

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

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

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

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

[edit] MODSEC_99_MALWARE_OUTPUT

Malicious Output Detector

Enable/Disable the malware output rule class.

[edit] MODSEC_99_SCANNER

Web Malware Upload Scanner

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

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

[edit] Rule Manager

The Rule manager can be used to configure individual WAF rules, such as what response the system such take for that rule, if an email or GUI alert should be presented, and so on. To access the rule manager please follow this process:

Step 1) Log into the ASL GUI

Step 2) Click the "Configuration" tab.

Step 3) Select "Rule Management"

This will bring up the rule management screen. There are two tabs on this screen:

Global: This sets global features for all the rules

Rules: This presents all the individual rules, and options to configure that rule specifically.

[edit] Global Options

If you change a setting on this screen, you must click the "Update" button for the setting changes to take effect.

The follow settings are available in the Global setting screen:

[edit] Email to

This sets the email address to send alerts to. The default is $EMAIL which inherits the global email address set in the ASL Configuration screen. If you want to use the same email address you set when you configured when you install ASL leave this setting as "$EMAIL". Otherwise, change this to the email address you want rule alerts sent to.

[edit] Email From

Set this to the From: line you want to use for the emailed alerts. Available variables are $HOSTNAME is is populated by the servers fully qualified hostname, and $EMAIL which is set in the ASL Configuration screen. The default is usually effective for most users.

[edit] Max Emails per hour

This sets a limit on the maximum number of emails the system will sent to the Email to: address. This basically "queues up" alerts. If events occur after the Max Emails per hour limit has been reached, then those alerts will be held until the next hour and will be grouped together in a single email sent the next hour.

If you want alerts to be sent as they occur, and not to be queued up, set this to 9999.

[edit] Active Response

This sets whether of not ASL will block the source of the attack, by implementing a firewall rule for the source of the attack. (Which may be a temporary shun, or a permanent shun depending on the setting below "Shun Timeout")

[edit] Shun Timeout

This tells ASL if the firewall block, or "shun", should be temporary or permanent. Once the Shun Time (described below) has been reached the source IP address will be allowed to connect again. The ASL Configuration settings also allow for advanced options for this, such as multiplers that cause sources to be shunned for longer periods of time as more attacks are detected from the source.

[edit] Shun Time

Timeout period is in seconds. This sets the maximum amount of time a source address will be blocked by ASL/

If Shun Timeout is set to no, the "shun" is permanent and this option is ignored.

[edit] Rules

The Rules Manager has two tabs:

[edit] HIDS

This contains all the Rules for HIDS. For documentation on the HIDS please see the ASL HIDS documentation page.

[edit] WAF

This contains all the Rules for the WAF. There are two columns on this tab, the left column contains the current rule sub classes, and the screen on the right shows all rules that match your current filter selections. The window on the right is populated by selecting either a subclass of rules, or by typing in search criteria in the boxes at the top of the screen.

If you select a rule sub class, for example "adult-spam" that will pull up all the rules in the class on the right hand side of the screen.

Or you can search for specific rules by using the filter bar at the top of the screen. The filter options are:

Category: This is another way to select a rule subclass, this is optional, you do not have to select a rule class. If you leave this in either the default, or you set this to (any) your filter will apply to all the WAF rules.

Level: Rules have different levels, depending on severity. Some rules are only informational, some indicate suspicious activity and others are full blown attacks. A higher number is a high severity or importance, and a lower number is a lower severity or importance. This filter is optional, you do not need to select a level if you do not want to filter by level. If you leave the default your filter will apply to all levels.

Search: This allows you to search by any thing in the rule, its name, ID, etc. If you hit enter in this field it will start the search.

When you have finished with your filter criteria, just click the "filter button" or hit enter in the search field.

[edit] Configuring specific rules

Once you have the rule manager open, and have pulled up a rule you want to modify just click on the down arrow next to the rules ID to open the rules options.

[edit] Rule Options

For WAF rules the following options are available:

[edit] Disabled

Setting this "yes" globally disables the rule. If you want to disable a rule for a specific domain or FQDN see the Vhost option below.

[edit] Severity

This sets the severity level for the event. This allows you to set rules to be lower or higher priority which will effect:

1. How they are displayed in the GUI

2. Whether they are shunned or not (a minimum severity level can be set in ASL to control if an event is important enough to block the source IP address, please see the ASL Configuration documentation for these settings.

3. If an email alert is sent. A minimum severity level can be set in ASL to control if an event is important enough to send an email alert, please see the ASL Configuration documentation for these settings.

[edit] Active Response

This sets if the system should perform any active response actions against the source IP address. This option is ignored if Active Response is disabled in the Global options.

[edit] Email

This sets if the event will generate an email alert. Keep in mind that the event must also be above the minimum level set in the ASL Configuration.

[edit] Logging

This sets if the event will be displayed, at all, in the ASL GUI. Setting this to off "silences" the event in the ASL GUI. It does not prevent the event from being logged to the systems logs.

[edit] Vhost settings

This subpanel allows you to set domain or FQDN specific settings for a rule. For example, if you want a rule to other behave per its defaults, but want to change its behavior for a specific domain you can set that domain here.

Currently this is limited to disabling the rule for the domain. In the future this will be expanded to allow other options for the rule as with the global settings.

Simply type in the domain name in the text box on the right, select "yes" and click add.

[edit] Rule Tuning

Please see the Mod_security page.

[edit] Events

WAF events are displayed in the ASL Events window. Please see the ASL Events page for usage information.

[edit] Configuring web servers to use the T-WAF

This section provides courtesy instructions about how to configure a remote web server to work with the T-WAF, so that the remote web server reports the correct client IP address and not the IP address for the T-WAF server.

This can also be used with local web services. For local apache servers, we do not recommend you use the T-WAF. Instead, make sure you are using the embedded mode explained at the beginning of this article. The WAF will integrate natively with Apache 2.x, and is highly recommended for that platform.

[edit] Apache

Note: If you are using embedded mode (which is the default) you do not need to do this. You will only need to do this if you are using the T-WAF to proxy traffic to a remote apache server. If you have a local apache server that ASL is installed on, install modsecurity locally.

For remote apache servers, to setup Apache to report the clients IP when using the T-WAF follow this process:

Step 1) Install mod_rpaf

http://stderr.net/apache/rpaf/

Step 2) Add this to your remote servers apache configuration

LoadModule rpaf_module path/to/mod_rpaf-2.0.so
RPAFenable On
RPAFsethostname On
RPAFproxy_ips <IP FOR THE ASL SERVER>
RPAFheader X-Forwarded-For

Change the IP in this line:

RPAFproxy_ips <IP FOR THE ASL SERVER>

To the IP for your ASL server. For example, if the ASL servers IP address is 1.2.3.4 this line will look like this:

RPAFproxy_ips 1.2.3.4

Step 3) Restart the remote apache server

[edit] Litespeed

To setup Litespeed to report the correct IP address of the client when using the T-WAF follow these instructions:

Step 1) Log into the LiteSpeed Web Admin Console

Step 2) Under Configuration, enable the option "Use Client IP in Header".

Step 3) Restart Litespeed

[edit] Nginx

Step 1) Edit your nginx.conf file and add the following to your http section:

http {
set_real_ip_from   127.0.0.1/32;
set_real_ip_from   <YOUR SERVERS IP>/32;
set_real_ip_from   <YOUR SERVERS OTHER IPS>/32;
real_ip_header     CF-Connecting-IP;

Replace <YOUR SERVERS IP> with your servers IP(s). For example, if your server had the IPs 1.2.3.4, 1.2.3.5 and 1.2.3.6 your configuration would look like this:

set_real_ip_from   127.0.0.1/32;
set_real_ip_from   1.2.3.4/32;
set_real_ip_from   1.2.3.5/32;
set_real_ip_from   1.2.3.6/32;
real_ip_header     CF-Connecting-IP;

Step 2) Restart nginx.