103

What's the best approach towards determining if I have a rogue DHCP server inside my network?

I'm wondering how most admins approach these kinds of problems. I found DHCP Probe through searching, and thought about trying it out. Has anyone had experience with it? (I would like to know before taking the time to compile it and install).

Do you know any useful tools or best-practices towards finding rogue DHCP servers?

masegaloeh
  • 17,978
  • 9
  • 56
  • 104
l0c0b0x
  • 11,697
  • 6
  • 46
  • 76
  • 2
    MS Tool and very simple to use! Rogue DHCP Server detection - RogueChecker.zip http://blogs.technet.com/b/teamdhcp/archive/2009/07/03/rogue-dhcp-server-detection.aspx – aa.malta Nov 08 '13 at 10:38
  • I found an official reference to your link aa.malta at http://social.technet.microsoft.com/wiki/contents/articles/25660.how-to-prevent-rogue-dhcp-servers-on-your-network.aspx but the link no longer appears to work as of 2016. It shows me blog posts from 2009, but I only see posts for July 6 and June 29. There doesn't seem to be a July 3 post as indicated by the link URL you posted. Looks like MS removed it for who knows what reason. – Daniel Jan 24 '16 at 17:59
  • Looks like this direct link (which I found on a wordpress site) works to download the file from a Microsoft Server. Link is working as of January 2016. Since the URL is Microsoft, I feel it can be trusted, but I make no guarantees: http://blogs.technet.com/cfs-file.ashx/__key/communityserver-components-postattachments/00-03-26-09-62/RogueChecker.zip – Daniel Jan 24 '16 at 18:04
  • Wayback machine has a copy https://web.archive.org/web/20100601022750/http://blogs.technet.com/b/teamdhcp/archive/2009/07/03/rogue-dhcp-server-detection.aspx – antgiant Mar 06 '19 at 13:55

15 Answers15

59

One simple method is to simply run a sniffer like tcpdump/wireshark on a computer and send out a DHCP request. If you see any offers other then from your real DHCP server then you know you have a problem.

