Forum Discussion

funkdaddy_31014's avatar
funkdaddy_31014
Icon for Nimbostratus rankNimbostratus
Apr 21, 2011

Addressing Vulnerabilities - Presence of a Load-Balancing Device Detected

We routinely run Qualys scans on our environment, and the scan comes back with minor vulnerabilities called "Presence of a Load-Balancing Device Detected" based on "IP Identification". The results show a (usually inaccurate) number of web servers behind the Load Balancers. I have pasted some output of the scan report to show the results. Note that of the various methods used to detect the presence of a LB, the only one identified in our reports (See RESULTS section at very bottom) are "IP Identification".

 

 

Questions:

 

 

1. Anyone have any idea how "IP Identification" is done to find the number of servers behind the load balancer?

 

 

2. What configuration can be done on the Big-IP to get rid of this vulnerability?

 

 

3. I'm no security expert - how big of a deal is this vulnerability?

 

 

Thanks,

 

-Funkdaddy

 

 

 

1 Presence of a Load-Balancing Device Detected (5)

 

 

QID: 86189 CVSS Base: 0 [1]

 

Category: Web server CVSS Temporal: -

 

CVE ID: -

 

Vendor Reference: -

 

Bugtraq ID: -

 

Service Modified: 05/20/2009

 

User Modified: -

 

Edited: No

 

PCI Vuln: No

 

THREAT:

 

The service detected a load-balancing device in front of your Web servers. This information can provide an attacker with additional

 

information about your network.

 

Different techniques were used to detect the presence of a load-balancing device, including HTTP header analysis and analysis of IP

 

Time-To-Live (TTL) values, IP Identification (ID) values, and TCP Initial Sequence Numbers (ISN). The actual technique(s) responsible for

 

the detection can be seen in the Result section.

 

The exact number of Web servers behind a load balancer is difficult to determine, so the number reported here may not be accurate.

 

Furthermore, Netscape Enterprise Server Version 3.6 is known to display an erroneous "Date:" field in the HTTP header when the server

 

receives a lot of requests. This makes it difficult for the service to determine if there is a load-balancing device present by analyzing the

 

HTTP headers. Also, the result given by the analysis of IP ID and TCP ISN values may vary due to different network conditions when the

 

scan was performed.

 

IMPACT:

 

By exploiting this vulnerability, an intruder could use this information in conjunction with other pieces of information to craft sophisticated

 

attacks against your network.

 

Others page 4

 

Note also that if the Web servers behind the load balancer are not identical, the scan results for the HTTP vulnerabilities may vary from one

 

scan to another.

 

SOLUTION:

 

To prevent the detection of the presence of a load-balancing device based on HTTP header analysis, you should use

 

Network-Time-Protocol (NTP) to synchronize the clocks on all of your hosts (at least those in the DMZ).

 

To prevent detection by analyzing IP TTL values, IP ID values, and TCP ISN values, you may use hosts with a TCP/IP implementation that

 

generates randomized numbers for these values. However, most operating systems available today do not come with such a TCP/IP

 

implementation.

 

 

***RESULTS***

 

 

xxx.xx.xx.54 (extranet.xyz.com, -) F5 Networks Big-IP port 443/tcp over SSL

 

RESULTS:

 

Number of web servers behind load balancer:

 

3 - based on IP Identification values

 

 

xxx.xx.xx.103 (wpress.xxx.com, -) F5 Networks Big-IP port 443/tcp over SSL

 

RESULTS:

 

Number of web servers behind load balancer:

 

4 - based on IP Identification values

 

 

