Survey Data Mining:   Home | FAQ | Archive | Glossary
Free Reports
  


You are viewing an outdated report. The latest version of this report was published on October 1st, 2024


    
Firewalled IIS Servers
April 1st, 2012

The Report
This report describes systems that we've detected via conventional HTTP requests as being IIS servers that have been firewalled behind some kind of NAT (Network Address Translation) device.

What is NAT?
The IETF (Internet Engineering Task Force) describes NAT being used for the following:

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.

The 3 blocks of private addresses, as specified in RFC1918, and reserved by IANA (Internet Assigned Numbers Authority) are:

     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)
How We (Or anyone else) Can Detect NAT Usage
When a browser requests a web page, it uses the HTTP protocol. HTTP requests consist of instructions on what page to retrieve along, while HTTP responses consist of information about the server and document being returned, along with the actual document (be it HTML, text, gif or otherwise).

For example, the following session shows captures a request to a typical web server:

    $ telnet www.securityspace.com 80
    Trying 216.201.108.18...
    Connected to www.securityspace.com.
    Escape character is '^]'.
    GET /sample.html HTTP/1.0
Having 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.

Is This Really a Problem?
Unfortunately, there is no clean answer to that. In most cases, the answer is probably not. However, the information, coupled with potential other misconfigurations, can provide a hacker with sufficient information to breach your network.

A general rule of thumb is that you never give out information if you can avoid doing so, unless it is necessary.

How Do We Fix This?
Microsoft provides a knowledge base article that describes how to configure the web server to return the Fully Qualified Domain Name (e.g. http://www.yourdomain.com) instead of an IP address such as 10.1.1.1.

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.

The Statistics
Note when reviewing these numbers that for this report, we look only at distinct IP addresses, NOT host names. This means we're looking at a number that much more accurately reflects the number of IIS servers out there, rather than the number of web sites hosted on these servers.

DescriptionCountPercent
Number of IIS servers examined1,089,093100.00%
Number of IIS Servers that revealed the IP address via the Content-Location tag2540.02%
Number of IIS Servers that revealed an IP in the Content-Location tag different from the IP accepting the connection6,9700.64%
Number of IIS Servers that revealed a private non-routable IP in the Content-Location tag6,5220.60%
Number of IIS Servers that use the Class A 10.*.*.* private network2,7250.25%
Number of IIS Servers that use the Class B 172.16-31.*.* private network1,4490.13%
Number of IIS Servers that use the Class C 192.168.*.* private network2,3480.22%



© 1998-2024 E-Soft Inc. Todos los derechos reservados.