Toma de decisiones y juicios de valor

The WEBSITE > Website Translations page is used to set a variety of address translation rules for application-specific packets sent through the Barracuda Web Site Firewall. It translates the internal codes, headers, and cookies so that the actual message is concealed to the external users. It has features for Web site cloaking and translation of URLs and headers in the requests and responses.

Configuring Request Rewrite

This policy sets rewrite rules for inbound requests. It specifies the parameters to modify incoming request headers. It allows you to add, delete, or rewrite headers and rewrite or redirect the URL. Request Rewrites are used for specific purposes. For example, the Barracuda Web Site Firewall fully terminates the TCP/IP session for the original request and creates a new request using the private interface (PIF) as the new source IP address. If you have a need for the original source IP address, you could add a header that stores that address.

It is used to relay the actual client information back to the back-end resource. Enabling this parameter allows a back-end resource to know exactly who is the client and from where the client is requesting the information.

This feature is available only with the purchase of Barracuda Web Site Firewall model 460 and higher.

To configure Request Rewrite

1. Specify values for the following fields:

• Rule Name. Enter the name for the request rewrite rule.

• Sequence Number. Enter the sequence number of this request rewrite policy. The sequence number sets the order of execution for multiple configured policies from highest (1) to lowest (64).

• Action. Select the request rewrite action for this policy from the drop-down list. • Header Name. Enter the header name to match for this policy. This is required if the

action is to a header (rather than an URL).

• Old value. Enter the old value of a header or URL path to be rewritten.

• Rewrite Value. Enter the new value of a header or URL path to rewrite. This is required if the action is to rewrite (or redirect) a header or URL.

• Rewrite Condition. Enter the condition under which the rewrite should occur. An asterisk (*) indicates there are no conditions (applies to all). Refer Request Rewrite Condition on page 62 for more information.

• Continue Processing. Select whether to check against other (higher sequence number) policies or stop here. This is relevant only when additional policies have been configured.

2. Click Add to add the above configurations.

Request Rewrite Condition

Request rewrite condition is an expression that consists of a combination of HTTP headers and/or query string parameters. For HTTP headers, word "Header" should be prefixed before the header expression and for Non-HTTP headers "Header" should not be prefixed. Define the header type (for example, user agent or accept) for which you want an action to occur or add a wildcard to accept any type of header.

Customized Security for Websites 63

• contains, CONTAINS, co, CO - checks if the operand contains the given value.

• ncontains, nCONTAINS, nco, nCO - checks if the operand does not contain the given value. • rcontains, rCONTAINS, rco, rCO - checks if the operand contain the given value. The given

value is interpreted as a regular expression.

• equals, EQUALS, eq, EQ - checks if the operand is equal to the given value.

• nequals, nEQUALS, neq, nEQ - checks if the operand is not equal to the given value.

• requals, rEQUALS, req, rEQ - checks if the operand is equal to the given value. The given value is interpreted as a regular expression.

• exists, EXISTS, ex, EX - checks if the operand exists. It does not require any given value. • nexists, nEXISTS, nex, nEX - checks if the operand does not exist. It does not require any given

value.

Each expression can be joined with another expression by using either of the following tokens: • or, OR, || - This checks for either of the expressions are true.

• and, AND, && - This checks if both the expressions are true.

More than one expressions can be grouped together by using parenthesis '(' and ')'.

The expression consists of an operation being carried out on one of the following tokens. Each of the following tokens are case insensitive.

Header

This refers to an HTTP header on the request path. The term "Header" should be followed by the name of the header on which the action is to be applied.

Example: Header Accept co soap or Header Soap-Action ex

Client IP

This refers to the IP address of the client sending the request. The IP address can be either host IP address or subnet IP address specified by a mask. Only the following operations are possible for this token:

"EQUAL" and "NOT EQUAL"

Using any other operations are not permitted.

Example: Client-IP eq 192.168.1.0/24 (subnet IP address containing the mask) Client-IP eq 192.168.1.10 (host IP address)

