ASL WAF

Introduction

The ASL WAF has two non-exclusive modes operation:

1) Embedded mode

2) Proxy mode

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.

Proxy mode

Proxy mode 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.

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:

WAF Tab

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

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.

local

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, which do not support the WAF embedded WAF module. 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 port you wish to protect.

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

remote

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.

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.

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.

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

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 Configuration Tab

Step 3) Select the "ASL Configuration" sub menu

Step 4) Scroll down to the Mod_security configuration section. The following options are available:

MODSEC_REQUESTBODYLIMIT

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.

MODSEC_00_WHITELIST

Enable/Disable whitelist rule class. Note enabling this will bypass *ALL* security checks for hosts on the whitelist. It is a truly terrifying option. Enabling this will void your support, just kidding. But seriously, enabling this will in fact tell the WAF to totally ignore everything from the source, it wont even alert. We dont recommend you you use this.

===== MODSEC_00_ANTIEVASION

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

MODSEC_00_STRICT

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

Enable/Disable Real-time Black List (RBL) rule class. You should only use this if the ASL server has a really fast local DNS 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.

MODSEC_00_AE_RULES

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

MODSEC_01_RULES

Enable/Disable the Bypass 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_10_ANTIMALWARE

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

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

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

MODSEC_11_DLP

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_BRUTE

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

MODSEC_20_USERAGENTS

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

MODSEC_30_ANTISPAM

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

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

MODSEC_50_ROOTKITS

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

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

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_99_JITP

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

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

Enable/Disable the malware output rule class.

MODSEC_99_SCANNER

Enable/Disable PHP check enforcement mode. Note setting this to no will still test for vulnerabilitites.

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. The following are the options you can use for each rule: