Firewalled IIS Servers
January 1st, 2020
IP V4 Network Address Translation (NAT) has become an increasingly common function in the Internet for a variety of reasons. NATs are used to interconnect a private network consisting of unregistered IP addresses with a global IP network using limited number of registered IP addresses. NATs are also used to avoid address renumbering in a private network when topology outside the private network changes for variety of reasons. And, there are many other applications of NAT operation.
In other words, in the context of the web servers a browser visits, the IP address we visit, may appear to be one thing, while the server that is actually providing the data may be residing on a completely different IP address, with a device in between (often a firewall) translating traffic to allow communications to work.
When NAT is employed, administrators will typically use one of 3 ranges of IP addresses, known as private, or non-routable addresses. These ranges are designated for private use, and as such cannot be reached directly from the internet. A separate device, such as a firewall, can be configured to send traffic incoming to a specific port (e.g. http port 80) to an internal private address, making it appear as if the webserver is operating on a public address.
10.0.0.0 - 10.255.255.255 (10/8 prefix) 172.16.0.0 - 172.31.255.255 (172.16/12 prefix) 192.168.0.0 - 192.168.255.255 (192.168/16 prefix)
For example, the following session shows captures a request to a typical web server:
$ telnet www.securityspace.com 80 Trying 18.104.22.168... Connected to www.securityspace.com. Escape character is '^]'. GET /sample.html HTTP/1.0Having issued the request to retrieve the page sample.html, the server responds with the HTTP header and an HTML page.
HTTP/1.1 200 OK Date: Fri, 04 May 2001 20:08:11 GMT Server: Apache/1.3.12 (Unix) Connection: close Content-Type: text/html <HTML> <HEAD></HEAD> <BODY>Sample Page</BODY> </HTML> Connection closed by foreign host. $
Now let's consider the exact same response received from a poorly configured IIS server:
HTTP/1.1 200 OK Server: Microsoft-IIS/4.0 Content-Location: http://10.1.1.1/sample.html Date: Wed, 11 Apr 2001 07:22:38 GMT Content-Type: text/html Accept-Ranges: bytes Last-Modified: Tue, 09 Jan 2001 21:41:34 GMT ETag: "b43f97ef847ac01:4096" Content-Length: 55 <HTML> <HEAD></HEAD> <BODY>Sample Page</BODY> </HTML> Connection closed by foreign host. $
The above example shows that the IIS server is returning a header field called Content-Location, and that this field is showing the location of the document being requested from the webserver's perspective. In this case, it happens to reveal that the web server resides on a private class A address of 10.1.1.1, providing pretty good proof that there is a NAT device between the webserver and the internet at large, and that the device is probably a firewall of some sort.
A general rule of thumb is that you never give out information if you can avoid doing so, unless it is necessary.
A different procedure applies to IIS version 4.0 and IIS version 5.0. In addition, a work-around exists involving renaming static web pages to end with .asp and to then configure a custom HTTP Header that specifies a Content-Location tag explicitly.
Security Audits | Managed DNS | Network Monitoring | Site Analyzer | Internet Research Reports
© 1998-2020 E-Soft Inc. All rights reserved.