WAF/IPS Policies
Administration of built-in modules
Last updated
Administration of built-in modules
Last updated
This section allows you to administer WAF/IPS Policies, which define the sets of defined behaviors for the WAF. The Policies are assigned to paths/URLs in the Security Profiles section of the Web Proxy page.
Existing WAF/IPS Policies are listed on the left side; selecting one will display its contents on the right for editing. A default Policy must always exist. Additional Policies for specific situations can be defined if needed.
Admins can create new WAF/IPS Policies, as discussed below. Admins can also edit many of the Policies that are included out of the box in a new deployment.
Out of the box, many of the included Policies are named with a prefix of WAF. This naming convention is recommended when creating/editing new Policies, but it is not mandatory.
A prefix of WAFT indicates a Reblaze-maintained WAF/IPS Policy template. If you do not wish to see any templates on this page, select the Hide Templates checkbox on the upper right. Templates are used by the Create New Site wizard, and can also be assigned to other sites/applications by admins in the Security Profiles section of the Web Proxy page.
To create a WAF/IPS Policy, select an existing one and choose Duplicate, then edit the newly-created copy.
When viewing or editing a WAF/IPS Policy, the Active Modules section allows you to enable/disable some of the modules. The four on the left are always active and cannot be turned off. (However, an ACL Policy that resolves to an action of Bypass will exempt a requestor from them.) These four modules are:
Parameter | Functionality |
Essential Headers Checkup | A request without a header is illegitimate (and generally is an indication of a bot). This module blocks these requests. |
HTTP Methods | This module defines the HTTP Methods that are allowed in requests. |
Argument Limitations | This module enforces the Request Arguments Limitations that are specified below the list of Allowed HTTP Methods. |
RFC Compliance | This module ensures that every request is RFC compliant. Most penetration tools are non-compliant (often deliberately so)—thus, this module alone defeats and excludes a high amount of hostile traffic. |
The next three modules are optional, but are recommended in most situations:
Parameter | Functionality |
Bad Robots | Identifies and blocks malevolent bots, based on their user agents. This works differently than the Active Challenge process to identify bots. Therefore, when active challenges are disabled, this WAF capability can still be used. |
Dual Encoding | A common penetration technique is to encode a hostile request multiple times, in an attempt to evade detection and filtering. For example, an injection attack might be encoded in binary, and then sent as if it were plain text. Or, different types of encoding might be mixed together in the same request. This module detects and defeats these attempted attacks. |
* Injection Proof | This module detects and defeats different kinds of injection attacks: SQL, XSS, and OSC. (The "*" is a wildcard.) |
At the bottom of the page are the Request Arguments Limitations, Whitelist Argument Names, and Whitelist Rule IDs. These allow you to permit or deny requests based on the arguments contained in the request. For assistance with these entries, please contact support.
There will be at least one Policy that is designated by the Reblaze icon. It is provided and maintained by Reblaze, and is read-only.
