Find rogue dhcp server

Tillebeck · Aug 17, 2011, 9:55 PM

How to find a rogue dhcp server on Pfsense 2.0?
Have checked the DHCP log but seem not to find it (may have been offline or reported error is related to something else than a rogue dhcp server)

Have changed from another router to pfsense. In the "old one" a big warning on the main page would say "Rogue dchp server detected". can the pfsense do someting like that? Report problems. Rogue DCHP server, running out of memory etc. etc.?

BR. Anders

wallabybob · Aug 17, 2011, 10:20 PM

In this context, what is a rogue DHCP server? You have a pfSense interface with DHCP server enabled and there is another DHCP server on the same LAN segment? You have pfSense interface configured to get its IP address by DHCP and it gets configuration information from a server other than the "official" server?

dhatz · Aug 17, 2011, 11:14 PM

An Ethernet switch supporting "DHCP snooping" is probably the best solution (many managed switches do, including Cisco, the L3 switches by HP etc).

Tillebeck · Aug 18, 2011, 8:43 AM

Using the switch would work. But in this specific scenario I only control the router (pfsense).

definition: Rogue DHCP server (quess it is the right word)
I think of a classic network accessing the internet through a pfsense-box:
WAN <-> Pfsense <-> LAN

On LAN someone occasionally connect cheap wireless routers to the LAN using one of the LAN-ports on the wireless routeres. Therefore the wireless router will act as an additional DHCP-server on LAN. It is then a pure lottery if a client will get a lease from the pfsense box and have access to the internet, or from the cheap wireless router (rogue DHCP server) that is leading nowhere

How can I find such a "rogue dhcp server"?
I just thought that there maybe could be some checkbox to check like "detect rogue dhcp servers" and have a notice right written to screen on the status page after login. Searched the forum, guess there is not such an option.

Solution might be:
I guess it is go to System logs -> DHCP and then do a manuel search&find

If that is possible, then I will log onto the switch and ask for the port that this MAC is hooked up to. Different switches, different commands. I use HP Procurve. That is something like "mac-address xx:xx:xx:xx:xx and it tells the port. Easy, if the MAC is known. Else kind of difficult.

BR. Anders

Tillebeck · Aug 18, 2011, 9:12 AM

"An Ethernet switch supporting "DHCP snooping" is probably the best solution (many managed switches do, including Cisco, the L3 switches by HP etc)."

Thanks. Never heard of that. I will take a look and see if HP Procurve 25xx and 26xx can do that too. That is the ones we usually install.

Br. Anders

jimp · Aug 18, 2011, 4:31 PM

The only non-disruptive ways to find it would be snooping the switch, or just shut off pfSense's DHCP server and then see what the IP/MAC of the DHCP server shown on a client pulling a fresh lease looks like.

The disruptive way would be to switch that interface on pfSense into a dhcp client, and then look at the IP/MAC of the dhcp server it pulls from, then switch back to static and fix the IP back the way it was.

Once you have the IP/MAC you can find out what type of device it is from the MAC and look on the switches to find out what port that MAC is connected through.

One DHCP server is not likely to report/show you another DHCP server on the network, which is why you'd have to investigate it as a dhcp "client".

NOYB · Aug 18, 2011, 9:18 PM

Sniffer (wireshark, tcpdump) for any DHCP ACK without correct, DNS, Gateway, etc. is your rouge device(s).

Wireshark display filter might look similar to this:
bootp.type == 2 and bootp.option.type == 6 and (!(bootp.option.value == b8.10.21.36.b8.10.04.16))

Where bootp.option.value is the hex DNS server ip addresses.

A capture filler would probably be more suited. At lest narow down the capture down to only replies from DCHP servers.

Or maybe even eaier might be just a capture filter for any DHCP packet not containing the MAC of a blessed DHCP server.
Perhaps a capture filter similar to this:
src port 67 and not ether src host 00:18:01:15:af:a3

Tillebeck · Aug 26, 2011, 7:56 AM

Thanks for the tips. I will go with the easy model suggested by jimp.

disconnect the pfsense
hook up a laptop to the LAN
get IP from rogue dhcp-server
start to ping it
disconnect switches one by one until destination host is unreachable
on that swithch disconnect every active LAN connection one by one until destination host is unreachable

