Tag Archive: DHCP


Layer 2 security methods.

Another week has passed and I’ve used it to concentrate on layer 2 security: DHCP Snooping, Dynamic ARP Inspection and IP Source Guard. I had trouble getting the latter two to work until I realised they work together with DHCP Snooping, and static entries you have to define. But it works now, another thing learned, another check box for the Cisco SWITCH exam.

Time to list some common layer 2 security methods. I will briefly discuss each one here. Note that I use example values, and where I use a VLAN, you can also use a VLAN list most of the time. The interface range command works for these commands as well, allowing for faster configuration.

Port security
The easiest one I think: binds a MAC address to a switchport, so only that host can connect to only that switchport. By default, only one MAC address is allowed, but you can set it to more. Recommended in case of IP Phones, or a hypervisor with multiple virtual machines. Commands:

Switch(config-if)#switchport port-security
Switch(config-if)#switchport port-security mac-address sticky
Switch(config-if)#switchport port-security violation restrict

The second command uses the ‘sticky’ keyword. This means the first MAC address to be detected will be used and added to the running-config. Saves you the time of typing a lot of MAC addresses. The violation mode is restrict here, which drops frames from other MAC addresses and logs an SNMP trap. ‘protected’ would do the same without SNMP trap, and ‘shutdown’ would shutdown the port so nothing can be received on it anymore.

DHCP Snooping
Prevents a rogue DHCP server from handing out IP addresses in the network. The point is not that IP addresses are handed out, but the DHCP server determines the default router, allowing it to influence routes. Personally, I don’t think it’s an often used attack, but it also builds a DHCP binding table on the switch that can be used to prevent other attacks. Configuration:

Switch(config)#ip dhcp snooping
Switch(config)#ip dhcp snooping vlan 1

This activates it for VLAN 1. Of course, the link going to the right DHCP server should be trusted:

Switch(config-if)#ip dhcp snooping trust

IP Source Guard
This function makes sure that a frame sent by a host really came from that host. It does so by comparing the source IP with the source switchport. For the source IP, it either needs the DHCP snooping database (which you can see with the ‘show ip dhcp snooping’), or statically defined entries. An example of a statically defined entry:

Switch(config)#ip source binding 0010.72ab.07f5 vlan 1 192.168.0.5 interface FastEthernet0/3

To enable it, the command must be done on the interface(s):

Switch(config-if)#ip verify source

You can also add the keyword ‘port-security’ after this to check the right MAC address too, but port-security has to be enabled.

Dynamic ARP Inspection
DAI makes sure no false ARP replies or gratuitous ARPs (GARP) are sent. Like IP Source Guard, it uses either the DHCP snooping database or static entries. The static entries are defined with an arp access-list:

Switch(config)#arp access-list ExampleARPlist
Switch(config-acl)#permit ip host 192.168.0.5 mac host 0010.72ab.07f5

To apply it on a VLAN:

Switch(config)#ip arp inspection vlan 1
Switch(config)#ip arp inspection filter ExampleARPlist vlan 1

Private VLANs
I’m mentioning them here because it adds to the security. Very useful in environments where you want hosts to communicate with the gateway, but not each other. For a configuration example, see one of my first blog posts.

802.1x
This makes sure only hosts with the right credentials can connect. A client device must have support for this, but every modern operating system has this. A client device provides a username and password (usually to be filled in somewhere in the network interface options). This password is then checked against a database, usually by RADIUS. If the right credentials are provided, the client device gains access to the network. Activating it requires several commands, as authentication has to be set up. I’m not going to explain how to set up the RADIUS server here.

Switch(config)#aaa new-model
Switch(config)#radius-server host 192.168.1.1
Switch(config)#aaa authentication dot1x default group radius
Switch(config)#dot1x system-auth-control

Switch(config-if)#dot1x port-control auto

Disable Dynamic Trunking Protocol
To prevent a device from forming a trunk link with a switch, and thus gain access to all VLANs, always disable DTP on end-node links:

Switch(config-if)#switchport nonegotiate

BPDU Guard
To prevent any of the end-nodes from taking over as a spanning-tree root bridge, it’s best to configure BPDU Guard. Since these switchports can also be configured with portfast for faster convergence, you can enable BPDU Guard by default too:

Switch(config)#spanning-tree portfast bpduguard default

Switch(config-if)#spanning-tree bpduguard enable

Alternatively, you can configure ‘bpdufilter’ instead of ‘bpduguard’. The difference is that with the first command BPDUs will be filtered, whereas the second command will disable the port.

