Infrastructure Protection on Cisco IOS
`Software-Based Platforms
`
`This document describes currently available tools that you can use to protect Cisco IOS software-based
`infrastructure elements, such as routers and switches, from direct attacks. The same tools can help
`prevent accidental misconfiguration that may present a risk to the infrastructure. This document also
`provides deployment guidelines to help facilitate the implementation of these technologies as an
`integrated security solution, rather than as isolated elements.
`
`The first section provides an overview for the set of basic tools that help mitigate attacks designed to
`overwhelm the resources available on a device. The next three sections provide a closer look at more
`advanced features that require additional explanation. The last section provides deployment guidelines
`explaining how to implement these features in an integrated way. The appendices provide additional
`useful reference information.
`
`Contents
`
`3
`
`4
`
`5
`
`Basic Tools and Techniques for Infrastructure Protection
`Tuning Input Hold Queues
`4
`Protecting Against ICMP Unreachable Overload
`Configuring Scheduler Allocation
`5
`Infrastructure Protection Access Control Lists
`iACL Technology Overview 6
`Threat Vectors
`6
`Functional Overview 7
`Expected Effectiveness
`8
`iACL Deployment Recommendations
`Design Considerations and Limitations
`Platform and Software Availability
`11
`iACL Sample Configuration
`11
`Useful Debugs and Show Commands
`
`8
`
`10
`
`12
`
`Corporate Headquarters:
`Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA
`
`© 2006 Cisco Systems, Inc. All rights reserved.
`
`Exhibit 2019
`IPR2016-00309
`
`

`
` Contents
`
`
`
`15
`17
`
`20
`
`28
`31
`
`40
`
`36
`
`20
`
`42
`
`Related Tools
`13
`More Information
`13
`Receive Access Control Lists
`13
`rACL Technology Overview 13
`Threat Vectors
`14
`Functional Overview 14
`Expected Effectiveness
`15
`rACL Deployment Recommendations
`Design Considerations and Limitations
`Platform and Software Availability
`18
`rACL Sample Configuration
`18
`Useful Debugs and Show Commands
`Related Tools
`20
`More Information
`Control Plane Policing
`21
`CoPP Technology Overview 21
`Threat Vectors
`22
`Functional Overview 22
`Expected Effectiveness
`28
`CoPP Deployment Recommendations
`Design Considerations and Limitations
`Platform and Software Availability
`36
`Dependencies and Prerequisites
`CoPP Sample Configuration
`36
`Useful Debugs and Show Commands
`Management and Telemetry
`41
`Related Tools
`42
`More Information
`Control Plane Protection
`42
`Control Plane Protection Technology Overview 43
`Threat Vectors
`43
`Functional Overview 44
`Expected Effectiveness
`48
`Control Plane Protection Deployment Recommendations
`Design Considerations and Limitations
`48
`Platform and Software Availability
`49
`Dependencies and Prerequisites
`49
`Control Plane Protection Sample Configuration
`Useful Debugs and Show Commands
`50
`
`48
`
`49
`
`Infrastructure Protection on Cisco IOS Software-Based Platforms
`
`2
`
`OL-10601-01
`
`

`
`Management and Telemetry
`Related Tools
`51
`More Information
`51
`Integrated Deployment Guidelines
`51
`Basic Tools and Techniques for Infrastructure Protection
`Infrastructure Protection Access Control Lists
`52
`rACLs and CoPP
`54
`CoPP and Control Plane Protection
`58
`Appendix A—Turning Off Unnecessary Services
`Cisco Discovery Protocol (CDP)
`59
`Directed Broadcast
`59
`Finger
`60
`Maintenance Operations Protocol (MOP)
`HTTP Server
`61
`IP BOOTP Server
`IP Redirects
`63
`IP Source Routing
`PAD 64
`Proxy ARP
`Ident
`64
`TCP and UDP Small Servers
`65
`Appendix B—Controlling Device Access
`Password Management
`65
`Interactive Access Control
`Role-Based CLI Access
`70
`Appendix C—Commonly Used Protocols in the Infrastructure
`
`62
`
`63
`
`64
`
`65
`
`67
`
` Basic Tools and Techniques for Infrastructure Protection
`
`
`
`51
`
`58
`
`60
`
`52
`
`72
`
`Basic Tools and Techniques for Infrastructure Protection
`
`This section describes the following basic tools and techniques, which provide infrastructure protection
`for Cisco IOS software-based platforms by helping to control the utilization of the limited resources on
`a device:
`
`• Tuning input hold queues
`
`• Protecting against ICMP unreachable overload
`
`• Configuring Scheduler allocation
`
`In addition to implementing these basic tools and techniques, Cisco IOS software-based devices should
`be configured according to the device hardening best practices, which help ensure the security of the
`device by disabling unnecessary services, and by controlling access to the device. Refer to Appendix A
`for best practices regarding disabling unnecessary services. Refer to Appendix B for best practices
`regarding device access control.
`
`OL-10601-01
`
`Infrastructure Protection on Cisco IOS Software-Based Platforms
`
`3
`
`

