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

    Find rogue dhcp server

    Scheduled Pinned Locked Moved
    DHCP and DNS
    6
    17
    18.7k
    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

      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

      1 Reply Last reply Reply Quote 0
      • 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