7 Replies

  • Oops, the report output got omitted:

    
    1 Presence of a Load-Balancing Device Detected (5)
    
    QID: 86189 CVSS Base: 0 [1]
    Category: Web server CVSS Temporal: -
    CVE ID: -
    Vendor Reference: -
    Bugtraq ID: -
    Service Modified: 05/20/2009
    User Modified: -
    Edited: No
    PCI Vuln: No
    THREAT:
    The service detected a load-balancing device in front of your Web servers. This information can provide an attacker with additional
    information about your network.
    Different techniques were used to detect the presence of a load-balancing device, including HTTP header analysis and analysis of IP
    Time-To-Live (TTL) values, IP Identification (ID) values, and TCP Initial Sequence Numbers (ISN). The actual technique(s) responsible for
    the detection can be seen in the Result section.
    The exact number of Web servers behind a load balancer is difficult to determine, so the number reported here may not be accurate.
    Furthermore, Netscape Enterprise Server Version 3.6 is known to display an erroneous "Date:" field in the HTTP header when the server
    receives a lot of requests. This makes it difficult for the service to determine if there is a load-balancing device present by analyzing the
    HTTP headers. Also, the result given by the analysis of IP ID and TCP ISN values may vary due to different network conditions when the
    scan was performed.
    IMPACT:
    By exploiting this vulnerability, an intruder could use this information in conjunction with other pieces of information to craft sophisticated
    attacks against your network.
    Others page 4
    Note also that if the Web servers behind the load balancer are not identical, the scan results for the HTTP vulnerabilities may vary from one
    scan to another.
    SOLUTION:
    To prevent the detection of the presence of a load-balancing device based on HTTP header analysis, you should use
    Network-Time-Protocol (NTP) to synchronize the clocks on all of your hosts (at least those in the DMZ).
    To prevent detection by analyzing IP TTL values, IP ID values, and TCP ISN values, you may use hosts with a TCP/IP implementation that
    generates randomized numbers for these values. However, most operating systems available today do not come with such a TCP/IP
    implementation.
    
    
    ***RESULTS***
    
    xxx.xx.xx.54 (extranet.xyz.com, -) F5 Networks Big-IP port 443/tcp over SSL
    
    RESULTS:
    Number of web servers behind load balancer:
    3 - based on IP Identification values
    
    xxx.xx.xx.103 (wpress.xyz.com, -) F5 Networks Big-IP port 443/tcp over SSL
    
    RESULTS:
    Number of web servers behind load balancer:
    4 - based on IP Identification values
     
  • One possible solution is to use an I rule with the HTTP sanitize command:

     

     

    rule header_sanitize {

     

    when HTTP_RESPONSE {

     

    HTTP::header sanitize

     

    }

     

    }

     

     

    Be careful though, there is a known issue with version 10.0 - 10.2 http://support.f5.com/kb/en-us/solutions/public/12000/000/sol12083.html
  • Hi,

     

     

    Anyone has any luck to answer this? I had Qualys detecting this Vulnerability via IP identification. The threat level is Low, but client wants to know their options.

     

     

    Dany
  • nathe's avatar
    nathe
    Icon for Cirrocumulus rankCirrocumulus
    One question that was asked previously was "Anyone have any idea how "IP Identification" is done to find the number of servers behind the load balancer?". The answer (or poss one of a few answers) is that the external security company have crafted some scans, using one of a few pen test tools, against the IP of your website (which is in fact your load balancer) and interrogated the IP ID number returned. If there was no load balancer and, say, simply one web server then the number that the IP ID increments by would have a pattern to it (to some degree). By having a load balancer with 1 or many backend web servers then the returned IP IDs may be vastly different each time, which would suggest different servers are being load-balanced. Hope that makes sense? The crudeness of this would be a reason why they've "guessed" incorrectly the amount of web servers.

     

     

    As to "how big of a deal is this vulnerability?". The pen testers may get different results if the load balanced web servers are not exactly the same i.e. patch levels not the same so, to them, the possibility of iinconsistency of results would prevent them from auditing the security most accurately and giving you the full picture.

     

     

    Not sure if the F5 can mitigate against this. If it can, it will be by using the ASM module somehow.

     

     

    Hope this helps,

     

    N
  • This seems like a non-issue. What can attacker do once they determine that a site is using a load balancer?

     

     

    NMAP or online scans can generally fingerprint the OS of a site to provide more detail. For instance, example.com shows it's being hosted by a BIG-IP:

     

    http://searchdns.netcraft.com/?restriction=site+ends+with&host=example.com

     

     

    So an attacker even knows the vendor of the load balancer. It still begs the question of what can they do with that information?

     

     

    You could try to change the behavior of BIG-IP to hide itself, but that would involve modifying TCP/UDP/iCMP behavior at a fairly low level. Is it really worth it to tinker with performance optimized settings to try to hide this minimal amount of information? I think it's better to invest time securing the infrastructure with timely patching, pentesting, etc versus worrying about OS fingerprinting.

     

     

    Aaron
  • As someone stated earlier - the IP ID "range" variance is indicative of LB - for example when doing something like:

     

     

    $ sudo hping3 wwww.amazon.com -S -p 80

     

    HPING wwww.amazon.com (en0 72.21.210.29): S set, 40 headers + 0 data bytes

     

    len=46 ip=72.21.210.29 ttl=243 id=24092 sport=80 flags=SA seq=0 win=8190 rtt=22.2 ms

     

    len=46 ip=72.21.210.29 ttl=241 id=14744 sport=80 flags=SA seq=1 win=8190 rtt=22.1 ms

     

    len=46 ip=72.21.210.29 ttl=242 id=63761 sport=80 flags=SA seq=2 win=8190 rtt=22.0 ms

     

    len=46 ip=72.21.210.29 ttl=243 id=58747 sport=80 flags=SA seq=3 win=8190 rtt=22.0 ms

     

    len=46 ip=72.21.210.29 ttl=243 id=54002 sport=80 flags=SA seq=4 win=8190 rtt=22.1 ms

     

    len=46 ip=72.21.210.29 ttl=243 id=30840 sport=80 flags=SA seq=5 win=8190 rtt=22.2 ms

     

    len=46 ip=72.21.210.29 ttl=242 id=7919 sport=80 flags=SA seq=6 win=8190 rtt=22.1 ms

     

    len=46 ip=72.21.210.29 ttl=241 id=9077 sport=80 flags=SA seq=7 win=8190 rtt=22.1 ms

     

    len=46 ip=72.21.210.29 ttl=242 id=5873 sport=80 flags=SA seq=8 win=8190 rtt=22.1 ms

     

     

    My question - follow-up to the original one - is different: when going "after" the real IP of any server being load balanced, the pen-test does not reveal any problems, whereas when going "after" the VIP a few alerts are being raised. How is that possible, and is the LB possibly sensitive to attacks to the system, itself, via the services that it offers (vs. servers behind it being at risk)?