`
` Basic Tools and Techniques for Infrastructure Protection
`
`
`
`Tuning Input Hold Queues
`
`The input hold queues hold packets destined to the router or that need to be processed by the route
`processor (RP). These queues are maintained for each physical interface, and are shared among
`subinterfaces. With the exception of asynchronous interfaces, the default input queue size is 75 packets,
`and when that input queue limit is reached the router starts dropping packets.
`
`Denial of service (DoS) attacks against a router can fill the input queue, knocking out legitimate packets.
`This is especially dangerous for routing and other control plane traffic, such as Border Gateway Protocol
`(BGP).
`Fortunately, the size of the input queue is configurable per interface using the hold-queue [size]
`command from interface configuration mode. Generally speaking, it is recommended to increase the
`queue to 1500 packets. However, before doing that, it is a good practice to first check the memory
`available. The number of packets currently set in the input queue can be seen in the “input queue” field
`in the output from the show interface command.
`For more information about the hold-queue command, see the following website:
`
`http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123cgcr/inter_r/int_d1g.htm#wp114
`2192
`
`Protecting Against ICMP Unreachable Overload
`
`According to Internet standards (RFC 1812), whenever a router drops a packet, it should return an ICMP
`unreachable packet to the packet source. Routers typically drop incoming packets either because they
`cannot find a valid route or because the packet should be routed to the Null interface. The latter is
`typically the case with “black hole” filtering. In the past, the Cisco 12000 series routers processed ICMP
`unreachable packets with the RP, which left an an opening for DoS attacks against the router. It was
`possible to overwhelm the RP by generating a large amount of packets that required the creation of ICMP
`unreachables. At this time, ICMP unreachables are handled by the line cards themselves, which protects
`the RP.
`
`There are two workarounds to solve the issue that affects these older Cisco routers:
`
`• Disable ICMP unreachable messages
`
`• Rate limit ICMP unreachable traffic
`The first workaround is to prevent the router from sending ICMP unreachables by entering the no ip
`unreachables command from interface configuration mode as in the following example:
`
`router(config)# interface ethernet 0
`router(config-if)# no ip unreachables
`
`However, in some cases ICMP unreachables are necessary, so preventing the router from sending them
`is not always appropriate.
`
`The second workaround is to rate limit the number of ICMP unreachables packets that are sent. In
`Cisco IOS software-based routers this is possible with the ip icmp rate-limit command. The Supervisor
`720 (Catalyst 6500 Series Switches and the Cisco 7600 Series Routers) provides a hardware-based rate
`limiter that is configurable with the mls rate-limit unicast ip icmp unreachable command.
`The following is an example of the ip icmp rate-limit command for Cisco IOS software-based routers:
`
`router(config)# ip icmp rate-limit unreachable [df] milliseconds
`
`Infrastructure Protection on Cisco IOS Software-Based Platforms
`
`4
`
`OL-10601-01
`
`

`
` Infrastructure Protection Access Control Lists
`
`
`
`Replace milliseconds with the number of milliseconds between two consecutive ICMP unreachable
`packets. The default is 500 ms, which means that no more than one ICMP unreachable packet is sent
`every 500 ms. The optional df flag rate limits ICMP unreachable packets with code 4 (fragmentation
`required and DF set). The best practice is to set milliseconds to 2000 and use the df option.
`For more information about the ip icmp rate-limit unreachable command, see the following website:
`
`http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123cgcr/ipras_r/ip1_i1g.htm#wp10
`81902
`
`For more information about the ICMP unreachable rate limiter and other DoS protection controls
`available on the Supervisor 720, see the following website:
`
`http://www.cisco.com/en/US/partner/products/hw/switches/ps708/products_configuration_guide_chapt
`er09186a0080435872.html
`
`Configuring Scheduler Allocation
`
`Using the scheduler allocate command, which schedules CPU time spent on processes versus interrupts,
`is another good practice to mitigate an ICMP Unreachable overload condition.
`
`When a Cisco router is fast-switching a large number of packets, it can spend so much time responding
`to interrupts from the network interfaces that no other processing is performed. Some very fast packet
`floods can cause this condition. The effect can be reduced by using the scheduler interval command,
`which instructs the router to stop handling interrupts and attend to other business at regular intervals.
`The following is a typical configuration:
`
`router(config)# scheduler interval 500
`
`This command specifies that process-level tasks will be handled no less frequently than every 500
`milliseconds. This command very rarely has any negative effects, and should be a part of your standard
`router configuration unless you know of a specific reason to leave it out.
`Many newer Cisco platforms use the scheduler allocate command instead of scheduler interval. You
`use the scheduler allocate command to configure two intervals (in microseconds): an interval for the
`system to run with interrupts enabled, and an interval for the system to run with interrupts masked. If
`your system does not recognize the scheduler interval 500 command, try the scheduler allocate
`command, as shown in the following example:
`
`router(config)# scheduler allocate 4000 1000
`
`The values in this example are those used by the AutoSecure feature, but you should tune these
`parameters for your specific platform. For more information about the scheduler allocate command, see
`the following website:
`
`http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123cgcr/fun_r/cfr_1g06.htm#wp103
`3741
`
`Infrastructure Protection Access Control Lists
`
`This section describes infrastructure protection access control lists (iACLs), which help prevent or
`mitigate direct infrastructure attacks by explicitly permitting only authorized traffic to the infrastructure
`equipment, while allowing transit traffic. Although designed for Internet Service Providers (ISPs),
`iACLs can also be used to protect the enterprise infrastructure with a few alterations. This section
`includes the following topics:
`
`•
`
`iACL Technology Overview
`
`OL-10601-01
`
`Infrastructure Protection on Cisco IOS Software-Based Platforms
`
`5
`
`

`
` Infrastructure Protection Access Control Lists
`
`
`
`• Threat Vectors
`
`• Functional Overview
`
`• Expected Effectiveness
`
`•
`
`iACL Deployment Recommendations
`
`• Design Considerations and Limitations
`
`• Platform and Software Availability
`
`•
`
`iACL Sample Configuration
`
`• Useful Debugs and Show Commands
`
`• Related Tools
`
`• More Information
`
`iACL Technology Overview
`
`Because iACLs are designed as the first line of defense against external threats, they should be deployed
`at network ingress points. Technically speaking, iACLs consist of extended ACLs that restrict external
`access to the infrastructure address space. They allow only authorized devices to communicate with
`infrastructure elements like routers and switches, while letting transit traffic flow freely.
`
`Because they are deployed at network ingress points, it is a good practice to configure iACLs to also
`provide RFC-1918, RFC-3330, and anti-spoofing filtering.
`
`Note
`
`RFC 3330 defines special use addresses that might require filtering. RFC 1918 defines reserved address
`space that cannot be used for valid source addresses on the Internet. RFC 2827 provides ingress filtering
`guidelines.
`
`In general, an iACL is composed of the following four sections or modules:
`
`• First module—Special use address and anti-spoofing entries that deny packets from illegitimate
`sources and that deny packets with source addresses belonging within your address space entering
`from an external source.
`
`• Second module—Entries providing explicit permission for traffic from legitimate external sources
`destined to infrastructure addresses.
`• Third module—deny statements for all other traffic from external sources destined to infrastructure
`addresses.
`• Fourth module—permit statements for all other normal backbone traffic en route to
`non-infrastructure destinations.
`
`Threat Vectors
`
`Use iACLs to help mitigate attacks from external sources directed at infrastructure equipment. Routers,
`as well as other network devices, have finite processing power, and an excessive amount of traffic
`directed to them can exhaust their available resources, particularly CPU capacity. When this happens,
`the router or other network device may start dropping packets, including routing protocol and other
`control packets. This results in a denial of service (DoS) condition.
`
`Infrastructure Protection on Cisco IOS Software-Based Platforms
`
`6
`
`OL-10601-01
`
`

