Forwarding Plane Security and Troubleshooting

While the management and control planes are concerned with data that is destined for the local router or switch, the forwarding or data plane is concerned with data that is traversing the router or switch. Securing the data plane entails securing the actual flows through the router or switch.  In Cisco IOS software, a plethora of tools can be used to secure the data plane.

Troubleshooting data plane issues depends on the technology that has been implemented to secure the data plane. As always, a solid understanding of these technologies makes the troubleshooting process that much simpler. The following sections will describe common data plane security mechanisms which include the following:

1. Router and Switch Access Control Lists
2. Catalyst Switch Port Security
3. Private VLANs
4. IEEE 802.1x Port-Based Authentication
5. Trunking
6. The Cisco IOS Firewall

Router and Switch Access Control Lists

The forwarding or data plane can be secured by implementing ACLs, which can take the form of Router ACL (RACLs), Port ACLs (PACLs) or VLAN ACLs (VACLs) in Cisco IOS Catalyst switches. There are many types of Router ACLs that can be configured in Cisco IOS software. These include named and number standard and extended ACLs. Router ACLs are commonly applied on interfaces in either the inbound or outbound direction using the ip access-group <name|number> interface configuration command. These ACLs are used to filter packets transiting the interfaces on which they are applied.

When a packet enters a router or switch, the destination address of the packet is checked against the entries in the routing table to identify the egress interface. The packet is also checked against any configured RACLs assigned to the interface, and will either be permitted or denied accordingly. When an inbound RACL is applied to an interface, the router or switch checks the received packets against the statements in the RACL looking for a match. If a match is found, and the RACL action is to permit, then the device continues to process the packet. However, if a match is found, and the action is to deny, the device discards the packet and typically, unless otherwise configured, sends an ICMP Destination Unreachable message, back to the source.

When an outbound RACL is applied on an interface, the device first performs a route lookup for the destination address in the routing table to determine the egress interface via which the packet should be forwarded. If a valid path is found in the routing table, and a match is found for the RACL, and the action of the RACL is permit, then the device continues to process the packet. But, if the RACL action is to deny the packet, then the packet is discarded by the device, which then sends an ICMP Destination Unreachable message back to the source host(s).

However, if a match is not found, the implied deny all statement at the end of the RACL is applied and the router discards the packet, sending the source an ICMP Destination Unreachable message. Finally, if a valid path to the intended destination is not found in the routing table, then the device simply discards the packet.

When troubleshooting data forwarding issues on routed interfaces, check configured or applied RACLs using the show ip access-lists command. If the RACL is long, you can enable logging by appending the log or log-input keywords. The log keyword allows you to see matches against the IP ACL, while the log-input keyword provides additional information, such as the Layer 2 address of the hosts that match the RACL entry.

Port ACLs (PACLs) are similar to router ACLs but are supported and configured on Layer 2 interfaces on a switch. Port ACLs are supported on physical interfaces as well as on Etherchannel interfaces. PACLs are not supported on private VLANs. In addition to this, keep in mind that PACLs do not support the log RACL keyword. Port ACLs perform access control on all traffic entering the specified Layer 2 port and apply only to ingress traffic on the port.

When implementing PACLs, it is important to remember that they do not affect Layer 2 control packets, such as CDP packets, that are received on the port. Additionally, keep in mind that PACLs are supported only in hardware only and do not apply to packets that are processed in software. When you create a Port ACL, an entry is created in the ACL TCAM. PACLs can be configured as either standard or extended IP ACLs or MAC ACLs. This allows you to filter IP traffic by using IP access lists and non-IP traffic by using MAC addresses. As is the case with RACLs, you can use the show ip access-lists command to troubleshooting PACL Layer 3 filtering problems. In the event that MAC filtering has been implemented, use the show mac access-group command to view applied MAC ACLs on a per-interface basis as follows:

To view the configured MAC ACL, use the show access-lists command as follows:

