I had a chat with another one of the ISC Incident Handlers the other day about inventorying large networks, which is covered in the first two Controls in the SANS "Critical Security Controls" (http://www.sans.org/critical-security-controls).  Paraphrased, these controls boil down to "know what's on your network" and "know what software and services are running on those stations".

This seems like a couple of pretty obvious statements, but it started me thinking about my client base.  For instance, about just how many are still running old print servers that top out at 10Mbps and advertise IPX printer SAPs.  Similarly, I started implementing a standard to isolate ATMs in a banking environment (without changing any IPs), and found a number of switches sol old that they didn't support port based ACLs, or Private VLANs or source port filtering. 

In short, it's really easy to let sleeping dogs lie (or prevaricate) - it's easy to let that 10 year old (plus) hardware that's been working forever stay on the network until you need a feature that doesn't exist on them.  And if it's easy to let this happen with IT owned gear that you know about, how about stuff that's NOT owned by IT?  Stuff like cameras, projectors and video conferencing units?  Or how about even more removed from IT - gear like elevator controls and HVAC systems?  Time clocks or PLCs?   Or, just to up the ante, medical devices that are network attached in a hospital or other health-care setting?

And that's just the hardware.  If you are inventorying your corporate stations' software, you're most likely using the OS's "list applications" commands or API calls to do this, whether in your own scripts or wrapped into a commercial product.  

For windows, you might use commands like:

wmic product list /format:csv > applist_for_database_import.csv
or
wmic product list brief /format:htable > %COMPUTERNAME%_applist.html

In Linux, depending on the distro you might use one of these:

rpm -qa
yum list installed
dpkg --get-selections

However,  these commands and other active scanning methods won't help you in a lot of cases - situations like:

• Stations not owned by IT, so you likely don't have credentials
• Embedded devices, which might not have a CLI
• Other embedded devices, which might not be owned by IT (back to no credentials again)
• Stations that you don't know exist
• Stations on networks you don't know about
• Access points that your users might have hidden under their desks
• Applications like Java, where you might be up to date in C:\Program Files (x86)\Java, but you might have an oldy-moldy Java install that came bundled with an app 4 or 5 years ago, buried 6 levels deep in some other application directory
• Or utility type applications, stuff like Putty (when was the last time you updated your copy of putty?), or applets like the GNUtils that got downloaded once 6 or 7 years ago, then copied from laptop to laptop so that all your scripts work? 
• Any application that didn't install using the OS native install (msi in windows, rpm, apt-get or yum in Linux)

So, what should you do to find these incognito stations and camoflaged applications?  For many of my clients, we look for evidence of these situations in the network traffic that they create, just the same way we often find Indicators of Compromise in malware or attack situations. 

Several tools will help you in finding, fingerprinting and identifying versions of apps like this.  The "granddaddy" of these "passive scanner" applications is p0f.  Downloadable from http://lcamtuf.coredump.cx/p0f3/, it's been around for over 10 years, is still actively developed and is still free.  If you have a budget and are looking for a commercial alternative,  PVS from Tenable might also fit the bill - either instead of or in conjunction with p0f.  Info on PVS can be found here: http://www.tenable.com/products/passive-vulnerability-scanner, it's available for free for up to 16 nodes, or you can get an "eval-ware" version for larger networks.

So, with good tools in hand and pure intentions in your heart, how to proceed?  You'll need to find a spot on your network to capture traffic of interest - the obvious place is to put your sensor station would be on a SPAN port, sniffing the traffic on the inside interface of our firewall.  However, this won't find traffic to identify internal-only stations like internal-use database servers, print servers and the like.  For these, you'll want a SPAN port capturing an entire internal VLAN, or perhaps capturing traffic from internal router ports.  It's best to take some time and apply some business process knowledge to place your station well, or in many cases several stations.

There are lots of other pointers on using "fingerprint" applications - the SANS Reading Room at http://www.sans.org/reading-room is a great place to start, or the SANS Security Resources pages here http://www.sans.org/security-resources/idfaq/p0f.php.

In my most recent deployment of p0f, we found unpatched Win95 stations running a pharmaceutical assembly line.  Stations that were put in by the industrical controls vendor back in the mid-90's, buried inside the cabinets with the PLCs and so on, then just plugged into the network so the plant engineers could get to them.  Nobody left in the organizations had any idea these stations were there, the plant engineers who used them knew the interfaces, but not what was behind them.  And of course these stations were just about as business critical as you could find - SCADA systems in all but name.

What tools have you used for passive discovery?  Use our comment form and let us know where you've placed passive sensors in your network and most importantly, what's the most interesting things that you've found?

===============
Rob VandenBrink
Metafore