Proxy/Firewall Detection with PVS

During the past year, the Passive Vulnerability Scanner's rules were modified to detect network proxies and firewalls. This process also involved the reduction of reporting multiple browser types for different hosts running behind a NAT device or proxy.

As an example, what happens if PVS (or any sniffer, IDS, etc.) see's the following string in a packet leaving the network?

GET/StageOne/msnmsgr_exe/6_2_0_137/hungapp/0_0_0_0/00000000.htm?OS=5.1.2600.2.00010300.1.0&...
User-Agent: MSDW
Host: watson.microsoft.com

Well, most folks would think that:

1. The source IP is running MS Windows version 5.1.2600.2.etc and,
2. An error just occurred in MSN Messenger version 6.20.0.137 and,
3. The client is now sending an error message to Microsoft

And, a year ago, the PVS would have flagged the machine for the items denoted above.  However, within the last six months, Tenable has been undergoing a process of detecting where and why false positives are occurring within PVS.  One of the problem areas was that PVS was flagging firewalls and proxies as the actual client.  Mind you, I'm not talking about known NAT devices, as you can always turn off alerts going to/from those devices via the configuration file. 

We decided to find a generic way of detecting proxies and firewalls on the network.  The primary goal of this was to weed out false positives.  A tangential benefit has been that companies can now detect firewalls and proxies that are deep within their corporate network. 

Why does finding these NAT or proxy devices matter for a larger enterprise network? Consider the following issues:

• What happens if a remote business unit (connected to your internal network) is dual-homed to another network? 
• What happens if a user decides to set up an access point within your corporate network? 
• What happens if a user sets up a 3G connection to their corporate laptop, enables routing, goes home, and then uses the laptop as a remote router when they want to connect to corporate resources?

Finding firewalls and proxies within large, complex networks can be a daunting task. The good news is that these firewalls and proxies all leave their fingerprint as they pass NATed traffic around the network - and the PVS can detect these.

So, how do we detect firewalls and proxies? We modified the PVS rules to look for anomalies within the client-side applications and OS behaviors that only occur if multiple hosts are behind a NAT device or proxy. Here are a few examples currently implemented in the PVS signatures:

• The PVS looks for applications which are specific to an operating system.  PVS then finds mismatches.  Example: A host running the Firefox browser on the Microsoft platform AND a Safari browser on MAC OX X coming from the same IP.
• PVS looks for anomalous operating system updates. Most OSes and many applications have automated software for figuring out when an update is available.  The PVS looks for mismatches on the same IP.   
• Multiple versions of the same application. This is very straightforward. It's "odd" to see three versions of Firefox coming from the same IP.  This is also accomplished with MSN Messenger, AIM, Zonealarm, etc. etc.

By searching for the applications of multiple individual hosts occurring on "one" public IP address, the PVS can identify where NAT devices and proxies are located with a high degree of accuracy.

If passive network monitoring to find vulnerabilities is a new concept to you, please feel free to download the "Blended Security Assessments" whitepaper. This shows how both active and passive vulnerability analysis provides much deeper coverage and monitoring of your network than either technology by itself. There is also a video demonstration of PVS data being managed by a Security Center.