Zoredache
  • 128,755
  • 40
  • 271
  • 413
  • 31
    Helps using the following filter: "bootp.type == 2" (for only showing DHCP offers, and seeing if there is response from different/unknown sources) – l0c0b0x Jun 16 '09 at 20:13
  • 4
    Use a program like DHCP-Find (http://www.softpedia.com/get/Network-Tools/Network-IP-Scanner/DHCP-Find.shtml) in conjunction with TCPDump/Wireshark to trigger DHCP responses. – saluce May 19 '12 at 15:03
  • 2
    Can you offer a more specific solution? – tarabyte Nov 30 '16 at 23:07
  • @tarabyte I am not sure what solution I or improvments I should offer. I think this question has pretty good coverage from the dozen other good answers? My goto option these days is to just configure your switches to block DHCP like Jason Luther suggested. Was there something specific that needed to be covered better? – Zoredache Nov 30 '16 at 23:54
  • 3
    I was expecting more of a sequence of commands that make use of `tcpdump`, `arp`, etc. with explicit parameters and explanation of those parameters. – tarabyte Dec 01 '16 at 00:49
  • 1
    For those wondering why `bootp.type == 2` doesn't work with tcpdump (syntax error) checkout this answer http://serverfault.com/a/304715/101677. – Elijah Lynn Mar 08 '17 at 02:10
24

To recap and add to some of the other answers:

Temporarily disable your production DHCP server and see if other servers respond.

You can get the IP address of the server by running ipconfig /all on a windows machine, and then you can get the MAC address by looking for that IP address using arp -a.

On a Mac, run ipconfig getpacket en0 (or en1). See http://www.macosxhints.com/article.php?story=20060124152826491.

The DHCP server information is usually in /var/log/messages. sudo grep -i dhcp /var/log/messages*

Disabling your production DHCP server might not be a good option, of course.

Use a tool that specifically looks for rogue DHCP servers

See http://en.wikipedia.org/wiki/Rogue_DHCP for a list of tools (many of which were listed in other responses).

Configure switches to block DHCP offers

Most managed switches can be configured to prevent rogue DHCP servers:

kaiser
  • 1,251
  • 1
  • 16
  • 24
Jason Luther
  • 408
  • 3
  • 6
19

dhcpdump, which takes input form tcpdump and shows only DHCP related packets. Helped me find rootkited Windows, posing as fake DHCP in our LAN.

vartec
  • 6,137
  • 2
  • 32
  • 49
16

The Wireshark / DHCP explorer / DHCP Probe approaches are good for a one time or periodic check. However, I'd recommend looking into DHCP Snooping support on your network. This feature will provide constant protection from rogue DHCP servers on the network, and is supported by many different hardware vendors.

Here's the feature set as indicated in the Cisco docs.

• Validates DHCP messages received from untrusted sources and filters out invalid messages.

• Rate-limits DHCP traffic from trusted and untrusted sources.

• Builds and maintains the DHCP snooping binding database, which contains information about untrusted hosts with leased IP addresses.

• Utilizes the DHCP snooping binding database to validate subsequent requests from untrusted hosts.

Dave K
  • 2,751
  • 2
  • 21
  • 17
  • 2
    Juniper's DHCP Snooping doc: http://www.juniper.net/techpubs/en_US/junos9.2/topics/concept/port-security-dhcp-snooping.html ProCurve's DHCP Snooping: http://h40060.www4.hp.com/procurve/uk/en/pdfs/application-notes/AN-S12_ProCurve-DHCP-snooping-final.pdf – sclarson May 15 '09 at 14:25
11

dhcploc.exe is the quickest and handiest way on Windows systems. It is available in the XP Support Tools. The Support Tools are on every OEM/retail XP disk, but may or may not be on "recovery disks" provided by some OEMs. You can also download them from MS.

It's a simple commandline tool. You run dhcploc {yourIPaddress} and then press the 'd' key to do a fake discovery. If you leave it running without pressing any keys, it will display every DHCP request and answer it hears. Press 'q' to quit.

quux
  • 5,358
  • 1
  • 23
  • 36
  • Just used this in combination with killing individual switch ports to track down a sneaky rogue server we were dealing with. Good stuff! – DHayes Sep 10 '10 at 15:44
  • 1
    You can still use DHCPloc.exe on Windows 7: 1. Download "Windows XP Service Pack 2 Support Tools" from [here][1]. 2. Right-click on the executable and select Properties->Compatibility then turn on Compatibility Mode and set it to "Windows XP (Service Pack 3)". 3. Install as normal. DHCPLoc.exe works fine on my Win7 x64 installation. [1]: http://www.microsoft.com/en-us/download/details.aspx?id=18546 – parsley72 Apr 29 '12 at 23:24
  • 1
    I just noticed you can download just the executable from the following location and it works fine under Win 10 x64: https://gallery.technet.microsoft.com/DHCPLOC-Utility-34262d82 – PeterJ Nov 04 '16 at 01:14
11

I suggest starting two terminals, one for monitoring and another for sending a request. Terminal1 will show responses from all existing DHCP servers including MAC address. This example was run on Ubuntu:

Terminal1 (for monitoring):

sudo tcpdump -nelt udp port 68 | grep -i "boot.*reply"

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp2s0, link-type EN10MB (Ethernet), capture size 262144 bytes
20:a6:80:f9:12:2f > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 332: 192.168.1.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 290
00:23:cd:c3:83:8a > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 192.168.1.253.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 548

Terminal2 (for sending a request):

sudo nmap --script broadcast-dhcp-discover -e eth0

Starting Nmap 7.01 ( https://nmap.org ) at 2019-10-13 21:21 EEST
Pre-scan script results:
| broadcast-dhcp-discover:
|   Response 1 of 1:
|     IP Offered: 192.168.1.228
|     DHCP Message Type: DHCPOFFER
|     IP Address Lease Time: 2h00m00s
|     Server Identifier: 192.168.1.1
|     Subnet Mask: 255.255.255.0
|     Router: 192.168.1.1
|_    Domain Name Server: 8.8.8.8, 8.8.4.4
WARNING: No targets were specified, so 0 hosts scanned.
Nmap done: 0 IP addresses (0 hosts up) scanned in 0.94 seconds

That monitoring terminal is needed just to see all responses (nmap is able to show only the first response).

kaiser
  • 1,251
  • 1
  • 16
  • 24
ajaaskel
  • 231
  • 2
  • 5
  • 3
    For linux at least, unlike the noise of the accepted answer and others, this works, is simple and both tcpdump and nmap are already installed. Helped me track down rouge dhcp server on my network quickly. – DKebler Nov 12 '20 at 20:02
10

Scapy is a python based packet crafting tool that is good for these sort tasks. There is an example of how to do exactly this here.

Huygens
  • 1,678
  • 2
  • 19
  • 36
Kyle Brandt
  • 82,107
  • 71
  • 302
  • 444
  • 3
    Wow, I find Scapy is so powerful after delving into it for several days. It surpasses the crappy tools like dhcpfind.exe and dhcploc.exe. Scapy 2.2 can run on Linux and Windows -- I tried both. The only barrier is you HAVE TO know Python programming language to quite some extent to harness its power. – Jimm Chen May 21 '13 at 01:35
  • The link you posted is broken – Jason S Feb 10 '15 at 20:46
  • @JasonS Hi I've updated the link, but the changing is pending peer review... While waiting you can find it here: https://bitbucket.org/secdev/scapy/wiki/doc/IdentifyingRogueDHCPServers – Huygens Aug 14 '15 at 16:06
  • 1
    Scapy is locked up. There's a [GitHub fork](https://github.com/Tylous/Scapy-com) that claims to have extended functionality but has no real README or docs. – kaiser Feb 23 '21 at 16:14
9

To expand on l0c0b0x's comment about using bootp.type == 2 as a filter. The bootp.type filter is only available in Wireshark/tshark. It is not available in tcpdump which the contextual location of his comment inclined me to believe.

Tshark works perfectly for this.

We have our network divided up into numerous broadcast domains, each with their own Linux-based probe with a point of presence on the "local" broadcast domain and on an administrative subnet in one fashion or another. Tshark combined with ClusterSSH allows me to easily look for DHCP traffic or (anything else for that matter) on the further flung corners of the network.

This will find DHCP replies using Linux:

# ifconfig ethX promisc
# tshark -i ethX -n port 68 -R 'bootp.type == 2'
Community
  • 1
  • Very helpful, I spent a fair bit of time trying to figure out why I was getting `tcpdump: syntax error`. Even posted a question on it, your answer unblocked me, thanks! http://networkengineering.stackexchange.com/questions/39534/tcpdump-bootp-type-2-tcpdump-syntax-error/39535#39535 – Elijah Lynn Mar 10 '17 at 05:16
  • 1
    Also, I think something has changed with the `-R `. I get `tshark: -R without -2 is deprecated. For single-pass filtering use -Y.`. `-Y` works nicely. – Elijah Lynn Mar 10 '17 at 05:17
7

once you've established that there's a rogue dhcp server on the network I found the quickest way to resolve it was...

Send an email round to the whole company saying:

"which one of you has added a wireless router into the LAN, you've killed the internet for everyone else"

expect a sheepish response, or the conflicting device to disappear, quickly :)

Shh now
  • 79
  • 1
  • 1
3

You can use RogueChecker from Microsoft:

original link: http://blogs.technet.com/b/teamdhcp/archive/2009/07/03/rogue-dhcp-server-detection.aspx

link with download: https://web.archive.org/web/20141022013752/http://blogs.technet.com/b/teamdhcp/archive/2009/07/03/rogue-dhcp-server-detection.aspx

also read this information:

https://social.technet.microsoft.com/wiki/contents/articles/25660.how-to-prevent-rogue-dhcp-servers-on-your-network.aspx

juFo
  • 393
  • 3
  • 9
  • 21
3

Disable the main DHCP server and (re)configure a connection.

If you get an IP address, you've got a rogue.

If you have a Linux handy, the standard dhcpclient tells you the IP address of the DHCP server (else you can sniff the traffic to see where the DHCP response came from).

Vinko Vrsalovic
  • 1,523
  • 2
  • 15
  • 20
  • 2
    While this would of course work, stopping a production DHCP server is probably not the best approach if you are actually concerned about *providing the service*... – Massimo Feb 14 '12 at 11:04
  • 3
    Depends on the amount of people you are serving. You can disrupt the service for a couple of minutes in most cases and nobody will notice, especially in the middle of the day when most people have their lease already. – Vinko Vrsalovic Feb 16 '12 at 11:44
3

There are several ways, if your running a small network the simplest way is to turn off / disable / un-plug your dhcp server and then run ipconfig /renew or similar on a client and if you obtain and IP you have something rougue on your network.

Another way would be to use Wireshark packet capturer/analyser to look at your network traffic and find DHCP connections, there is a lab worksheet on how do do this avaliable from here.

There are also a number of utilies avaliable which proport to do this one is DHCP explorer another is DHCP probe which you mentioned in your original post.

Jona
  • 746
  • 1
  • 9
  • 17
2

You could do a ping sweep of your networks and then compare that to the number of DHCP leases handed out by your DHCP server.

You need to have a general idea of the number of static devices (router interfaces and printers perhaps) which will skew this number slightly, but this should be a quick and accurate way of identifying them across multiple networks.

Peter
  • 5,403
  • 1
  • 25
  • 32
2

on debian/ubuntu one also has the options to use dhcpdump and/or tcpdump with the help of e.g. dhclient

Use dhcpdump:

  • 1.a) run dhcpdump -i eth0 in one shell/shell (eth0 or the name of your interface)
  • 1.b) start dhclient in another shell (it doesn't have to run successfully)
  • 1.c) look into the output of dhcpdump for information (it should be a nice formatted, informative list of the most details)

