VLAN Security Tips - Best Practices

This article focuses on VLAN Security and its implementation within the business network environment. We provide tips and Cisco CLI commands that will help you upgrade your VLAN network security.

Even though many Administrators and IT Managers are aware of VLAN technologies and concepts, unfortunately, it has been proven that the same does not apply when it comes to VLAN Security. While this section mainly focuses on security implemented on Cisco switches, many of the concepts can be applied on other vendor switches.

The first principle in securing a VLAN network is physical security. If you do not want your devices to be tampered with, physical access to the device must be strictly controlled.  Core switches are usually safely located in a datacenter with restricted access, however edge switches are not that lucky and are usually placed in areas where they are left exposed.

Just as physical security guidelines require equipment to be in a controlled space, VLAN-based security requires the usage of special tools and following a few ‘best security practices’ to give the desired result.

Let’s take a look at a few important steps an Administrator or IT Manager can take, to strip their network from the security problems most networks suffer today:

Removal of Console-port Cables, Introduction of Password-Protected Console/Vty Access with Specified Timeouts and Restricted Access.  

Console ports on the back side of Cisco switches provide direct access to the system. If no care is taken to secure this access method, then the switch might remain fully exposed to anyone with the popular ‘blue console cable’. Configuration of complex user credentials on the console and telnet/ssh ports will ensure any unwanted visitor will remain in the dark when trying to access the device.  Using special commands such as the ‘exec-timeout’ commands,  when the Administrator accidently forgets to logout of the session, it will automatically timeout after the programmed timeout value.

Following is a set of commands that will help you accomplish the above measures to help restrict access to the swich:

Switch# configure terminalSwitch(config)# username admin privilege 15 secret *Firewall.cx*Switch(config)# line console 0Switch(config-line)# login localSwitch(config-line)# password ciscoSwitch(config-line)# exec-timeout 60 0

We also apply the same commands to our VTY (telnet/ssh) section and create an access-list 115 to restrict telnet/ssh access from specific networks & hosts:

Switch (config)# line vty 0 15Switch (config-line)# password cisco
Switch (config-line)# login localSwitch (config-line)# exec-timeout 60 0
Switch (config-line)# transport preferred ssh  Switch (config-line)# access-class 115 in

 

Following is the access-list 115 we created:

Switch (config)# access-list 115 remark -=[Restrict VTY Access]=-
Switch (config)# access-list 115 permit ip host 74.200.84.4 any
Switch (config)# access-list 115 permit ip host 69.65.126.42 anySwitch (config)# access-list 115 permit ip 192.168.50.0 0.0.0.255 any
Switch (config)# access-list 115 remark

Always ensure the use of the ‘secret’ parameter rather than the ‘password’ parameter in your username syntax, when defining usernames and their passwords. The classic ‘password’ parameter uses a much weaker encryption algorithm that is easily unencrypted.

To demonstrate this, you can use the 'password' parameter and then copy past the encrypted password into our popular Cisco Type 7 Password decrypt page and see what happens!

Avoid Using VLAN1 (Default VLAN)  for your Network Data

VLAN 1 is a special VLAN selected by design to carry specific information such as CDP (Cisco Discovery Protocol), VTP, PAgP and more.  VLAN 1 was never intended to be used as standard VLAN to carry network data.

By default configuration, any Access Link on a Cisco switch is set to VLAN 1, causing a major security issue as direct access to the network backbone is given.  As a consequence, VLAN 1 can end up unwisely spanning the entire network if not appropriately pruned.

The practice of using a potentially omnipresent VLAN for management purposes puts trusted devices to higher risk of security attacks from untrusted devices that by misconfiguration or pure accident gain access to VLAN 1 and try to exploit this unexpected security hole.

As a general rule of thumb, the network Administrator should prune any VLAN, and in particular VLAN 1 from all ports where that VLAN is not needed.

The following example prunes VLANs 1  to 5 and 7 to 8, allowing access only to VLAN 6 when in trunking mode. Furthermore, we assign the port to VLAN 6 only:

