90

I have a network, where a have a couple of VLANS. There is a firewall between the 2 VLANs. I am using HP Procurve switches and have made sure that switch-to-switch links accept tagged frames only and that host ports don't accept tagged frames (They are not "VLAN Aware"). I've also made sure that the trunk ports don't have a native VLAN. I've also enabled "Ingress Filtering". Furthermore, I've made sure that host ports are only members of a single VLAN, which is the same as the PVID of the respective port. The only ports which are members of multiple VLANs are the trunk ports.

Can someone please explain to me why the above isn't secure? I believe I've addressed the double tagging issue..

Update: Both switches are Hp Procurve 1800-24G

This question was IT Security Question of the Week.
Read the Apr 20, 2012 blog entry for more details or submit your own Question of the Week.

Community
  • 1
jtnire
  • 1,001
  • 1
  • 8
  • 3
  • Im not a super uber switch/router guy, but some environments in my mind its not possible to hard code the port to a vlan. Especially with VOIP situations, where you have a pc daisy chained off of a cisco or shoretel phone. Or am I misunderstanding? –  Nov 13 '13 at 01:49

10 Answers10

74

VLAN:s are not inherently insecure. I'm writing this from a service provider perspective, where VLANs are the technology used in 99% (statistics made up on the spot) of cases to segment different customers from each other. Residential customers from each other, residential customers from enterprise leased lines, enterprise VPNs from each other, you name it.

The VLAN hopping attacks that exist all depend on a few factors;

  • The switch speaks some kind of trunk protocol to you, allowing you to "register" for a different VLAN. This should never, ever occur on a customer port, or someone should get fired.

  • The port is a tagged port, and the switch isn't protected against double tagged packets. This is only an issue if you have customers on VLAN-tagged ports, which you shouldn't. Even then, it's only an issue if you allow untagged packets on trunk ports between switches which, again, you shouldn't.

The "packets travel on the same wire" reasoning is valid, if the attacker has access to the physical wire in question. If that's the case, you have a lot bigger problems than what VLANs can solve.

So, by all means use VLANs as a security measure, but make sure that you never, ever speak VLAN tags with the entities you want segmented from each other, and do keep track of which switch features are enabled on ports facing such entities.

Jakob Borg
  • 1,326
  • 8
  • 9
  • 6
    Yep - describes it well. And to be fair, ISP's typically get this right. End user organisations have differing results - usually through lack of experience:-) – Rory Alsop Feb 24 '11 at 09:23
  • I wonder if this applies to the "GPON" style fibre optic to the home / FTTN installed in New Zealand recently. Usually we get a "Chorus" branded ONT installed in our homes. While this ONT is said to only operate on physical port 1, there are 3 othe r UTP ports unused. We need to use CPE routers capable of PPPoE and VLANs. I wonder if packets due for my next door neighbour are arriving and being dropped inside that ONT? Then what if I swap it out for a bad-guy ONT? – Tomachi Jan 10 '21 at 14:52
33

One reason why people discourage the use of VLANs for security is that there have been some attacks which allow for VLAN hopping, due to misconfigurations of the switches.

Cisco also have a good paper addressing some potential VLAN security concerns.

Essentially using VLANs for network segregation introduces more potential for a misconfiguration on the switches or bug in the software running them could allow for an attacker to bypass the segregation.

That said a lot of the issues with VLAN hopping and attacks on VTP are pretty old now, so it's possible that up to date switches would address them.

Gavin S. Yancey
  • 103
  • 4
Rory McCune
  • 60,923
  • 14
  • 136
  • 217
20

It is my opinion that VLAN hopping attacks are hugely overrated. This does not mean that you should not deploy very well understood operational procedures to reduce/eliminate the risks of this attack (i.e. do not never ever use in your access ports the same VLANID that you are using for the native VLAN on your 802.1q trunks. As a corollary, never use VLAN 1). What I'm trying to say is that from the perspective of someone who wants to attack you, there are others layer two (L2) techniques that are far more reliable and with far more impact than a VLAN hopping attack.

