CacheGuard-OS
User's Guide - Version UF-2.3.3

The WAF

WAF stands for Web Application Firewall and allows you to protect Web applications against malicious Web requests destined to violate or damage Web applications and/or servers. CacheGuard appliance integrates a WAF that works jointly with the Web Server Cloaking to provide an even higher level of security for Web servers. The WAF can protect against content attacks such as, but not limited to, XSS (Cross Site Scripting), SQL injection and command injection. Malicious requests are then blocked even before reaching real Web servers (hosts).

To enable the WAF, both rweb and waf modes must be activated using the mode rweb on and mode waf on commands. You can refer to the Web Server Cloaking section to learn how to configure the rweb mode. Then you can use the waf command to configure the content filtering for protected Web applications. The CacheGuard WAF provides two types of content filtering that can be activated on the same appliance at the same time. The two content filtering types are as follows:

• Generic Filtering: rejects all known content attacks and can be globally activated (for all websites) or be activated per protected website.
• Customised Filtering: allows or denies Web requests that you can design by yourself per website.

Generic Filters

Generic WAF rules are classified by groups called filters (a filter is composed of WAF rules). Each blocking rule in a generic filter has a score point (an integer) and whenever a rule is matched in a Web traffic, its score point is added to a global score. Once a threshold score is reached for a given Web traffic, the Web traffic is blocked by the WAF. Generic filters are provided by OWASP and are classified as follows:

• dliis: rules to prevent from IIS applications Data Leakage.
• dljava: rules to prevent from Java applications Data Leakage
• dlphp: rules to prevent from PHP applications Data Leakage.
• dlsql: rules to prevent from SQL requests Data Leakage.
• java: rules to protect Java Applications.
• lfi: rules to protect against Local File Inclusion attacks.
• nodejs: rules to protect Node.js Applications.
• php: rules to protect PHP Applications.
• rce: rules to protect against Remote Code Execution attacks.
• rfi: rules to protect against Remote File Inclusion attacks.
• sf: rules to protect against Session Fixation attacks.
• sqli: rules to protect against SQL Injection attacks.
• xss: rules to protect against Cross-site Scripting attacks.

Generic filters can be globally activated or deactivated. For instance, to activate the WAF and protect all websites (cloacked by the reverse Web proxy in rweb mode) against SQL injection attacks, you can use the following commands:

• mode rweb on
• mode waf on
• waf generic sqli on
• apply

In absence of any generic WAF filter specifications for a website, that website would be protected by globally activated generic WAF filters. If a particular website needs specific protections, you have the possibility to activate or deactivate generic WAF filters for that website. For instance, to deactivate the sqli generic filter for the www.example.com website, you can use the following commands:

• waf rweb generic www.example.com sqli off
• apply

Custom Filters

Custom WAF filters allow you to have accurate control over Web requests on a website in particular. A custom WAF filter is composed of custom WAF rules defined in a textual file that you can load into a CacheGuard appliance. A custom WAF rule allows you to allow or deny a Web request according to its HTTP method and content. A rule is defined in 1, 2 or 3 lines according to the specified HTTP method.

The definition of a custom WAF rule should always begin with the rule keyword and be followed by an identifier, an action (allow or deny) and an HTTP method (in lowercase). Supported HTTP methods are GET, HEAD and POST. For the GET and POST methods, a second optional line can specify allowed contents (the path and arguments part) in the Web request. The second line should always begin with the uri keyword and be followed by a (PCRE: Perl Compatible Regular Expression) regular expression specifying allowed contents. For the POST method, a third optional line can specify allowed contents in the POST request. The third line should always begin with the body keyword and be followed by a regular expression specifying allowed data in the body part of the POST request.

As an example, the following custom WAF filter includes 6 rules: the first and second rules allow GET requests on respectively "/" and "index.html" locations. The third rule, allows POST requests on "/cgi-bin/set-phone.cgi" with a body in the form of "name=<string>&phone=<numbers>". The last 3 rules block (deny) any other Web requests.

rule r1 allow get
uri "^/$"

rule r2 allow get
uri "^/index\.html$"

rule r3 allow post
uri "^/cgi-bin/set-phone.cgi$"
body "^name=[[:print:]]*\&phone=[[:digit:]]*$"

rule r4 deny get
rule r5 deny head
rule r6 deny post

To apply this custom WAF filter to the www.example.com website, save it first in a file located on a trusted file server. Then you will be able to load it into your CacheGuard appliance and associate it to the www.example.com website. Please refer to access file command manual to learn how to declare a trusted file server. The following commands load a custom WAF filter described in a file named www.example.com.rules from a TFTP file server having the 172.18.2.1 IP address and apply it to the www.example.com website:

• waf rweb custom www.example.com load tftp 172.18.2.1 www.example.com.rules
• apply

When a custom WAF filter is loaded into the appliance, the custom WAF rule compiler examines its content and in case where an error is detected, the loading is rejected. Note that when generic WAF filters are combined with a custom WAF filter, generic WAF filters are applied first. In this way, malicious Web requests are rejected by generic WAF filters before reaching the custom WAF filter.

Reputation Filters

CacheGuard appliance can block Web requests incoming from IP addresses that have a bad reputation. This is called reputation based filtering. The reputation based filtering in CacheGuard appliance, can be configured to block all Web requests sent from IP addresses belonging to a country in particular or to an RBL (Real Time Blacklist). You can find more information on the reputation based filtering in the waf command manual.

Website Auditing

A Web request auditing Web GUI is integrated into the CacheGuard appliance and allows you to inspect all HTTP requests on a given website. With the help of the Web auditing, you can know why a Web request is blocked and what is the WAF rule (generic or custom) that blocks it. To activate the Web auditing for the www.example.com website, use the following commands:

• admin waudit on
• waf rweb audit www.example.com on
• apply

The Web auditing Web GUI is accessible via the https://<cacheguard-ip-address>:8091 URL where <cacheguard-ip-address> is the CacheGuard appliance IP address. The IP address to use depends on the administration access policy and administration topology configured on the appliance. Please refer to the access admin and admin topology command manuals for further information. The screenshot below shows the Web auditing GUI. Sometime a WAF rule is matched by mistake for a regular Web request. We call that a false positive match. The Web request auditing can help to detect false positive matches in order to remedy by modifying the Web application (when it's possible) or by bypassing rules that cause false positive matches. You can refer to the waf command manual to learn more about WAF rule bypassing.