VLAN Access Control Lists (VACLs) operate in a similar manner to Router ACLs (RACLs), but are a means to apply access control to packets bridged within a VLAN or routed between VLANs. Unlike RACLs, which are applied on an inbound or outbound basis, VACLs have no sense of direction and therefore apply to traffic at both ingress and egress. Within a VLAN, packets arriving on the Layer 2 interface have the VACL processed on ingress and egress.
Used alone, VACLs can be configured to filter both bridged and routed packets. Additionally, they can also be used in conjunction with RACLs to filter both bridged and routed traffic. Troubleshoot VACL issues using the show vlan filter <access-map|vlan> suite of commands. The show vlan filter access-map <name> command prints information showing the VLAN the specified VLAN access map has been applied to as illustrated below:

The show vlan filter vlan <ID> command prints information on the VACL that is applied to the specified VLAN as illustrated in the following output:

In addition to the show vlan filter commands, you can also use the show vlan access-mapcommand to view the configured parameter for all or the specified VACL:

A common issue when implementing RACLs, PACLs, and VACLs is attempting to apply conflicting ACLs. However, care should be taken when attempting to implement different types of ACLs on the switch. If a conflicting VACL and PACL configuration is implemented, the switch will log an error message similar to the following error message:

Likewise, if a conflicting RACL and PACL configuration is implemented, the switch will log an error message similar to the following error message:

And finally, if a conflicting RACL and VACL configuration is implemented, the switch will log an error message similar to the following error message:

In summation, when implementing RACLs, PACLs, and VACLs, keep the following in mind:

1. RACLs are applied to Layer 3 interfaces, which includes switch SVIs
2. RACLs are applied in the inbound and outbound directions
3. PACLs are applied only on Layer 2 ports
4. PACLs are applied in the inbound direction
5. PACLs do not affect management protocols, such as CDP
6. PACLs can filter based on Layer 2 or Layer 3 address
7. VACLs can be applied to VLANs; they cannot be applied to interfaces
8. VACLs can be used to filter both bridged and routed traffic
9. VACLs have no sense of direction and filter inbound and outbound traffic
10. VACLs can be used with RACLs to filter routed and bridged traffic

Catalyst Switch Port Security

Port security is another Cisco IOS software tool that can be used to protect the data plane. This feature secures the CAM table, by limiting the number of MAC addresses that can be learned on a particular port or interface. With the port security feature, the switch maintains a table that is used to identify which MAC address (or addresses) can access which local switch port. The primary purpose of the port security feature is to protect against CAM table overflow or MAC address flooding attacks. However, the same feature can also be used to protect against MAC spoofing attacks which were described earlier in this chapter in the section on DHCP Snooping.

CAM table overflow or MAC address flooding attacks work by flooding the switch with a large number of randomly generated invalid source and destination MAC addresses until the CAM table fills up and the switch is no longer able to accept new entries. In such situations, the switch effectively turns into a hub and simply begins to broadcast all newly received frames to all ports on the switch, essentially turning the VLAN into one big Broadcast domain.

The primary purpose of CAM table overflow or MAC address flooding attacks is to get the switch to go into a ‘fail-open’ state, which essentially means that all traffic is flooded or transmitted out of all ports. In such cases, the attacker is able to capture all data transiting the switch as they can see all packets that are being sent by the switch.

The port security feature can be used to specify what specific MAC address is permitted access to a switch port as well as to limit the number of MAC addresses that can be supported on a single switch port. The methods of port security implementation described in this section are:

1. Static Secure MAC Addresses
2. Dynamic Secure MAC Addresses
3. Sticky Secure MAC Addresses

Static secure MAC addresses are statically configured by network administrators and are stored in the MAC address table as well as in the switch configuration. When static secure MAC addresses are assigned to a secure port, the switch will not forward frames that do not have a source MAC address that matches the configured static secure MAC address or addresses.

Dynamic secure MAC addresses are dynamically learned by the switch, and are stored in the MAC address table. However, unlike static secure MAC addresses, dynamic secure MAC address entries are removed from the switch when the switch in reloaded or powered down. These addresses must then be re-learned by the switch when it boots up again.

