When a client initially connects to a port protected by IP source guard only DHCP discover and request messages are allowed, everything else is dropped. An important point to keep in mind is that at this point no traffic, including DHCP, will cause the switch to add an entry for the client in the CAM table and therefor when the DHCP server responds with an offer the switch will not know where to send the packet and when DHCP snooping is enabled replies from the DHCP server are not flooded out all ports if there is no entry in the CAM, so the DHCP offer will be dropped. To get around this DHCP option 82, or Relay Agent Information, is necessary. Option 82 is a frequently misunderstood value, likely because unlike other options it is not set by the DHCP server, rather it is set by an intermediary device such as a DHCP relay agent or a switch. Option 82 is made up of two TLVs (type, length, value) fields, the circuit ID and remote ID. The values of these fields are up to the vendor, the default for Cisco switches is to use circuit ID to record vlan, module, and port of the interface the request is received through and remote ID for switch’s ID (MAC address). When DHCP snooping is enabled you can view the Option 82 configuration with ‘show ip dhcp snooping’ as seen below.

When a DHCP packet is received on an untrusted port the switch adds the option 82 information and sends it on it’s way, if the option 82 field already exists the packet will be dropped (this behavior can be changed by using the ‘ip dhcp snooping information option allow-untrusted’ command under interface configuration). When the DHCP server receives the discover it is expected to return the values in option 82 with it’s offer, unfortunately not all DHCP servers support this, most glaringly is Microsoft’s server which just ignores option 82. Assuming that the server does support option 82 and returns an offer with the information intact the switch will determine whether it is the originator of the option 82 information by checking whether the MAC address in the remote ID field matches it’s own, it then looks at the VLAN, module, and port carried in the circuit ID field to find out which port the packet should be sent out, the switch then strips option 82 out of the packet and forwards it to the specified port. The same process will occur with the request and ack portion of DHCP. If the offer is sent back from the DHCP server without the option 82 information the switch is unable to determine where the packet should be sent and drops it.

Once the DHCP negotiation is completed the switch will add the IP and MAC mapping to the DHCP snooping table and the MAC address will be eligible to be added to port security and the CAM table. Note that the MAC address is not added by the DHCP snooping process, additional traffic must occur before the MAC address is added.

Now that we know how IP source guard works lets get to the configuration.

1. Configure the port connected to the DHCP server as trusted.

2. Enable DHCP snooping globally.

3. Configure interface as access port.

4. Enable port security on the interface. (For more details on port security see my CAM Table Overflow Attack article.)

4. Enable IP source guard with MAC verification.

We can verify the configuration with the following commands:

• As seen above ‘show ip dhcp snooping’ shows us which VLANs snooping is enabled for, option 82 parameters, and which interfaces are configured as trusted.

• ‘show ip dhcp snooping binding’ will display the current bindings for each interface.

• Use ‘show port security interface [interface]‘ to see the port security configuration for a particular interface.

• ‘show ip verify source’ displays the status of each port with IP source guard enabled.

We’re all done with the configuration, but what exactly are we protected against? Well, pretty much any attack that relies on the ability to spoof the source IP or MAC address, this includes CAM overflow, CAM table poisoning, ARP table poisoning (correction: ARP is not IP-based so it is not affected), and DHCP exhaustion to name a few. The DHCP snooping also protects against rogue DHCP servers.

I hope this article shed some light on IP source guard, as always comments are appreciated.

As an example I setup a 3750 switch with one computer and one router attached (the router could be a computer, it’s just what I had handy). The switches VLAN 1 was assigned 10.0.0.1/24 and the router 10.0.0.2/24. The computer was running Ubuntu with Wireshark and macof installed. Macof is a simple tool designed specifically to overflow a switches CAM table by rapidly generating thousands of packets with bogus source MAC addresses. I proceeded to test the switch’s reaction to a mac flooding attack as follows.

1. Started a ping from the router to the switch. As expected none of the unicast traffic was visible in Wireshark.

2. Started macof and verified that the CAM table filled. Still no unicast traffice in Wireshark.

(I’m not sure why the total mac address space available shows as 40 on my 3750, but the CAM table is indeed filled. Apparently it was a bug, an older IOS doesn’t exhibit the same issue.)

3. Cleared the MAC entry of the router from the switch’s CAM table. The replies from the switch to the router immediately showed up in Wireshark.

So what happened? As soon as the routers MAC address was removed from the CAM table the available slot was taken by one of the addresses spoofed by macof and when the next echo response was sent the switch no longer knew which port to send it to and had to send it out all ports in the VLAN. If I had not cleared the address I would have had to wait for the device to stop all communications for 5 minutes (the default aging time on Cisco switches), at which point the switch would automatically remove the entry.