We use another router to. It can list rogue DHCP-servers with there MAC addresses. In the DHCP-log on tht pfsense I can se entries from clients on the subnet that the rogue DHCP-server uses (192.168.0.xxx plus client MAC). But not the rogue DHCP-server's MAC. I tried to ping it from the pfsense, but no response offcause; different net.

Suggestion: If possible, then let the pfsense get the MAC from any rogue DHCP-server. I know another router that can (www.smartshare.dk) so it is possible. But probably not top priority.

Thansk for all the help.
Anders

Tillebeck · Aug 26, 2011, 12:01 PM

Will just add some from the system log -> dhcp

All 192.168.24.xxx with MAC are pfsense router
All 192.168.1.xxx with MAC are rogue DHCP clients
Only thing needed is MAC for rogue DHCP- server… that would be nice2have too

Aug 26 13:54:18 	dhcpd: DHCPREQUEST for 192.168.1.143 (192.168.1.1) from e4:ce:8f:88:a6:b9 via vr0: wrong network.
Aug 26 13:54:18 	dhcpd: DHCPNAK on 192.168.1.143 to e4:ce:8f:88:a6:b9 via vr0
Aug 26 13:56:36 	dhcpd: DHCPREQUEST for 192.168.1.140 from 00:1f:5b:cd:b2:fb via vr0: wrong network.
Aug 26 13:56:36 	dhcpd: DHCPNAK on 192.168.1.140 to 00:1f:5b:cd:b2:fb via vr0
Aug 26 13:56:38 	dhcpd: DHCPREQUEST for 192.168.1.174 from 00:1f:5b:cd:b2:fb via vr0: wrong network.
Aug 26 13:56:38 	dhcpd: DHCPNAK on 192.168.1.174 to 00:1f:5b:cd:b2:fb via vr0
Aug 26 13:56:51 	dhcpd: DHCPREQUEST for 192.168.24.12 from 00:26:f2:60:56:a7 (WGR614V9) via vr0
Aug 26 13:56:51 	dhcpd: DHCPACK on 192.168.24.12 to 00:26:f2:60:56:a7 (WGR614V9) via vr0
Aug 26 13:57:33 	dhcpd: DHCPREQUEST for 192.168.1.174 from 00:1f:5b:cd:b2:fb via vr0: wrong network.
Aug 26 13:57:33 	dhcpd: DHCPNAK on 192.168.1.174 to 00:1f:5b:cd:b2:fb via vr0
Aug 26 13:57:35 	dhcpd: DHCPREQUEST for 192.168.1.140 from 00:1f:5b:cd:b2:fb via vr0: wrong network.
Aug 26 13:57:35 	dhcpd: DHCPNAK on 192.168.1.140 to 00:1f:5b:cd:b2:fb via vr0

wallabybob · Aug 26, 2011, 10:18 PM

@Tillebeck:

Only thing needed is MAC for rogue DHCP- server… that would be nice2have too

It most cases you won't be able to get that from the "good" dhcp server. Initial DHCP request is sent to broadcast MAC which means all stations on the LAN see it and see MAC address of client. Thereafter the conversation is between two specific MAC addresses which means that switches will normally hide it from other stations.

However, you might be able to to find the rogue server from the rogue clients. Their log might record some details of the server they used.

NOYB · Aug 27, 2011, 12:06 AM

@wallabybob:

@Tillebeck:

Only thing needed is MAC for rogue DHCP- server… that would be nice2have too

It most cases you won't be able to get that from the "good" dhcp server. Initial DHCP request is sent to broadcast MAC which means all stations on the LAN see it and see MAC address of client. Thereafter the conversation is between two specific MAC addresses which means that switches will normally hide it from other stations.

DHCP Offers and ACK to DHCP Discover Requests are also broadcasts. Therefore seen by all clients.

wallabybob · Aug 27, 2011, 4:52 AM

@NOYB:

DHCP Offers and ACK to DHCP Discover Requests are also broadcasts. Therefore seen by all clients.

I have looked at tcpdumps and system logs for a number of DHCP interactions between my Linux netbook and pfSense 2.0 acting as DHCP server. I didn't seen anything from the server sent to the broadcast MAC address. Maybe I missed something.

Here's one transaction recorded in the system log:

Aug 27 11:54:30 kogan dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 4
Aug 27 11:54:34 kogan dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 6
Aug 27 11:54:40 kogan dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 8
Aug 27 11:54:40 kogan dhclient: DHCPOFFER of 192.168.51.211 from 192.168.51.173
Aug 27 11:54:40 kogan dhclient: DHCPREQUEST of 192.168.51.211 on eth1 to 255.255.255.255 port 67
Aug 27 11:54:40 kogan dhclient: DHCPACK of 192.168.51.211 from 192.168.51.173
Aug 27 11:54:40 kogan dhclient: bound to 192.168.51.211 – renewal in 3234 seconds.

and corresponding tcpdump:

tcpdump: WARNING: eth1: no IPv4 address assigned
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
11:54:30.101183 00:12:7b:46:e7:65 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:12:7b:46:e7:65, length 300, xid 0x494c7532, Flags [none]
Client-Ethernet-Address 00:12:7b:46:e7:65 [|bootp]
11:54:34.004241 00:12:7b:46:e7:65 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:12:7b:46:e7:65, length 300, xid 0x494c7532, secs 4, Flags [none]
Client-Ethernet-Address 00:12:7b:46:e7:65 [|bootp]
11:54:40.004199 00:12:7b:46:e7:65 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:12:7b:46:e7:65, length 300, xid 0x494c7532, secs 10, Flags [none]
Client-Ethernet-Address 00:12:7b:46:e7:65 [|bootp]
11:54:40.006416 c8:3a:35:c4:ee:f3 > 00:12:7b:46:e7:65, ethertype IPv4 (0x0800), length 342: (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
192.168.51.173.67 > 192.168.51.211.68: BOOTP/DHCP, Reply, length 300, xid 0x494c7532, secs 10, Flags [none]
Your-IP 192.168.51.211
Client-Ethernet-Address 00:12:7b:46:e7:65 [|bootp]
11:54:40.007095 00:12:7b:46:e7:65 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:12:7b:46:e7:65, length 300, xid 0x494c7532, secs 10, Flags [none]
Client-Ethernet-Address 00:12:7b:46:e7:65 [|bootp]
11:54:40.009546 c8:3a:35:c4:ee:f3 > 00:12:7b:46:e7:65, ethertype IPv4 (0x0800), length 342: (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
192.168.51.173.67 > 192.168.51.211.68: BOOTP/DHCP, Reply, length 300, xid 0x494c7532, secs 10, Flags [none]
Your-IP 192.168.51.211
Client-Ethernet-Address 00:12:7b:46:e7:65 [|bootp]

In a transaction like the above, how would a listening station determine the MAC address of the DHCP server?

NOYB · Aug 27, 2011, 6:51 AM

Discover, Offer, Request, Ack. All broadcast to 255.255.255.255

Wiki info also discribes this as the DHCP behavior.
http://en.wikipedia.org/wiki/DHCP
http://en.wikipedia.org/wiki/Rogue_DHCP

Maybe we should consult an RFC
http://tools.ietf.org/html/rfc2131

4.1 Constructing and sending DHCP messages
"If 'giaddr' is zero and 'ciaddr' is zero, and the broadcast bit is
set, then the server broadcasts DHCPOFFER and DHCPACK messages to
0xffffffff. "
"A client that cannot receive unicast IP datagrams until its protocol
software has been configured with an IP address SHOULD set the
BROADCAST bit in the 'flags' field to 1 in any DHCPDISCOVER or
DHCPREQUEST messages"


23:12:00.634257 30:46:9a:0a:f6:22 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 295: (tos 0x0, ttl 64, id 1, offset 0, flags [none], proto UDP (17), length 281)
    192.168.0.239.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 30:46:9a:0a:f6:22, length 253, xid 0x1b05bbe7, Flags [Broadcast] (0x8000)
	  Client-Ethernet-Address 30:46:9a:0a:f6:22
	  Vendor-rfc1048 Extensions
	    Magic Cookie 0x63825363
	    DHCP-Message Option 53, length 1: Discover
	    MSZ Option 57, length 2: 576
	    Parameter-Request Option 55, length 3: 
	      Subnet-Mask, Default-Gateway, Domain-Name-Server
23:12:02.456832 00:18:01:51:fa:72 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: (tos 0x10, ttl 16, id 0, offset 0, flags [none], proto UDP (17), length 328)
    192.168.1.1.67 > 255.255.255.255.68: [udp sum ok] BOOTP/DHCP, Reply, length 300, xid 0x1b05bbe7, Flags [Broadcast] (0x8000)
	  Your-IP 192.168.1.10
	  Server-IP 192.168.1.1
	  Client-Ethernet-Address 30:46:9a:0a:f6:22
	  Vendor-rfc1048 Extensions
	    Magic Cookie 0x63825363
	    DHCP-Message Option 53, length 1: Offer
	    Server-ID Option 54, length 4: 192.168.1.1
	    Lease-Time Option 51, length 4: 86400
	    Subnet-Mask Option 1, length 4: 255.255.255.0
	    Default-Gateway Option 3, length 4: 192.168.1.1
	    Domain-Name-Server Option 6, length 12: 192.168.1.1,8.8.8.8,8.8.8.8
23:12:02.459679 30:46:9a:0a:f6:22 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 339: (tos 0x0, ttl 64, id 2, offset 0, flags [none], proto UDP (17), length 325)
    192.168.0.239.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 30:46:9a:0a:f6:22, length 297, xid 0x1b05bbe7, Flags [Broadcast] (0x8000)
	  Client-Ethernet-Address 30:46:9a:0a:f6:22
	  Vendor-rfc1048 Extensions
	    Magic Cookie 0x63825363
	    DHCP-Message Option 53, length 1: Request
	    Server-ID Option 54, length 4: 192.168.1.1
	    Lease-Time Option 51, length 4: 86400
	    Subnet-Mask Option 1, length 4: 255.255.255.0
	    Default-Gateway Option 3, length 4: 192.168.1.1
	    Domain-Name-Server Option 6, length 12: 192.168.1.1,8.8.8.8,8.8.8.8
	    MSZ Option 57, length 2: 576
	    Requested-IP Option 50, length 4: 192.168.1.10
	    Parameter-Request Option 55, length 3: 
	      Subnet-Mask, Default-Gateway, Domain-Name-Server
23:12:02.666351 00:18:01:51:fa:72 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: (tos 0x10, ttl 16, id 0, offset 0, flags [none], proto UDP (17), length 328)
    192.168.1.1.67 > 255.255.255.255.68: [udp sum ok] BOOTP/DHCP, Reply, length 300, xid 0x1b05bbe7, Flags [Broadcast] (0x8000)
	  Your-IP 192.168.1.10
	  Server-IP 192.168.1.1
	  Client-Ethernet-Address 30:46:9a:0a:f6:22
	  Vendor-rfc1048 Extensions
	    Magic Cookie 0x63825363
	    DHCP-Message Option 53, length 1: ACK
	    Server-ID Option 54, length 4: 192.168.1.1
	    Lease-Time Option 51, length 4: 86400
	    Subnet-Mask Option 1, length 4: 255.255.255.0
	    Default-Gateway Option 3, length 4: 192.168.1.1
	    Domain-Name-Server Option 6, length 8: 192.168.1.1,8.8.8.8

wallabybob · Aug 27, 2011, 8:32 AM

Thanks for the packet capture. What DHCP server and client were involved in those transactions?

@NOYB:

Discover, Offer, Request, Ack. All broadcast to 255.255.255.255

Are you claiming that, on Ethernet, DHCP server ALWAYS sends (or should ALWAYS send) DHCPOFFERs to Ethernet broadcast MAC address?

NOYB · Aug 27, 2011, 8:46 PM

No. That was summary of the included capture.

Client: NetGear GS108T Switch
DHCP Server: Actiontec MI424-WR (Verizon/Frontier ISP Provided)

wallabybob · Aug 27, 2011, 9:46 PM

Do we agree?:

Sometimes an Ethernet DHCP server can complete a DHCP assignment without sending a packet to the broadcast address.

Do we also agree:

By monitoring DHCP transactions an arbitrary listening station on an Ethernet may discover the MAC address of SOME DHCP servers on the Ethernet but, in general, will not be able to discover the MAC address of ALL DHCP servers on the Ethernet.

hefferbub · Sep 28, 2011, 4:58 PM

I have a similar problem on my network. I recently ran across some free software from Princeton: http://www.net.princeton.edu/software/dhcp_probe/.

It runs in the background and listens like a DHCP client. You can configure it to know which is your real DHCP server and it will trigger a warning message which includes the IP and MAC address of any offending DHCP servers.

You still have to physically locate the rogue, but at least this warns you as soon as it happens. I have also had some success finding the rogues by taking the MAC address that DHCP_probe gives me and checking the ARP caches of my switches to follow which ports have seen that MAC until I get to its final actual port.

Jeff