Layer 2 Security - Private VLANs (the Story Continues ...)

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 ===============	Rob VandenBrink 521 Posts ISC Handler
Subscribe	May 12th 2010 9 years ago
Rob clearly points out: "their only traffic path is via layer 3, to other subnets or to other isolated ports in that PVLAN." 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	Erik van Straten 122 Posts
Quote	May 12th 2010 9 years ago
How is this different than having two different VLANs? One for each host or community, then make the uplink port send frames tagged with the IEEE 802.1q headers to the router?	Erik van Straten 7 Posts
Quote	May 13th 2010 9 years 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?)	Erik van Straten 17 Posts
Quote	May 13th 2010 9 years ago
Speaking of layer 2 security, it surprises me that it seems noone knows that ARP poisoning is more powerful, more reliable, and works 100% of the time (even when the ARP entry is not in the table), and is somewhat more stealthy when sending spoofed ARP requests, instead of classic replies. I recently posted about this: http://blog.zorinaq.com/?e=6 -mrb	Erik van Straten 2 Posts
Quote	May 13th 2010 9 years ago
Re ARP poisoning - we've discussed this in previous diaries, with both a video (stealing admin passwords from RDP) and protections at the switch level isc.sans.org/… isc.sans.org/…	Rob VandenBrink 521 Posts ISC Handler
Quote	May 13th 2010 9 years ago
Re Jeremy's different VLANs question - the hosts in a Private VLAN are all on the same subnet, and have the same default gateway. The protections are all at layer 2. This is especially attractive for ISPs and Cloud-type providers. Using PVLANs can really conserve a lot of public addresses when compared with assigning routed blocks to each customer.	Rob VandenBrink 521 Posts ISC Handler
Quote	May 13th 2010 9 years ago
Rob: http://isc.sans.org/diary.html?storyid=7567 contains an incomplete description of ARP poisoning. Dynamic ARP Inspection blocks not only replies, but also requests. Because even requests can poison the cache. You proved the point I made in my blog post that not many people know this	Rob VandenBrink 2 Posts
Quote	May 13th 2010 9 years ago
Good Catch - thanks for the correction ! 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 cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SXF/native/configuration/guide/… 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 521 Posts ISC Handler
Quote	May 13th 2010 9 years ago
Once technique I used in Snarp (a poison tool/relay, written 10 years ago for NT4) was not to use fake ARP requests or replies, but ICMP pings with fake ARP information. The targets happily updated their own MAC tables with the MAC addresses and IP addresses of the pings, thus poisoning the cache. This worked very well, especially on routers who could not be poisoned with ARP request/replies. Just focusing on ARP requests/replies is not enough when evaluating if a system is susceptible to poisoning.	Frank 24 Posts
Quote	May 15th 2010 9 years ago

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 ===============

Rob VandenBrink

521 Posts
ISC Handler

Rob clearly points out: "their only traffic path is via layer 3, to other subnets or to other isolated ports in that PVLAN."

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

Erik van Straten

122 Posts

How is this different than having two different VLANs? One for each host or community, then make the uplink port send frames tagged with the IEEE 802.1q headers to the router?

Erik van Straten
7 Posts

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?)

Erik van Straten
17 Posts

Speaking of layer 2 security, it surprises me that it seems noone knows that ARP poisoning is more powerful, more reliable, and works 100% of the time (even when the ARP entry is not in the table), and is somewhat more stealthy when sending spoofed ARP *requests*, instead of classic *replies*. I recently posted about this:

http://blog.zorinaq.com/?e=6

-mrb

Erik van Straten
2 Posts

Re ARP poisoning - we've discussed this in previous diaries, with both a video (stealing admin passwords from RDP) and protections at the switch level

isc.sans.org/…

isc.sans.org/…

Rob VandenBrink

521 Posts
ISC Handler

Re Jeremy's different VLANs question - the hosts in a Private VLAN are all on the same subnet, and have the same default gateway. The protections are all at layer 2. This is especially attractive for ISPs and Cloud-type providers. Using PVLANs can really conserve a lot of public addresses when compared with assigning routed blocks to each customer.

Rob VandenBrink

521 Posts
ISC Handler

Rob: http://isc.sans.org/diary.html?storyid=7567 contains an incomplete description of ARP poisoning. Dynamic ARP Inspection blocks not only replies, but also requests. Because even requests can poison the cache. You proved the point I made in my blog post that not many people know this :-)

Rob VandenBrink
2 Posts

Good Catch - thanks for the correction !

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
cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SXF/native/configuration/guide/…
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

521 Posts
ISC Handler

Once technique I used in Snarp (a poison tool/relay, written 10 years ago for NT4) was not to use fake ARP requests or replies, but ICMP pings with fake ARP information. The targets happily updated their own MAC tables with the MAC addresses and IP addresses of the pings, thus poisoning the cache. This worked very well, especially on routers who could not be poisoned with ARP request/replies. Just focusing on ARP requests/replies is not enough when evaluating if a system is susceptible to poisoning.

Frank

24 Posts