Can DHCP Server determine client's OS? [closed]

Question

Is it possible for the DHCP Server to determine the client operating system?

I'm working on a monitoring tool for gateways on local networks that is web-based and would like to be able to somehow determine what OS a device on the network is running and it seems to me the most obvious place to discover that is at the time an IP address is assigned by the DHCP Server.

Failing that, I do know how to filter traffic on port 80 and pull the HTML header info, but this method relies on waiting for the device to surf the web and thus less desirable than a very early on detection/resolution, esp. as not every device will be used to browse the internet.

I have complete control of the gateway's configuration -- its running a pared down debian distro, so any other tools that would do the job -- DHCP, DNS, ARP, etc, I'm open to suggestions!

Answer 1

Some work has been done to determine subtle differences in DHCP packets from different OSes, resulting in DHCP fingerprints. Examples include the options present in DHCP request and their order, and the content of certain options like option 55 (parameter list).

Have a look at the papers and signatures at fingerbank.org. This suggests (have not tested it myself) passive OS fingerprinting based on DHCP traffic can be done. The result can possibly be improved by including other information, like generic IP properties (TTL, diffserv, ...).

Active fingerprinting might provide a better result, but might not be an option in your use case.

The Fingerbank website mentions a couple of open source products which use the signatures. Proprietary DHCP appliance Infoblox seems to include a similar feature, but no technical details are provided.

Answer 2

Some DHCP clients do not reliably disclose the OS information at boot. As was mentioned above, there is some intellectual property associated with these techniques; for instance, Infoblox and Cisco ISE can build client OS profiles based on the dhcp packets they see. Actually Cisco ISE includes some fairly sophisticated OS classification algorithms, if you can send more than dhcp to it.

Alternatively, you could use a heuristic like the Windows endian bug in the "seconds elapsed" field, but relying on an OS bug is a poor way to handle OS detection.

If you really must detect the OS without a dedicated vendor appliance, just issue an IP address, and scan the host with NMAP after sending the DHCP Ack. Using HTTP headers is not as reliable as nmap, because anyone can change the UserAgent string if they want. nmap is not 100% reliable at OS detection, but it is about as good as you will find if you must choose a single method for everything.

I would make this a configurable option on the server since some folks may not like a default nmap scan on every DHCP host.

Example nmap OS scan against Windows7:

[mpenning@myhost ~]$ sudo nmap -O 10.1.1.1

Starting Nmap 5.51 ( http://nmap.org ) at 2013-08-24 16:20 CDT
Nmap scan report for 10.1.1.1
Host is up (0.00078s latency).
Not shown: 985 closed ports
PORT      STATE SERVICE
135/tcp   open  msrpc
139/tcp   open  netbios-ssn
445/tcp   open  microsoft-ds

Device type: general purpose
Running: Microsoft Windows Vista|2008|7
OS details: Microsoft Windows Vista SP0 - SP2, Server 2008, or Windows 7 Ultimate
Network Distance: 5 hops

OS detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 5.25 seconds
[mpenning@myhost ~]$

Answer 3

As part of the DHCP process itself, I don't believe so. However, you could scrape your dhcpd logs, watch for dhcp acks and based on those execute an external process like nmap os fingerprinting to see if you can figure out what's behind the IP that was just assigned.

Answer 4

Shortest accurate answer is no. You already got useful answers about nmap, but if it must be via DHCP many clients send their vendor class identifiers (DHCP option 60) in their discover packets so the DHCP server can provide an offer with vendor specific options (DHCP option 43). If you run tcpdump an look at DHCP discover packets sent by clients for option 60 you can see stuff like MSFT 5.0 for Windows clients, udhcpc usualy for embedded devices running micro dhcp client, etc. Keep in mind that this information is not very specific since it is used to distinguish DHCP client rather then operating system.