Troubleshooting Control Plane Security
Even though the majority of the packets going to a router/switch are forwarded by the data plane, some of the packets must be handled by the system’s route processor. A few examples of those types of traffic, formally referred to as control plane traffic, are routing protocols, keepalives, and spanning tree. Packet overloads on a router’s control plane can slow down routing processes and, as a result, degrade network service levels and user productivity. Packets that traverse the control plane are those destined for that router’s CPU, as opposed to network endpoints. All packets entering the control plane are redirected by the data (forwarding) plane. One cause for an overburdened router control plane is denial-of-service (DoS) attacks on the control plane.
Control plane protocols such as routing protocols, Spanning Tree Protocol (STP), and Address Resolution Protocol (ARP) influence or feed the data structures that are used by the data plane to forward frames or packets. Therefore, any device that participates in these protocols can affect the forwarding behavior of the network. By manipulating routing tables, ARP caches, or the spanning-tree topology, packets/frames can be diverted or dropped. Similarly, first-hop redundancy protocols (FHRP), Dynamic Host Configuration Protocol (DHCP), and ARP can be used to influence the forwarding behavior between hosts and routers. Therefore, unauthorized participation in any of these protocols should be prevented to secure the network.
Securing the Control Plane
Most routing protocols support neighbor authentication based on MD5 hashes, only allowing a router that is in possession of a shared key to become a neighbor. A similar mechanism is supported by first-hop redundancy protocols, such as the Hot Standby Router Protocol (HSRP), Virtual Router Redundancy Protocol (VRRP), and Gateway Load Balancing Protocol (GLBP). Using an authentication mechanism prevents unauthorized devices from participating in these important control plane protocols and misdirecting or black-holing application traffic.
The IEEE 802.1D STP does not have an authentication mechanism. Therefore, other mechanisms must be used to prevent unauthorized interaction with the Spanning Tree Protocol. To facilitate this, Cisco switches support the BPDU Guard feature, which shuts down a port if bridge protocol data units (BPDUs) are detected on a port. Cisco switches also support the Root Guard feature, which allows a neighboring switch to participate in the spanning tree protocol but shuts down the port if it sends superior BPDUs. A superior BPDU leads to election of a new device as the spanning-tree root. Other features such as BPDU filtering are also available to protect STP.
The DHCP and ARP protocols can be secured by enabling the DHCP snooping and dynamic ARP inspection (DAI) features. These features inspect DHCP and ARP packets to detect malicious DHCP requests, DHCP replies, and ARP replies. They allow only legitimate ARP and DHCP traffic, and block malicious traffic that aim to redirect user traffic by manipulating the ARP and DHCP tables.
Finally, the control plane policing and control plane protection features can be implemented to protect the CPU of infrastructure devices (routers and switches) from being overloaded by unwanted control plane traffic. Control plane and control plane protection use the Cisco Modular QoS CLI (MQC) to protect the infrastructure from DoS attacks.
Troubleshooting Security Implementations in the Control Plane
It is important to know which control plane security features have been implemented in your network and where (on which devices) they have been implemented. Control plane security features restrict which devices can participate in the control plane protocols. If these features are misconfigured, they may cause the operation of a control plane protocol between devices to fail. A checklist similar to the following could be used by support engineers to troubleshoot control plane security implementations:
- Are routing protocols or FHRPs set up for authentication properly?
- Are STP security features such as BPDU Guard, BDPU Filter, Loop Guard, or Root Guard enabled correctly?
- Is DHCP snooping configured properly?
- Is the configuration of DAI correct?
- Are the configurations for control plane policing or control plane protection done appropriately?
Troubleshooting Data Plane Security
Routers and switches can play an important role in protecting the hosts on the network and securing the exchange of traffic on the network. Because routers and switches are involved in processing and forwarding network traffic, they can play an effective role in inspecting and filtering traffic as it flows through the network.
Securing The Data Plane
The Cisco IOS firewall software provides enhanced security functions for the data plane. There are two types of Cisco IOS firewall:
- Classic Cisco IOS firewall (stateful packet inspection)
- Zone-based policy firewall
Securing the Data Plane Using IOS Stateful Packet Inspection
Cisco IOS stateful packet inspection (formerly context-based access control) is a component of the Cisco IOS firewall. Cisco IOS stateful packet inspection allows certain incoming flows by first inspecting and recording flows initiated from the trusted network. IOS stateful packet inspection is able to inspect all the way to the application layer, taking into consideration characteristics of a flow on a per-protocol basis (context). IOS stateful packet inspection offers interface-based stateful inspection. The combination of the inspection policy and the ACL-based policy defines the overall firewall policy. For example, assume that you want to protect a trusted (internal) network from an untrusted (external) network using a router with two interfaces. The router must be placed between the two networks, and there will be four logical points at which the router can inspect traffic:
- Inbound on the internal interface
- Outbound on the external interface
- Inbound on the external interface
- Outbound on the internal interface
Cisco IOS stateful packet inspection is configured per interface, and it operates by dynamically modifying access list entries facing one direction based on the traffic it sees flowing in the opposite direction. As an example, assume that you are allowing all traffic traversing the router from the internal LAN (192.168.0.0/24) to the Internet (10.0.0.0/8), and denying all traffic flowing from the Internet toward the LAN (see Figure 9-2). To do this, you apply a simple access list to deny all IP traffic on the inbound direction of the external interface (Fa 0/0). Example 9-6 shows this work.
Example 9-6: An ACL Denying All Inbound Traffic Is Created and Applied to Fa 0/0
Router(config-ext-nacl)# deny ip any any
Router(config-ext-nacl)# exit
Router(config)# interface f0/0
Router(config-if)# ip access-group DENY_ALL in
Router(config-if)# exit
To allow web access initiated from the internal network, you must permit the response to the web request to return. Cisco IOS stateful packet inspection allows you to define an inspection rule for each protocol you want to monitor, and permit its respond. In this case, you want to track HTTP sessions. To create an inspection rule (called inshttp) to monitor HTTP, you would enter the following command:
The inspection rule has to be applied on the interface in a particular direction. In this example, the direction has to be outbound on the external interface (Fa 0/0), because the router inspects traffic originating from the trusted network, and dynamically adjusts the ACL restricting traffic inbound on the external interface. Example 9-7 shows the inspect rule (called inshttp) being applied to the external interface (Fa 0/0) in the out direction.
Example 9-7: Applying the Inspect Rule to the Fa 0/0 Interface in the Outbound Direction
Router(config)# interface f0/0
Router(config-if)# ip inspect inshttp out
Router(config-if)# end
Router#
Now, the Cisco IOS stateful packet inspection is enabled in one direction for HTTP traffic on interface Fa 0/0. Outbound traffic (going toward the Internet) is tracked in the state table by session, and the DENY_ALL extended ACL restricting inbound traffic is automatically modified to accommodate legitimate return traffic. From the output of show ip inspect sessions illustrated in Figure 9-2, you can see that the trusted host 192.168.0.2 has opened an HTTP connection to 10.0.0.2. Cisco IOS stateful packet inspection will continue to track this session until it is closed by either end or when the idle timer expires.
To display Cisco IOS stateful packet inspection configuration and session information, use the show ip inspect all command in privileged EXEC mode, as demonstrated in Example 9-8. Cisco has an added ACL bypass functionality so that a packet can avoid redundant ACL checks. This is done by allowing the firewall to permit the packet on the basis of existing inspection sessions rather than dynamic ACLs. Because input and output dynamic ACLs have been eliminated from the firewall configuration, the show ip inspect session detail command output no longer shows dynamic ACLs. Instead, the output displays the matching inspection session for each packet that is permitted through the firewall.
Example 9-8: show ip inspect all Command Output
Session audit trail is enabled
Session alert is enabled
<...output omitted...>
Inspection Rule Configuration
Inspection name inshttp
http alert is on audit-trail is on timeout 3600
https alert is on audit-trail is on timeout 3600
Interface Configuration
Interface FastEthernet0/0
Inbound inspection rule is not set
Outgoing inspection rule is inshttp
http alert is on audit-trail is on timeout 3600
https alert is on audit-trail is on timeout 3600
Inbound access list is DENY_ALL
Outing access list is not set
! Output omitted for brevity
Audit trails can be enabled to generate syslog messages for each stateful inspection session creation and deletion. Example 9-9 shows how audit trail is enabled using the ip inspect audit-trail command. You can see a sample firewall session audit trail message in the figure output. Example 9-9 also shows a sample output of the debug ip inspect command that has been entered to observe more detailed information such as object creation.
Example 9-9: Enabling IP Inspect Audit Trail and Debug
Router(config)#
%FW-6-SESS_AUDIT_TRAIL_START: Start http session: initiator
(192.168.0.2:10032) –– responder (10.0.0.10:80)
Router# debug ip inspect
Object-creation INSPECT Object Creations debugging is on
Router#
CBAC* OBJ_CREATE: Pak 6621F7A0 sis 66E4E154 initiator_addr
(192.168.0.2:10032) responder_addr (10.0.0.10:80) initiator_alt_addr
(192.168.0.2:10032) responder_alt_addr (10.0.0.2:80)
CBAC OBJ-CREATE: sid 66E684B0 acl DENY_ALL Prot: tcp
Src 10.0.0.10 Port [80:80]
Dst 192.168.0.2 Port [10032:10032]
CBAC OBJ_CREATE: create host entry 66E568DC addr 10.0.0.10 bucket 8
(vrf 0:0) insp_cb 0x66B61C0C
Securing the Data Plane Using the Zone-Based Policy Firewall
The zone-based policy firewall (ZPF) offers an easy-to-understand configuration model. Figure 9-3 shows a pictorial presentation of implementing ZPF. ZPF allows grouping of physical and virtual interfaces.
Firewall policies are configured on traffic moving between zones. ZPF simplifies firewall policy troubleshooting by applying explicit policy on interzone traffic. Firewall policy configuration is very flexible. Varying policies can be applied to different host groups, based on ACL configuration.
ZPF supports the following functionalities:
- Stateful inspection
- Application inspection: IM, POP, IMAP, SMTP/ESMTP, HTTP
- URL filtering
- Transparent firewall
- Virtual Routing and Forwarding (VRF)-aware firewall
Example 9-10 demonstrates a simple ZPF configuration. First, the inspect class map called MY-CLASS is defined as all TCP-based traffic that also match access list 102 (Telnet, SMTP, FTP, and HTTP). Next, the policy map MY-POLICY defines which action to perform on the traffic matching the class map MY-CLASS. In this example, the action is to inspect the traffic to create dynamic inspection objects. Before applying this policy to the traffic, you need to define security zones. A corresponding zone pair is then created to represent the direction of the traffic to which the policy will be applied. Finally, the zones need to be assigned to the appropriate interfaces. In this example, there are two zones: PRIVATE and PUBLIC. Interface FastEthernet 0/0 is in zone PRIVATE, and interface FastEthernet 0/1 is in the zone PUBLIC. Zone pair PRIV-PUB states that all traffic sourced from zone PRIVATE and destined for zone PUBLIC will be processed according to policy map MY-POLICY.
Example 9-10: ZPF Configuration Example
! Define inspect class-maps:
class-map type inspect match-any TCP
match protocol tcp
class-map type inpsect match-all MY-CLASS
match access-group 102
match class-map TCP
! Define inspect policy-map:
policy-map type inspect MY-POLICY
class type inspect MY-CLASS
inspect
! Define zones:
zone security PRIVATE
zone security PUBLIC
! Establish zone pair, apply policy:
zone-pair security PRIV-PUB source PRIVATE destination PUBLIC
service-policy type inspect MY-POLICY
! Assign interfaces to zones:
interface FastEthernet0/0
zone-member security PRIVATE
interface FastEthernet0/1
zone-member security PUBLIC
! Define ACLs
access-list 102 permit tcp any any eq telnet
access-list 102 permit tcp any any eq smtp
access-list 102 permit tcp any any eq ftp
access-list 102 permit tcp any any eq www
Other Methods of Securing the Data Plane
Unauthorized or unwanted traffic can be blocked by implementing traffic-filtering features such as ACLs and VLAN access maps (on LAN switches) and Cisco IOS firewall and IPS features. The Unicast Reverse Path Forwarding (uRPF) feature can be deployed as an antispoofing mechanism by filtering packets that enter a router or switch through an interface that is not on the best path back to the source IP address of the packet. Routers (and Adaptive Security Appliances) can also protect network traffic using IP Security (IPsec). IPsec encryption and authentication techniques guarantee the integrity and confidentially of traffic that needs to be tunneled across an unsecure network.
Another category of features that can be used to secure the data plane are those that allow controlled access to interfaces on switches and, to a lesser extent, routers. For example, technologies such as 802.1X and Network Admission Control (NAC) can be used to allow network access through a switch port only if certain criteria are met. In case of 802.1X, a device is allowed access to the network only after the user has been successfully authenticated. 802.1X authentication is performed using the RADIUS protocol by a server that references its own local database or an external database. In the case of NAC, the criteria for successful admission to the network can be more sophisticated. For example, a device is allowed access only if it has a specific patch level for its operating system or a minimum version of antivirus software.
Troubleshooting Security Implementations in the Data Plane
It is vital that you know which security features are implemented at which points in the network. Misconfigured security features can cause valid traffic to be dropped. Therefore, security features should always be considered as a possible cause of network connectivity problems. When your troubleshooting process indicates that there is network layer connectivity between two hosts, but upper layers are not working as expected, you should consider whether any form of packet filtering might be implemented between those two hosts.
In addition, when you are observing problems on the management plane or control plane of a network device, always keep in mind that management and control traffic also passes through the data plane and that data plane security features could be the cause of the failure.
The troubleshooting tools for the ZPF are similar to the tools used for classic Cisco IOS firewall:
- When audit trails are enabled, syslog messages are generated for each stateful inspection session.
- Debugging can be used to obtain more detailed information.
Example 9-11 shows a sample of syslog messages generated due to stateful inspection.
Example 9-11: Syslog Messages for IP Stateful Inspect
publicPrivateOut:myClassMap:Start http session: initiator (10.1.1.100:3372)
–– responder (172.16.1.100:80)
May 31 18:02:34.907 UTC: %APPFW-4-HTTP_JAVA_APPLET: HTTP Java Applet
detected - resetting session 172.16.1.100:80 10.1.1.100:3372 on zone-pair
publicPrivateOut class myClassMap appl-class HttpAic
May 31 18:02:34.919 UTC: %FW-6_SESS_AUDIT_TRAIL: (target:class)-
(publicPrivateOut:myClassMap):Stop http session: initiator
(10.1.1.100:3372) sent 297 bytes –– responder (172.16.1.100:80) sent 0 bytes
As a demonstration of how useful syslog messages can be, let us assume that a user complains that he is unable to browse to a web server with the IP address 172.16.1.100. An administrator searches the syslog for the string 172.16.1.100, and from the search results shown in Example 9-11, the administrator realizes that a Java applet reset option was configured on the ZPF. The class map is myClassMap, and the appl-class is HttpAic. The administrator corrects this problem by allowing the embedded Java applet to the server in the HTTP AIC policy (HttpAic). Syslog is the most effective troubleshooting tool available for ZPF. It captures alert, audit trail, and debug command output.
There are several useful show commands for performing ZPF troubleshooting and verification:
- show zone security: This command displays information for all the zones configured on the router and the corresponding member interfaces. With this command, you can verify zones configuration and their assignment.
- show zone-pair security: This command provides important information about how zones are paired, the zone-pair direction (with respect to the traffic flow), and the policy applied to the zone-pair traffic, as demonstrated in Example 9-12.
- show policy-map type inspect: This command shows the relevant information for the policy, what traffic is matched to which class, and what action is applied to each class of traffic. This command also displays the dynamically created session objects. Example 9-12: show zone-pair security Command Output
Router# show zone-pair security source PRIVATE destination PUBLIC
Zone-pair name PRIV-PUB
Source-Zone PRIVATE Destination-Zone Public
Service-policy MY-POLICY
0 comments
Post a Comment