Sticky secure MAC addresses are a mix of static secure MAC addresses and dynamic secure MAC addresses. These addresses can be learned dynamically or configured statically and are stored in the MAC address table, as well as the switch configuration (NVRAM). This means that when the switch is powered down or rebooted, it will not need to dynamically discover the MAC address again because they will already be saved in the configuration file.

Once port security has been enabled, administrators can define the actions the switch will take in the event of a port security violation. Cisco IOS software allows administrators to specify four different actions to take when a violation occurs:

1. Protect
2. Shutdown (default)
3. Restrict
4. Shutdown VLAN

The protect option forces the port into a protected port mode. In this mode, all Unicast or Multicast frames with unknown source MAC addresses will simply be discarded by the switch. When the switch is configured to protect a port, it will not send out a notification when operating in protected port mode, meaning that administrators would never know when any traffic was prevented by the switch port operating in this mode.

The shutdown option places a port in an err-disabled state when a port security violation occurs. The corresponding port LED on the switch is also turned off when a port security violation occurs and this configured action mode is used. In shutdown mode, the switch sends out an SNMP trap, a Syslog message, and the violation counter is incremented. This is the default action taken when port security is enabled on an interface.

The restrict option is used to drop packets with unknown MAC addresses when the number of secure MAC addresses reaches the administrator defined maximum limit for the port. In this mode, the switch will continue to restrict additional MAC addresses from sending frames until a sufficient number of secure MAC addresses is removed, or the number of maximum allowable addresses is increased. As is the case with the shutdown option, the switch sends out an SNMP trap, a Syslog message, and the violation counter is incremented.

The shutdown VLAN option is similar to the shutdown option, however, this options shuts down a VLAN instead of the entire switch port. This configuration could be applied to ports which have more than one single VLAN assigned to them, such as a voice VLAN and a data VLAN, for example, as well as to trunk links on the switches.

When troubleshooting port security, it is important to first check the configuration that has been implemented using the show running-config interface <name> command. As stated earlier in this guide, default port security configuration parameters can cause operational issues with other features such as FHRPs, i.e. HSRP, VRRP and GLBP because only a single MAC address is allowed per port. This can be validated via the show port-security interface <name> command as illustrated below:

When looking at the output of this command, it is important to understand the information that is printed by the switch. The Port Status field indicates the operational state of the port, i.e. whether the port is up or down. In the example above, the port is down, which could be due to Layer 1 issues, because the shutdown command was issued under the port, or because theswitchport port-security command has not been issued under the interface or port.

The Violation Mode field indicates the configuration violation mode. The default mode is shutdown. The Aging Time and Aging Type fields specify the aging time and type parameters. By default, secure MAC addresses will not be aged out and will remain in the switch MAC table until the switch is powered off. However, this default behavior may be adjusted by configuring aging values for dynamic and secure static MAC addresses. The valid aging time range is 0 to 1440 minutes.

The aging type specifies how secure addresses are aged. This can either be an absolute value or following a configured period of inactivity. The absolute mechanism causes the secured MAC addresses on the port to age out after a fixed specified time. All references are flushed from the secure address list after the specified time and the address must then be relearned on the switch port. Once relearned, the timer begins again and the process is repeated as often as has been defined in the configured timer values. This is the default aging type for secure MAC addresses.

The inactivity time, also referred to as the idle time, causes secured MAC addresses on the port to age out if there is no activity (i.e. frames or data) received from the secure addresses learned on the port for the specified time period.

The Maximum MAC Addresses field specifies the number of allowed secure MAC addresses per port. The default is one (1) and the maximum value depends on the switch platform. The Total MAC Addresses field indicates the current total MAC addresses learned on the port. TheConfigured MAC Addresses field specifies the number of statically configured secure addresses on the port. The Sticky MAC Addresses field specifies the number of sticky secure MAC addresses configured on the port. The Last Source Address:Vlan field specifies the MAC address of the last secure MAC address learned on the port. This is applicable only when port security is configured on a trunk link. And finally, the Security Violation Count field specifies the number of security violations on the port. To further reinforce what has been discussed in this section, consider the following output:

From the port security interface output that is printed above, we can determine the following:

1. The interface is up, and the switchport port-security command was issued under the interface. This is reflected in the Secure-up port status
2. The switchport port-security violation restrict command was issued under the interface because the default violation mode is Shutdown
3. The switchport port-security aging time 10 and switchport port-security aging type inactivity commands were issued under the interface because the aging time default is 0 minutes and the aging type default is absolute
4. The switchport port-security maximum 10 command was issued under the interface since by default only one MAC is permitted when port security is enabled
5. Referencing the total MAC addresses, we can determine that the switchport port-security mac-address sticky command was issued and specified five secure sticky addresses, while the switchport port-security mac-address was issued and specified one secure address because, by default, these addresses are not defined
6. And finally, we can determine that no security violations have been detected on the interface or port as the counter still has a value of zero (0)

Private VLANs

Private VLANs prevent inter-host communication by providing port-specific security between adjacent ports within a VLAN across one or more switches. Access ports within PVLANs are allowed to communicate only with the certain designated router ports, which are typically those connected to the default gateway for the VLAN. Both normal VLANs and private VLANs can co-exist on the same switch; however, unlike normal VLANs, private VLANs allow for the segregation of traffic at Layer 2. This effectively transforms a traditional Broadcast segment into a non-Broadcast multi-access segment.

The private VLAN feature uses three different types of ports, which are Community, Isolated, and Promiscuous ports. Community PVLAN ports are logically combined groups of ports in a common community that can pass traffic amongst themselves and with promiscuous ports. Ports are separated at Layer 2 from all other interfaces in other communities or isolated ports within their PVLAN.

Isolated PVLAN ports cannot communicate with any other ports within the PVLAN. However, isolated ports can communicate with promiscuous ports. Traffic from an isolated port can only be forwarded to a promiscuous port and no other port.

Promiscuous PVLAN ports can communicate with any other ports, including community and isolated PVLAN ports. The function of the promiscuous port is to allow traffic between ports in community of isolated VLANs. Promiscuous ports can be configured with switch ACLs to define what traffic can pass between these VLANs. It is important to know that only one (1) promiscuous port is allowed per PVLAN, and that port serves the community and isolated VLANs within that PVLAN. Because promiscuous ports can communicate with all other ports, this is the recommended location to place switch ACLs to control traffic between the different types of ports and VLANs.

Isolated and community port traffic can enter or leave switches via trunk links, because trunks support VLANs carrying traffic among isolated community and promiscuous ports. Hence, PVLANs are associated with a separate set of VLANs that are used to enable PVLAN functionality in Cisco Catalyst switches. The three types of VLANs used in PVLANs are:

1. The Primary VLAN
2. Isolated VLAN
3. Community VLAN

Primary VLANs carry traffic from a Promiscuous Port to isolated, community and other promiscuous ports within the same primary VLAN. Isolated VLANs carry traffic from Isolated ports to a Promiscuous Port. Ports in isolated VLANs cannot communicate with any other port in the private VLAN without going through the Promiscuous Port.

Community VLANs carry traffic between community ports within the same PVLAN, as well as to promiscuous ports. Ports within the same Community VLAN can communicate with each other at Layer 2; however, they cannot communicate with ports in other Community or Isolated VLANs without going through a Promiscuous Port. Isolated and community VLANs are typically referred to as secondary VLANs. A private VLAN therefore actually contains three elements. These are:

1. The PVLAN itself
2. The secondary VLANs (Community and Isolated)
3. The promiscuous port

The Community VLAN defines a set of ports that can communicate with each other at Layer 2, as long as they belong to the same Community VLAN, but cannot communicate with ports in other Community VLANs or Isolated VLANs without first going through the Promiscuous Port.  The Isolated VLAN defines a set of ports that cannot communicate with any other port within the Private VLAN, either another Community VLAN port or even a port in the same Isolated VLAN, at Layer 2. In order to communicate with ports in either of these VLANs, Isolated ports must go through the promiscuous port. Only a single Isolated VLAN per PVLAN is allowed. The Promiscuous Port forwards traffic between ports in Community and/or Isolated VLANs. Only one promiscuous port can exist within a single PVLAN; however, this port can serve all the Community and Isolated VLANs in the Private VLAN. ACLs may be applied to the Promiscuous Port to define the traffic that is allowed to pass between these different VLANs.