Option 2 if you dont like to use dhcpdump:

  • 2.a) run tcpdump -i eth0 -t -n > /tmp/my_file.txt in one shell/window
    (optional: -t = disable timestamp // -n = disable name-resolution, just IP-address, no servernames (for RHEL/centos use -nn) )
  • 2.b) start dhclient in another shell (it doesn't have to run successfully)
  • 2.c) stop the running tcpdump ()
  • 2.d) examine the file /tmp/my_file.txt with your favorite editor and search for things like: ".53 " (the default DNS port) / "NX" / "CNAME" / "A?" / "AAAA" -

*sidenote: tcpdump and dhcpdump probably have to be installed (e.g.: sudo apt get install tcpdump dhcpdump); dhcpdump depends on tcpdump

MacMartin
  • 338
  • 1
  • 4
  • 17
0

Under OSX (and I suspect Linux), this is what I did:

tcpdump -i en0 -n port 67 or port 68

You will need to change the en0 to be the name of your interface. Once I made a DHCP request (by clicking Renew DHCP Lease in the advanced section of the Network System Preferences panel), I saw something like the follwing:

15:59:17.843 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 6:b:5:9:f:3, \
        length 300
15:59:17.847 IP 10.1.2.1.67 > 10.1.2.155.68: BOOTP/DHCP, Reply, length 309

Port 67 is listed in my /etc/services as "bootps" Bootstrap Protocol Server.

Turning off your primary DHCP server may be needed to see any other network devices that are inappropriately responding to DHCP requests.

Gray
  • 569
  • 1
  • 5
  • 17