`
` Infrastructure Protection Access Control Lists
`
`
`
`Under normal circumstances, most of the traffic handled by a router is data plane traffic, which transits
`the device over the forwarding path. Only a small portion of the traffic is control and management plane
`traffic, which is destined to the infrastructure device itself over the receive path for RP handling.
`
`Examples of control and management plane traffic, which is directed to the router itself and which is
`handled by the RP includes the following:
`
`• Routing protocols
`
`• Remote access protocols, such as SSH and telnet
`
`• Network management traffic, such as SNMP
`
`• Other protocols, such as ICMP, or IP options, might also require processing by the RP
`
`Because iACLs only permit access to the infrastructure IP addresses from authorized sources , they help
`reduce the scope of attacks targeting the infrastructure from unauthorized external sources.
`
`Functional Overview
`
`You should build iACLs in a structured manner, keeping in mind that ACLs are processed sequentially.
`The specifics regarding how an iACL should be constructed depend on the particular deployment
`scenario. However, an iACL generally consists of four distinct sections or modules, which are described
`in this section:
`
`The first module is designed to block any obvious illegitimate traffic, such as packets arriving with a
`source IP address belonging to the internal infrastructure address space, as this is clearly spoofing. In
`addition, the first section of the ACL should also prevent packets with source IP addresses in the private
`address space (RFC-1918), or special use addresses (RFC-3330). The following is an example of the
`required entries:
`
`! Deny your infrastructure space as a source of external packets
`access-list 101 deny ip your_public_infrastructure_block any
`! Deny src addresses of 0.0.0.0 and 127/8 (special useIPv4 addresses)
`access-list 101 deny ip host 0.0.0.0 any
`access-list 101 deny ip 127.0.0.0 0.255.255.255 any
`! Deny RFC1918 space from entering AS
`access-list 101 deny ip 10.0.0.0 0.255.255.255 any
`access-list 101 deny ip 172.16.0.0 0.0.15.255 any
`access-list 101 deny ip 192.168.0.0 0.0.255.255 any
`
`The second module should allow legitimate routing and management traffic (such as BGP, OSPF, SNMP,
`or SSH) destined to the infrastructure equipment. This requires a clear understanding of the legitimate
`traffic required by the specific infrastructure. An iACL built without the proper understanding of the
`protocols and the devices involved may end up blocking critical traffic. Unless you are careful, the iACL
`has the potential of delivering a DoS attack, instead of preventing it. The section “rACL Deployment
`Recommendations” section on page 15 describes a technique to facilitate the safe construction of iACLs.
`
`The following configuration fragment shows how the second section of the iACL would look if the only
`legitimate external traffic were eBGP and OSPF packets from specific peers:
`
`! Permit eBGP session
`access-list 101 permit tcp host bgp_peer host local_ip eq 179
`access-list 101 permit tcp host bgp_peer eq 179 host local_ip
`! Permit OSPF
`access-list 101 permit ospf host ospf_neighbour host 224.0.0.5
`! Permit DR multicast address, if needed
`access-list 101 permit ospf host ospf_neighbour host 224.0.0.6
`access-list 101 permit ospf host ospf_neighbour host local_ip
`
`OL-10601-01
`
`Infrastructure Protection on Cisco IOS Software-Based Platforms
`
`7
`
`