When troubleshooting PVLANs, first verify that the implemented configuration is correct. For example, if users are unable to access other devices in their or other VLANs, ensure that they are using the correct default gateway and the default gateway has been assigned to the promiscuous port because this port allows for both intra and inter-PVLAN communication. In addition to verifying PVLAN configuration, also perform additional basic checks such as verifying that the ports are configured and operational, for example.

IEEE 802.1x Port-Based Authentication

Identity Based Networking Services (IBNS) provides identity-based network access control and policy enforcement at the switch port level. The IBNS solution extends network access security based on the 802.1x technology, Extensible Authentication Protocol (EAP) technologies and the Remote Authentication Dial-In User (RADIUS) security server service.

IEEE 802.1x is a protocol standard framework for both wired and wireless Local Area Networks that authenticates users or network devices and provides policy enforcement services at the port level to provide secure network access control. 802.1x is an IEEE standard for access control and authentication that provides a means for authenticating users who want to gain access to the network and placing them into a pre-determined VLAN, effectively granting them certain access rights to the network. In simpler terms, 802.1x simply mitigates against rogue or unknown devices from gaining unauthorized access to either the wired or wireless network.

The 802.1x protocol provides the definition to encapsulate the transport of EAP messages at the Data Link Layer over any PPP or IEEE 802 media (e.g. Ethernet, FDDI, or Token Ring) through the implementation of a port-based network access control to a network device. EAP messages are communicated between an end device, referred to as a supplicant, and an authenticator, which can either be a switch or a wireless access point. The authenticator relays the EAP messages to the authentication server, e.g. a Cisco ACS server, via the RADIUS server protocol.

There are three primary components (or roles) in the 802.1x authentication process. These three components, which are described in the following section, are:

1. Supplicant or Client
2. Authenticator
3. Authentication Server

An IEEE 802.1x supplicant or client is simply an 802.1x-compliant device such as a workstation, laptop or even an IP phone with software that supports the 802.1x and EAP protocols. The supplicant client sends an authentication request to the access LAN via the connected authenticator device, e.g. the access switch, using Extensible Authentication Protocol (EAP).

An 802.1x authenticator is a device that enforces physical access control to the network based on the authentication status (i.e. permit or deny) or the supplicant. An example of an authenticator would a switch or router.  The authenticator acts as a proxy and relays information between the supplicant and the authentication server.

The authenticator receives the identity information from the supplicant via EAP over LAN (EAPOL) frames, which are verified and then encapsulated into RADIUS protocol format before being forwarded to the authentication server. It is important to remember that the EAP frames are not modified or examined during the encapsulation process, which means that the authentication server must support EAP within the native frame format. When the authenticator receives frames from the authentication server, the RADIUS header is removed, leaving only the EAP frame, which is then encapsulated in the 802.1x format. These frames are then sent back to the supplicant or client.

The authentication server is the database policy software, such as Cisco Secure ACS, that supports the RADIUS server protocol and performs authentication of the supplicant that is relayed by the authenticator via the RADIUS client-server model.

The authentication server validates the identity of the client and then notifies the authenticator whether the client is allowed or denied access to the network. Based on the response from the authentication server, the authenticator relays this information back to the supplicant. It is important to remember that during the entire authentication process, the authentication server remains transparent to the client because the supplicant is communicating only to the authenticator. The RADIUS protocol with EAP extensions is the only truly-compliant supported authentication server when configuring 802.1x port-based authentication.

When configuring 802.1x authentication, you must enable AAA on the switch or router using theaaa new-model global configuration command. Next, create or use the default 802.1X authentication method list and specify RADIUS server information by issuing the aaa authentication dot1x [method-list|default] group [name|radius] global configuration command.