It is also worth mentioning that filling the CAM table affects all VLANs on the switch. While traffic will still be confined to individual VLANs the switch will begin flooding traffic to all ports in each respective VLAN.

Mitigation

There are plenty of good guides for implementing port security to protect against CAN overflow attacks. I’m going to explain it again here primarily because I’m currently studying for the CCSP and explaining the topics is an excellent way to learn and ingrain the material in one’s head.

Port security is Cisco’s method of restricting which source MAC addresses can appear on frames entering a port. MAC addresses can be limited based on specific allowed addresses, the total number of MAC addresses seen on the port at any one time, or a combination of both. To stop a CAM table overflow attack in it’s tracks we only need to limit the total number of MAC addresses per port, I’ll discuss tying specific MAC addresses to a port in another post.

The ‘show port-security’ command will display an overview of all ports configured with port security, for more detail on a specific port use ‘show port-security <interface>’.

As you can see port security is not enabled on this port.

1. Port security only works on access ports, so we must first configure the port as such.

2. Now we can enable port security.

3. By default only one MAC address will be allowed on the port at a time. In some cases you may want to allow more than one, such as is you have a IP phone and computer attached to the port or if technical users have virtualization software installed on their computers. It takes thousands of MAC addresses to fill a CAM table so allowing a few per port doesn’t pose much of a risk. Here I’ve allowed 10 MAC address on the port.

You can see that the violation mode is shutdown, this means that the port will be shutdown in an err-disable state if more than 10 MAC addresses appear on the port. The two other options are protect and restrict. Restrict blocks any traffic from MAC addresses beyond the first 10 and logs a message to syslog. Protect is like restrict except that it doesn’t log any messages, and is useful if you want to make troubleshooting more difficult. We can change the violation mode like so.

Lets see how the switch reacts to a CAM table overflow attack with each the violation types.

Shutdown

To clear the err-disabled state the port must be shutdown then no shutdown.

Protect

Notice that nothing was logged to the console and the security violation count remains at zero. To clear the learned MAC addresses from port security use ‘clear port-security dynamic interface [interface]‘.

Restrict

In restrict mode messages are logged as the policy is violated and the violation count increments for each violating MAC address.

By default, once the maximum number of MAC addresses have been seen on a port no other devices may use that port until the MAC addresses are manually cleared. If you would like the allowed MAC addresses to be removed after a period of time aging can be configured on the port. There are two settings related to aging, one is the number of minutes until a MAC address is aged out, the other is the aging type. The aging type can be either absolute or inactivity. The default is absolute, which means that the aging timer starts as soon as the entry is added and will be removed once the specified number of of minutes elapses. The timer for inactivity starts when the MAC address is no longer communicating on the port and is reset if the MAC address start communicating again. Here’s how to configure the switch to age entries out after five minutes of inactivity.

After five minutes we can see that the total MAC addresses has changed from 10 to 0.

I hope this explanation of CAM overflow attacks and mitigations has been helpful. As always I welcome any questions, comments, or corrections.

Before we get into the build lets explore the types of network taps and their pros and cons.

• Hub
  These are cost effective and very simple network taps. The problem is that they force the port to half duplex, which is handy because you can monitor the link with a single network card but if there is a problem relating to full duplex on the link it may not be observable when changed to half duplex. Additionally, if the link is heavily used inserting a hub may affect performance on the network. Finally, true hubs are harder and harder to find since there is little use for them outside monitoring traffic.

• Port Mirroring
  Referred to as SPAN (Switched Port Analyzer) in the Cisco world, many managed switches have the ability to duplicate frames from a monitored port to a dedicated monitoring port. If your switches have this capability it is a non-invasive (you don’t have to unplug ports to insert a tap) method of monitoring a link, though it too has downsides. Mirroring typically runs as a low priority process and if the switch is under heavy load packets may not be mirrored (particularly bad for IDS), corrupt frames get dropped at ingress and are not mirrored, if bidirectional traffic exceeds the capability of the monitoring port excess traffic will be dropped (ie, when the monitoring ingress and egress traffic on a gigabit link the maximum bidirectional traffic is 2Gbps, which would exceed the capabilities of a gigabit monitoring port).

• Aggregation Tap
  An aggregation tap is connected inline between devices and copies all traffic to a monitoring port. This is similar to port mirroring, the difference being an aggregation tap is a dedicated device, they don’t drop frames do to being overloaded and corrupt frames are passed to the monitoring port. Like port mirroring they can be overloaded if bidirectional traffic exceeds the output of the monitoring port. Aggregation taps tend to be expensive, particularly for personal use. (Note: There are many types of aggregation taps, with varying features, this is not meant to be a thorough examination.)
