How can I set up VLANs in a way that won't put me at risk for VLAN hopping?

We're planning to migrate our production network from a VLAN-less configuration to a tagged VLAN (802.1q) configuration. This diagram summarizes the planned configuration:

One significant detail is that a large portion of these hosts will actually be VMs on a single bare-metal machine. In fact, the only physical machines will be DB01, DB02, the firewalls and the switches. All other machines will be virtualized on a single host.

One concern that has been is that this approach is complicated (overcomplicated implied), and that the VLANs are only providing an illusion of security, because "VLAN hopping is easy".

Is this a valid concern, given that multiple VLANs will be used for a single physical switch port due to virtualization? How would I setup my VLANs appropriately to prevent this risk?

Also, I've heard that VMWare ESX has something called "virtual switches". Is this unique to the VMWare hypervisor? If not, is it available with KVM (my planned hypervisor of choice)?. How does that come into play?

Solution 1:

In addition to the info on Why do people tell me not to use VLANs for security? here are some more specific & general bits to consider:

General Thoughts on Security
The most secure system is one where each subnet's hosts are connected to a switch having exactly the number of ports that will be used by connected devices. In such a configuration you can't plug random machines into your secure networks, since doing so would require unplugging something (and theoretically your monitoring system would notice that).

VLANs give you something similar in terms of security, breaking your switch up into smaller virtual switches (virtual LANs: VLANs) that are isolated from each other logically, and with proper configuration can appear to all the systems connected to them as if they were physically isolated.

General Thoughts on relatively-secure VLAN Setups
My practice for VLAN-capable switches is that all traffic must be assigned to a VLAN, with the following basic configuration:

Assign all unused ports to an "unused" VLAN.

All ports connecting to a specific computer should be assigned natively to the VLAN that computer should be in. These ports should be in one and only one VLAN (barring certain exceptions that we'll ignore for now).
On these ports all incoming packets (to the switch) are tagged with the native VLAN, and outgoing packets (from the switch) will (a) only originate from the assigned vlan, and (b) be untagged and appear just like any regular ethernet packet.

The only ports that should be "VLAN trunks" (ports in more than one VLAN) are trunk ports -- those carrying traffic between switches, or connecting to a firewall that will split up the VLAN traffic on its own.
On the trunk ports the vlan tags coming in to the switch will be respected, and vlan tags will not be stripped from packets leaving the switch.

The configuration described above means that the only place you can easily inject "VLAN hopping" traffic is on a trunk port (barring a software problem in your switches' VLAN implementation), and much like in the "most secure" scenario this means unplugging something important and causing a monitoring alarm. Similarly if you unplug a host to connect to the VLAN it lives in your monitoring system should notice that host's mysterious disappearance and alert you.
In both of these cases we're talking about an attack involving physical access to the servers -- While it may not be completely impossible to break VLAN isolation it is at a minimum very difficult in an environment set up as described above.

Specific Thoughts on VMWare and VLAN Security

VMWare Virtual Switches can be assigned to a VLAN -- When these virtual switches are connected to a physical interface on the VMWare host any traffic emitted will have the appropriate VLAN Tag.
Your VMWare machine's physical interface would need to be connected to a VLAN trunk port (carrying the VLANs that it will need access to).

In cases like this it is doubly important to pay attention to VMWare Best Practices for separating the Management NIC from the Virtual Machine NIC: Your Management NIC should be connected to a native port in an appropriate VLAN, and your Virtual Machine NIC should connect to a trunk that has the VLANs the virtual machines need (which ideally shouldn't carry the VMWare Management VLAN).

In practice enforcing that separation, in concert with the items I mentioned and what I'm sure others will come up with, will yield a reasonably secure environment.

Solution 2:

VLan hopping is easy if and only if rogue devices are allowed to trasmit packets on trunks without vlan tags.

This is most common in the following situation. Your 'normal' traffic is not tagged; you have a 'secure' vlan that is tagged. Since machines on the 'normal' network can transmit packets which are not tag-inspected (most commonly they would be by the access switches) the packet could have a false vlan tag, and thus hop on the vlan.

The easy way to prevent this: all traffic gets tagged by access switches (firewalls/routers may be an exception, depending on how your network is configured). If the 'normal' traffic get tagged by the access switch, then any tag the rogue client forges will get dropped by the access switch (because that port wouldn't have access to the tag).

In short, if you use vlan tagging, then everything must be tagged in the trunks to keep it secure.