Securing your client network 1: Enforce DHCP usage

June 14, 2015

In my last blog post I talked about going the full Layer 3 way and not building complex Layer2 subnets throughout your network. As many have the argument of security for building their networks this way I thought I write down how I secure client networks. With client networks I mean the part of the network client systems like PCs, phones, printer, … are connected to. Some of the articles and setups can also be used for the data center networks but thats an other story … 😉

All setups I describe in this series I have implemented in productions networks over the years and are therefore not stuff that only works in theory but they work in real life and solve real world problems. So lets start with something easy but which has real benefits not only for security – enforcing DHCP usage by all client systems.

Motivation

Sure, everybody knows for what DHCP is used but lets talk a little bit about the benefits besides not needing to configure each clients manually.

If clients get their IP address via DHCP its easier to move the client systems to other subnets. So the need to extend your subnet over multiple switches decreases.
Result: Helps you to a more routed network and so simpler and more stable network. Clients can move through out your network and it just works.
It is also easier to change the client subnet if needed it for an upgrade/change of the network architecture.
Result: Makes much more flexible to change your network.
If you enforce the use of DHCP you also get an log file which client had which IP address at a given time and also to which switch port the client was connected. If there are static IP addresses in your network which you don’t control your log file ins incomplete.
Result: Audit logs in case you need to do a forensic investigation on how and by what systems an attack was carried out. Most systems log the IP address and you need to map that to a specify systems/location.
Also if you enforce the usage of DHCP, you can use the DHCP requests/replies for protection against of ARP spoofing (or at least mitigation) in your network.
Result: An attacker can not sniffer the traffic from an other client system in the same subnet.
If enforced, no idiot configures an IP address static which is also used dynamically.
Result: Quieter life for you. 😉

Implementation

To enforce DHCP usage we need to make sure that not using DHCP does not work. How can we do that? Simple – disable ARP learning on the Layer 3 switch, which is the default gateway of a client subnet. ARP (Address Resolution Protocol) is used to resolve IP addresses to MAC addresses, so if the default gateway needs to send a packet to a client systems and it does not know the MAC address (in its ARP table) – its not able to send the packet. Of course the setup needs to work for systems that use DHCP. How is this done? Also simple, the default gateway is most likely already configured as DHCP relay for the central DHCP server so it gets every request and reply. The DHCP reply contains the IP address assigned by the server and the MAC address of the client. The layer 3 switch just needs to write that into its ARP table. From this time on the IP address resolves always to that MAC address until a new DHCP rely provides and not MAC address for a given IP address.

For Extreme Networks switches (XOS) it is as simple as typing that lines per client VLAN/subnet:

enable ip-security dhcp-snooping vlan <vlanClient> port <ClientPorts> violation-action drop-packet snmp-trap configure trusted-ports <UpLinkPorts> trust-for dhcp-server (only once needed) enable ip-security arp learning learn-from-dhcp vlan <vlanClient> ports <ClientPorts> enable ip-security arp gratuitous-protection vlan Default disable ip-security arp learning learn-from-arp vlan <vlanClient> ports <ClientPorts>

If the clients are connected directly to the layer 3 switch (default gateway for the client subnet) I recommend changing the first command to

enable ip-security dhcp-snooping vlan <vlanClient> port <ClientPorts> violation-action drop-packet block-port permanently snmp-trap

So that guy who did start a DHCP server in your network needs to call you, before it works again – otherwise I recommend configuring that this way on the switch the client is connected to.

Optional

Following setups / configurations should be done to increase the security in this part still more:

Save the DHCP log file for a longer time period as is default for Windows DHCP servers which rotate every week and make sure all information you need is in the log file.
Enable ARP spoofing protection also on the clients systems where possible (most likely on on PCs possible). Most enterprise endpoint protection systems allow such a configuration.
Integrate the configuration of DHCP reservations (e.g. for printers) into your network authentication solution. It already needs to know the MAC address of the client so adding the IP address there is simple. It keeps also the DHCP scopes clean, so if a client is removed from the network authentication, it automatically removes the reservation from the DHCP server. The side benefit is that your service desk employees could also use this to create DHCP reservations without needing DHCP administrator privileges – and its often easier to have an audit log of the changes than on the Windows DHCP server.

In HowTo, IT Security, Networking | 1 Comment

1 Comment »

RSS feed for comments on this post. TrackBack URI

[…] second article in the securing your client network series (after Enforce DHCP usage) is about separating different client device classes in the network. Typically enterprises separate […]

Pingback by Securing your client network 2: Separate by devices classes | Robert Penz Blog — June 16, 2015 #

Securing your client network 1: Enforce DHCP usage

1 Comment »

Leave a comment