| Solution |
This article presents 3 options to confirm the presence of a ROGUE DHCP Server (not expected Server) on the network.
- Extract the optional 'Server Identifier' from the DHCP Request message.
Note: Packet capture can be done in 2 ways:
- CLI: diagnose sniffer packet <interface> " port 67 and port 68" 6 0 l
The 'interface' part here is referring to the interface where the ROGUE DHCP server is hosted. Here the ports 67 and 68 are being used, as the DHCP uses ports 67 and 68(By default).
Example: diagnose sniffer packet port1 "port 67 and port 68" 6 0 l
- GUI of the firewall: Navigate to Network, under which is Diagnostics. When clicked on diagnostics, the main page contains the packet capture skeleton, where the packets can be captured based on the IP address, ports, or protocols.
As per the image:
From the packet captured on the FortiGate, open the DHCP Request message (broadcasted from the client) and look for the option 'Server Identifier' as shown below.
From RFC 2131, this option should exist on the message, or at least the Vendor Class Identifier.
-
Using the packet capture from the FortiGate.
In cases where there is no information about the server available from the option above, it is necessary to try another approach.
From Wireshark, it is expected that at least the following packets were captured:
 pcap01
As shown in the image above, there are no DHCP Server messages (Offer or Ack), but there is another device (50:00:00:02:00:01) sending an ARP Request for the IP 192.168.30.7, and there is an ARP Announcement afterward.
This means that some DHCP Servers are verifying if they already have the IP 192.168.30.7 on the network to decide if it is offered to the client, then it is the confirmation that no one answered, and the client sends the ARP Announcement.
From this example, if some devices already have this specific IP assigned, the communication between the clients will not be visible because it is unicast, but it will show a DHCP Declined message broadcasted from the client, and the process of Discover, Offer, etc, will restart.
Note: In a large-scale environment, there may be many ARP Request messages that may not be from a DHCP Server. In these cases, it is necessary to look for the messages surrounding the ARP Announcement and then dismiss the irrelevant ones by process of elimination, possibly through tracking the MAC address.
-
Just disable the DHCP Service on the FortiGate.
This option is simpler than the first option: disable the status of the DHCP Server on the interface, and retry obtaining an IP from the client
If the client receives the IP assignment, all necessary information has been obtained. It will then only be necessary to get the DHCP Server MAC address to confirm that there is a Rogue DHCP Server and to confirm who it is from that address.
Example: Get a new DHCP address on a Windows client. Open CMD and type 'ipconfig /all', and it will be possible to check the DHCP server IP address. Now run the command 'arp -a' it will be possible to check the ARP table of the Windows client, and what is the MAC address of the server found with the command 'ipconfig /all'. With this information, it will now be possible to discover which switchport the rogue DHCP server is directly connected to.
Related articles:
Technical Tip: Understanding DHCP Server and DHCP Relay functionality on FortiGate
Troubleshooting Tip: Check DHCP Messages with VLAN Tag using Wireshark Packet Capture
|
