Keeping an eye on those BYODs with DHCP

Published: 2012-09-07
Last Updated: 2012-09-07 14:24:46 UTC
by Chris Mohan (Version: 1)
4 comment(s)

A plethora of technologies, bespoke systems and acronyms offer management offer protection against unauthorised devices being connected to networks, but money, time, effort and management backing is needed to make this a reality. Imagine company X's policy is only authorized, company-approved computers can be connected and all violations have to be logged and reported or the auditors will be very unhappy. And no-one like to see sad auditors. But there’s no budget.  So what’s a poor security admin to do? Well here's a suggestion.

Dynamic Host Configuration Protocol (DHCP) ubiquitous to most networks, making connectivity to the network only an Ethernet cable away*. For those with an eye on security, DHCP logs are a gold mine.

On gaining a DHCP lease the IP address assigned to the system and that IP address, the expiry time, the system’s hostname and Media Access Control address (MAC address) get stored in the DHCP database. So let’s look a couple of ways to turn these pieces of data in to security gold, remember our goal is to detect and alert on non-company approved systems being plugged in to the network.

The first step is to get access and a copy of the DHCP logs (or direct access to the DHCP database), so the data can be parsed and sorted into a format that can be dropped in to a script to automate the detection process. Most company networks are hopefully built using decent naming conventions and using only a couple of vendor’s computing hardware. This means by using some simple scripting, detecting those anomalies to the company standards should be a breeze. To clarify this:

System hostnames:
Companies tend to have a naming standard for their machines to make inventories, auditing and identifying manageable. Some example machines names: a00001, XYZ1234 and so on. Hostnames of JamesMegaLappy, SkyRocket and haz0r don’t fit that naming standard and a basic regular expression [1] check against the naming standard will be able to pick this up instantly.

MAC address:
IEEE assigns an Organizationally Unique Identifier (OUI) [2] to each company manufacturing Ethernet devices. The company must use its own OUI [3] for the first three bytes of MAC addresses for equipment it produces. For example, the OUI of MAC address 00:06:5B:32:12:A0 is 00065B. For this example, company X uses two brands of computer hardware OIDs 00065B and 0001E6. A scripted task can run through the DHCP logs to pick out any MAC addresses that don’t start with these OIDs.A script running hourly against the

A script reading DHCP logs detecting either a non-standard hostname or OID and sending an email alert is quick, easy to implement and an effective detection method to find those non-company approved systems. Using the expiry time entry to confirm when the device got its IP address, it provides a time frame of someone adding a device to the network, so local staff looking for the unauthorized system have a starting point to ask questions.

This isn’t fool proof as it is trivial to change both the hostname and MAC address to blend in, but it’s highly effective against the majority of devices being plugged in to networks by those uncomprehending of the company’s polices or those acting maliciously.

For those who like to take the offensive defence approach on their networks against policy violations, the offending  MAC address can be added as a DHCP reservation with  DHCP scope options that point the default gateway and DNS server to, say 127.0.01. This is limits what the offending device can connect to the next time it renews it DHCP lease or requests a new IP address. 

Join Ashley Deuble for MGT 414: SANS® +S™ Training Program for the CISSP® Certification Exam in Brisbane, Australia

* DHCP leases can be offered to wirelessly as well but that would have broken my flow.



Chris Mohan --- Internet Storm Center Handler on Duty

Keywords: dhcp isc sans security
4 comment(s)


With respect to mining DHCP, if you can place full packet monitoring between your clients and DHCP servers, even more information can be gleaned. Two projects worth mentioning:

Fingerbank is a database of DHCP fingerprints.

Packetfence is an open source NAC solution that uses the Fingerbank database to identify devices.

Monitoring DHCP logs for compliance to a host naming convention is a great idea. If you are in a Windows AD environment where devices in AD are considered company owned/managed, an additional step you can take via monitoring is reaching out via network login with a credential for a basic check. If the device presented a hostname that conformed to your standard and accepted the credentialed check, you'll have a higher confidence that the host is supposed to be there.

Your point about solutions like this not being foolproof is good advice. You'll always need to think of these solutions as providing different levels of confidence. It's never on or off, black or white, yes or no.
A while ago I found a great discussion on this topic, as well as script (that was written in 2006 !!) to pull down DHCP leases from Windows DHCP servers.

First it pulls down all of the registered DHCP servers. Then it queries each server, asking for all of the DHCP scopes on that server. Then it pulls down all of the leases in each scope. Finally, it pulls down all of the computers in your AD domain, and spits out a list of DHCP devices that AREN'T in your domain.

I made quick a few modifications to the script, but at this point I can't remember why. Still, it was really interesting to see all of the iPhones and Kindles connected to my enterprise wireless network.

I'm considering re-writing the script from scratch. Anyone interested in helping?

Discussion / script:
I have 2 networks that use DHCP for wireless (wifi) devices.

The first is a company LAN, and the wifi access point has MAC filtering to only permit authorized devices to connect to the AP. Once connected, these devices are served a DHCP address that is matched to their wired static ethernet address. The reason for this is to permit the nightly backup server to find these devices.

The second network is a rather open "guest/roving" wifi network. Here, the consumer grade router hands out DHCP addresses. This network is connected directly to the WILD network via the NATting built into the wifi router. No DHCP logs are available from this device.

To monitor this guest network, I have a dual-homed wired ethernet device connected to it via a wired port on the wifi router, and connected to the company lan on the other ethernet NIC, with no forwarding enabled, and pretty heavy firewalling using iptables under linux. This linux box polls the address space on the guest wifi router to see what addresses are connected. This has the advantage that it will pick up squatters who did not get their address from the dhcp server. The mac address sniffed for the poll response, and matched with known mac addresses (from the dhcp server on the company lan) to determine which valid device is connected to which guest network ip address. A log file is generated, with the device mac address, ip address, device name, and timestamp. From this log file, a graph is generated. In the graph legend, the names and LSbyte of the ip address are displayed. Unknown devices are identified with their mac address instead of a device name, so they jup right out at you.

This graph is visible at:


I find this quite handy for seeing who is/was connected when.
In one place we had arpwatch coupled with custom script doing DNS lookups. Worked like charm identifying anything newly connected.

Diary Archives