Uri

The URI is a Uniform Resource Identifier and identifies the resource upon which to apply the request. Example: URI rco /abc*html

Method

This refers to HTTP method in the request. Example: Method eq GET

Http Version

This refers to the version of the HTTP protocol of the request. Example: HTTP-Version eq HTTP/1.1

This refers to query part of the URL which is passed to the servers as a name-value pair. In addition, the word "$NONAME_PARAM" is used to refer to the case where the parameter name is absent. Example: Parameter sid eq 1234, Parameter $NONAME_PARAM co abcd

Pathinfo

This refers to the portion of URL which contains extra information about the path of the resource on the server.

Example: pathinfo rco abc*

Configuring Response Rewrite

This policy sets rewrite rules for outbound responses. It allows you to add, delete, or rewrite headers. Response Rewrites are used for specific purposes. For example, if responses include a header that lists the source IP address you could delete that header. This would prevent users from seeing the actual IP address of a server.

To configure Response Rewrite

1. Specify values for the following fields:

• Rule Name. Enter the name for the response rewrite rule.

• Sequence Number. Enter the sequence number of this request rewrite policy. The sequence number sets the order of execution for multiple configured policies from highest (1) to lowest (64).

• Action. Select the request rewrite action for this policy from the drop-down list. • Header Name. Enter the header name to match for this policy. This is required if the

action is to a header (rather than an URL).

• Old value. Enter the old value of a header or URL path to be rewritten. This is required if the action is to rewrite (or redirect) a header or URL.

• Rewrite Value. Enter the new value of a header or URL path to rewrite. This is required if the action is to rewrite (or redirect) a header or URL.

• Rewrite Condition. Enter the condition under which the rewrite should occur. An asterisk (*) indicates there are no conditions (applies to all). Refer Response Rewrite Condition on page 64for more information.

• Continue Processing. Select whether to check against other (higher sequence number) policies or stop here. This is relevant only when additional policies have been configured.

2. Click Add to add the above configurations.

Response Rewrite Condition

Response rewrite condition is an expression that consists of a combination of HTTP headers and/or query string parameters. For HTTP headers, word "Header" should be prefixed before the header expression and for Non-HTTP headers "Header" should not be prefixed. Define the header type (for example, user agent or accept) for which you want an action to occur or add a wildcard to accept any type of header.

The following are the possible operations that can be given in the expression. • contains, CONTAINS, co, CO - checks if the operand contains the given value.

• ncontains, nCONTAINS, nco, nCO - checks if the operand does not contain the given value. • rcontains, rCONTAINS, rco, rCO - checks if the operand contain the given value. The given

Customized Security for Websites 65

• equals, EQUALS, eq, EQ - checks if the operand is equal to the given value.

• nequals, nEQUALS, neq, nEQ - checks if the operand is not equal to the given value.

• requals, rEQUALS, req, rEQ - checks if the operand is equal to the given value. The given value is interpreted as a regular expression.

• exists, EXISTS, ex, EX - checks if the operand exists. It does not require any given value. • nexists, nEXISTS, nex, nEX - checks if the operand does not exist. It does not require any given

value.

Each expression can be joined with another expression by using either of the following tokens: • or, OR, || - This checks for either of the expressions are true.

• and, AND, && - This checks if both the expressions are true.

More than one expressions can be grouped together by using parenthesis '(' and ')'.

The expression consists of an operation being carried out on one of the following tokens. Each of the following tokens are case insensitive.

Header

This refers to an HTTP header on the request path. The term "Header" should be followed by the name of the header on which the action is to be applied.

Example: Header Accept co soap or Header Soap-Action ex

Response Header

This refers to an HTTP header on the response path. The term "Response-Header" should be followed by the name of the header on which the action is to be applied.

Example: Response-Header Set-Cookie co sessionid

Status Code

This refers to the status code of the response returned by the servers. Example: Status-Code eq 200