Content Rewriting

The Barracuda Load Balancer ADC allows you to rewrite selected content of requests and responses. This feature can be used to implement website cloaking and translation of URLs and headers in requests and responses. It can translate the internal codes, headers, and cookies so they are concealed from external users. Content rewriting allows you to configure address translation rules for application specific packets sent through the Barracuda Load Balancer ADC.

Configuring URL Translation

When a web server returns a URL, sensitive information can be exposed and used to launch a variety of web attacks against the server. You can prevent these potential attacks by configuring URL translation rules on the Barracuda Load Balancer ADC to modify the prefix, domain, and response body of an internal URL to an externally viewable URL.

You can also use URL translation to make internal applications publicly accessible, even when the applications link to internal servers that are not defined in the external DNS name space. For example, Company ABC has an internal application registered in the internal DNS as finance.abc. The application can be made available on the Internet at www.companyabc.com/finance.abc with a URL translation rule that maps the internal domain to the external domain of www.companyabc.com. 

To configure URL translation rules, go to the URL Translations section of the TRAFFIC > Website Translations page.

Configuring HTTP Request Rewrite

HTTP request rewrite rules specify how to modify the request headers and URL or specify how to redirect a request. Headers can be added, removed, or edited on the Barracuda Load Balancer ADC before the request is forwarded to the back-end server. The URL can be rewritten to map to a different resource. A redirect response can also be issued to the clients to point them to an updated location or resource. For example, Request Rewrite is used by default to relay the client IP address to the back-end server (in Proxy mode), by inserting the header X-Forwarded-For with the value of the client IP. The back-end server can extract and use this value. Similarly, authentication parameters (such as certificate details or user name) can be forwarded by inserting request headers and using macros. See   How to Pass Client Certificate Details to a Back-end Server for more details. To configure HTTP Request Rewrite, navigate to TRAFFIC > Web Translations and then scroll to HTTP Request Rewrite. For detailed configuration instructions, click Help on that page. To format a Request Rewrite
Condition refer to Rewrite Condition Format below.

Configuring HTTP Response Rewrite

This policy sets rewrite rules for outbound responses. It allows you to add, delete, or rewrite headers. Response Rewrites are used for many purposes. For example, if a response included a header listing the source IP address, response rewrite could delete that header preventing external users from seeing the actual IP address of the server.
To configure HTTP Response Rewrite, use TRAFFIC > Website Translations > HTTP Response Rewrite. For detailed configuration instructions, click Help on that page.

Configuring Request Rewrite and Response Rewrite

To configure a request rewrite rule, perform the following steps:

1. Go to the TRAFFIC > Website Translations page, and in the HTTP Request Rewrite section or HTTP Response Rewrite  section, specify values for the following fields:
   
   1. Rule Name – Enter a name for the request or response rewrite rule.
   2. Sequence Number – Set the sequence number for the request or response rewrite policy. This number determines the order of execution for multiple configured policies from highest (1) to lowest (1500).

   3. Action – Set the action to: Insert Header –Inserts a header to the request; Remove Header – Removes the header from the request; Rewrite Header – Rewrites the value of the existing header in the request.

   4. Header Name – Enter the relevant Header Name, for example X-Forwarded-For.
   5. Old Value – Enter the initial request header to be rewritten if the Action is Rewrite Header. An asterisk (*) rewrites all named headers, or specify the value or expression to be rewritten.
   6. Rewrite Value – Enter the new value of the header to be rewritten when the Action is set to Insert Header or Rewrite Header. Use the macros listed below to specify parameters from the client. When rewriting a header you can specify one or more fields using the separators such as colon (:), semicolon (;), space ( ) and comma (,). In Rewrite Value, the fields can be defined for example: "Name=abc_cookie; Domain=example.com:Path=/". The rewrite-value supports substring addressing of matches, i.e. the matching sub strings can be referenced using $1,$2,...$n. See Supported Macros below for a list of macros supported for rewrite values.
   7. Rewrite Condition – Set the condition under which a rewrite should occur. An asterisk (*) indicates there are no conditions (applies to all). Details on the format of the Rewrite Condition are explained below in Rewrite Condition Format. 
2.  Click Add to add the above settings.

Note: When multiple policies are configured, the request continues to be processed by other (higher sequence number) policies. If you wish to stop processing after a particular rule is matched, click Edit next to the rule and set Continue Processing to No.

Rewrite Condition Format

The request Rewrite Condition specifies when a rewrite should occur. The Rewrite Condition is made up of expressions combining Request Rewrite Tokens   and Operations for Request Rewrite and Response Rewrite Conditionson those tokens for Request Rewrites. The Rewrite Condition is made up of expressions combining Response Rewrite Tokens   and Operations for Request Rewrite and Response Rewrite Conditionson those tokens for Response Rewrites.These expressions can then be joined with each other using logical or (or, OR, ||) or logical and (and, AND, &&). Examples of Rewrite Conditions: (Header User-Agent co mozilla) , (URI rco /abc*html), (Client-IP eq 10.0.0.1)&&(Method eq POST). An asterisk indicates there are no conditions for rewrite, so the rewrite is done in every case.

