Web servers may be configured to send redirects to client requests. In some cases, specially crafted queries may be used to expose internal IP addresses. Typically this is done by sending a blank host header which can result in the server sending a redirect using its own IP address as the host name.
An example configuration is provided below:
The Virtual IP address is 10.140.0.223 and the Real Server is defined as 10.140.0.22.
The domain name resolution is as follows:
www.domain.com 10.140.0.223
The Real Server (10.140.0.222) uses IIS Web Services and is configured to redirect requests to /redirectURL.
Problem
In the normal case when we connect to the server, it responds with the correct redirect based on the host name sent in the initial query:
Test with normal http 1.0 request.
kemptech@LC-161:~$ curl http://www.domain.com -v -l --http1.0
> GET / HTTP/1.0
> User-Agent: curl/7.35.0
> Host: www.domain.com
> Accept: */*
< HTTP/1.1 302 Redirect
< Content-Type: text/html; charset=UTF-8
< Location: http://www.domain.com/redirectURL
* Server Microsoft-IIS/8.5 is not blacklisted
< Server: Microsoft-IIS/8.5
< Date: Fri, 06 Feb 2015 15:06:21 GMT
< Connection: close
< Content-Length: 156
<
<head><title>Document Moved</title></head>
* Closing connection 0
<body><h1>Object Moved</h1>This document may be found <a HREF="http://www.domain.com/redirectURL">here</a></body>
However, if the request is sent as HTTP 1.0 with a blank host header, the server may respond with its own internal IP (10.140.0.222) in the Location Header. This results in the internal IP address of the Real Server being exposed.
Test: HTTP 1.0 request sent with empty Host Header.
kemptech@LC-161:~$ curl http://www.domain.com -v -l --http1.0 --Header 'Host: '
> GET / HTTP/1.0
> User-Agent: curl/7.35.0
> Accept: */*
< HTTP/1.1 302 Redirect
< Content-Type: text/html; charset=UTF-8
< Location: http://10.140.0.222/redirectURL
* Server Microsoft-IIS/8.5 is not blacklisted
< Server: Microsoft-IIS/8.5
< Date: Fri, 06 Feb 2015 15:06:39 GMT
< Connection: close
< Content-Length: 154
<
<head><title>Document Moved</title></head>
* Closing connection 0
<body><h1>Object Moved</h1>This document may be found <a HREF="http://10.140.0.222/redirectURL">here</a></body>kemptech@LC-161:~$
Solution
Depending on the server type, there should be a way to prevent the internal IP address from ever being sent in 302 Redirects on the Server. However, if this is not possible, a LoadMaster Content Rule may be used to block any internal IP addresses from being exposed in a 302 redirect.
Header modification rule:
Rule Type: Replace Header
Header: Location
Match String: /(https?:\/\/)([0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3})(?::\d+)?(\/.*)/
Replacement: \1www.domain.com\3
This can then be added to the Virtual Service: Virtual Services > View/Modify Services > Advanced Properties > HTTP Header Modifications > Response Rules.
The internal address is now hidden in all 302 Redirect Responses and replaced with www.domain.com.
Result
kemptech@LC-161:~$ curl http://www.domain.com -v -l --http1.0 --Header 'Host: '
> GET / HTTP/1.0
> User-Agent: curl/7.35.0
> Accept: */*
>
< HTTP/1.1 302 Redirect
< Content-Type: text/html; charset=UTF-8
< Location: http://www.domain.com/redirectURL
* Server Microsoft-IIS/8.5 is not blacklisted
< Server: Microsoft-IIS/8.5
< Date: Fri, 06 Feb 2015 15:20:40 GMT
< Connection: close
< Content-Length: 154
<
<head><title>Document Moved</title></head>
* Closing connection 0
<body><h1>Object Moved</h1>This document may be found <a HREF="http://10.140.0.222/redirectURL">here</a></body>
The internal ip might be exposed for the port 80 Redirect on the LM, this can be mitigated by putting the FQDN in Redirect box instead of the %H (https://FQDN%s).