Layer 2 Security - Private VLANs (the Story Continues ...)
Rob, you say - it's been a little while since we talked about Layer 2 Security (almost a week) - does that mean that we're done?
Not a chance - we haven't talked about Private VLANs yet!
A VLAN is often defined as a "broadcast domain", and in most cases is co-incides with an IP subnet. Private VLANs (also called PVLANs) are the exception to this, a Private VLAN is still usually a single IP subnet, but the "broadcast domain" definition no longer holds true.
In a private VLAN, you start by defining an "uplink" port (also called a "promiscuous" port). This is normally the port (or link aggregation group) that is attached to the uplink router(s), firewall(s), provider network or server(s). After that is set, you define "isolated" ports. Any frame received on a isolated port is forwarded only out the uplink port, no matter what destination MAC or IP address it might have. This includes ARP traffic or any broadcast traffic. Frames received on the promiscuous port are then forwarded in the usual way - ARPs, Broadcasts and all other layer 2 frames work as you would expect them to.
So what this means is that isolated ports in a Private VLAN cannot "speak" to each other at all - their only traffic path is via layer 3, to other subnets or to other isolated ports in that PVLAN.
The concept of private ports can be expanded to include larger port groups - this concept is called "community" ports. Community ports can speak to each other via layer 2 just like a regular vlan, but are separated from ports in other communities, and from isolated ports.
Typical applications for private VLANs might be in a Colocation Facility or public or private IaaS network (Infrastructure as a Service Cloud), where you might have several customers using the same subnet, but communications between the customers is not desirable as it would circumvent their firewalls. This might also be used on a DMZ, where you might want to restrict communications between DMZ hosts, but it's not worth the effort or cost of creating a separate DMZ for each host. Another common use for Private VLANs might be in a hotel situation, where each hotel room has internet access, all are on the same subnet, but communications between the rooms is not desired (for obvious reasons.)
This diary touches on only the most basic concepts of Private VLANs - I won't get into the specifics of the configuration, as they vary quite a bit between various vendors' gear. Also be aware that this covers only the most basic of PVLAN concepts - there's enough material in this for a good few hundred pages, if you were writing a book on Layer 2/3 Switching and Security for instance
As always, if there are any errors in this diary, or if you'd like to comment with other examples of how you've seen PVLANs used, feel free to use the "comment" link.
=============== Rob VandenBrink Metafore ===============
Comments
He's correct, but beware not to overlook the last part of that sentence; you may end up with the two hosts in the topmost picture unexpectedly communicating with each other (via layer 3). This is what Cisco calls a "Private VLAN Attack" in http://www.cisco.com/en/US/products/hw/switches/ps708/products_white_paper09186a008013159f.shtml#wp39271
More detailed Cisco info w.r.t. PVLAN's can for example be found here: http://www.cisco.com/en/US/products/hw/switches/ps700/products_tech_note09186a008013565f.shtml
Bitwiper
May 12th 2010
1 decade ago
Jeremy
May 13th 2010
1 decade ago
Rob,
Thanks for the post, I find it stunningly clear and well depicted.
(Haven't seen graphics in a post before, is this a new feature?)
Prontissimo
May 13th 2010
1 decade ago
http://blog.zorinaq.com/?e=6
-mrb
mrb
May 13th 2010
1 decade ago
http://isc.sans.org/diary.html?storyid=7567
http://isc.sans.org/diary.html?storyid=7303
Rob Vandenbrink
May 13th 2010
1 decade ago
Rob VandenBrink
May 13th 2010
1 decade ago
mrb
May 13th 2010
1 decade ago
These diaries on Layer 2 Sec are meant more to engage readers in discussion and raise awareness of network security features that folks might not be using but might find useful, not to substitute for complete documentation.
The interception of ARP requests as well as replies when DAI is configured is well documented, usually right near the top of most vendor's docs on the subject. Cisco's explanation at
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SXF/native/configuration/guide/dynarp.html
for instance has verbage describing that both requests and replies are intercepted.
That being said, however, after re-reading my diary, I see that i called out "arp responses" specifically - I'll update it tomorrow to a more generic "ARP packets"
Thanks again !
Rob VandenBrink
May 13th 2010
1 decade ago
Frank
May 15th 2010
1 decade ago