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