Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Find rogue dhcp server

    Scheduled Pinned Locked Moved DHCP and DNS
    17 Posts 6 Posters 19.1k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • T
      Tillebeck
      last edited by

      "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

      1 Reply Last reply Reply Quote 0
      • jimpJ
        jimp Rebel Alliance Developer Netgate
        last edited by

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

        Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

        Need help fast? Netgate Global Support!

        Do not Chat/PM for help!

        1 Reply Last reply Reply Quote 0
        • N
          NOYB
          last edited by

          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

          1 Reply Last reply Reply Quote 0
          • T
            Tillebeck
            last edited by

            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

            1 Reply Last reply Reply Quote 0
            • T
              Tillebeck
              last edited by

              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
              1 Reply Last reply Reply Quote 0
              • W
                wallabybob
                last edited by

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

                1 Reply Last reply Reply Quote 0
                • N
                  NOYB
                  last edited by

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

                  1 Reply Last reply Reply Quote 0
                  • W
                    wallabybob
                    last edited by

                    @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?

                    1 Reply Last reply Reply Quote 0
                    • N
                      NOYB
                      last edited by

                      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
                      1 Reply Last reply Reply Quote 0
                      • W
                        wallabybob
                        last edited by

                        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?

                        1 Reply Last reply Reply Quote 0
                        • N
                          NOYB
                          last edited by

                          No.  That was summary of the included capture.

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

                          1 Reply Last reply Reply Quote 0
                          • W
                            wallabybob
                            last edited by

                            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.

                            1 Reply Last reply Reply Quote 0
                            • H
                              hefferbub
                              last edited by

                              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

                              1 Reply Last reply Reply Quote 0
                              • First post
                                Last post
                              Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.