The Leaky VLANs myth?

I have often encountered the myth that VLANs are insecure and should not be used. People who state this proceed to buy a separate switch for each LAN that they deploy. Great commission for the salesman, but bad for the business paying the premium for the extra tin!
A closer questioning of this reasoning exposes the myth that these people believe VLANs leak. My perception is that the root of this myth is a poor analysis done yonks ago and published on SANS, Intrusion Detection FAQ: Are there Vulnerabilities in VLAN Implementations? VLAN Security Test Report. This dated reports states as a recommendation: "Try not to use VLANs as a mechanism for enforcing security policy. They are great for segmenting networks, reducing broadcasts and collisions and so forth, but not as a security tool." This report is used as the basis of many flawed recommendations, see this thread. VLANs are a security tool but they are not an exclusive security tool!
VLANs are not an alternative to a firewall. Duh! VLANs are not an alternative to a router either. Duh! Firewalls (or routers) are not an alternative to VLANs. Duh! But not using VLANs, period, is short sighted and flawed. Not using VLANs is a larger risk than actually using them! Without using VLANS, it is not possible to implement a reasonably secure network design. Security is in the design and configuration, not the components! VLANs don't leak and I challenge any security bunnies out there, to provide documented proof of a successful exploit!

https://www.linkedin.com/pulse/my-top-10-posts-pulse-ronald-bartels/

Comments

  1. Hey Ronald

    I for one have never agreed with the approach to use separate physical switches. As you say VLAN’s are secure. Having said that I must however disagree in that there are VLAN attacks that can be executed with various degrees of success. According to my current understanding the main VLAN attacks are:
    • MAC Flooding Attack
    • 802.1Q and ISL Tagging Attack
    • Double-Encapsulated 802.1Q/Nested VLAN Attack
    • ARP Attacks
    • Private VLAN Attack
    • Multicast Brute Force Attack
    • Spanning-Tree Attack
    • Random Frame Stress Attack
    Only two of these I believe relate to VLAN Leakage or a better description would be VLAN Hopping (getting access on a L2 level to a VLAN different to the one to which the attacking host is currently assigned bypassing L3 controls). The relevant attacks are Double-Encapsulation and 802.1Q / ISL Tagging attack. Both of these can quite easily be exploited if you have physical access to the building. This brings me to I believe the actual problems relating to VLAN security. The two real problems are basic configuration of the switching environment and having proper physical controls in place. If these basics are done correctly then these attacks will not be successful which illuminates the problem as they cannot be done remotely to start with.

    ReplyDelete
  2. Great insight Wimpie. You correctly point out that there is no remote exploit possible and that a correct configuration is sufficient mitigation.
    I still remain unsure about the vulnerability itself which as you have described is real poor coding by the vendor which should be handled by a fault framework.
    Additionally, if a server has a http vulnerability, then the hole is already punched for the exploit. If it was possible to "VLAN hop," how would that make it any more or less vulnerable?
    BTW: Have you ever been able to "VLAN hop" yourself?

    ReplyDelete

Post a comment