`
` Infrastructure Protection Access Control Lists
`
`
`
`The third module of the iACL should deny any other external traffic destined to the infrastructure address
`space, as shown in the following example:
`
`! Deny all other access to infrastructure
`access-list 101 deny ip any your_public_infrastructure_block
`
`The fourth and final module of the iACL should allow any transit traffic. In ISP networks, which are
`transit networks in nature, this part of the ACL is typically an entry allowing any other IP traffic, such
`as the following:
`
`! Permit transit traffic (ISP).
`access-list 101 permit ip any any
`
`Contrary to ISP networks, enterprise networks are typically the destination for traffic. Therefore the last
`section of the iACL can be made more restrictive, by only permitting the protocols and the IP addresses
`required for legitimate communications on a specific network. For example:
`
`! Permit only HTTP service traffic (Enterprise)
`access-list 101 permit tcp any 192.168.100.0 eq http
`
`This entry allows only HTTP traffic over TCP to a specific network.
`
`Expected Effectiveness
`
`Overall, iACLs are a great help for mitigating direct infrastructure attacks, and are highly recommended.
`However, there are circumstances in which iACLs may not be effective, including the following:
`
`• Attacks that use the IP addresses and protocols of trusted peers. Attackers may spoof the IP
`addresses and protocols used by trusted peers to match the permit statements in the iACL.
`
`• DoS initiated from trusted peers. Unintentional attacks may originate from trusted peers as a result
`of misconfiguration or intentional attacks launched from compromised trusted peers.
`
`Control Plane Policing (CoPP), explained in the “Control Plane Policing” section on page 21, is a feature
`that helps mitigate both cases, and its deployment should be considered in conjunction with iACLs.
`
`Also, keep in mind that iACLs are designed to secure the infrastructure and do not provide protection
`from attacks against targets other than the infrastructure itself.
`
`iACL Deployment Recommendations
`
`The first line of defense against external direct attacks on the infrastructure is provided by iACLs (see
`Figure 1). For this reason, you should apply iACLs inbound on the ingress interfaces of the routers acting
`as entry points to the network.
`
`Infrastructure Protection on Cisco IOS Software-Based Platforms
`
`8
`
`OL-10601-01
`
`

`
` Infrastructure Protection Access Control Lists
`
`
`
`Figure 1
`
`Infrastructure Protection ACLs—The First Line of Defense
`
`SRC: 127.0.0.1
`DST: any
`
`SRC: valid
`DST: Rx (any R)
`
`iACL "in"
`
`iACL "in"
`
`PR1
`
`PR2
`
`R2
`
`R1
`
`R3
`
`CR1
`
`R4
`
`R5
`
`CR2
`
`92679
`
`iACL "in"
`
`iACL "in"
`
`SRC: eBGP peer
`DST: CR1 eBGP
`
`SRC: valid
`DST: external to AS
`(e.g. customer)
`
`As previously mentioned, an iACL built without the proper understanding of the protocols and the
`devices involved may end up being ineffective and may even result in a denial of service (DoS)
`condition. For this reason, it is vital to gain an adequate level of understanding about the legitimate
`traffic destined to the infrastructure before deploying an iACL.
`
`In some networks, determining the exact traffic profile needed to build the filters required might be
`difficult. For this reason, this document recommends a conservative methodology for deploying iACLs.,
`using iterative ACL configurations to help identify and incrementally filter unwanted traffic as you gain
`a better understanding of the traffic on your network.
`
`To deploy iACLs using this conservative methodology, complete the following steps:
`
`Step 1
`
`Identify protocols used in the network using a discovery ACL.
`
`Start by deploying a discovery or classification ACL, which permits all the commonly used protocols
`that access infrastructure devices. “Appendix C—Commonly Used Protocols in the Infrastructure”
`contains a list of commonly used protocols in the infrastructure.
`The discovery ACL should have a source address of any and a destination address that encompasses the
`entire infrastructure IP address space. Logging can be used to develop a list of source addresses that
`match the protocol permit statements. A last line including permitting ip any any is required to enable
`traffic flow.
`
`The objective of configuring the discovery ACL is to determine the protocols that the specific network
`uses. Use the log keyword for analysis to determine what else might be communicating with the router.
`
`OL-10601-01
`
`Infrastructure Protection on Cisco IOS Software-Based Platforms
`
`9
`
`

`
` Infrastructure Protection Access Control Lists
`
`
`
`Note
`
`Although the log keyword provides valuable insight into the details of ACL hits, excessive hits to an
`ACL entry including this keyword might result in an overwhelming number of log entries and possibly
`high router CPU usage. Only use the log keyword for short periods of time as needed to help classify
`traffic.
`
`Step 2
`
`Review identified packets and begin filtering access to the infrastructure.
`
`Once the packets filtered by the discovery ACL have been identified and reviewed, deploy an ACL with
`a permit any source to infrastructure addresses for the expected protocols.
`As in Step 1, the log keyword can provide more information about the packets that match the permit
`entries. Using the deny ip any your_public_infrastructure_address_block command at the end can help
`identify any unexpected packets destined to the routers. The last line of this ACL should be a permit ip
`any any statement to permit the flow of transit traffic. This ACL will provide basic protection and will
`allow network engineers to ensure that all required traffic is permitted.
`
`Step 3
`
`Restrict the range of source addresses.
`
`Once you have a clear understanding of the protocols that must be permitted, further filtering can be
`performed to restrict the protocols to known or authorized source addresses. For example, you can
`explicitly permit external BGP neighbors or specific GRE peer addresses.
`
`This step narrows the risk of attack without breaking any services and allows you to apply granular
`control to sources that access your infrastructure equipment.
`
`Step 4
`
`(Optional): Limit the destination addresses within the iACL.
`
`This final phase is meant to limit the range of destination addresses that will accept traffic for a protocol.
`Some ISPs only allow specific protocols to use specific destination address on the router and this
`restriction may also be used for enterprise iACLs.
`
`Design Considerations and Limitations
`
`This section describes some additional design considerations and limitations to keep in mind when
`deploying iACLs. It includes the following topics:
`
`• ACLs and Fragmented Packets
`
`• Understanding Control and Management Plane Traffic
`
`• ACL Performance
`
`ACLs and Fragmented Packets
`
`ACLs provide a fragments keyword, which enables specialized fragmented packet handling behavior.
`In general, non-initial fragments that match the L3 statements (irrespective of the L4 information) in an
`ACL are affected by the permit or deny statement of the matched entry.
`
`In the iACL context, filtering fragments adds an additional layer of protection against DoS attacks that
`use only non-initial fragments (for example, FO > 0). However, the use of a deny statement for
`non-initial fragments at the beginning of the iACL will deny all non-initial fragments from accessing the
`router. Under rare circumstances, a valid session might require fragmentation and therefore might be
`filtered if a deny fragments statement exists in the iACL.
`
`Infrastructure Protection on Cisco IOS Software-Based Platforms
`
`10
`
`OL-10601-01
`
`

