I hate to bump a dead topic, but seeing as there's been no reply - I figured it would be nice to drop my 2c for future readers who may come across this thread.
So! Layer 2 attacks against any network device can take many forms. One could leverage the age-old ARP poisoning method to modify the CAM table of your layer-2 medium between your target and its gateway, flood CDP messages to the upstream device (as OP mentioned) in an effort to exhaust device resources, try to negotiate a trunk by sending DTP's, flooding traffic which hits the control plane of a device resulting in a DoS, and so on. It's a pretty expansive topic, but the good news is that most vendors have enabled software features to mitigate such attack vectors with relative ease. For the duration of this post, I will be using Cisco syntax to describe the steps to resolution. If there's any other attack methodologies or vectors anyone can think of that they would like addressed, feel free to post 'em.
So how does one devour an elephant... Bite by bite I suppose. So here goes. Feel free to skip down to the "mitigation" section if you are already familiar with DTP, VTP, Trunks, vlans (802.1Q ... no ISL here :3 ).
Sending DTP's to a switch to form a trunk for VLAN hopping, etc.Before we can dive into the specifics for defeating a DTP-based attack vector against a switch, we need to address the following:
- What is a trunk?
- What is a VLAN?
- What is VLAN pruning on a Trunk?
- How does DTP work?
- Cross-Protocol Dependencies (VTP)
What is a trunk?A Trunk is a layer-2 interface which passes multiple VLAN's across it. This is extremely handy when designing a network where you may want to push separate layer-2 broadcast domains through a set of switches, and only selectively allow hosts onto said network on a per-port basis. In simpler terms, you can have - for example - one port per building on an entirely separate management network, which is completely separate from all other systems, while still allowing direct layer-2 communication between end hosts. It's a pretty simple concept really, but in production they can be absolutely ridiculous to manage.
What is a Vlan?A Vlan (802.1q) is basically an encapsulated ethernet frame which informs the network how to properly handle the traffic being received / forwarded. If you're familiar with the layout of an Ethernet frame, then just picture an additional 32-bit header being inserted between the Source MAC and Ethertype sections of the frame. This 32-bit header contains something called a TPID and TCI - which is getting about as technical as I want to take this. Long and short here is that this 32-bit header informs a network device what VLAN ID said traffic belongs to, and as such determines what access said member has access to. The Vlan is a building block of sorts in network designs which allows for LAN segmentation, minimization of broadcast domains, and even some policy-based routing.
What is VLAN pruning on a Trunked interface?VLAN Pruning on a Trunk allows an administrator to selectively exclude Vlans from traversing a trunked interface. This of course improves security, and allows for tighter control of broadcast domains and network engineering. This is also pretty important when you consider the impact this has on the spanning-tree process when running either MST or some variant of PVST. I'm going to avoid getting too deep into spanning-tree in here given the fact that I've been typing for quite a while already, and am not even half way done T-T.
DTP - How does it work?Dynamic Trunking Protocol is one of those ideas that someone came up with that was pretty good in the beginning - but very quickly became a pain in the ass of anyone wanting to build a secure access layer. In short, it allows a device connected to a switch port to negotiate and form a trunk, thereby allowing said device access to ALL vlans that exist within that switch's VLAN database (and if it's running VTP, that's a lot).
So, DTP will only form a trunk with a device which has the same VTP domain configured... so that seems secure enough right? lolno...
In the packets that DTP will send out, the VTP domain will actually be right there! In clear text no less! So a would-be attacker could very easily respond to this DTP-enabled device with a forged packet indicating the same VTP domain - and BAM. You've got yourself a trunk.
Cross-Protocol Dependencies?As discussed previously, DTP does rely on VTP (the VLAN trunking protocol) in order to dynamically form a trunk with an adjacent device. VTP in short, is a protocol which facilitates the propagation of VLAN data (VLAN ID's, VLAN names) across a switched network. It will actually add the VLAN information to the local vlan database, and any non-pruned trunk ports will begin allowing said tagged traffic across the trunk. Additionally, VTP is in and of itself a huge vulnerability. I can't tell you how many networks I've seen get blown out due to a new switch being added to the network in the "VTP Server" mode - and proceeding to erase all VLAN databases across the layer-2 switched network. But, I can't complain too much. It guarantees me a job so long as customers don't RTFM.
So to recapitulate, (and stay with me here, this is going to be verbiage-dense): DTP relies on VTP domains to form dynamic trunks with devices adjacent to DTP-enabled ports. This allows said device to form a non-pruned 802.1q-enabled trunk allowing for tagged vlan traffic to originate from the end-device and potentially gain access to LAN segments that should otherwise be off-limits. In addition to this, the protocols that DTP relies on are inherently vulnerable - or just plain dangerous. VTP allows for VLAN's to be learned *and deleted* dynamically. DTP runs by default on all Cisco switch ports.
Scenarios wherein CDP or MAC tables are filled resulting in resource exhaustion:
As OP highlighted, there do exist scenarios in which a local attacker (or remote attacker who loaded malware onto a local system) could create a scenario resulting in a DoS. Flooding the CDP table - at least on today's equipment is not likely going to impact much of anything, as the majority of forwarding decisions are made in hardware - called TCAM. The CDP table does not exist in TCAM, and would only impact memory-centric applications, such as BGP, EEM, etc.
As for flooding the CAM table - this too is a viable attack vector that could do quite a bit of damage. BUT - it's pretty easy to solve at the same time.
Mitigation:This is kind of an interesting one to me. Off the top of my head, there are no real built-in ways to police CDP traffic. I can however think of two ways (aside from disabling CDP on access ports) that would work. NOTE: Cisco IP Phones rely on CDP to pull their voice vlan for their multi-access port, so disabling CDP isn't always a solution.
One could write an EEM applet to periodically check for CDP table changes over a certain threshold, and proceed to disable the port in question. In addition to this, you could blast out a syslog notification, or even send an email to the administrator ... all from your network device.
The other option that would be interesting to check out would be to implement CoPP to rate-limit CDP. I found the below config snippet in a Cisco IOS-XE 3.3 doc here on page 4:
http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst4500/15-1/XE_330SG/configuration/guide/config/cntl_pln.pdfSwitch# config terminal
Enter configuration commands, one per line. End with CNTL/Z.
Switch(config)#qos
Switch(config)#macro global apply system-cpp
Switch(config)#policy-map system-cpp-policy
Switch(config-pmap)#class system-cpp-cdp
Switch(config-pmap-c)#police 32000 1000 conform-action transmit exceed-action drop
Switch(config-pmap-c)#end
Switch#- CAM Table Flood and ARP Poisoning
To defeat the common CAM table flooding tactic, it is a simple task to configure access ports with something called sticky arp, or port-security. One could also turn in DAI (dynamic ARP inspection) which integrates into the DHCP snooping daemon to validate all IP/MAC bindings on the network by tracking every DHCP request / reply, and ensuring that every device adheres to this. One could also enable CoPP (control-plane policing) to ensure the device wouldn't be adversely affected by a sudden flood of traffic. This can be easily comprehended if you were to check out the MSFC on the Catalyst 6500 architecture.
6500 architecture:
http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-6500-series-switches/prod_white_paper0900aecd80673385.htmlARP options on ASR:
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_arp/configuration/xe-3s/asr1000/arp-xe-3s-asr1000-book/arp-config-arp.html#GUID-EE3D7DB6-AD44-4AD5-8F83-7B58CAE1974COld Cisco whitepaper on DAI w/ Ettercap:
http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-6500-series-switches/white_paper_c11_603839.html- "Securing" DTP, VTP, STP, CDP:
So, I use the term securing with Doctor Evil quotation fingers. Generally speaking, I like to just disable DTP, CDP and VTP altogether, as the only real benefit they offer is to try to automate the job of a network engineer - which sadly doesn't work as well as they intended.
Here is an example of one of my switchport configurations on one of my access switches:
core01.nj(config)#do show run int g3/12
Building configuration...
Current configuration : 188 bytes
!
interface GigabitEthernet3/12
switchport
switchport access vlan 200
switchport trunk encapsulation dot1q
switchport mode access
spanning-tree bpduguard enable
spanning-tree portfast edge
switchport nonegotiate **DTP
no cdp enable **CDP
core01.nj(config)#do show run | s vtp
vtp domain null
vtp mode off *note* mode transparent would work as well
What I did not list here were STP-related configurations. I'll leave that for another day. If you're interested and want to learn more however, check out features such as "bpduguard, rootguard, bpdufilter".
So, when it comes to protocol-level manipulation of a network, the only real exploitable scope would be the human stupidity that went into deploying and maintaining the network. The great news for me (job security) and you (schadenfreude) is that there's a whole lot of people, VAR's, etc that have no idea how these protocols inter-operate and function. Don't be one of those people :3
Nord