Switch(config)# interface fastethernet0/24Switch(config-if)# switchport trunk allowed vlan remove ? (help)
WORD  VLAN IDs of disallowed VLANS when this port is in trunking mode

Switch(config-if)# switchport trunk allowed vlan remove 1,2,3,4,5,7,8
Switch(config-if)# switchport access vlan 6

Disable High-Risk Protocols on any Port That Doesn’t Require Them 

If a port is connected to a ‘foreign’ device, don’t try to speak its language – it could be turned to someone else’s advantage and used against your network. Ensure you disable protocols such as CDP, DTP, PAgP, UDLD (Unidirectional Link Detection Protocol)  and always enable spanning-tree  portfast & bpduguard on the port.

Here is an example on how to disable the above mentioned protocols and enable spanning-tree portfast bpduguard:

Switch(config)# interface fastethernet0/24Switch(config-if)# no cdp enableSwitch(config-if)# no udld port
Switch(config-if)# spanning-tree portfast
Switch(config-if)# spanning-tree bpduguard enableSwitch(config-if)# spanning-tree guard root

Finally, if the port is not to be used, issue the ‘shutdown’ command to ensure it won’t be accessed by anyone without the proper authorisation.

VTP Domain, VTP Pruning and Password Protection

Two choices exists here – either configure the VTP domain appropriately or turn off VTP altogether!  VTP is a great tool that ensures all VLAN information is carried to your network switches. If necessary security measures are not taken, wiping your network-wide VLAN configuration is as easy as connecting a switch with the ‘proper’ devastating configuration.

 A switch configured with the same ‘VTP domain’, a role type of ‘Server’ and a higher ‘VTP revision’ number of the real VTP server (usually the core switch), is all that’s required to cause major disruption and panic across any network size. All other switches will automatically ‘listen’ to the new ‘VTP Server’ and wipe all existing VLAN information. You can then start looking for a new job.

A few simple self-explanatory commands on your core switch will help ensure the above scenario is avoided:

CoreSwitch(config)# vtp domain firewall.cxCoreSwitch(config)# vtp password fedmag secretCoreSwitch(config)# vtp mode server
CoreSwitch(config)# vtp version 2CoreSwitch(config)# vtp pruning

Edge switches will require the ‘vtp mode client’ and ‘vtp password’ command, after which they will automatically receive all necessary VLAN information from your core switch.

You can verify the configuration using the ‘show vtp status’ command:

CoreSwitch # show vtp status
VTP Version capable          : 1 to 3

VTP version running             : 2

VTP Domain Name               : firewall.cx

VTP Pruning Mode                : Enabled

VTP Traps Generation           : Disabled

Device ID                            : c062.6b10.5600

Configuration last modified by 192.168.50.1 at 3-16-11 16:53:48

Local updater ID is 192.168.50.1 on interface Vl1 (lowest numbered VLAN interface found)

Feature VLAN:

--------------

VTP Operating Mode                       : Server

Maximum VLANs supported locally   : 1005

Number of existing VLANs               : 8

Configuration Revision                    : 25

MD5 digest                                    : 0xDD 0x9D 0x3B 0xA0 0x80 0xD8 0x7A 0x3A

                                                      0x1F 0x2F 0x2A 0xDB 0xCD 0x84 0xCE 0x5F 

Control Inter-VLAN Routing Using IP Access Lists

Inter-VLAN routing is a great and necessary feature. Because in many cases there is the need to isolate VLANs or restrict access between them, the usage of IP Access lists is mandatory.

IP Access lists should be created in such a way, that they allow the normal flow of traffic between VLANs, but do not expose the networks that need to be protected. Once the Access Lists are created, they are applied directly on the VLAN interface of the core layer-3 switch.   All traffic from the designated VLAN trying to pass to other VLANs will be denied according to the Access Lists, making sure the core network is not exposed. 

Let’s take a common example to make this tip more practical.

