CEH - Sniffing on VLANs
-
I knew you could sniff on switch-based networks before working on my CEH cert. I always like to put it as basically Ethernet just grew up (after hubs); you have to do it a little differently. I knew about flooding tables on switches, but my questions are: How do VLANs come into play with this attack? Many (most?) switches also have VLAN features built into them. Does flooding tables cause VLANs to be ignored (assuming a switch fails to open instead of closed) as well? Or are VLANs still active even though the switch is set to open (In order words, you'll see the traffic in your vlan but not across all workstations that would be in other VLANs on the same switch)? If VLANs ARE still active, is there a type of attack that can be used or a perfectly legitimate override mechanism that can be retooled for the purposes of shutting down the VLAN feature so you can then see all the traffic on the switch?
-
With VLANs, the same risks would be applicable regarding your own native VLAN as it would be on a non-VLAN (e.g. non-managed switch) environment. You could look at it like a bunch of virtual switches inside of one, or multiple, physical switches. However, the inherent security benefits of utilizing VLANs to segregate traffic have their own security concerns, which is what I assume you are asking about.
Each VLAN should have it's own MAC table, so flooding one should not directly impact the other(s). With that said, it comes down to the implementation (good or bad) of the switch vendor. But the general rule is that what happens on one VLAN stays on one VLAN. Assuming the network is designed correctly, local traffic should not cross VLANs unless going through some network intermediary device (e.g. a router).
If you are able to connect to a trunk port, or are able to fool the switch into thinking you are a legitimate switch and can dynamically enable trunking, then you have a pretty large attack surface as you can then receive all broadcast traffic across all (or some, depending on configuration) of the VLANs. This is why it's important for a network admin to make sure dynamic trunking is disabled on all, especially access, ports. Don does a good job of explaining this in the Cisco videos.
But even on an access port, there are some attacks that could get you to circumvent the VLAN you are a member of. I've never personally seen this done in practice, but my understanding is that if you can craft packets in a way that corrupts the VLAN tagging being done, you can get your traffic to drop to the native VLAN for the trunking between switches. This is why it's best practice to set this to some unused blackhole network and put all of your important traffic (including device management) on to it's own separate, and trunked, VLAN.
Of course there are other ways a network admin can help mitigate risks on people connecting to access ports.
-
Yeah, that's kind've what I was thinking -- that other VLANs would not be affected. I didn't realize each VLAN actually had their own tables. I always kind've thought the VLAN stuff rode sort've ontop of Layer 2 but out-of-band of the OSI model. Sort've like it's own thing. Unfortunately (or fortunately depending on how you look at it) it makes the pentester's life a bit harder. I guess if you're dealing with VLANs, at that point you'd be looking at other infiltration methods, USB keys, phishing, social engineering, etc. Which to me always seems like cheating. But I guess demonstrating even a human vulnerability is still demonstrating vulnerability.
-
It's not a guarantee, and depends on the switch, but according to Cisco:
http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6000-series-switches/23563-143.html
"Note that most modern switches including the Catalyst 2900 XL, 3500 XL, 2940, 2950, 2970, 3550, 3750, 4500/4000, 5000, and 6500/6000 series switches maintain L2 forwarding tables per VLAN."It may occupy the same place in memory and share the same overall caps, but even if all the resources are exhausted, the switch should never allow cross-VLAN traffic as a result of an attack. Even if the CAM table is full, the VLAN assignment is still present.
-
Hmm... Reading through that article, it doesn't actually say one or or the way what it does with the VLANs, it just basically says, on newer devices (7.5+) there's protection on by default (unicast flood protection), and you can have multiple different events occur, such as shutting down the VLAN, limit the VLAN, In fact it even references preventing a table from being filled as it's -BAD- when a table gets filled (which it is) but it implys they don't have a solution in place for when that happends and instead focus their efforts on preventing it from happening (things like limiting any new MAC address entries until a table has freed up more slots). I'm going to mark this as solved, because ultimately I think you're probably right; I don't think VLAN traffic will go across to other VLANs. Interesting stuff though. Thanks!
-
All a VLAN is is a Layer 2 Tag. You have an Ethernet frame that get's forwarded to a port, that port has a list of VLANs allowed on it .
Simply put if the traffic doesn't match the VLAN allowed on that port it will not get forwarded to that port period. The only attack that I know of that will allow you to bypass this behavior is VLAN hopping using double tagging or taking advantage of switch mis-configurations
VLAN hopping can be avoided by simply following best practice procedures when designing a network. The Native VLAN has to be one that is not used for anything and is not VLAN1 (also don't use VLAN 1) . All trunk ports should prune VLAN1 and the native VLAN (there is no reason to carry traffic on those 2 VLANs anywhere). And set all ports that don't need trunking to access ports.
With Double tagging it's a bit more complicated. I can add 2 tags to an Ethernet Frame. When the first tag is verified my Frame will be forwarded and the first tag will be stripped. then when my Frame needs to be Forwarded a seconded time (let's say the port I am trying to access is on another physical switch and I have to cross a trunk link to get to it or the switch needs to preform a recursive search in the MAC table ) when my frame is checked again the second tag will be seen and the switch will put it on the VLAN of my choosing.
This double tagging I think would be a problem on older hardware since it seems like the only way to protect against this would be to make the switch aware that this is an attack vector and actively search for double tags.