NOTE: As per Cisco online documentation, when configuring 802.1x authentication, ‘ The only method that is truly 802.1X-compliant is the group radius method, in which the client data is validated against a RADIUS authentication server’. Cisco IOS software also allows you to use the local database, enable password or line passwords for authentication.

Following that, proceed and configure RADIUS server parameters, e.g. keys and ports, via theradius-server host global configuration command for an individual server or the aaa group server radius global configuration command for a RADIUS server group. Next, globally enable IEEE 802.1x authentication on the switch using the dot1x system-auth-control global configuration command.

And finally, enable 802.1x port-based authentication on desired switch ports using the dot1x port-control {auto|force-authorized |force-unauthorized} interface configuration command. The following configuration example illustrates how to configure 802.1x port-based authentication on a switch interface:

Switch(config)#dot1x system-auth-control

When troubleshooting 802.1x port-based authentication, troubleshooting targets include the client (supplicant), authenticator and authentication server. As a network engineer, your primary focus would be on the authenticator as this is the device under your administration on which the port-based authentication configuration is implemented.

When troubleshooting 802.1x authentication issues, verify that 802.1x is enabled on the switch port by checking the device configuration or using the show dot1x interface <name>command, the output of which is shown below:

In addition to this, check that the port authorization state is set to auto. If the port authorization state is set to force-unauthorized, the port will remain in the unauthorized state, ignoring all attempts by the client to authenticate. In other words, the switch or router cannot provide authentication services to the client through the interface or port. Another thing to check is that 802.1x port-based authentication has been globally enabled on the switch. Again, you can check the configuration, parsing it for the dot1x system-auth-control configuration statement or simply use the show dot1x command to validate this configuration as shown below:

In the event that the configuration on the switch or router appears to be correct, verify that there is connectivity between the switch or router and the RADIUS server. You can perform a simple IP connectivity test using the ping utility and additionally use the debug aaa authentication command to perform additional verification and also AAA troubleshooting.

Trunking

Trunk links are used to carry traffic from multiple VLANs. By default, the users residing on one VLAN cannot directly communicate with users in another VLAN without going through a router or Layer 3 interface, e.g. an SVI. Despite this default operation, attackers can use VLAN hopping attacks to bypass a Layer 3 device in order to communicate directly between VLANs. For this reason, it is important to ensure that trunk links are secured. The main objective of VLAN hopping is to compromise a device residing on another VLAN. There are two primary methods used to perform VLAN hopping attacks:

1. Switch spoofing
2. Double-tagging

In switch spoofing, the attacker impersonates a switch by emulating ISL or 802.1Q signaling, as well as Dynamic Trunking Protocol (DTP) signaling. DTP provides switches with the ability to negotiate the trunking method for the trunk link they will establish between themselves.

Double-tagging or double-encapsulated VLAN attacks involve tagging frames with two 802.1Q tags in order to forward the frames to a different VLAN. The embedded hidden 802.1Q tag inside the frame allows the frame to traverse a VLAN that the outer 802.1Q tag did not specify. This is a particularly dangerous attack because it will work even if the trunk port is set to off.

While there are no structured troubleshooting steps for VLAN hopping attacks per-se, there are some techniques that you should be familiar with and implement to prevent such attacks. These techniques and mitigation methods include the following:

1. Ensure that the native VLAN used on all the trunk ports is different from the VLAN ID of user access ports. It is best to use a dedicated or isolated VLAN that is specific for each pair of trunk ports and not the default VLAN
2. Configure the native VLAN to tag all traffic so as to prevent the vulnerability of double-tagged 802.1Q frames hopping VLANs. This functionality can be enabled by issuing the vlan dot1q tag native global configuration command
3. Disable Dynamic Trunking Protocol on all untrusted ports using the switchport nonegotiate command, effectively preventing automatic trunk configuration
4. Alternatively, configure the untrusted ports as access ports using the switchport mode access command
5. Place all unused ports in a common unrouted VLAN that is local to the switch. Use a VLAN number that is easily recognizable, such as 666 for example

Cisco IOS Firewall

The Cisco IOS Firewall suite can be used to secure the data plane; however, it has been included in its own section as this topic is not included in any of the other current CCNP study guides.