So Rob, you say, aren’t we done talking about protecting switches and the like at Layer 2 yet?  We talked about Man in the Middle Attacks in October, and Layer 2 remediation against Man in the Middle Attacks in November, that should cover it, right?

The short answer is “no” – we haven’t talked about Broadcast control or MAC address flooding yet !

Broadcasts are part of everyday life on most networks – they’re necessary for most networks to operation.  ARP and DHCP are both a great examples of protocols that use broadcasts for different reasons.    However, the problem with broadcasts is that they are received by every station on the subnet, each station has to actually read at least the packet header to then determine that the packet is or isn’t for them, then discard it if it’s not theirs.  This takes up a very small but measurable amount of CPU. It's this CPU useage that gives broadcasts their bad name.

So what level of broadcast traffic on a network is “reasonable”?  A Cisco paper that I often refer to (http://www.cisco.com/en/US/docs/internetworking/design/guide/nd20e.html ) indicates that at 1,000 broadcasts per second, you can expect to lose on average roughly 1% CPU per host.  Now considering the age of this document (it references 25MHz 386 processors), you can see that we can probably go much higher than that these days.  But at 1,000 broadcasts per second, you've probably either got a very (very) large subnet, or some other problem that should be addressed !

So, when can you see broadcast floods?  In most cases, seeing more than 2-3 broadcasts per minute from any one host would be high.  But you absolutely will see higher rates – for instance, as a workstation logs in, it will send DHCP requests for an IP address, then ARP requests for it’s DNS server, gateway, Domain Controller (if it’s a windows host), as well it will also ARP for the IP address of each host it has a resource (or share) on.  This can really add up ! 

We can see higher broadcast levels when a station is running a recon tool.  For instance, initiating an nmap scan on a local subnet initiates a broadcast flood (one ARP request per ip address in the subnet range).

I’ve seen broadcast floods during testing of new network gear as well, usually by engineer-types.  For instance, in one case we saw engineers developing new ip cameras generate enough broadcasts per second that it overflowed the capture buffer in wireshark on my laptop.  For political reasons we couldn’t move them (or their tests) off the production, so we changed their VLAN and implemented broadcast control (see below) to limit their impact on the production networks.

If you run "real" video servers on your network, you'll likely see higher levels of broadcast (or more likely multicast) traffic originating from them.  You'll need to consider the switch ports for these servers in detail if you are configuring broadcast control on your switches.

MAC Address flooding is different than broadcast flooding - a MAC address flood occurs when a station sends traffic from several different MAC addresses (stations generally only have 1 MAC address each).  Virtual switches on platforms like VMware, XEN or Hyper-V will source traffic from multiple MAC addresses (their own, plus one per virtual machine),and clusters and load balancers will also "play games" with MAC addresses.  But aside from these,  you won’t normally see single hosts with multiple MACs in real life, it’s generally a malicious thing.    What you will see in real life though is unmanaged switches under people's desk, with 3-4 PCs each plugged into them.   Or classrooms with unmanaged switches, hosting 24 or more PCs.  (you see the pattern here)

Tools like macof (part of dug song’s most excellent dsniff suite) can be used to generate mac address floods. The purpose of MAC Address floods is to overflow the MAC Address table (or CAM table, depending on your switch vendor and model).  The MAC Address table relates mac addresses to switch ports, and since this table is stored in memory on the switch, it will have a fixed maximum size.  What happens on a switch when the mac address table is full will vary.  Once the CAM table is full, all existing mac entries behave as before, but new MAC addresses are "new", so requests for them are flooded to all ports as part of the normal learning process.  So under a sustained attack, a MAC address flood will essentially turn your expensive switch into a cheap hub, and all traffic will be visible to your attacker.  Since macof can generate in excess of 15,000 MACs per second, it's not a tough attack to carry out.  In older or less robust switches, the switch may crash, so if you are experimenting with these tools, it's best to do it on a test network.

REMEDIATION:

Remediation against broadcast floods is simple.  At a macro level, an alternative definition for a VLAN is “broadcast domain”.  Since broadcasts are a layer 2 phenomena (aside from helper addresses and directed broadcasts), VLANs are a good way to limit the scope of broadcasts.  So if you have devices that generate higher levels of broadcast traffic, you can put them in their own VLAN to at least contain the offending traffic.

Broadcasts are commonly controlled at the port level with “storm control” commands.  These commands generally limit broadcast traffic to a configured number of packets per second.  On some switches, the limit is on a percentage of interface bandwidth metric, so “0” blocks all broadcasts, and 100 imposes no limits at all. Multicast and true broadcast packets can usually be limited separately.

Remediation against MAC address floods is also very easy.  “Port security” commands restrict how many MAC addresses can appear on a single Ethernet port.  Similar to broadcast control, you can set the level of how many MAC addresses are permitted on each port, and also you can configure what happens when you exceed the limit.

A violation of either port security or broadcast storm control settings will by default place the offending Ethernet port in an “errdisable” state.  Again, by default, the port will stay in that state, unusable, until you reset it.  You can set  a timer and recovery options on a port with the “errdisable recovery” commands.  Recovery options can usually be set separately for each error type.  So you might allow automatic recovery from a broadcast storm after 30 seconds, but force manual intervention to recover from a MAC address flood.

Again, note that anyone with a cheap switch or hub under their desk, with 2-3 PCs attached to it can easily trigger port security, shutting down the entire uplink for their whole switch.  We’ve also seen classrooms with unmanaged 24 or 48 port switches in this situation.  You’ll want to either eradicate hubs and switches like these, or at least identify where they are and set your metric high enough on those ports so that you don’t shut down their uplinks. 

Before you implement these remediations - do your homework !!  Both of these commands will disable ports when triggered, so read your vendor documentation and know your network before you go live!  If you are in doubt, having violations trigger alerts rather than disable ports is usually a safer approach, at least until you know where you have problems you need to fix, and where you need to grant exceptions to the rules.