`
` Infrastructure Protection Access Control Lists
`
`
`
`For example, adding the following entries to the beginning of an iACL would deny any non-initial
`fragment access to the RP. However, non-fragmented packets or initial fragments would pass to the next
`lines of the iACL unaffected by the deny fragments statements.
`
`<<snip>>
`
`access-list 101 deny tcp any your_public_infrastructure_address_block fragments
`access-list 101 deny udp any your_public_infrastructure_address_block fragments
`access-list 101 deny icmp any your_public_infrastructure_address_block fragments
`...
`<<snip>>
`
`The above rACL snippet also facilitates classification of the attack because each protocol (UDP, TCP,
`and ICMP) increments separate counters in the ACL.
`
`Because many attacks rely on flooding core routers with fragmented packets, filtering incoming
`fragments to the core infrastructure provides an added measure of protection and helps ensure that an
`attack cannot inject fragments by simply matching Layer 3 rules in the iACL.
`
`See the following website for a detailed discussion of the options available for filtering fragments:
`
`http://www.cisco.com/warp/public/105/acl_wp.html#intro
`
`Understanding Control and Management Plane Traffic
`
`Care must be taken to ensure that the iACL does not filter critical traffic such as routing protocols or
`traffic required for management access to the routers. Filtering required traffic could disable remote
`access to the router, and connectivity would have to established with a local console connection.
`
`It is recommended that this feature should be tested in a lab configuration that mirrors the actual
`deployment as closely as possible before deployment.
`
`ACL Performance
`
`ACL performance varies from platform to platform. Before deploying ACLs, review the performance
`characteristics of your hardware.
`
`Platform and Software Availability
`
`Because iACLs are based on the widely available extended access control lists, they can be universally
`deployed on any Cisco IOS software-based routers.
`
`iACL Sample Configuration
`
`The example below shows an iACL protecting a router in a scenario involving the following addresses:
`
`• The ISP address block is 169.223.0.0/16
`
`• The ISP infrastructure block is 169.223.252.0/22
`
`• The loopback for the router is 169.223.253.1/32
`
`• The router is a peering router and peers with 169.223.253.2 (to address 169.223.253.1)
`
`The iACL shown below was developed based on this information. The ACL permits external BGP
`peering to the external peer, provides anti-spoof filters, and protects the infrastructure from all external
`access.
`
`OL-10601-01
`
`Infrastructure Protection on Cisco IOS Software-Based Platforms
`
`11
`
`

`
` Infrastructure Protection Access Control Lists
`
`
`
`!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
`! Infrastructure ACL Example
`!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
`
`o access-list 110
`
`! n
`
`! !
`
` !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
`!--- Module 1: Anti-spoofing Denies
`!--- These ACEs deny fragments, RFC 1918 space,
`!--- invalid source addresses, and spoofs of
`!--- internal space (space as an external source).
`
`! !
`
`--- Deny fragments.
`access-list 110 deny tcp any 169.223.252.0 0.0.252.255 fragments
`access-list 110 deny udp any 169.223.252.0 0.0.252.255 fragments
`access-list 110 deny icmp any 169.223.252.0 0.0.252.255 fragments
`!--- Deny special-use address sources.
`!--- See RFC 3330 for additional special-use addresses.
`access-list 110 deny ip host 0.0.0.0 any
`access-list 110 deny ip 127.0.0.0 0.255.255.255 any
`access-list 110 deny ip 192.0.2.0 0.0.0.255 any
`access-list 110 deny ip 224.0.0.0 31.255.255.255 any
`!--- Filter RFC 1918 space.
`access-list 110 deny ip 10.0.0.0 0.255.255.255 any
`access-list 110 deny ip 172.16.0.0 0.15.255.255 any
`access-list 110 deny ip 192.168.0.0 0.0.255.255 any
`
`! !
`
`!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
`!--- Module 2: Explicit Permit
`!--- Permit only applications/protocols whose destination
`!--- address is part of the infrastructure IP block.
`!--- The source of the traffic should be known and authorized.
`
`! !
`
`--- Note: This template must be tuned to the network’s
`!--- specific source address environment. Variables in
`!--- the template need to be changed.
`!--- Permit external BGP.
`access-list 110 permit tcp host 169.223.253.2 host 169.223.253.1 eq bgp
`access-list 110 permit tcp host 169.223.253.2 eq bgp host 169.223.253.1
`
`! !
`
`!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
`!--- Module 3: Explicit Deny to Protect Infrastructure
`access-list 110 deny ip any 169.223.252.0 0.0.252.255
`
`! !
`
`!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
`!--- Module 4: Explicit Permit for Transit Traffic
`access-list 110 permit ip any any
`
`Useful Debugs and Show Commands
`
`To verify ACL configurations, use the show command from EXEC mode.
`
`To display the contents of all access lists, enter the following command:
`
`Router# show access-lists
`
`To display the contents of one access list, enter the following command:
`
`Router# show ip access-list
`
`Infrastructure Protection on Cisco IOS Software-Based Platforms
`
`12
`
`OL-10601-01
`
`

`
`
`
` Receive Access Control Lists
`
`Related Tools
`
`Control Plane Policing (CoPP) complements iACLs by providing protection in the following situations
`where iACLs are not effective:
`
`• Attacks that spoof the IP addresses and protocols of trusted peers
`
`• DoS attacks initiated from trusted peers
`
`More Information
`
`For information beyond that provided in this section, see Protecting Your Core: Infrastructure Protection
`Access Control Lists (Document ID: 43920), available at the following website:
`http://www.cisco.com/en/US/tech/tk648/tk361/technologies_white_paper09186a00801a1a55.shtml
`
`Receive Access Control Lists
`
`Receive Access Controls Lists (rACLs) are designed to protect the RP on high-end routers from
`unnecessary traffic destined to the RP that could potentially affect system performance.
`
`Originally introduced for the Cisco 12000 Series Routers, rACLs are now available on other high-end
`routing platforms including the Cisco 7500 Series Routers and the Cisco 10000 Series Routers.
`
`Note
`
`Control Plane Policing (CoPP) is preferable, when it is available, because it provides rate limiting in
`addition to the filtering provided by rACLs (see the “Control Plane Policing” section on page 21).
`
`This section describes how to use and implement rACLs and includes the following topics:
`
`•
`
`rACL Technology Overview
`
`• Threat Vectors
`
`• Functional Overview
`
`• Expected Effectiveness
`
`•
`
`rACL Deployment Recommendations
`
`• Design Considerations and Limitations
`
`• Platform and Software Availability
`
`•
`
`rACL Sample Configuration
`
`• Useful Debugs and Show Commands
`
`• Related Tools
`
`• More Information
`
`rACL Technology Overview
`
`An rACL is a standard or an extended ACL that controls the traffic sent by the various line cards to the
`RP on distributed architectures like the Cisco 1200 Series Routers,. Note that rACLs do not apply to
`transit traffic.
`
`OL-10601-01
`
`Infrastructure Protection on Cisco IOS Software-Based Platforms
`
`13
`
`

`
` Receive Access Control Lists
`
`
`
`When configured, rACLs are first created on the RP, and then pushed to the line card CPU. When packets
`enter the line cards, the packets are first sent to the line card CPU. Packets requiring processing by the
`RP are compared against the rACL before being sent to the RP.
`An rACL typically consists of permit statements allowing the protocols and sources that are expected
`by the RP, and may also include deny statements explicitly blocking unwanted traffic. Like other ACLs,
`rACLs have an implicit deny ip any any at the end. To activate an rACL, enter the following command
`from global configuration mode:
`
`router(config)# ip receive access-list num
`
`Replace num with the number of the standard or the extended ACL.
`
`Threat Vectors
`
`An rACL helps mitigate attacks directed at the RP that are intended to overwhelm its capacity. On
`distribu