Attacks to the ARP protocol for example are extremely simple to deploy and if your switches do not offer any kind of protection against it, the attacker can cause great damage. If your VLAN is small then your exposure is huge, if your VLAN is big, then your exposure is mega-super-huge (I have customers whose whole corporate network is a huge VLAN, but that´s another issue).

Then you have attacks to the stability of your LAN through the use and abuse of the Spanning Tree Protocol (yersinia is the de-facto tool for this). Also extremely easy to deploy and with a great impact to your infrastructure.

If your "standard" hacker cannot exploit ARP or Spanning Tree or DHCP it is my experience that he will "move to"/focus-in other parts of your infrastructure (DBs, Web, DNSs) before trying to successfully exploit VLAN hopping.

If layer 2 security is your kind of flavor, I cannot sufficiently recommend you read the "LAN Switch Security" book from Cisco Press.

Mark Davidson
  • 9,367
  • 6
  • 43
  • 61
jliendo
  • 361
  • 1
  • 4
10

The major lack of security is down to the fact that although you are segregating from a logical perspective, you are actually running the networks across the same wires, so from the perspective of an attacker on one VLAN it is typically not much work to access the other VLAN.

This is why if, during a security audit, I find a management VLAN for routers running across the same network as userland VLAN it raises a big red flag.

The main reason organisations use VLANs is that it is cheap as only one physical network needs to be implemented.

Physical segregation is the simplest solution, but does require more NICs, more wires etc.

Encryption (essentially turning the VLAN into a VPN) can also work, and isn't rocket science.

Rory Alsop
  • 61,367
  • 12
  • 115
  • 320
  • 28
    Encryption _has_ some relationship to rocket science, especially the part where it blows up in a very spectacular way when you slap it together with not enough care and understanding. – Thomas Pornin Jan 10 '11 at 14:32
  • 1
    :-) nice. Of course what I meant was that in this context, creating a VPN would be simple (as I was expecting the OP to use encryption functionality present in typical network devices, not to write the encryption code themself) – Rory Alsop Jan 10 '11 at 14:45
  • If you by "typically not much work" mean "typically impossible in a properly configured switch", then yes. Otherwise, no. – Jakob Borg Feb 24 '11 at 08:11
  • @JakobBorg - you'd hope wouldn't you. Actually you are mostly right - unfortunately misconfiguration is very common! – Rory Alsop Feb 24 '11 at 08:59
  • 2
    No doubt. :) Nevertheless, I never really liked the "VLANs shouldn't be used for security purposes" mentality, because they are used successfully for exactly that purpose every day by every ISP in the world. I made it an answer instead, because it doesn't fit in the comment field. :) – Jakob Borg Feb 24 '11 at 09:12
  • What do you mean by "userland"? – curiousguy Jun 27 '12 at 13:15
  • I used userland to refer to the network users will connect to, as opposed to the management, reporting or other networks – Rory Alsop Jun 27 '12 at 13:17
  • @RoryAlsop - What do you mean by "from the perspective of an attacker on one VLAN it is typically not much work to access the other VLAN"? Under what scenarios is this possible? Is this assuming misconfiguration of a switch or router? If yes, what are examples of misconfigurations that can lend themselves to these types of attacks? – Motivated Jan 30 '19 at 16:17
5

The other answers are great. However, I think there are some circumstances where you don't want to risk mixing potentially malicious clients with trusted ones. A great example is the entertainment network of a vehicle (car, airplane, etc) vs. the systems control network. On an airplane, you really shouldn't take the risk that some random passenger manages to exploit the switch or router, giving them access to systems control. Similarly, there shouldn't be much need for your CD player to talk to your brakes in an automobile.

And when I talk about an exploit, I don't really mean VLAN hopping attacks. I mean exploiting a vulnerability that results in arbitrary code execution on the switch or router itself. It would be naive to think such things could never happen.

silly hacker
  • 51
  • 1
  • 1