You’ve created a new guest VLAN (VLAN 6 – Network 192.168.141.0/24) to provide free Internet access to your company visitors. The requirement is to allow full Internet access, but restrict access to other VLANs.  In addition, configuration of a DHCP server is also deemed necessary, to make your life easier and less troublesome.

Here’s the configuration used for the DHCP server serving this VLAN:

CoreSwitch(config)# ip dhcp pool vlan6-Guest-Internet  
CoreSwitch(dhcp-config)# network 192.168.141.0 255.255.255.0
CoreSwitch(dhcp-config)# dns-server 192.168.130.5
CoreSwitch(dhcp-config)#  default-router 192.168.141.1 

Note that 192.168.141.1 is our core switch VLAN 6 IP Address, and 192.168.130.5 is our DNS server located on a different VLAN.

Next, we create our necessary Access Lists.

CoreSwitch(config)# access-list 100 remark --[Allow Guest DNS requests to DNS Server]--
CoreSwitch(config)# access-list 100 permit udp 192.168.141.0 0.0.0.255 host 192.168.130.5 eq 53
CoreSwitch(config)# access-list 100 remark [Necessary for DHCP Server to receive Client requests]
CoreSwitch(config)# access-list 100 permit udp any any eq bootps
CoreSwitch(config)# access-list 100 permit udp any any eq bootpc
CoreSwitch(config)# access-list 100 remark --[Deny Guest Access to other VLANs]--
CoreSwitch(config)# access-list 100 deny   ip 192.168.141.0 0.0.0.255 192.168.50.0 0.0.0.255 log
CoreSwitch(config)# access-list 100 deny   ip 192.168.141.0 0.0.0.255 192.168.130.0 0.0.0.255 log
CoreSwitch(config)# access-list 100 deny   ip 192.168.141.0 0.0.0.255 192.168.135.0 0.0.0.255 log
CoreSwitch(config)# access-list 100 deny   ip 192.168.141.0 0.0.0.255 192.168.160.0 0.0.0.255 log
CoreSwitch(config)# access-list 100 deny   ip 192.168.141.0 0.0.0.255 192.168.131.0 0.0.0.255 log
CoreSwitch(config)# access-list 100 deny   ip 192.168.141.0 0.0.0.255 192.168.170.0 0.0.0.255 log
CoreSwitch(config)# access-list 100 deny   ip 192.168.141.0 0.0.0.255 192.168.180.0 0.0.0.255 log
CoreSwitch(config)# access-list 100 remark --[Permit Guest Access to everywhere else –Internet ]--
CoreSwitch(config)# access-list 100 permit ip 192.168.141.0 0.0.0.255 any
CoreSwitch(config)# access-list 100 remark

 Notice that we permit DNS and DHCP requests initially, and then deny access to all VLANs. Finally we permit access everywhere else. This logical structure of our Access List is built to comply with the Top-Down Access List examination performed by the Core switch.

If we were to place the DNS or Bootp last in the Access List, it would clearly fail as the deny statements would prevail.  Finally, the ‘log’ parameter seen on our deny statements would trigger a log entry on our core switch, allowing us to catch any guests trying persistently to access our other VLANs

Last step would be to apply the access-list to the newly created VLAN interface, in the ‘incoming’ direction:

CoreSwitch(config)# interface vlan 6CoreSwitch (config-if)# ip access-group 100 in

Article Summary

VLAN Technology is wonderful – it offers great enhancements to the network and provides paths to run multiple services in isolated environments without sacrificing speed, quality and network availability. If the necessary basic security guidelines are taken in consideration during its initial implementation and ongoing administration, it can perform wonders and dramatically reduce the administrative overhead from your IT Administrators or Managers. On other hand, if these security guidelines are ignored, the imminent exposure of the whole network is at risk and simply a matter of time.

Perhaps the most serious mistake that an IT Administrator or Manager can make, is to underestimate the importance of the DataLink layer, and of VLANs in particular, in the architecture of switched networks.

It should not be forgotten that any network is only as robust as its weakest link, and that therefore an equal amount of attention should be given to any of its layers, to make sure that its entire structure is sound.