Create application delivery rules, or implement your own security and access control rules on top of Imperva's existing security logic.
You can configure up to a maximum of 500 custom rules per site.
Note: To create delivery rules your subscription must include the Load Balancer.
In this topic:
Create a rule
Navigate to the Rules page to create a new rule:
- On the Cloud Security Console sidebar, click Websites (default).
- Click a site name to access the site's dashboard.
- On the sidebar, click Rules.
- Click Add Rule.
The Add/Edit Rule page includes the following elements:
Define a filter to determine when the rule is applied.
The filter defines the conditions that trigger the rule action. If left empty, the rule is always run.
The rule filter can include up to 2048 characters.
For details, see Define a rule filter.
Define the action you want Imperva to take for every request that matches the rule.
For details, see:
Give the rule a meaningful name.
Enable or disable the rule.
Note: The rule must be enabled if you want to use the Test Rule option below.
|Send an email notification whenever this rule is triggered||
Available for Security rules only.
|Test Rule Only on My IP Addresses||
Activates the rule for a select number of IPs only. When you create a rule, Imperva will detect your IP and use that as the default IP for testing.
Rules propagate across the system immediately to ensure that changes are applied in near real time.
In order to minimize the risk to your production environment, it’s recommended to activate a new or modified rule in test mode prior to activating in production.
Save the rule and enter a revision comment. The comment is stored as part of the rule revision for future reference.
Note: The revision comment may not contain special characters. Only alphanumeric, space, period (“.”), and underscore (“_”) characters are allowed.
For details on revision history, see Manage Rules.
Define a filter for the rule using predefined parameters.
For the full list of parameters, see Rule Filter Parameters.
Under If, select the part of the request or the sessions to which the filter is applied. For example, Client IP or Country. For full details on the available parameters, see Rule Filter Parameters.
Defines how the filter value is matched.
Most filter parameters support only a subset of the list of operators. For example, the QueryString filter parameter supports only the ‘equal to’ and ‘not equal to’ operators. When a filter parameter is selected (see Matched object above), only the supported operators will be displayed in the operator field.
For the full list of filter parameters and the supported operators for each, see Rule Filter Parameters.
|Value||The value to be matched.|
When you define a filter and click +Add, the filter syntax is added to the Editor. You can add as many filters as required. The filters are added to the rule syntax using the AND logic. For information about combining filters using the OR logic, refer to the Syntax Guide.
Alternatively, you can add filters directly using the native syntax. Every rule is checked for syntax validity before it is saved. For details, see the Syntax Guide.
Note: When defining application delivery rules (not security rules) an empty rule filter will match any request.
|Validate||Verifies the rule syntax. Validation is also performed automatically whenever you save a rule.|
Define the action you want Imperva to take for every request or response that matches the rule filters.
Note: When a server is identified as 'down' by the Imperva Load Balancer, our proxies start to send active monitoring requests to the origin server that is defined for the site, using the site’s Host header. (Origin servers are defined for the site in the Cloud Security Console in Websites > Settings > Origin Servers.)
If there are custom delivery rules defined for the site, such as forward or rewrite rules, they are not run.
Therefore, the default origin server itself must be able to receive requests from the proxy so that we can confirm server availability.
For more details on active monitoring, see Load Balancing Monitoring Settings.
In this section:
Redirect a URL. When a request matches a condition of a redirect rule, Imperva responds with a 30X response code which redirects the client to a different URL.
The redirected URL can be fixed for all requests matching the rule condition or, alternatively, can be customized based on the specific request line of each request.
The supported redirect codes are: 301, 302, 303, 307 and 308 (Redirect codes W3C specification).
Redirect rules are the first type of rules to be evaluated. This means that if a redirect action has been triggered, Imperva will stop inspecting the request for other rules.
Example: Redirect to a new site.
Original request: http://www.oldsite.com/sport/football
Redirected request: http://www.newsite.com/sport/football
Note: Redirect to FQDN and redirect to HTTPS in Website > Settings > General have a higher priority than rules in the Rules table. To maximize ease-of-use, it’s recommended to define all redirect rules in the Rules table.
The rewrite/remove actions can be used to modify, add, and remove different request attributes such as URL, headers, and cookies. Imperva receives the request from the client, applies the relevant changes, and then forwards the request to the origin server. Responses to Rewrite actions are cached by default.
Use the Add new if missing option to add a header or cookie that is absent from the original request. Note: You cannot use this option when the To field contains wildcard variables $1, $2, ..., as Imperva cannot determine the value of the header.
Available rewrite actions:
Rewrite Request URL
Modifies the path to which a specific request is targeted. In such a case, the client enters a certain path in his browser, while the server uses a different path to serve the requested resource.
User enters www.mysite.com/football in his browser and is served by the www.mysite.com/sport/football page with no change to the request line.
|Rewrite Request Header||
Modifies or adds a request header before passing traffic to the origin server.
The user has to indicate the header name, whether the header should be added if it is absent from the original request, and the new header value.
When rewriting the Host header, the following aspects should be kept in mind:
|Remove Request Header||
Removes a specific request header so that it won’t be sent to the origin server.
In this example, the X-Old-Header header will be removed from any request in which it appears.
Remove multiple header occurrences: Removes all occurrences of the specified header from the request. By default, only the first occurrence of the header is removed
|Rewrite Request Cookie||
Modifies or adds cookies that are sent by the client to the origin server. The cookie name and value should be indicated.
If the web application expects to receive a cookie to identify a specific client characteristic (e.g., device type), a new cookie can be sent to the origin without actually setting a cookie on the client side (the cookie is created on the Imperva edge and sent to the origin).
The value of the theme cookie will be set to light for requests towards the origin (theme=light).
|Remove Request Cookie||
Removes a specific cookie set on the client, which means that it won’t be sent to the origin server.
The cookie theme will be removed.
The rewrite/remove actions can be used to do the following, before the response is returned to the client.
- modify, add, and remove headers from the response
- rewrite the HTTP response status code
- replace the default error response and error code
Imperva receives the response from the origin server, applies the relevant changes, and then returns the response to the client.
Use the Add new if missing option to add a header that is absent from the original response.
Wildcards and variables are supported for header rewrite.
Note: You cannot use the Add new if missing option when the To field contains wildcard variables $1, $2, ..., as Imperva cannot determine the value of the header.
|Rewrite Response Header||
Modifies or adds a response header before passing the response back to the client.
Enter the header name, the new header value, and whether the header should be added if it is absent from the original response.
Note: The following headers are restricted and cannot be rewritten: Cache-Control, Content-Type, Content-Length, Transfer-Encoding and Content-Encoding.
|Remove Response Header||
Removes a specific response header so that it won’t be sent back to the client.
In this example, the X-Old-Header header will be removed from any response in which it appears.
Remove multiple header occurrences: Removes all occurrences of the specified header from the response. By default, only the first occurrence of the header is removed
|Rewrite Response Code||
Modifies the status code in the response from the origin server before sending it back to the client.
The Response Status Code field accepts any 3-digit number.
|Rewrite Response Error||
Replaces the default error response and error code that are returned to the client when a request is blocked.
For details, see Create Custom Error Response Rules.
Responses to Forward actions are cached by default.
|Forward to Data Center||
Select the data center to which a specific request will be sent.
The target data center can include a single origin server or multiple origin servers in a load balanced mode.
To use a data center for forwarding, select the Support only forward rules option on the Origin Server settings page.
Data centers that are configured to support forwarding can accept requests only through the Forward rule, and cannot be used to support Global Server Load Balancing.
GSLB between Data Centers used for Forwarding is not supported.
The data centers that are configured to support forwarding are displayed in the Target Data Center dropdown list.
|Forward to Port||
Forward matching requests to a specific port on the origin server.
Context: Select one of the following:
Value: Enter the port number or header name.
Note: A custom rule configured with the Forward to Port action overrides the Port Forwarding setting on the Delivery Settings page.
When defining delivery actions, such as rewrite or redirect, string replacements can be a useful tool for keeping the number of rules under control and easy to manage.
String replacements work in the following way:
- There are always From and To fields.
- The string in the From field represents the full string to be replaced and may include wildcards.
- In order for a rule to apply, there must be an exact match on the From field. This is an additional filtering layer on top of the rule criteria filter.
- The To field represents the full string replacement target. It may contain a reference to the wildcards used in the From field, causing replacements to behave in a dynamic manner during request runtime.
- The asterisk wildcard * can be used in the From field, each * can be referenced using the $ character in the To field.
- The asterisk will match the first instance in the string (unlike in regular expressions).
- A rule can support up to nine different asterisks: $1 will refer to the first *, $2 to the second *,...,$9 to the ninth *
Example: Using wildcards in a redirect rule.
Original request: http://www.mysite.com/sport/football
Redirected request: http://www.mysite.com/football/sport
The following variables can be used in the To field, for both redirect and rewrite actions:
|$scheme||Request scheme/protocol.||http or https|
|$host||Host header value - the host name.||www.mysite.com|
|$path||Request line path.||/sport/football/results.php|
|$args||Request line arguments.||country=US&year=2016|
|$url||$path + ? + $args||/sport/football/results.php?country=US&year=2016|
The client's outgoing port number. It can be used, for example, to distinguish users behind NAT.
|$continent||Two character continent code.||EU|
Two character ISO 3166-1 country code.
When the country cannot be identified, such as for an IP using an anonymous proxy, the code 00 is used.
|$state||Two character state, province, or region, where applicable.||CA|
|$latitude||Approximate latitude coordinates.||4.863890|
|$longitude||Approximate longitude coordinates.||52.300830|
|$postalcode||Postal/zip code. May be available for requests from specific countries.||1191|
|$epoch||The Unix timestamp - an integer value representing the number of microseconds that have elapsed since the beginning of the Unix epoch (January 1, 1970).||1502617252081|
|$asn||The Autonomous System Number. It can be used to send the client's ASN to the origin in a header.||1680|
Example: Use variables to redirect requests to a new path (/football), maintaining the original scheme, domain, and arguments.
Original request: https://www.mysite.com/sport/football/results.php?country=US&year=2016
Redirected request: https://www.mysite.com/football?country=US&year=2016
Define the action you want Imperva to take for every request that matches the rule filters:
|Alert||Generates a non-blocking alert for this event.||Useful for testing new rules.|
|Block Request||Blocks the current request and generates an alert.||Preferred block action.|
|Block Session||Blocks the current session and generates an alert. Any subsequent request from the same session is blocked.||Session is based on the Imperva session cookie - not the application's session (e.g. JSESSIONID).|
|Block IP||Blocks the current IP and generates an alert. Any subsequent request from the same IP is blocked for a period of 10 minutes.||Use with caution. Clients originating from a VPN, proxy, or NAT may be inadvertently blocked.|
|Require Cookie Support||Requires any client that matches the rule filters to support cookies in order to complete the request.||May be of limited value when working with APIs.|
|Require CAPTCHA Support||Requires any client matching the rule filters to pass a CAPTCHA test in order to complete the request. Since the CAPTCHA test is embedded in an HTML page, this action should only be enabled for HTML resources.||Since the CAPTCHA test is embedded in an HTML page, this action should only be enabled for HTML resources.|