CacheGuard OS
User's Guide - Version EH-1.5.2
Web Application Firewall (WAF)
The WAF module allows you to protect Web applications against malicious HTTP requests destined to violate or damage Web infrastructures. This module provides protection against content attacks like XSS (Cross Site Scripting), SQL Injection or Command Injection. Malicious requests are filtered and blocked before reaching Web applications.
Two content filtering methods are available in CacheGuard OS: Generic content filtering and Customised content filtering. Generic filters reject all known attacks and may be configured by activating or deactivating available filters for all protected Web sites or only for a given Web site. Customised filters are applied to a specific Web site by allowing or denying known authorised or unauthorised HTTP requests.
The WAF module works in conjunction with the reverse proxy so the the reverse Web mode should be activated and configured prior to any WAF configuration. Please refer to the
Web Server Cloaking section of the documentation to configure the reverse Web mode.
To activate the WAF or content filtering module use the following commands:
Generic Content Filters
To activate the filter named "generic_attacks" for all Web sites use the following commands:
- mode waf on
- waf generic generic_attacks on
- apply
The "generic_attacks" filter protects your Web application against the following bad requests:
- OS Command Injection Attacks
- Coldfusion Injection
- LDAP Injection
- SSI injection
- UPDF XSS
- Email Injection
- HTTP Request Smuggling
- HTTP Response Splitting
- RFI Attack
- Prequalify Request Matches
- Session fixation
- File Injection
- Command access
- Command injection
- PHP injection
If you want to deactivate the filter "generic_attacks" for the Web site "www.example.com" use the following commands:
- mode waf on
- waf rweb generic www.example.com generic_attacks off
- apply
Custom Content Filters
Custom filters allow you to have a more restrictive control on allowed or denied requests on a given Web site. The "GET", "HEAD" and "POST" HTTP method can be filtered by defining regular expressions for allowed or denied requests.
Regular expressions are based on PCRE (Perl Compatible Regular Expression). A restrictive policy may list all allowed requests and end the list with a "deny everything" rule.
The process of custom rules creation is very easy. You have just to create your rule set using your favourite text editor and then upload it into the appliance.
To allow only the GET method on the URI "/" and the POST method on the URI "/cgi-bin/set-phone.cgi" with posted values "name=<string> phone=<numbers>" to the Web site "www.example.com" proceed as follows:
Use a text editor to create a file with the name of your choice (we've chosen the name "www.example.com.rules" in this example) and the following content:
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
Put this file on a trusted file server (Here we suppose the trusted file server is a TFTP file server reachable at the IP address 172.18.2.1 - See the command "access file" for further information about trusted file servers). Now you can use the following commands to upload your custom rule file for the Web site "www.example.com.":
- waf rweb custom www.example.com load tftp 172.18.2.1 www.example.com.rules
- apply
When a custom rule file is loaded into the appliance, the rule compiler examines its content and if there are syntax or other errors, the loading is rejected and errors are printed. At this stage you have to fix errors using your text editor and reload the file. Note that generic filters may be combined with custom filters. When using both generic and custom filters, generic filters are always applied before custom rules. This way malicious requests are rejected before reaching your custom filters.
Reverse Web Auditing
An auditing module integrated into the appliance allows you to inspect all HTTP requests for a given Web site. This module allows you to easily design your custom rules. To activate the auditing mode for the "www.example.com" Web site, use the following commands: (Note that in this example all required commands are invoked but if you've already set some features you are not obliged to use all listed commands).
- ip internal 172.18.2.254 255.255.255.0
- mode waf on
- mode rweb on
- admin waudit on
- admin topology internal on
- access admin add internal 172.18.2.1
- hostname cacheguard
- domainname example.com
- port waudit 8091
- waf rweb audit www.example.com on
- apply
Now to inspect HTTP requests use a Web navigator and connect to the URL "https://172.18.2.254:8091".
The above picture shows the Web auditing GUI.
Copyright (C) 2009-2020 CacheGuard - All rights reserved