• Passive Tap
  As the name implies a passive tap contains no special circuitry and is connected inline with the monitored devices. It functions simply by splitting out the receive and transmit wires so that the electrical signal is sent to both the intended devices and two monitoring ports. Two monitoring ports are required because the transmit and receive is not aggregated like with port mirroring or an aggregation tap. Due to this passive taps require two network cards in order to capture bidirectional traffic. This requirement is both a blessing and a curse, the obvious downside is that you need to add an additional network card in your monitoring computer, and popular software such as Wireshark is incapable of capturing from multiple cards at once so it becomes necessary to run multiple instances and combine the results later. (Some operating systems can bond interfaces so that multiple instances aren’t necessary.) The benefit of a passive tap, other than being cheap, is that full bidirectional traffic can be captured, assuming the the monitoring device is able to keep up. EDIT: Passive network taps do not work on gigabit links, 1000BASE-T uses all four pairs for both receive and transmit so it is not possible to tap gigabit with a passive device.

Although most of the switches I own and work with are capable of mirroring ports I wanted to be able to see all traffic passing over a link and be able to insert a tap at any point rather than only at a switch. Initially I looked for a guide to building a passive tap but found most of them overly complicated or ugly and fragile. Some were even wired so poorly that in practice they would have taken down the link they were connected to.

In the end I decided to come up with my own. The goal of this project is to create a functional, compact tap sturdy enough to be tossed in a bag and doesn’t look like a mess of wires. Knowing that I would need four RJ45 jacks I started by looking for small enclosures that could house four keystone jacks, I didn’t find many and those that I did weren’t quite what I wanted. While browsing Monoprice I came across a two port surface mount box with built in RJ45 jacks and wondered how difficult it would be to attach two of them together to create a cube with four jacks. Since they were only a few dollars each I decided to purchase a couple to see if they would fit the bill. To my gratification they worked out better than expected. Enough with the background, lets build one!

Parts

• 2 x Monoprice Surface Mount Box Cat5e Double
• 2 x Very small nuts and bolts (I used 1/4″ long, 7/64″ diameter bolts)
• 1 x ~12″ length of Cat5 cable

Tools

• Scissors or Snips
• Drill with bit the same diameter as bolts
• 110 Punch down tool
• Philips head screw driver

The Build

1. Remove the screw from the top of the wall mount boxes and set the tops aside.

2. Unscrew the circuit board from each box.

3. Hold the boxes back to back with the openings for the jacks facing in opposite directions. (I chose to make the boxes face away from each other, you can have them facing the same direction if you would like.) On each side, put the tip of a marker through the hole closest to the jack openings, making sure that it marks the back of the other box.

4. Use the drill to make a hole where you made the marks.

5. Secure the boxes together using the bolts and nuts.

6. Drill a hole through one of the blank areas to the left or right. This hole will be used to pass the receive and transmit wire pairs into the adjoining box, you may need to make it slightly larger than the previous holes.

7. Screw the circuit board back on to one side of the tap. Use one of the covers to give yourself a stable base.

8. Remove the casing from the length of Cat5 cable, don’t untwist the pairs. The wires will be punched down as follows:

9.Punch down the wires for the two passthrough ports according to the table above, wire numbers are marked on the circuit board. Try to untwist the pairs as little as possible while punching them down, otherwise interference may be introduced. Don’t trim or cut off one side of the green and orange pairs, these will be used to wire in the tap ports. I recommend punching down the green and orange pair last.

10. Double check that everything is wired properly, then unscrew the circuit board from the box. Feed the excess green and orange wires through the hole drilled earlier.

11. Screw the circuit board back on as well as the cover.

12. Turn the box over and screw in the other circuit board.

13. Punch down the orange and red pairs according to the table from step 8. The orange pair will transmit the data being sent from the switch, the green pairs will transmit the data sent from the host device. (This doesn’t apply if you are connecting the cables between two host devices.) I recommend that you keep track of which port is connected to which so you can label them when finshed.

14. Double check the wires are in the correct places and screw the cover on. Label each side as either passthrough or tap (the ports that are fully connected are the passthrough ports, the ports with only two wires connected are the tap ports), optionally you can also label the tap ports as switch or host as discussed in step 13.

You should now have a complete passive network tap! Connect it between a couple devices and try it out with Wireshark or your packet capture tool of choice. If you don’t see any packets check your cabling and the wiring inside the tap.

I hope that this article was helpful. Questions, feedback, and improvements are welcome in the comments. I’m also interested in how you intended to use your new tap.

Next time I’ll discuss how to combine two packet capture files (hint: mergecap) and show how *nix users can bond interfaces together so that merging the files is not necessary.

Disclaimer: I take no responsibility for any affect this tap has on your network. A properly wired and connected tap can’t affect the monitored devices, but an improperly wired tap could be devastating. Always test the tap in a non-production environment.