Can DHCP Server determine client's OS?
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!
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.
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:
[[email protected] ~]$ 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 [[email protected] ~]$
Thanks for pointing out nmap's fingerprinting capabilities...Its neat and works about 50% of the time (got 5 out 10 computers on my network correct), but its scans take from 25 secs to 102 seconds for each device. This did, however lead help me understand much about OS fingerprinting and esp. passive options which seem to be my best bet.
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.0for Windows clients,
udhcpcusualy 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.