Addressing Vulnerabilities - Presence of a Load-Balancing Device Detected

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

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)?

+1 @Hoolio