In this section, we discuss security considerations at the customer edge router as Layer 3 and Layer 2 devices. We illustrate the security factors for both constructs and highlight recommendations for deployment.
In scenarios where customers seek a Layer 2 interconnection service for their Layer 3 networks as would be expected through a Frame Relay/ATM offering, the security approaches are simplest to implement while providing a reasonable degree of control over network access.
The customer needs to follow the Layer 3 best practices as described in Chapter 4, "Secure MPLS VPN Designs." This should include using MD5 signatures for the routing protocol mechanisms traversing the service provider network. In addition, the service provider should provide a MAC address?based filter on the access point to the Layer 2 provider edge. This filter should permit the MAC address of the customer CE router only.
An example is as follows:
vacl blah permit aabb.ccdd.eeff vacl deny all
The service provider should further implement traffic load controls on the provider edge router facing the customer's interconnection device. That is, received traffic should be bandwidth limited to the levels as agreed on in the service contract between the customer and the service provider. Bandwidth limiting can be provided by using input policing mechanisms as shownhere:
service-policy dogger police 3000000 interface ethernet 0/0 service-policy dogger in
In addition, it would be preferable that the service provider also police outbound traffic volumes to protect the customer's network from network anomalies escaping from the service provider core.
The customer should also implement protections on its service provider?facing edge devices to prevent any aberrant traffic loads from impacting its local operations.
In designs where a customer Layer 2 domain is interconnected by a service provider Layer 2 EoMPLS network, the security considerations are considerably more significant and complex in implementation.
As such, the following configuration components should be addressed for Ethernet VLAN security, VPLS security, and and hijack management access security:
Secure console/aux access
Disable password recovery (if possible)
Ensure that U-PE cannot become spanning tree root (priority configuration)
Establish broadcast controls on interfaces
Disable/block Cisco Discover Protocol (CDP), Bridge Protocol Data Units (BPDUs), and Dynamic Trunking Protocol (DTP) on the UNI interfaces
Ensure VTP operation in transparent mode
Apply MAC address limits
Remove VLAN 1 and reserved VLANs from UNI
Remove unused VLANs from allowed list
Shut down all unused ports
Hard-code physical port attributes
Establish error reporting
Enable 802.1x as applicable
The interconnect device (CE and especially U-PE) access ports should be strongly secured to prevent unauthorized intrusion into the service provider network. The general recommendations for securing access to Cisco devices can be summarized by protecting access to console ports and implementing router password security mechanisms.
Many of the above recommendations can also be readily applied to large enterprise networks.
In addition, consideration should be given to disabling password recovery mechanisms inherent in most Cisco hardware. This fail-safe measure allows a user with physical access to the device to power the device off and on and issue a "break" sequence on the console port within 20 seconds of the reboot. This will drop the router into "ROMMON" mode, where the configuration may be viewed and possibly manipulated.
For example, most Cisco routers and switches allow the service provider to disable this recovery mechanism using the following command sequence: no service password-recovery.
Once this command is entered, the switch will display the following banner on power-up:
The password-recovery mechanism has been triggered, but is currently disabled. Access to the boot loader prompt through the password-recovery mechanism is disallowed at this point . However, if you agree to let the system be reset back to the default system configuration , access to the boot loader prompt can still be allowed. Would you like to reset the system back to the default configuration (y/n) ?
A "Y" response to this prompt will cause the configuration and VLAN database to be erased. This will prevent unauthorized access to the switch through a password-recovery attack. Note, however, that the configuration will be destroyed and as such the device will be out of service, requiring the service provider to recover the U-PE before user traffic can resume. As such, the service provider must ensure that the configurations are safely stored and must consider that an attack on the device is sufficient reason for a service outage of this magnitude.
Because the default VLAN used for all ports is 1, it is strongly recommended never to use VLAN 1 in production networks. After a system reset, no port will be connected to a VLAN.
Additionally, access to the console may be disabled with the following approach:
line console 0 no exec
This will disable access to the device from the console port. CLI-based device management via alternative access mechanisms (SSH) should be ensured prior to issuing this command. It is suggested that this approach only be used where the device in question is located in an unsecured area.
The U-PE is the service provider's interconnect point to the customer network. As such, it should never become the root of the service provider's Layer 2 network. To ensure that this is the case, the bridge priority of the U-PE should be set to a high number so that it will not overrule the priority of the service provider?desired root bridges (primary and secondary).
cons-osr1(config)#bridge 1 priority ? <0-65535> Priority (low priority more likely to be root)
In addition, the root guard mechanism can be utilized to protect the switches from receiving BPDUs that suggest that the root bridge has changed. This root guard configuration is applied to ports where the path to the true root bridge should not appear.
cons-osr1(config-if)#spanning-tree guard ? loop Set guard mode to loop guard on interface none Set guard mode to none root Set guard mode to root guard on interface
The root guard mechanism differs from the BPDU filter approach in the sense that root guard allows connected devices to participate in spanning tree operations as long as they do not attempt to advertise a superior root priority. If such frames are received, the port is disabled, and once the offending messages cease, the port is automatically re-enabled. Root guard should not be enabled on the root switch ports directly facing the secondary root.
The Catalyst switch products can be configured to limit the amount of broadcast traffic load permitted to enter an interface. This can be useful in preventing the propagation of broadcast storms from a particular L2 area to other areas of the network. A sample configuration snippet is shown here:
cons-osr1(config-if)#storm-control ? broadcast Broadcast address storm control multicast Multicast address storm control unicast Unicast address storm control cons-osr1(config-if)#storm-control broadcast ? level Set storm suppression level on this interface cons-osr1(config-if)#storm-control broadcast level ? <0 - 100> Enter Integer part of level as percentage of bandwidth
The UNI interface between the service provider and its customers should not process unwarranted L2 control traffic.
This would include:
Cisco Discovery Protocol (CDP)
Dynamic Trunking Protocol (DTP)
Spanning Tree Protocol (STP) Bridge Protocol Data Units (BPDUs)
Allowing these control packets to flow freely across a UNI exposes information about the devices on both ends (CDP), allows for the establishment of trunks without manual intervention (DTP), and establishes loop-free pathing through a given set of nodes (STP). While these are useful mechanisms within a contained enterprise environment, they are security exposures in the service provider?Customer interconnect devices and should be disabled/blocked. Examples Examples 7-1, 7-2, and 7-3 show you how to disable/block these protocols.
cons-osr1#sh cdp Global CDP information: Sending CDP packets every 60 seconds Sending a holdtime value of 180 seconds Sending CDPv2 advertisements is enabled cons-osr1#conf t Enter configuration commands, one per line. End with CNTL/Z. cons-osr1(config)# cons-osr1(config)#no cdp run cons-osr1(config)# cons-osr1(config)#^Z cons-osr1#sh cdp % CDP is not enabled
cons-osr1(config-if)#switchport ? access Set access mode characteristics of the interface autostate Include or exclude this port from vlan link up calculation capture Set capture mode characteristics of this interface dot1q Set interface dot1q properties host Set port host mode Set trunking mode of the interface nonegotiate Device will not engage in negotiation protocol on this interface interface FastEthernet2/40 switchport switchport trunk encapsulation dot1q switchport trunk native vlan 999 switchport trunk allowed vlan 22 switchport mode trunk switchport nonegotiate
cons-osr1(config-if)#spanning-tree bpdufilter ? disable Disable BPDU filtering for this interface enable Enable BPDU filtering for this interface cons-osr1 sh run int fas 2/40 Building configuration... Current configuration : 242 bytes ! interface FastEthernet2/40 shutdown switchport switchport trunk encapsulation dot1q switchport trunk native vlan 999 switchport trunk allowed vlan 22 switchport mode trunk switchport nonegotiate spanning-tree bpdufilter enable
However, this functionality is implemented in software on the 3550. As an alternative, hardware-based access control lists (ACLs) can be used to filter ingress control protocol data units (PDUs).
For example, the following ACL controls a number of control packets found in switched networks:
Extended MAC access list stop_ugly_stuff deny any 0180.c200.0000 0000.0000.001f deny any host 0100.0ccc.cccc deny any host 0100.0ccc.cccd deny any host 0100.0ccd.cdcd deny any host 0100.0ccd.cdce deny any host 0100.0ccc.cdd0 deny any host 000c.8580.d000 permit any any c3550-b(config)#int fas 0/24 c3550-b(config-if)#mac access-group stop_ugly_stuff in
Note the addition of the final deny statement in the ACL. This is set to deny packets destined to the unicast MAC address of the switch itself, preventing Layer 2 attacks directed at the switch MAC address. (Note: The MAC address shown is an example.)
While use of the VLAN Trunking Protocol can be advantageous within an enterprise environment, it poses security risks in an SP world because VTP allows for the dynamic definition of VLANs amongst switches. Example 7-4 shows how to disable this mode of operation.
cons-osr1(config)#vtp mode ? client Set the device to client mode. server Set the device to server mode. transparent Set the device to transparent mode. cons-osr1(config)#vtp mode trans Setting device to VTP TRANSPARENT mode. cons-osr1(config)#^Z cons-osr1# cons-osr1# sh vtp st VTP Version : 2 Configuration Revision : 0 Maximum VLANs supported locally : 1005 Number of existing VLANs : 8 VTP Operating Mode : Transparent VTP Domain Name : VTP Pruning Mode : Disabled VTP V2 Mode : Disabled VTP Traps Generation : Disabled MD5 digest : 0xCB 0x80 0x9C 0x6C 0x19 0xF8 0x59 0xE3 Configuration last modified by 127.0.0.12 at 2-26-04 15:39:18
Switches can be configured to permit access from a predefined maximum number of MAC addresses. This helps to prevent CAM table overflows usually associated with MAC overflow attacks. The switch can be configured to perform differing operations if the predefined maximum is exceeded, as follows:
Protect mode? Drops packets with unknown source addresses until you remove a sufficient number of secure MAC addresses to drop below the maximum value.
Restrict mode? Drops packets with unknown source addresses until you remove a sufficient number of secure MAC addresses to drop below the maximum value and causes the SecurityViolation counter to increment.
Shutdown mode? Disables the offending port and generates an SNMP trap. In addition, it requires manual intervention to restore the operation.
Port security configuration is not permitted on trunk ports in some software releases.
Example 7-5 illustrates a configuration for port security on an Ethernet switch.
cons-osr1(config-if)#switchport port-security ? aging Port-security aging commands mac-address Secure mac address maximum Max secure addresses violation Security violation mode cons-osr1(config-if)#switchport port-security maximum ? <1-1025> Maximum addresses cons-osr1(config-if)#switchport port-security violation ? protect Security violation protect mode Restrict Security violation restrict mode Shutdown Security violation shutdown mode
In newer code, global commands allow for the definition of a maximum number of MAC addresses per VLAN (see Example 7-6).
cons-osr1(config-if)#mac-address-table limit vlan 666 maximum 13 action ? warning Specifies that the one syslog message will be sent and no further action will be taken when the action is violated. limit Specifies that the one syslog message will be sent and/or a corresponding trap will be generated with the MAC limit when the action is violated. limit flood Enables unknown unicast flooding Shutdown Specifies that the one syslog message will be sent and/or the VLAN is moved to the blocked state when the action is violated.
Again, the shutdown option requires manual intervention if the MAC address limit is exceeded and this parameter becomes activated.
By default, VLAN 1 is used for control traffic and as a native VLAN for untagged incoming frames. The native VLAN operation of the switches should be mapped to a different VLAN that is not part of the customer domain:
c3550-b(config-if)#switchport trunk native vlan ? <1-4094> VLAN ID of the native VLAN when this port is in trunking mode c3550-b(config-if)#switchport trunk native vlan 999
Forcing the tagging of the native VLAN prevents untagged ingress frames from being picked up and forwarded over the native VLAN:
cons-osr1(config)#vlan dot1q tag native
In addition, VLAN 1 can be removed from trunk ports in hybrid Catalyst software releases:
Console> (enable) clear trunk 8/1 1 Removing Vlan(s) 1 from allowed list. Port 8/1 allowed vlans modified to 2-1005.
Alternatively, through the use of VLAN mapping and filtering, access to the control VLAN can be limited.
Remove unassigned VLANs from the system configurations to avoid accidental availability of VLANs on ports where they are not required. Example 7-7 shows the removal of unused VLAN configurations.
cons-osr1(config-if)#switchport trunk allowed vlan none cons-osr1(config-if)#do sh run int fas 2/40 Building configuration... Current configuration : 260 bytes ! interface FastEthernet2/40 Switchport Switchport trunk encapsulation dot1q Switchport trunk native vlan 999 Switchport trunk allowed vlan none Switchport mode trunk Switchport nonegotiate spanning-tree bpdufilter enable spanning-tree guard root End
Note that the switchport trunk allowed vlan none configuration statement will not be displayed on the port once some VLANs have been explicitly enabled. Example 7-8 shows this example with VLAN 666 being enabled.
cons-osr1(config-if)#switchport trunk allowed vlan 666 cons-osr1(config-if)#do sh run int fas 2/40 Building configuration... Current configuration : 259 bytes ! interface FastEthernet2/40 switchport switchport trunk encapsulation dot1q switchport trunk native vlan 999 switchport trunk allowed vlan 666 switchport mode trunk switchport nonegotiate spanning-tree bpdufilter enable spanning-tree guard root End
In order to reduce the possibility of configuration mismatches or network intruders causing instability, the operational characteristics of the ports in question should be locked down as much as possible. This means hard coding speed, duplex and disabling flow control, as Example 7-9 shows.
c3550-b(config-if)#speed ? 10 Force 10 Mbps operation 100 Force 100 Mbps operation auto Enable AUTO speed configuration c3550-b(config-if)#dup ? auto Enable AUTO duplex configuration full Force full duplex operation half Force half-duplex operation cons-osr1(config-if)#int g 1/1 cons-osr1(config-if)#speed ? 1000 Force 1000 Mbps operation nonegotiate Do not negotiate speed cons-osr1(config-if)#flowcontrol ? receive Configure receiving flow operation send Configure sending flow operation
Hard-coding may result in mismatches between the interface unless all interfaces are hard-coded. (For example, a switch port configured for full-duplex may result in a workstation failing to detect full-duplex, thus running as half-duplex.)
The SP and customer should ensure that error occurrences on the network are carefully monitored, and any anomalous events should be investigated. In addition, several additional reporting mechanisms should be enabled on the PE routers, including the following:
cons-osr1(config-if)#logg event ? bundle-status BUNDLE/UNBUNDLE messages link-status UPDOWN and CHANGE messages spanning-tree Spanning-tree Interface events trunk-status TRUNK status messages
Link status, trunk status, and spanning tree status monitoring should be enabled where appropriate.
Consideration should be given to the use of the 802.1x mechanisms on interconnections where both sides support this functionality. Essentially, 802.1x specifies a supplicant/authenticator operation where the client requests access to the network using Extensible Authentication Protocol over LAN (EAPoL) handshaking. The switch port will not permit data flows from the client other than EAPoL until it has been authorized by an AAA server.