As described in Chapter 2, when the destination MAC address of a unicast Ethernet frame is not present within the CAM table, the frame is broadcast (flooded) out of every switch port within the associated VLAN. Broadcasting frames degrades network performance and increases the risk of broadcast storms and bridging loops. This default behavior may be prevented via the unknown unicast flood blocking (UUFB) feature available within IOS.
The UUFB feature blocks unknown unicast traffic flooding and only permits egress traffic destined to known MAC addresses (in other words, installed in the CAM table) to exit on the UUFB-enabled port. The UUFB feature is supported on all ports that are configured with theswitchport IOS interface configuration command, including PVLAN ports. UUFB is configured using the switchport block unicast IOS interface configuration command.
Summary
This chapter reviewed a wide array of techniques available to mitigate attacks within the IP data plane and within Layer 2 switched Ethernet networks. Many of the techniques are specifically intended for network security, including, for example, ACLs, uRPF, FPM, IP Options Selective Drop, and IP sanity checks. Conversely, many others, including the QoS, QPPB, ICMP, and IP routing techniques, are not intended (nor often considered) for network security but provide powerful tools that may be leveraged to mitigate the risk of security attacks. The optimal techniques that provide an effective security solution will vary by organization and depend on network topology, product mix, traffic behavior, operational complexity, and organizational mission. Defense in depth and breadth techniques (discussed in Chapter 3) can be helpful in understanding the interactions between various data plane security techniques and in optimizing the selection of appropriate measures.
Chapters 5 through 7 review the techniques available within the IP control, management, and services planes, respectively, to mitigate the risk of attacks.
Review Questions
1 Which ACL types are commonly used for incident response during active security attacks?
2 What is a potential drawback of tuning the IOS BGP weight attribute so that strict uRPF operates correctly at the SP network edge for multihomed transit customers?
3 Describe two key differences between FPM and interface ACLs.
4 Which technique may be used to reserve a percentage of a router’s interface bandwidth solely for control plane traffic?
5 Name an IP option header type that results in IOS process level packet handling.
6 Where is the logical place to disable the generation of ICMP Destination Unreachable reply messages (Type 3)?
7 Name two distinct IOS features (other than CEF) that QPPB relies upon.
8 What is the primary configuration difference between source-based RTBH filtering and destination-based RTBH filtering?
9 Name three stateful data plane security techniques and three stateless techniques.
10 Name the IOS Layer 2 Ethernet switch port mode that disables DTP.
Further Reading
Baker, F., and P. Savola. Ingress Filtering for Multihomed Networks. RFC 3704/BCP 84. IETF, March 2004. http://www.ietf.org/rfc/rfc3704.txt.
Evans, J., and C. Filsfils, “Deploying Diffserv at the Network Edge for Tight SLAs, Part I.” IEEE Internet Computing, vol. 8, no. 1: 61–65 (2004).
Evans, J., and C. Filsfils. “Deploying Diffserv at the Network Edge for Tight SLAs, Part II.” IEEE Internet Computing, vol. 8, no. 2: 61–69 (2004).
Ferguson, P., and D. Senie. Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing. RFC 2827/BCP 38. IETF, May 2000. http://www.ietf.org/rfc/rfc2827.txt.
Passmore, D. “Impact of P2P on Networks.” Business Communications Review.
vol. 35, no. 5: 14–15 (May 2005).
Parmakovic, D. “Service Provider Security.” Cisco white paper.
http://www.cisco.com/web/about/security/intelligence/sp_infrastruct_scty.html.
Savola, P. “Experiences from Using Unicast RPF.” draft-savola-bcp84-urpf- experiences-02.txt. IETF, Nov. 15, 2006. http://tools.ietf.org/id/draft-savola-bcp84- urpf-experiences-02.txt.
“Access Control List Logging.” Cisco white paper. http://www.cisco.com/web/about/
security/intelligence/acl-logging.html.
“ACL IP Options Selective Drop.” Cisco IOS Software Releases 12.0S Feature Guide.
http://www.cisco.com/en/US/products/sw/iosswrel/ps1829/
products_feature_guide09186a00801d4a94.html.
“ACL Support for Filtering IP Options.” Cisco IOS Software Releases 12.3T Feature Guide. http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/
products_feature_guide09186a00801d4a7d.html.
“BGP and the Internet: Advanced Community Usage.” Cisco Systems, 2000.
http://www.questnet.net.au/questnet2001/ppt/pdf/BGP-AdvCommunities.pdf.
“BGP Support for IP Prefix Import from Global Table into a VRF Table.” Cisco IOS Software Releases 12.3T Feature Guide. http://www.cisco.com/en/US/products/sw/
iosswrel/ps5207/products_feature_guide09186a00803b8db9.html#wp1027265.
Cisco 7600 Series Cisco IOS Software Configuration Guide, 12.2SR.
http://www.cisco.com/univercd/cc/td/doc/product/core/cis7600/software/122sr/
swcg/index.htm.
“Cisco IOS Firewall Overview.” Cisco IOS Security Configuration Guide, Release 12.4. http://cisco.com/en/US/products/ps6350/
products_configuration_guide_chapter09186a0080455ae3.html.
“Cisco IOS Network Address Translation Overview.” Cisco white paper.
http://www.cisco.com/en/US/tech/tk648/tk361/
technologies_white_paper09186a0080091cb9.shtml.
“Cisco IOS Quality of Service.” Cisco white paper. http://www.cisco.com/en/US/
products/ps6558/products_white_paper0900aecd802b68b1.shtml.
“Cisco IOS Software Support Resources.” http://www.cisco.com/en/US/products/sw/
iosswrel/tsd_products_support_category_home.html.
“Cisco Modular Quality of Service Command Line Interface.” Cisco white paper.
http://www.cisco.com/en/US/products/ps6558/
products_white_paper09186a0080123415.shtml.
“Configuring Cisco IOS Intrusion Prevention System (IPS).” Cisco IOS Security Configuration Guide, Release 12.4. http://www.cisco.com/en/US/products/ps6350/
products_configuration_guide_chapter09186a00804453cf.html.
“Configuring Traffic Storm Control.” Cisco Documentation. http://www.cisco.com/
univercd/cc/td/doc/product/core/cis7600/software/122sr/swcg/storm.htm.
“IS-IS Mechanisms to Exclude Connected IP Prefixes from LSP Advertisements.”
Cisco IOS Software Releases 12.0S Feature Guide. http://www.cisco.com/en/US/
products/sw/iosswrel/ps1829/products_feature_guide09186a00800ad395.html.
“NANOG Security Curriculum.” NANOG. http://www.nanog.org/ispsecurity.html.
“Network Based Application Recognition.” Cisco Systems. http://www.cisco.com/en/
US/products/ps6616/products_ios_protocol_group_home.html.
“Protecting Your Core: Infrastructure Protection Access Control Lists.” (Doc. ID:
43920.) Cisco white paper. http://www.cisco.com/warp/public/707/iacl.html.
“Providing Service Security With Cisco Service Control Technology.” Cisco SCE 1000 Series Service Control Engine Brochure. http://www.cisco.com/en/US/
products/ps6150/prod_brochure0900aecd8024ff1a.html.
“Transit Access Control Lists: Filtering at Your Network Edge.” (Doc. ID: 44541.) Cisco white paper. http://www.cisco.com/en/US/tech/tk648/tk361/
technologies_white_paper09186a00801afc76.shtml.
“Using CAR During DoS Attacks.” (Doc. ID: 12764.) Cisco Troubleshooting Tech Note. http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/
products_tech_note09186a00800fb50a.shtml.
“When Are ICMP Redirects Sent?” (Doc. ID: 13714.) Cisco Design Tech Note.
http://www.cisco.com/en/US/partner/tech/tk365/
technologies_tech_note09186a0080094702.shtml.
• Security techniques that may be used to protect the control plane of Layer 2 switched Ethernet networks
5
IP Control Plane Security
This chapter describes techniques available to mitigate the risks of unauthorized traffic reaching the IP control plane. As control plane protocols enable IP host connectivity across a routed network, it is critical that:
• Control plane resources within an IP router are protected to mitigate the risk of DoS attacks because most control plane packets are handled at the IOS process level
• Control plane protocols are secured to mitigate the risk of protocol attacks, which may result in unauthorized traffic redirection to a black hole or, alternatively, to an insecure network where an attacker may eavesdrop on conversations and manipulate packet content
Several of the control plane techniques described here were previously referenced in Chapter 4, “Data Plane Security,” given exception IP data plane traffic may require control plane processing. This includes data plane packets requiring ICMP handling, IP multicast state creation, or IP options header processing. Further, although data plane techniques such as infrastructure ACLs may help to protect internal control plane protocols such as OSPF, they offer limited protection for external control plane protocols that, by definition, peer with external devices. This chapter reviews the various IOS techniques available to protect BGP and to protect the router from ICMP attacks within the control plane. ICMP attacks that leverage the IP data plane were described in Chapter 4. Chapter 6, “Management Plane Security,” and Chapter 7, “Services Plane Security,” will review techniques to secure and mitigate attacks within the IP management and services planes, respectively.
As described previously, no single technology (or technique) makes an effective security solution. This applies not only to your wider IP network but also to individual IP traffic planes. Following the defense in depth and breadth principles outlined in Chapter 3,
“IP Network Traffic Plane Security Concepts,” you may consider deploying multiple complementary techniques, as described in this chapter, to mitigate the risk of control plane attacks.
Disabling Unused Control Plane Services
It is widely considered a network security best common practice (BCP) to disable any unused services and protocols on each device in the IP network. Unused services and protocols are generally not secured, and thus may be leveraged within an attack. The following services and protocols that are enabled by default within Cisco IOS represent a potential security risk. If you do not need these services, you should disable them.
(Management plane services and protocols that should also be disabled if not used are described in Chapter 6.)
• Gratuitous ARP:To disable the transmission of gratuitous Address Resolution Protocol (ARP) messages on PPP/SLIP interfaces for an address in a local pool, use theno ip gratuitous-arps command in IOS global configuration mode.
• IP source routing:To disable source routing, enter the no ip source-route command in IOS global configuration mode.With IP source routing disabled, any IP packet containing a strict or loose source-route option (per RFC 791) will be discarded.
Additional techniques available to mitigate the risk of IP options-based DoS attacks were reviewed in Chapter 4.
• Maintenance Operation Protocol (MOP): MOP is enabled on Ethernet interfaces and disabled on all other interface types by default within IOS. To disable MOP, use theno mop enabled command within IOS interface configuration mode.
• Proxy ARP:Proxy ARP is enabled for all interfaces by default within Cisco IOS. To disable it, use the no ip proxy-arp command in IOS interface configuration mode.
Proxy ARP is generally only required for broadcast (or shared LAN) networks that connect IP routers with:
— IP hosts that do not have a statically configured default gateway
— IP hosts that do not use a dynamic routing protocol
— IP hosts that do not use ICMP Router Discovery Messages (RFC 1256) Most other control plane services and protocols are disabled by default within Cisco IOS.
IOS management plane services that are enabled by default are described in Chapter 6. The IOS AutoSecure feature provides an automated mechanism to disable unnecessary IOS services. For more information on AutoSecure, refer to Chapter 6. Nevertheless, you should verify against your specific IOS devices and software releases that all unused services and protocols are disabled either by default or through the router configuration.
ICMP Techniques
ICMP, by its very definition per RFC 792, is a control plane protocol. However, it is generally used to report error conditions within IP data plane processing. As discussed in Chapter 2, “Threat Models for IP Networks,” ICMP may be used as an attack vector for IP data plane DoS attacks. By triggering packet failures within the IP data plane, for example, using crafted IP packets with insufficient TTL values, attackers may adversely
impact the IP control plane of affected routers. Because many of the attacks that target ICMP control plane functions are data plane attacks, the ICMP security techniques available to mitigate the risk of ICMP-related data plane attacks were described in Chapter 4. Refer to Chapter 4 for a detailed review of ICMP security techniques.
Nevertheless, there are specific techniques that you may use to mitigate the risk of control plane attacks that specifically use ICMP messages versus native IP data plane packet failures, per Chapter 4, including:
• no ip information-reply: Disables the router from generating ICMP Information Reply (Type 16) messages when it receives unsolicited ICMP Information Request (Type 15) messages. This command is applied by default within IOS interface configuration mode; hence, IOS routers will not respond to unsolicited ICMP Information Request messages. This command applies only to ICMP Information Request messages received. Example 5-1 illustrates how to explicitly disable the generation of ICMP Information Reply messages on an Ethernet interface, which again is the default IOS behavior.
ICMP Information Request messages are not widely used. However, an attacker may use this IETF standard ICMP message type to conduct reconnaissance, as well as to spike the router CPU and potentially trigger a DoS condition. For these reasons, the default behavior of no ip information- replyshould not be changed.
• no ip mask-reply: Disables the router from generating ICMP Address Mask Reply (Type 18) messages when it receives unsolicited ICMP Address Mask Request (Type 17) messages. This command is applied by default within IOS interface configuration mode; hence, IOS routers will not respond to unsolicited ICMP Address Mask Request messages. This command applies only to ICMP Address Mask Request messages received. Example 5-2 illustrates how to explicitly disable the generation of ICMP Address Mask Reply messages on an Ethernet interface, which again is the default IOS behavior.
ICMP Address Mask Request messages are not widely used. However, an attacker may use this IETF standard ICMP message type to conduct reconnaissance, as well as to spike the router CPU and potentially trigger a DoS condition. For these reasons, the default behavior of no ip mask-reply should not be changed.
Example 5-1 IOS Interface Configuration for Disabling ICMP Information Replies
interface Ethernet 0 no ip information-reply
Example 5-2 Sample IOS Interface Configuration for Disabling ICMP Address Mask Replies
interface Ethernet 0 no ip mask-reply
• Interface ACLs: Infrastructure and transit ACLs, as described in Chapter 4, may be used to filter unnecessary ICMP messages destined to network infrastructure, including but not limited to ICMP Source Quench (Type 4), ICMP Echo (Type 8; in other words, ping), and ICMP Timestamp (Type 13) messages. If it is not necessary for external devices to send ICMP messages to your network infrastructure, you should filter them at your network edge. Only those ICMP messages that are specifically needed should be permitted—for example, ICMP Destination Unreachable (Type 3) and ICMP Echo Reply (Type 0) messages. Denying ICMP Echo Requests and permitting ICMP Echo Replies allows you to ping external hosts, such as a public Internet web server, but prevents external hosts from pinging your network infrastructure.
If you wish to permit external pings to your DMZ that hosts public servers such as web and e-mail servers, be sure to make the ACL statement restrictive such that only pings are permitted to host addresses within the DMZ and not your wider network infrastructure. Further, you may use rate limiting to permit ICMP messages up to a configurable maximum rate. This allows specific ICMP messages to pass while limiting their potential impact as described in Chapter 4. In addition to interface ACLs and rate limiting, IP Receive ACLs (IP rACL) and Control Plane Policing (CoPP) may be used to filter and, optionally, rate limit ICMP messages from unauthorized sources.
IP rACLs and CoPP are described in detail later in the chapter, in the sections “IP Receive ACLs” and “Control Plane Policing,” respectively.
Selective Packet Discard
Selective Packet Discard (SPD) is an internal mechanism supported by many Cisco IOS platforms that manages ingress packets that are enqueued within the IOS process level input queues. SPD prioritizes control plane packets and other important traffic during periods of process level queue congestion. Prior to the advent of Cisco Express Forwarding (CEF), as described in Chapter 1, “Internet Protocol Operations Fundamentals,” significant numbers of transit packets were forwarded by the IOS process level in order to populate the fast- switching cache. Consequently, SPD was required to prioritize the routing protocol packets over the transit packets that share the same process level queues. On modern platforms running CEF, only receive packets and some exception packets are handled at the IOS process level. Examples of these types of packets include but are not limited to the following:
• Example receive adjacency IP and non-IP packets:
— IP control plane and routing protocol packets (for example, BGP, OSPF, and HSRP)
— ICMP messages (for example, Echo Request/Reply and Information Request/Reply)
— MPLS control protocol packets (for example, LDP and RSVP/MPLS-TE)
— Management protocol packets (for example, Telnet, SSH, SNMP, TFTP, RADIUS, and TACACS+)
— Multicast routing protocol packets (for example, PIM, DVMRP, and IGMP)
— Layer 2 keepalives (for example, PPP, Frame Relay LMI, BFD, and ATM OAM)
— ARP packets
• Example transit IP and non-IP exception packets:
— Multicast data plane packets (in other words, first packet of a multicast flow is punted to IOS process level for state creation, per Chapter 2)
— IP options packets (for example, router alert)
— MPLS packets with router alert label
— IP packets resulting in ICMP handling (for example, TTL expiry, IP Fragmentation Needed but Don’t Fragment (bit) was Set)
After packets are punted and placed into the ingress queues, and before IOS starts processing those packets, the SPD mechanism takes place. SPD is an additional tool that ensures certain important packets are handled with higher priority, while in situations of high traffic load at the IOS process level, the less-important packets are discarded. For example, when an interface flap occurs, routing protocol traffic must be guaranteed a high priority and not discarded while the interface recovers. At a high level, the SPD mechanism can be illustrated as shown in Figure 5-1. Here, packets ingressing the router are first placed within ingress queues (left side of figure). From there, input queue checks are made against the per-hardware interface hold queues (middle of figure). Finally, they are enqueued into the IOS process queues (right side of figure). How these packets move from the ingress queue to the IOS process queue is managed by the SPD mechanisms.