How secure is a VLAN?

[Ben_Stanton]

Here is the proposed plan;

 

2 seperate ADSL lines load balanced with fail over (we are in the sticks and only get a sketchy 1.4ishMb line).

 

VLAN1: Student laptops using wireless, possible virus/security threat

VLAN2: Domain

VLAN3: MOSS

 

Now, I don't want to get into a flaming war on these laptops. They will not join the domain. They are simply using the wireless for internet access and to use sharepoint. If VLAN1 is granted access to VLAN3 - can I be 100% certain that there will be no chance of it seeing VLAN2?

 

If it is not 100% secure, I do have another alternative although not my first choice.

 

Cheers

[Geoff]

They are simply using the wireless for internet access and to use sharepoint. If VLAN1 is granted access to VLAN3 - can I be 100% certain that there will be no chance of it seeing VLAN2?

 

There are six techniques for breaking VLANS. They are:

 

Frame tagging - Adding frame encapsulation or double encapsulation to packets to confuse the switch into thinking the frames belong on another VLAN.

 

DoS flood attacks - Attempting to flood MAC addresses in a switch, causing it to incorrectly forward packets. A similar attack is to flood the switch with random sets of packets, causing it to leak packets across VLANs.

 

MAC spoofing - Forging MAC addresses to make the switch believe you should be on a different VLAN, thus letting you go around a firewall.

 

Multicast flooding - Sending many multicast frames to cause the switch to incorrectly forward packets, perhaps as a DoS attack, an eavesdropping attack or a firewall work-around.

 

STP exploits - Inserting 802.1d spanning tree protocol frames to make the switch reconfigure topology and incorrectly forward frames. In extreme cases, this attack could cause the network to route all traffic through the affected switch, which would give the attacker the ability to eavesdrop on all network traffic.

 

ARP spoofing attacks - Sending spoofed ARP entries for real devices to cause the switch to forward packets across VLANs.

 

If it is not 100% secure, I do have another alternative although not my first choice.

 

You can fix things with hardware. Basically air gap your separate networks.

Or you can use a software solution. Packetfence is a NAC solution that immediately springs to mind. It's designed precisely for this sort of situation.

[tom_newton]

It's not 100% secure, but nothing is.

Theoretically, you're right, but practically, unless there's no electrical connection you can never be 100%. It depends on how much of an issue it would be if vlan1 saw vlan2, and what other security measures are in place.

[Ben_Stanton]

OK, but given this is an all girls college with only 220 students - do you still feel it a risk? Or are you suggesting that there are common virus' out there that can do the above?

 

The domain has no wireless, all hard cabled.

 

My second alternative was either access control or not load balancing and having two seperate lines and keeping the completely seperate. But then I lose the increase in bandwidth and resiliance.

[Geoff]

You can harden your VLANs to improve the security situation. Consider implementing the following:

 

• Use new switches - Switches produced within the last few years have been tested thoroughly for problems with their VLAN implementations.
   
  
• Separate the data from the management access - create a separate management VLAN and use only that VLAN for management. Switches shouldn't have IP addresses on any other VLAN.
   
  
• Use switch features to enforce restricted control access - Even if you create a separate management network, you will want to use other switch features to make sure the control access is thoroughly isolated. For example, most switches allow for basic ACLs that can be used to limit the IP addresses available for management. It's essential to make sure that you to use these ACLs to only allow management traffic from specific management station IP addresses, even if you are sure that only those management stations can be routed to that VLAN. Since your switches themselves now become suspect, they shouldn't be considered trusted devices.
   
  
• Limit and control traffic - Many switches have the ability to block broad types of traffic. If your goal, for example, is to enable IP connectivity, then you want to use an ACL to allow IP and ARP Ethernet protocols only, blocking all other types.
   
  
• Restrict cross-port traffic - When a group of systems are placed into a single security zone, the mere presence of connectivity offers the opportunity for attack. Several switch vendors offer the option to mark ports within a VLAN as "private," meaning that, although they can communicate off-switch, they can't communicate with each other. Also, it's highly unlikely that users on a wireless network will want to send packets to each other, so blocking traffic between wireless access points can increase security without impacting use of the WLAN.
   
  
• Disable unused features and ports - Most switches are willing to talk to internal control protocols, such as spanning trees, on any port. If you use ACLs to block such traffic, you should disable these protocols on any port where they are not explicitly needed. At the same time, any port that isn't in use should be shut down or placed in an unused VLAN.
   
  
• Document your physical layer - When secure and untrusted traffic coexist on the same switch, a security problem is simply a mispatched cable away. Extensive physical-layer documentation and standardization is critical to avoid errors that can compromise your security. For instance, you can use color-coded patch cables to indicate different VLANs, and color-code switch ports using plastic tape. While having good documentation won't prevent errors, even the most careless technician will think twice about plugging a green patch cable into a red switch port

[Ben_Stanton]

Wow, you type quick

 

Thanks Geoff, I'll weight up pro's and con's