Rogue DHCP server fun
As part of the day job we are often asked to look at "weird" things for clients. Earlier this week at a remote client site we had one of these "weird" things, although I guess the title gives it away. The machines at that location were all showing DNS settings for DNS servers that did not belong to the organisation. The default gateway was also changed to an IP address in a different subnet than was being used. The first thought was that junior had botched the DHCP settings on the server. A quick check on the server, that according to the misconfigured workstation provided the information, let him off the hook.
The second thought was malware, we've come across that in the past http://isc.sans.org/diary.html?storyid=6025, but we haven't seen much DHCP malware lately so we went for the, at this stage, more obvious option of a rogue DHCP server. To find it we sniffed the DHCP traffic and the cause was quickly clear. A DHCP server on the local network was responding faster than the corporate server which is at the other end of slowish link. Not all settings though, the IP address and domain name details were still from the corporate DHCP server.
After finding the MAC address of the device and having a look through the MAC tables on the local switches, the device was found and disconnected. Turns out it was an unauthorised ADSL modem with DHCP configured. It did get me thinking about how do we detect or prevent rogue DHCP servers on the network?
In Windows world DHCP servers need to be authorised. This will prevent a Windows server from accidentally handing out DHCP information until it is authorised, but it won't prevent a non Windows DHCP server from doing the same. With the audit logging switched on you may, in the eventlog and DHCP log files, be able to identify other devices that are performing a DHCP functions. There are also two windows tools that will identify rogue DHCP servers. dhcploc.exe from the Windows XP support tools is a CLI based tool. roguechecker is a more recent GUI tool (make sure you download them from the microsoft website). NMAP since version 5.10 has a script that may help as well. Running the dhcp-discover script should provide you with information on any DHCP servers. A final method is your trusty IDS who should be able to detect rogue DHCP servers on the network.
Preventing them in the first place seems to be trickier. RFC 3118 outlines an authentication mechanism for the protocol. DHCP packets are authenticated and only authorised packets are accepted by the client. However I could not find any information on the practical implementation of this (if you do, please let me know).
A second prevention mechanism is the use of DHCP snooping capabilities on switches. Essentially it only allows DHCP information to be provided by certain servers on certain ports. Each vendor will have documentation on how to implement it on their devices.
Network Access Protection (NAP) or control (NAC) will help by forcing all devices to authenticate to the network. Devices that do not meet the criteria or can't authenticate correctly are segmented on specific subnet or VLAN.
Each of these methods has its challenges. DHCP snooping on switches must be implemented correctly on each and every switch otherwise clients will not get their information. NAC/NAP can be complicated as many of you will know and may only work with certain operating systems, supplicants, etc.
Rogue DHCP servers can be a big issue. Make sure you have something in place to prevent or detect them in your environment.
Mark
Keywords: DHCP
8 comment(s)
×
Diary Archives
Comments
www
Nov 17th 2022
6 months ago
EEW
Nov 17th 2022
6 months ago
qwq
Nov 17th 2022
6 months ago
mashood
Nov 17th 2022
6 months ago
isc.sans.edu
Nov 23rd 2022
6 months ago
isc.sans.edu
Nov 23rd 2022
6 months ago
isc.sans.edu
Dec 3rd 2022
6 months ago
isc.sans.edu
Dec 3rd 2022
6 months ago
<a hreaf="https://technolytical.com/">the social network</a> is described as follows because they respect your privacy and keep your data secure. The social networks are not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go.
<a hreaf="https://technolytical.com/">the social network</a> is not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go. The social networks only collect the minimum amount of information required for the service that they provide. Your personal information is kept private, and is never shared with other companies without your permission
isc.sans.edu
Dec 26th 2022
5 months ago
isc.sans.edu
Dec 26th 2022
5 months ago