Book IndexHideShow
Back to topic

Cloud Application Security

Create Rules

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.

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:

  1. On the Cloud Security Console sidebar, click Websites (default).
  2. Click a site name to access the site's dashboard.
  3. On the sidebar, click Rules.
  4. Click Add Rule.

The Add/Edit Rule page includes the following elements:

Field/Option Description
Rule Filter

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.

Rule Action

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

For details, see:

Rule Name

Give the rule a meaningful name.

Note:

  • The Rule Name may not contain special characters. Only alphanumeric, space, period (“.”), and underscore (“_”) characters are allowed.
  • Rate Rules: A rate rule name may not contain special characters, including the underscore ("_") character or periods ("."). Only alphanumeric characters, hyphens ("-"), and spaces are allowed.
Enable Rule

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

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 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.

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 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.

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:

Action Description

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.

Notes:

  • The URL doesn’t include the scheme or host name/domain - only the request path.
  • The URL should start with a “/”.
  • If the host name/domain needs to be rewritten, a header rewrite action rule for the Host header should be defined.
  • Wildcards and variables are supported in URL rewrite.
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:

  • Host header modification affects SNI host name as well
  • In case the modified Host header value (host name/domain) is served from a different origin server, a Forward rule should be configured to direct the request to the appropriate origin server (data center)

Notes:

  • To add a header that is absent from the original request, use the Add new if missing option.
  • Wildcards and variables are supported in Header rewrite.
  • A header can be removed using the Remove Header action.
  • The following headers are restricted and cannot be rewritten: Cache-Control, Content-Type, Content-Length, Transfer-Encoding and Content-Encoding.
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).

Notes:

  • To add a cookie that is absent from the original request, use the Add new if missing option.
  • Wildcards and variables can be used for cookie rewrite.
  • A cookie can be removed using the Remove Cookie action.
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.

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.

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.

Action Description
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.

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 dropdown 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:

Variable Description Sample Values
$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
$src_port

The client's outgoing port number. It can be used, for example, to distinguish users behind NAT.

777
$continent Two character continent code. EU
$country

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.

NL
$state Two character state, province, or region, where applicable. CA
$city City name. Amsterdam
$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

Security actions

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

Rule action Description Notes
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 Javascript Support Requires any client that matches the rule filters to support Javascript in order to complete the request. Since the Javascript test is embedded in an HTML page, this action should only be enabled for HTML resources. Since the JavaScript test is embedded in an HTML page, this action should only be enabled for HTML resources.
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.

Read More

Join the Discussion