Preventing double tagging
And finally, this method has no real commands but is just a best-practice: always try to set the native VLAN on trunks to an unused VLAN, and choose another VLAN than VLAN 1 for management. This makes it harder to find the management VLAN, and prevents VLAN hopping attacks. VLAN hopping is done when a frame is sent with two 802.1q tags, of which the first one belongs to a native VLAN. At a trunk link, the first tag will be stripped off the frame, and when received on the next switch, the second VLAN tag will be used. This way, the frame ‘hops’ between VLANs, making attacks possible that are hard to trace.

Advertisements

Ever since I was able to give my IP Phone the correct time by NTP using the DHCP server, I’ve been playing around with the DHCP options to see if more is possible.

DHCP uses options in it’s packets to specify information. Each option specifies one specific piece of information. I’m going to list these most important options and explain them below. For a full list, see this site. The RFC is even more detailed if you’re in for a read.

  • 53 – DHCP message type (Discover, Offer,…).
  • 50 – Requested IP address: sometimes present in the Discover, always in the Request.
  • 55 – Parameter request list: used in the Discover only, requested options. Usually 1,3,15 and 6.
  • 1 – Subnet mask: must be specified before option 3.
  • 3 – Default router or gateway: more than one can be specified but this is rarely done.
  • 51 – Lease time: offered, or requested.
  • 54 – DHCP server: this is to specify which DHCP server is being negotiated with.
  • 6 – DNS server: commonly used but not required. More than one can be specified.
  • 15 – Domain name: also not required, but useful information in a domain.

Note that the above order is the order in which the options are presented in DHCP packets. Besides these commonly used options, other, less frequently used also exist:

  • 31 – Router discovery flag: see RFC 1256, makes IPv6-like ICMP router discovery possible.
  • 42 – NTP Server: more than one can be specified too here.
  • 60 – Vendor Class Identifier: used in Discover and Request to inform about the type of device.
  • 66 – TFTP server(s). This is useful for IP Phones, but some use option 150 instead.
  • 121 – Classless static routes. Classful static routes are option 33, deprecated.
  • 138 – CAPWAP controller address for Lightweight Access Point deployments (wireless). RFC 5417.
  • 150 – TFTP server(s). For IP Phones.

These options provide some centralised management of network services in a company. For example, in a voice VLAN, adding option 42 (NTP) and 150 (TFTP) will allow the IP Phones to display the correct time and receive firmware upgrades and other configuration settings from a TFTP server. Option 138 does the same for Lightweight Access Points, when using a large wireless infrastructure: the LAP is connected, receives an IP and controller address, downloads firmware and settings, and starts working.

I’m going to explain option 121 a bit more. Again, for a full read, see RFC 3442. Each client device has a routing table, just like a router.  On Windows, you can see this routing table with the ‘netstat -r’ command in the command line. Using option 121, you can add extra routes besides the default route to a device. The exact format is:

  • Eight bits for the prefix mask (since the maximum mask is 32, only six bits will be used).
  • Depending on the mask, a number of bits for the network prefix.
  • 32 bits for the next hop IP.
  • Multiple routes can be added, so after this another route can follow.

For example, in my home network, my computer is hooked up to a leyer 3 switch (the 3560), which connects to the gateway router, and one ethernet cable running to my home lab. My computer is in the 192.168.168.0/24 subnet. Say I use the 10.0.0.0/8 subnet in my home lab, with the 3560 at 192.168.168.5 doing the routing. If I want to ping 10.0.0.1 from my computer, the packet will be sent to the default gateway: the ISP router at 192.168.168.1, which will then forward it towards the ISP where it is dropped. However, if I can configure a static route 10.0.0.0/8 to 192.168.168.5, it will work again.

Since my DHCP server is also a Cisco device, I can add the option in the command line (though any DHCP server, Windows or Linux, will allow it too of course):

Router(config)#ip dhcp pool LANPOOL
Router(dhcp-config)#network 192.168.168.0 255.255.255.0
Router(dhcp-config)#default-router 192.168.168.1
Router(dhcp-config)#dns-server 8.8.8.8
Router(dhcp-config)#option 121 hex 080AC0A8A805

Why the hex ‘080AC0A8A805’? I’ll break it down for you. 08: the /8 subnetmask. 0A: 10, the network address part of 10.0.0.0, and finally hex C0A8A805 translates to 192.168.168.5. Note that for 10.0.0.0/24, next hop 192.168.168.5, the hex string would be ‘180A0000A8A805’. This string is longer because 24 network bits are required, not 8.

Now my pings to 10.0.0.1 succeed, and when doing a ‘netstat -r’ on the Windows computer, I can see a route to 10.0.0.0/8 in the routing table. This way, you can already start influencing traffic flows at the end devices. Whether that’s a smart choice, I’ll leave open for discussion.

PS. I know I’m spamming links to RFC documents, but in the networking world, if there’s any source you can trust, it’s a RFC, because vendors may stray from it.