OS Determination via Profiling

[scamarda]

My customer would like to use profiling to identify an unauthorized OS connecting to the network.  In this case, Windows XP.  Can we use DHCP or HTTP (blind redirect) to determine the OS and then if it is unauthorized, assign the appropriate blacklist authz profile?  I know I can do this with posture but the customer is looking for a profiling solution.  This web site https://fingerbank.org/about.html talks about DHCP fingerprinting. Can I use ISE profiling capabilities to achieve the same?

[dazza_johnson · Accepted solution]

Hi there, that is pretty much what profiling does. In my ISE 2.2 there are three built in conditions to profile XP - one of which uses HTTP as per your post (see condition below). For DHCP you could create your own condition but would need to do some packet captures to find out what fields within the DHCP packet are unique to XP and do not match other OSs such as Windows 7. Once profiled, you can apply the appropriate authz profile to the endpoint.

Hope this helps

[dazza_johnson]

Or, if you are really brave you can use NMAP within ISE to determine the OS (basically does an NMAP scan). I have never seen or heard of anyone using NMAP in ISE, keen to hear if people out there have tried it and how well it worked?

[scamarda]

Thanks for the quick response.   After I posted the question I thought about NMAP but thought that may not be a scalable option from a user experience perspective.  I'll pursue the blind redirect to capture User Agent value and keep the NMAP scan as a last option.

[paul]

Darren,

I use NMAP in all of my installs, but the OS detection can be iffy.  I use NMAP for my printer identification.  Also remember NMAP is required if you want to do SNMP scans to profile devices (not SNMP scans to network devices).  If NMAP detects the SNMP port is open then it will kick off a SNMP scan.

I have never like the built in ISE printer profiles.  The first thing I do on a customer install is write a custom NMAP scan policy to check for common ports and OS and apply that to any profiling rules that could contain printers (about 7 or them).  Cisco used to do this by default but in 2.0 the default scan for Unknown and most devices was changed to only SNMP ports + OS check.

Now that I have the printer classes being common port scanned I can write a custom profile that pulls in any device on the network that has port 9100 open.  Then I can look at those devices and see what SNMP attributes are being learned so my printer rule ultimately looks like:

Minimum certainty factor 200

NMAP 9100 open then certainty factor increase 100

SNMP Sys Desc contains jetdirect then certainty factor increase 100

SNMP Sys Desc contains laserjet then certainty factor increase 100

etc.

So basically it is a two factor profile where NMAP 9100 open is the key factor plus one of the other factors.

Works well and makes it harder to spoof a printer.

[dazza_johnson]

I love this kind of post, informative with a real-world example, thanks :-)

[Craig Hyps]

NMAP SMB Discovery and AD Probe are also useful probes to more definitively validate Windows OS version.  Windows XP clients typically use one of the following Option 55 strings, but these can also be seen on Windows 7 and others, so not definitive:

1, 15, 3, 6, 44, 46, 47, 31, 33, 121, 249, 43

1, 15, 3, 6, 44, 46, 47, 31, 33, 121, 249, 43, 0, ...

1, 15, 3, 6, 44, 46, 47, 31, 33, 121, 249, 43, 252, ...

NMAP is generally a triggered per matching profile, or once per Unknown detection, so has minimal impact on ISE and network bandwidth.

Craig

[scamarda]

Thanks folks.  Appreciate the info.  I will include NMAP as an option.