Defending Against Rogue DHCP Servers
Hey Hey,
This was originally submitted for the newsletter but again I'm resubmitting so that it's searchable and reaches a larger base. It's also a follow up to my previous tutorial DHCP and Resulting Theoretical Attacks
For some time now, large corporations that provide public internet/intranet access have been plagued with the problem of Rogue DHCP servers. This issue can be easily solved with some basic switch security techniques. Due to a lack of hardware this will be demonstrated with the following network setup, layered in a collapsed core design.
Figure 1 - Network Layout - http://www.seeminglyrandom.info/dhcp/dhcp-1.jpg
The network will consist of 4 VLANs and require 5 address ranges. The details of this setup can be found in the table below.
Figure 2 - VLAN/Hardware Layout w/ Address Scheme - http://www.seeminglyrandom.info/dhcp/dhcp-2.jpg
The web server used in this example is a Catalyst 2950 switch, so the config for that switch has also been included.
There are two forms of security used to restrict access and limit the attacks caused by Rogue DHCP servers. The first thought is to go immediately to 802.1x, since the devices support it, however being a public institution this would limit availability and also require users to have usernames and passwords, while not fully protecting from an accident rogue DHCP server (for example from a VMWare client). The first item that is required is the Cisco command switchport protected; this should be placed on all ports that will be used for client access. To better explain the switchport protected command we can reference a CiscoPress website
Quote:
Source: http://www.ciscopress.com/articles/a...99029&seqNum=3
A protected port feature is used in those environments where no traffic can be forwarded between two ports on the same switch. This way, one neighbor connected to one port does not see the traffic that is generated by another neighbor connected to the second port. The blocking of traffic (unicast, broadcast, or multicast) only works when both ports are protected. When a protected port is communicating with an unprotected port, the traffic is forwarded in the usual manner. Once the ports are protected, traffic between them can only be forwarded by a Layer 3 device.
This means that our clients will not know that each other exist. This is requires because VLANs are still using layer 2 functions and will Forward, Flood or Filter. If traffic from 192.168.1.1 came into our access-layer switch on physical port 2, logical VLAN 2 and was bound for 192.168.1.2 on physical port 3, logical VLAN 2 the traffic would be forwarded. 192.168.1.2 would automatically receive the information that 192.168.1.1 had sent. What switchport protected will do is block that communication deny communication between devices on the same Virtual LAN. The port protection will be dropped when the frame hits the layer 3 device to become a packet.
That means that a packet originating at 192.168.1.1 (remember this was, for example, Port 2 – VLAN 2) and bound for 192.168.2.1 (Port 4 – VLAN 3) will not be protected using port protection. This is where our layer 3 switch at the collapsed core and distribution layers comes into play. Placed on the layer 3 switch are a series of access-lists which are combined to form a VLAN Map. This VLAN Map allows us to filter Layer 2 bound data while using Layer 3 protocols. In our example this will be DHCP. All we want to do is eliminate rogue DHCP servers while continuing to allow all other traffic. This will require 5 access-lists. The first list will allow traffic from clients to port 67 on the DHCP server and the second list will be its counter part allowing traffic from the DHCP server back to its clients on port 68. The next two rules will limit our DHCP traffic. They will deny any traffic bound for port 68 or 67. This will not apply to traffic originating from or destined for the real DHCP server because the first rule that matches will be applied and processing of the VLAN Map will stop. The last rule will be an ‘allow any any’ this is because we don’t want all our other traffic to be blocked when the end of the access map is reached. Now we just want to set the match statements. We want to forward anything that matches our first to rules, while dropping anything matching the next two (Rogue Protection) and again forwarding the traffic matching the last rule.
Quote:
ip access-list extended AllowAll
permit ip any any
ip access-list extended DHCPtoClient
permit udp host 192.168.4.1 any eq bootpc
ip access-list extended DHCPtoServer
permit udp any host 192.168.4.1 eq bootps
ip access-list extended DHCPtoRogue
deny udp any any eq bootps
ip access-list extended DHCPfromRogue
deny udp any any eq bootpc
Quote:
vlan access-map DHCPRogueBlock 10
action forward
match ip address DHCPtoServer
vlan access-map DHCPRogueBlock 20
action forward
match ip address DHCPtoClient
vlan access-map DHCPRogueBlock 30
action drop
match ip address DHCPtoRogue
vlan access-map DHCPRogueBlock 40
action drop
match ip address DHCPfromRogue
vlan access-map DHCPRogueBlock 50
action forward
match ip address AllowAll
These two simple steps will allow for almost complete protection from Rogue DHCP servers on your network, while allowing for normal, uninterrupted network communication for the remainder of your network.
3550 Config File
2950-1 Config File
2950-2 Config File
Peace,
HT
