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!

    Infoblox has a DHCP server that will perform OS fingerprinting.

  • 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 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
    Starting Nmap 5.51 ( ) at 2013-08-24 16:20 CDT
    Nmap scan report for
    Host is up (0.00078s latency).
    Not shown: 985 closed ports
    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 .
    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.

    @MichaelLang To alleviate the amount of time it takes, run nmap with the `-T5` flag to speed things up **drastically**.

  • 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.

  • 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.

    Also, another useful way to at least narrow down what a device may be on the network is by looking up their OUI based on their MAC address at IEEE's website.

License under CC-BY-SA with attribution

Content dated before 7/24/2021 11:53 AM