This document explains how to configure the NetScaler to rewrite the contents of an HTTP header in an inbound request packet with the source IP address of the request.
Requirements:
This procedure works only on NetScaler version 6.1 and later. It is applicable only to HTTP/HTTPS services, and the documented procedure assumes that these services and HTTP/HTTPS vservers are already set up and functional.
Background
Once forwarded by the NetScaler toward the backend, HTTP requests to the Web servers appear, at the network layer, to originate from the mapped IP (MIP) of the NetScaler device. The source IP address in the request packets is set to the MIP.
In most configurations, responses from the Web servers pass through the NetScaler, which reverses the address translation before forwarding the response back to the client. In this way the internal Web servers are hidden from the client, who sees only the virtual IP of the HTTP vserver.
The problem with this configuration is that the Web server logs show the MIP for all client requests. This may not be desirable in environments which require the IP address of all Web accesses to be logged for accounting, security, or other purposes.
It may be desirable to have the client IP address recorded in an existing header (for example, X-Forwarded-For) such as in scenarios where an application running on the backend is configured to retrieve data from this header field. However, HTTP headers such as X-Forwarded-For may be added by systems such as proxy servers between the client and the NetScaler. When the NetScaler adds its own X-Forwarded-For header in addition to the one in the received packet, there can be ambiguity at the backend because the request contains duplicate headers. In this instance it is desirable to strip or corrupt the X-Forwarded-For header from the request before the NetScaler adds its own.
It may also be desirable to strip or corrupt the X-Forwarded-For (or other) header from the request for security reasons. Backend Web servers may be configured to log client IP addresses based on the value contained within the X-Forwarded-For header which, as part of a plain text HTTP packet, is inherently forgeable. A malicious user may use a spoofed X-Forwarded-For header to hide his identity from a Web server configured in this way. Carrying out the following procedure ensures that backend Web servers can trust the information contained within the X-Forwarded-For header.
Procedure
Note: The HTTP header X-Forwarded-For is used in the procedure as it is the most likely application of this procedure, however this procedure works for any HTTP header.
To configure content filtering:
1. Enable the content filtering feature:
> enable ns feature cf
2. Create a Policy Expression identifying the existence of the X-Forwarded-For header:
> add policy expression <expr name> "REQ.HTTP.HEADER X-Forwarded-For EXISTS"
3. Create a content filtering action to corrupt the header:
> add filter action <action name> corrupt X-Forwarded-For
4. Create a content filtering policy:
> add filter policy <policy name> -rule <expr name> -reqAction <action name>
5. Bind the policy globally:
> bind filter global <policy name>
This configuration garbles the name and contents of the X-Forwarded-For HTTP header in every packet received by the NetScaler, rendering the header nonexistent.
To configure client IP insertion:
Execute the following command configure the appropriate service to append the client's IP address contained in the X-Forwarded-For HTTP header to requests:
> set service <servicename> -cip ENABLED X-Forwarded-For
Requests from the NetScaler to the Web servers now have an extra field as shown in the following trace:
GET / HTTP/1.1
Host: www.test.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,/;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
X-Forwarded-For: 10.60.1.166
The backend server reads the information from the X-Forwarded-For header added by the NetScaler, so you can be sure that the information in the header is trustworthy.
This is test
