Create Rules

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.

Permissions

• The Modify site settings permission is required for adding and editing security rules.

• The Edit delivery rules permission is required for adding and editing delivery rules.

• Since rate rules can be used for both delivery and security rules, permissions for rate rules are included in both the Modify site settings permission and the Edit delivery rules permissions. For details on rate rules, see Create Rate Rules.

By default, the account admin user can manage these rules, and can add the required permission to roles assigned to additional users.

Create a rule

To open the Rules page to create a new rule, log in to your my.imperva.com account.

1. On the top menu bar, click Application.
2. On the sidebar, click Websites and click a website name.
3. On the sidebar, click Security > Rules.
4. Click Add Rule.

The Add/Edit Rule page includes the following elements:

Define a rule filter

Define a filter for the rule using predefined parameters.

For the full list of parameters, see Rule Filter Parameters.

Example:

Matched object	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.
Operator	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.
Editor	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.

Delivery actions

Define the action you want Imperva to take for every request or response that matches the rule filters.

In this section:

• Redirect URL
• Rewrite request
• Rewrite response
• Forward
• Replacement logic and wildcards
• Variables

Redirect URL

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.

Rewrite request

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.

Additional options for headers and cookies:

• Add new if missing: Use this 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.

• Rewrite if exists: Use this option to overwrite the value of the header or cookie if it is present in the request.

  This option is selected by default. If you remove this option, the Add new if missing option must be selected. In that case, the header or cookie is added if it does not exist, but an existing value is not overwritten.

Available rewrite actions:

Rewrite response

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.

Wildcards and variables are supported for header rewrite.

Additional options for headers:

• Add new if missing: Use this option to add a header that is absent from the original response. Note: You cannot use this option when the To field contains wildcard variables $1, $2, ..., as Imperva cannot determine the value of the header.

• Rewrite if exists: Use this option to overwrite the value of the header if it is present in the response.

  This option is selected by default. If you remove this option, the Add new if missing option must be selected. In that case, the header is added if it does not exist, but an existing value is not overwritten.

Forward

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 drop-down list.

Forward to Port

Forward matching requests to a specific port on the origin server. Context: Select one of the following: Use Port Value: Enter a port number. Use Header Name: Enter the name of the request header that includes the port number in the format IP:PORT. 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.

Replacement logic and wildcards

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

Variables

The following variables can be used in the To field, for both redirect and rewrite actions:

Examples:

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

Use variables to rewrite request headers. Identify the Imperva data centers that are most frequently used for your visitors. In this example, every request that reaches your origin server will include the Imperva-PoP header with the value of the Imperva data center that handled the request.

Security actions

Define the action you want Imperva to take for every request that matches the rule filters:

Setting Block Period

Security actions with a block period (i.e., Block Session, Block IP) have a fixed default setting of 10 minutes. Set a new block period from the following options:

• Fixed: Define a specific duration for the security block (i.e., 1-1440 minutes).

• Randomized: Apply a random duration from your defined time range to each security block (i.e., 1-1440 minutes).

Read More

• Delivery Rule Use Case Examples
• Security Rule Use Case Examples