Customer Edge

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.

CE Interconnection Service Is a Layer 3 Device

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.

Customer Edge Interconnection Service Is a Layer 2 Device

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

Hijack Management Security

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.

Disable Password Recovery

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.

NOTE

Recommendation

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.

U-PE STP Priority

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.

Apply Broadcast Limiters

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


Disable/Block Layer 2 Control Traffic

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.

Example 7-1. Disable CDP

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


Example 7-2. Disable DTP

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


Example 7-3. Disable STP

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.)

VTP Transparent Operation

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.

Example 7-4. Disable VLAN Trunking Protocol (Continued)

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


MAC Address Limits and Port Security

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.

NOTE

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.

Example 7-5. Port Security

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).

Example 7-6. MAC Address Limits Per VLAN

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.

Controlling Reserved VLANs

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.

Removing Unused VLANs

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.

Example 7-7. Removal Unused VLANs

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.

Example 7-8. Re-enabling VLAN Example

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


Hard-Code Physical Port Attributes

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.

Example 7-9. Hard-Coding Switch Configuration Example

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


NOTE

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.)


Establish Network Reporting

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.

Enable 802.1x

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.