Hands-On Pointers for VLAN-Based Security

Securing a virtual LAN network begins with physical security. These best practices can help administrators and IT managers achieve the desired result.

• One: Remove console-port cables and introduce password-protected console or virtual terminal access with specified timeouts and restricted access policies. 
  
  Console ports on the back of Cisco Systems switches provide direct access to the system. If care isn’t taken to secure this access method, then the switch remains fully exposed to anyone with the popular blue console cable.
  
  
  Configuration of complex user credentials on the console and telnet/Secure Shell ports will ensure that any unwanted visitor remains in the dark when trying to access the device. For example, when the “exec-timeout” command is used, if the administrator accidently forgets to log out of a session, it will automatically time out after the programmed time-out value.
  
  
  Here is a set of commands that will help you accomplish the above measures to restrict access to the switch:
  
  
  • Switch# configure terminal
  • Switch(config)# username admin privilege 15 secret *Firewall.cx*
  • Switch(config)# line console 0
  • Switch(config-line)# login local
  • Switch(config-line)# password cisco
  • Switch(config-line)# exec-timeout 60 0

  
  
  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, visit Cisco’s Type 7 Password decrypt page.

• Two: Apply the same commands to the virtual terminal (telnet/Secure Shell) section and create an access-list 115 to restrict telnet/SHH access from specific networks and hosts:  
  
  
  • Switch (config)# line vty 0 15
  • Switch (config-line)# password cisco
  • Switch (config-line)# login local
  • Switch (config-line)# exec-timeout 60 0
  • Switch (config-line)# transport preferred ssh 
  • Switch (config-line)# access-class 115 in

Following is a possible access-list 115:

• 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 any
• Switch (config)# access-list 115 permit ip 192.168.50.0 0.0.0.255 any
• Switch (config)# access-list 115 remark

• Three: Avoid using VLAN1 (the default VLAN)  for your network data.
  
  
  VLAN1 is a special VLAN selected by design to carry specific administrative information. It was never intended for use as a standard VLAN to carry network data.
  
  
  By default configuration, any access link on a switch is typically set to VLAN1, causing a major security issue as direct access to the network backbone is given. As a consequence, VLAN1 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 at higher risk of attacks from untrusted devices that by misconfiguration or pure accident gain access to VLAN1 and try to exploit this security hole.
  
  
  As a general rule of thumb, the network administrator should prune any VLAN — and in particular, VLAN1 — 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 VLAN6 when in trunking mode. Furthermore, this assigns the port to VLAN6 only:
  
  
  • Switch(config)# interface fastethernet0/24
  • Switch(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

• Four: 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 disable spanning-tree portfast and enable bpduguard on the port.
  

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

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

  
  
  Finally, if the port is not to be used, issue the “shutdown” command to ensure it can’t be accessed by anyone without the proper authorization.
  

• Five: Deploy VTP domain, VTP pruning and password protection.
  
  
  Two choices exist: 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 networkwide 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 the core switch will help ensure the above scenario is avoided:
  
  
  • CoreSwitch(config)# vtp domain firewall.cx
  • CoreSwitch(config)# vtp password fedmag secret
  • CoreSwitch(config)# vtp mode server
  • CoreSwitch(config)# vtp version 2
  • CoreSwitch(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 the 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

• Six: 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 use 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 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 (VLAN6 – Network 192.168.141.0/24) to provide free Internet access to 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 VLAN6 IP address, and 192.168.130.5 is our Dynamic Naming System 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 this permits DNS and DHCP requests initially, then denies access to all VLANs. Finally, we permit access everywhere else. The logical structure of the access list is built to comply with the top-down access list examination performed by the core switch.
  
  
  If you were to place the DNS or Bootp last in the list, it would clearly fail, as deny statements would prevail. Finally, the “log” parameter seen on the deny statements would trigger a log entry on the core switch, allowing the network administrator to catch any guests trying persistently to access other VLANs.
  The last step would be to apply the access list to the newly created VLAN interface, in the incoming direction:
  
  

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

  
  
  Finally, you can check to see if you’ve missed any networks by reviewing the access lists and using a network-scanning tool to scan subnets to see if any results are retuned.
  
  

More information and examples can be found at www.Firewall.cx.