3

I think you did quite well configuring your switches, because you understand what the attack vectors are. But people often tend to not understand this and that is what generates a risk - misconfiguration, intended or not.

There is no reason to say "never ever use VLANs for this", because you can configure your switches correctly. However, VLANs were not invented with security in mind, and so the configuration has to be done carefully, and you have to consider all potential attack vectors when reviewing your configuration. After all you can do it correct, but it is error-prone (i.e. you accept a little risk).

When you plan to separate networks with a huge difference of requirements in confidentially, integrity or availability you might find that the cost of losing one of these properties in your "golden" network outweighs the risk you have to accept when using VLANs for separation. This is usually the situation where I recommend to use separate physical devices instead of VLANs.

You can say that there are good reasons to use VLANs for segmentation, especially the cost-benefit ratio. But in some cases, when you calculate with risks and asset values you may find that the equation tends to speak for physical separation, which is usually less error-prone but more expensive.

fr00tyl00p
  • 2,329
  • 1
  • 15
  • 17
  • Very well put. I think the part about situations where there is a great disparity between the security requirements of two (or more) networks is particularly important. Using VLANs to achieve compartmentalization of parts of general-purpose network environments can make a huge difference vs. not doing so. (So that if an attacker breaches one machine he/she doesn't have access to the whole company/org) But using VLANs alone is often not going to be adequate for segmenting off high-security network portions from everything else; you'll need physical separation (preferable) or VPNs. – mostlyinformed Jun 11 '16 at 23:05
2

The simple answer is that VLAN's are designed to segregate traffic (more from a management and data flow perspective than security), they don't exist to secure any of the individual traffic streams (there's no encryption involved), so security assessors won't be happy if your security model is based solely around VLAN segregation.

ukcommando
  • 21
  • 1
1

As far as I know and understand the principle of VLANs there is no security risk by the protocol / device itself. By that I mean that VLAN are meant to segregate Layer2 unicast domains thus no, if properly configured VLAN_A and VLAN_B should not be able to talk to each other.

All things being equal if you put user on a trunk there is no reason they should not be able to talk to all VLANs ... (because thats how it's supposed to be) this in turn can be a misconfiguration are a desired configuration.

Now if a hacker has access to the physical hardware they also have access to software and then can gain access to ANY devices on that network.

This is why most large networks use VLANs to segregate networks and by that I mean banks, ISPs, the works... in PCI compliance VLANs are accepted as a segregation measure (that’s how the pinpad is separated from the cash registers and so on). Now that said like was said above the risk is always in the configuration and that is thru both for the configuration of the access ports and for the firewall, ACL and other configuration point. most of the switching is done in dedicated CPUs (ASICs) and thus will implement the VLAN segregation at a hardware level (even if its just a programmable chip) otherwise you would not be able to attain the rates you do with switches.

techraf
  • 9,141
  • 11
  • 44
  • 62
bob
  • 11
  • 1
1

Read into PVLANS (private VLANs). They provide true layer2 segregation and will prevent ARP spoofing attacks.

They can do more than this but this is the simplest configuration. Let's say you have ports 1,2,and 3 all on vlan 1. Port 3 is the default gateway, 1 and 2 are hosts. With PVLANs 1 can talk to 3 and 2 can talk to 3, but 1 can not talk to 2. If this works for you I suggest it.

Hardcode your access ports to a specific vlan to prevent hopping.

user974896
  • 317
  • 4
  • 9
0

I think I'm missing some details from your example -

Is each switch on a separate VLAN separated by a firewall or do the switches contain multiple VLAN's?

If each switch has a single VLAN and all traffic is routed through the firewall then you should be fine from a security standpoint, assuming the rulebase on the FW is right. In other words, you wouldn't be able to hop VLAN's without passing through the FW and the FW should be configured to block that traffic. IE - Switch 1 should only have VLAN 1 traffic so the FW will drop any VLAN 2 traffic coming from Switch 1.

user1490
  • 21
  • 1