Disabling Broadcast Domains With PVLAN

Yep. I am a fan boy. Been following the Internet Storm Center Diary (ISC) almost daily for years now. Have learned a lot and have been inspired to look deeper into various things by the diary over the years. Big up them incident handlers @ ISC.

I am also a firm believer that the broadcast domain concept in Ethernet and Token Ring design (and in whatever other network technology that implements it) is a security vulnerability.

Gaining man-in-the-middle (MITM) position in an Ethernet broadcast domain is trivial task with Ettercap (and similar) and MITM is about as close as you can get to complete system compromise in the networks. MITM in an Ethernet broadcast domain allows complete compromise of all network traffic to/from a victim system, so any efforts to mitigate and complicate the MITM attacks are fully endorsed here.

Rob Van Den Brink pointed out an effective technique to disable the Ethernet broadcast domains in his ISC post yesterday.

Private Virtual Local Area Network (PVLAN) is a commonly implemented feature in switches. It isolates the access ports by blocking all traffic from one port to another unless it is specifically sent by the source to another system in the same PVLAN (using MAC destination in the Ethernet frame). Uplink is the term used in PVLAN talk for the mighty port forwarding traffic to/from other networks. Any PVLAN port/host can send traffic ONLY to the uplink port or to another specific port/host in the same PVLAN.

The feature seems to be supported by both bigs Cisco and Juniper, but apparently Cisco does not support PVLANs on the 1xxx or the 2xxx series. You have to go all the way up to Cisco Catalyst 3560 models to have the technology supported. As far as I can see all Juniper EX switches support PVLANs.

Ensure your datacenter or cloud provider and your network administrators have PVLAN correctly implemented (as suitable) on the switches. Especially, if you are operating in any Infrastructure-as-a-Service (IaaS) clouds shared by multiple clients. My testing possibilities are very limited (and virtual only), so I really would love to hear about any issues caused by PVLAN implementation in whatever type of testing environment. Quick testing on a workstation access switch in a small Windows 2003 Active Directory domain did not reveal any immediate problems.

Note that there have been attacks published against PVLANs, so the normal post-installation hardening routines are needed here as well. There was the @stake Security Assessment in 2002 on Cisco Catalyst switches mentioning the Layer 2 Proxy attacks against PVLANs and later in 2005 Arhont Ltd. detailed a MAC spoofing attack allowing PVLAN jumping. Check the SecuriTeam article for the details and the Cisco response to Arhont Ltd.

Cisco has published some excellent papers on VLAN security and Layer 2 attacks. I recommend the VLAN Security White Paper and the SAFE Layer 2 Security In-Depth (PDF) for further reading. Check also the Securing Networks with Private VLANs and VLAN Access Control Lists for correct implementation guidance.