Request Rewrite Tokens

These tokens can be used in a request Rewrite Condition:

• Header – The HTTP header in the request. The word Header precedes the name of the relevant header or * to indicate all headers. Examples: Header Accept co soap,  Header Soap-Action ex.
• Client-IP –The IP address of the client sending the request. The IP address can be either a host IP address or a subnet specified by a subnet mask. Only operations EQ and NEQ can be combined with this token. Examples: Client-IP eq 192.168.1.0/24 (subnet qualified by a netmask) Client-IP eq 192.168.1.10 (host IP address)
• Uri – The Uniform Resource Identifier of the resource on which to apply the rule. Example: URI rco /abc*html
• Method – The HTTP method in the request. Example: Method eq GET
• Http-Version – The HTTP protocol version of the request. Example: HTTP-Version eq HTTP/1.1
• Parameter – The query part of the URL which is passed to the servers as a name-value pair. In addition, the word "$NONAME_PARAM" can be used when the parameter name is absent. Examples: Parameter sid eq 1234, Parameter $NONAME_PARAM co abcd
• Pathinfo – The portion of URL which contains extra information about the path of the resource on the server. Example: pathinfo rco abc*

Response Rewrite Tokens

These tokens can be used in a response Rewrite Condition:

• Header – The HTTP header in the request. The word Header precedes the name of the relevant header or * to indicate all headers. Examples: Header Accept co soap,  Header Soap-Action ex.

• Response-Header – 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 – The status code of the response returned by the servers. Example: Status-Code eq 200 

Operations for Request Rewrite and Response Rewrite Conditions

These operations can be combined with Request Rewrite Tokens and Response Rewrite Tokens in a request or response Rewrite Condition:

• contains, CONTAINS, co, CO – Token contains the given value.
• ncontains, nCONTAINS, nco, nCO – Token does not contain the given value.
• rcontains, rCONTAINS, rco, rCO – Token contains the given value which is interpreted as a regular expression.
• equals, EQUALS, eq, EQ – Token equals the given value.
• nequals, nEQUALS, neq, nEQ – Token does not equal the given value.
• requals, rEQUALS, req, rEQ – Token equals the given value interpreted as a regular expression.
• exists, EXISTS, ex, EX – Token exists.
• nexists, nEXISTS, nex, nEX – Token does not exist.

Configuring Response Body Rewrite

This policy sets the rule for searching and replacing any text string in the response body. Only responses whose content-type begins with text/ can be searched, including text/html, text/plain, text/javascript, text/css, text/xml. Neither flash nor applet content can be searched. The search and replace strings should be text rather than regular expressions. Metacharacters cannot be used, such as \r or \n in either search or replace, which means you cannot search and replace any multi-byte charset strings.

To configure Response Body Rewrite, use TRAFFIC > Website Translations > Response Body Rewrite. For detailed configuration instructions, click Help on that page.

Supported Macros

For Request Rewrites

• $SRC_ADDR Inserts the source (client) IP address. You can use it for the new value (Rewrite Value parameter) when inserting or rewriting a header
• $URI Should be specified in the new value, if you are rewriting or redirecting the URI. $URI specifies the complete request URI including the query string.
• $X509_VERSION The client certificate's X509 version string.
• $X509_SERIAL_NUMBER The serial number of the client certificate.
• $X509_SIGNATURE_ALGORITHM The Signature Algorithm used in the client certificate.
• $X509_ISSUER The client certificate's issuer string.
• $X509_NOT_VALID_BEFORE Time from which the client certificate is valid.
• $X509_NOT_VALID_AFTER Time after which the client certificate is invalid.
• $X509_SUBJECT The client certificate's Subject string.
• $X509_SUBJECT_PUBLIC_KEY_TYPE The X509 Certificate Subject Key Identifier String of the client certificate.
• $X509_SUBJECT_PUBLIC_KEY Public Key modulus of the client certificate.
• $X509_SUBJECT_PUBLIC_KEY_RSA_BITS Size of the client certificate's public key, in bits.
• $X509_EXTENSIONS The client certificate's X509 Extensions String.
• $X509_HASH The X509 Hash string of the client certificate.
• $X509_WHOLE The X509 client certificate represented as a string in PEM format.
• $AUTH_USER Adds the username.*
• $AUTH_PASSWD Adds the password.*
• $AUTH_GROUPS Adds the user roles.*

For Response Page

• %action-id The attack id of the violation which resulted in this response page being displayed.
• %host The host which sent this request.
• %s The URL of the request which caused this violation.
• %client-ip The Client IP address of the request which caused the violation.
• %attack-time The time at which the violation occurred.
• %attack-name The attack name of the violation which resulted in the response page to be displayed.