General Router Security

This section focuses on elements required to secure a single router. Examples of network element security include generic router security measures that can be applied on a router. We build on these network element guidelines to provide best practice security recommendations for key MPLS network elements such as CE, PE, and P routers as an introduction to our core security recommendations, which follow this section.

In this section, we illustrate router security best practices that are valid on all routers in the network and include generic best practices such as using AAA, strong passwords, turning off unused services, and so on. We further introduce capabilities such as rACL, CoPP, and autosecure.

Secure Access to Routers

Access requirements to a given router may include:

• Pingability by the service provider personnel

• Pingability by the customer personnel (restricted to routers to which access is required)

• Interactive access by the service provider personnel (SSH, telnet)

• SNMP read/write access by the service provider personnel

• SNMP read access by the customer personnel, if required

• Privileged mode operation by the service provider personnel

Interactive access to the routers may be accomplished using SSH as a recommended best practice. The security and encryption inherent in SSH make it the only access protocol that should be used within any network environment where there is any risk of compromise (for example, it should be used everywhere except in a limited lab environment).

In general, with respect to a PE-CE link operation, the benefits gained by allowing ICMP echo mechanisms outweigh the risks associated therein. However, some rate limiting for the ICMP traffic would address this concern to a certain degree.

Example 5-1 depicts a configuration for SSH access to a router. To enable SSH, first configure both a host name and domain name. Then use the command crypto key generate rsa to create a key pair, which is required for SSH, as shown in Example 5-2. After the key creation, SSH will automatically be enabled, and some default SSH commands will appear.

Example 5-1. SSH-Controlled Access to a Router

               hostname top

               #required for SSH



               username cow secret 5 $1$9uVj$iPPDLOS.VE73x/Z3XChLc.

               aaa new-model

aaa authentication login default tacacs+ local enable

aaa authorization exec default tacacs+ local if-authenticated

aaa authorization commands 15 default tacacs+ local if-authenticated

               #simple AAA login control forcing verification of

               username/password pair as above



               ip domain name barstool.com

               #domain name required for RSA key generation



               access-list 13 permit 1.13.13.13

               access-list 13 deny any log

               #access-list permitting host 1.13.13.13 and denying/logging

                all else



               line vty 0 4

               access-class 13 in

               #access list limiting access to vty's



               transport input ssh



               #only SSH incoming connections permitted

After configuring what is shown in Example 5-1, it is necessary to generate the RSA keys, as Example 5-2 shows.

Example 5-2. Key Generation for SSH

router(config)#crypto key generate rsa

The name for the keys will be: top.cisco.com

Choose the size of the key modulus in the range of 360 to 2048 for your

  General Purpose Keys. Choosing a key modulus greater than 512 may take

  a few minutes.



How many bits in the modulus [512]:

% Generating 512 bit RSA keys ...[OK]



top(config)#

2d04h: SSH: host key initialized

2d04h: %SSH-5-ENABLED: SSH 1.5 has been enabled

2d04h: SSH: successfully generated server key

Within an MPLS VPN environment, the configuration constructs for telnet access have been altered to apply them to VRF instances. For example, when applying an access class to a set of VTYs, the parameter "vrf-also" is required. Failure to include this modifier will cause all telnet attempts from a CE to be refused. As such, application of a simple access list to the VTY ports will prevent access to the router, as previously recommended, and with the log keyword included in the explicit deny, inappropriate attempts will be logged.

A configuration example for denying CE telnet access may be found in Example 5-3.

Example 5-3. Controlling Telnet access

Line vty 0 4

       login

       password 884f2A

       access-class dog in

       #applies access-list dog to inbound telnet requests

       ip access-list standard dog

               permit 1.13.13.2

               deny any log

       #creates a named ACL "dog" which permits access from host

       1.13.13.2 denies and logs all other attempts

The operations of other access service functions, such as rsh, rcp, and tftp, are not changed when used within an MPLS VPN environment. That is, access control remains as it has been prior to MPLS VPNs, and such controls should be applied using the appropriate access control lists (ACLs) and authentication mechanisms. Note that these services would not normally be enabled on a PE or CE router?the security implications are unacceptable, and the management requirements for these functions are minimal.

copy scp: flash:

Disabling Unnecessary Services for Security

Many of the built-in services in Cisco IOS are not needed in a SP backbone environment. These features should be turned off in your default configuration because they are not needed and they represent a security risk. Turn them on only if there are explicit requirements.

Some of these will be preconfigured in IOS to be turned off by default, but service providers should ensure they are explicitly turned off in configuration files:

• no service finger? Disables the process, which listens for "finger" requests from remote hosts. Only SP personnel normally access the backbone routers, and there are other and better means of tracking who is logged in. Besides, finger is a known security risk in the Internet, due to its divulgence of detailed information of people logged into a system.

• no service pad? Simply not required. It refers back to the days of X.25 networking, and in recent versions of IOS has become the default.

• Small TCP and UDP servers? Those with port numbers below 10?typical services include "echo" and "discard" ports, the former echoing all packets sent to it, the latter throwing away all packets sent to it. If they are enabled and active, they could be used to carry out successful denial of service attacks?their use will divert CPU resources away from other processes, which will cause problems for the connected networks and the Internet service dependent on that router.

• bootp service? Provides support for systems that find their configuration using the bootp process. This is commonly used in LANs (X-terminals use bootp, for example) and never on the WAN. It should be disabled.

• Cisco Discovery Protocol (CDP)? Used for some network management functions, but is dangerous in that it allows any system on a directly connected segment to learn that the router is a Cisco device and to determine the model number and the Cisco IOS software version being run. This information may in turn be used to design attacks against the router. CDP information is accessible only to directly connected systems. The CDP protocol may be disabled with the global configuration command no cdp running. CDP may be disabled on a particular interface with no cdp enable.

• Network Time Protocol (NTP)? Not especially dangerous, but any unneeded service may represent a path for penetration. If NTP is actually used, it is important to explicitly configure a trusted time source and to use proper authentication because corrupting the time base is a good way to subvert certain security protocols. If NTP isn't being used on a particular router interface, it should be disabled with the interface command no ntp enable. Note that usually NTP is an important service, for example to get precise timestamps on logging messages.

• ICMP unreachables? Disabled with the command no ip unreachables. Normally, an interface responds with an ICMP unreachable message back to the sender, if a packet is dropped on that interface. This can be abused to deny service to an interface. Therefore, where the generation of ICMP unreachables is not required, it is recommended to disable the generation or to rate-limit the generation of ICMPs. Note also that the Null0 interface generates ICMP unreachables, such that this command should also be applied to Null0.

• ICMP redirect message? Instructs an end node to use a specific router as its path to a particular destination. In a properly functioning IP network, a router sends redirects only to hosts on its own local subnets. No end node will ever send a redirect, and no redirect will ever be traversed more than one network hop. However, an attacker may violate these rules; some attacks are based on this. It is a good idea to filter out incoming ICMP redirects at the input interfaces of any router that lies at a border between administrative domains, and it is not unreasonable for any access list that is applied on the input side of a Cisco router interface to filter out all ICMP redirects. This causes no operational impact in a correctly configured network.

The IP protocol supports source routing options that allow the sender of an IP datagram to control the route that datagram will take toward its ultimate destination and, generally, the route that any reply will take. These options are rarely used for legitimate purposes in real networks. Some older IP implementations do not process source-routed packets properly, and it may be possible to crash machines running these implementations by sending the datagrams with source routing options. Also note that source-routed packets allow the circumventing of ACLs, for example where the ACL is looking into the source and destination header field, only while ACLs are effectively irrelevant for source-routed packets. A Cisco router with no ip source-route set never forwards an IP packet carrying a source routing option. You should use this command unless you know that your network needs source routing.

Table 5-1 lists the ports that should be blocked in a router unless there is a specific requirement.

In the same way, the ports listed in Table 5-2 should be blocked for external users.

IP Source Address Verification

Egress and ingress filtering are a critical part of a service provider's router configuration strategy. Ingress filtering applies filters to traffic coming into a network from outside. This can be from a service provider's customers and/or from the Internet at large. The goal is to verify the source address of incoming packets to prevent source address spoofing. Egress filtering applies a filter for all traffic leaving a service provider's network.

Both filtering techniques help protect a service provider's resources and customer's networks, enforce policy, and minimize the risk of being the network chosen by hackers to launch an attack on other networks. Service providers are strongly encouraged to develop strategies using egress and ingress filtering to protect themselves from their customers and the Internet at large.

12000 Protection and Receive ACLs (rACLs)

Data received by a gigabit switch router (GSR) can be divided into two broad categories: traffic that passes through the router via the forwarding path and traffic that must be sent via the receive path to the gigabit router processor (GRP) for further analysis. In normal operations, the vast majority of traffic simply flows through a GSR in route to other destinations. However, the GRP must handle certain types of data, most notably routing protocols, remote router access, and network management traffic such as Simple Network Management Protocol (SNMP). In addition to the aforementioned traffic, other Layer 3 packets might require the processing flexibility of the GRP. These would include certain IP options and certain forms of Internet Control Message Protocol (ICMP) packets.

A GSR has several data paths, each servicing different forms of traffic. Transit traffic is forwarded from the ingress line card (LC) to the fabric and then to the egress card for next hop delivery. In addition to the transit traffic data path, a GSR has two other paths for traffic requiring local processing: LC-to-LC CPU and LC-to-LC CPU to fabric to GRP. Generally, GSRs should be protected against three scenarios, which may result from DoS attacks directed at a GRP of the router:

• Routing protocol packet loss from a normal-priority flood

• Management session (telnet, Secure Shell [SSH], SNMP) packet loss from a normal-priority flood

• Packet loss from a spoofed high-priority flood

rACLs affect traffic sent to the GRP because of receive adjacencies. Receive adjacencies are Cisco Express Forwarding adjacencies for traffic destined to the IP addresses of the router, such as the broadcast address or addresses configured on the interfaces of the router. Receive ACLs are part one of a multipart program range of mechanisms to protect the resources in a router Control Plane Policing (CoPP), as explained later in this chapter, and are a recommended best practice for rate limiting on the 12000 platform.

Syntax

A receive ACL is applied with the following global configuration command to distribute the rACL to each LC in the router as in Example 5-4.

Example 5-4. Global Configuration Command to Distribute rACL to Each LC

[no] ip receive access-list num

In this syntax, num is defined as follows.

1-199 IP access list (standard or extended)

1300-2699 IP expanded access list (standard or extended)

Basic Template and ACL Examples

The sample ACL shown in Example 5-5 provides a simple outline and presents some configuration examples that can be adapted for specific uses. The ACL illustrates the required configurations for several commonly required services/protocols. For SSH, telnet, and SNMP, a loopback address is used as the destination. For the routing protocols, the actual interface address is used. The choice of router interfaces to use in the rACL is determined by local site policies and operations. For instance, if loopbacks are used for all BGP peering sessions, then only those loopbacks need to be permitted in the permit statements for BGP. These are nicely explained at Cisco.com.

Example 5-5. Basic ACL Template

!--- Permit BGP.



access-list 110 permit tcp host bgp_peer host loopback eq bgp

!--- Permit OSPF.



access-list 110 permit ospf host ospf_neighbor host 224.0.0.5

!--- Permit designated router multicast address, if needed.



access-list 110 permit ospf host ospf_neighbor host 224.0.0.6

access-list 110 permit ospf host ospf_neighbor host local_ip

!--- Permit Enhanced Interior Gateway Routing Protocol (EIGRP).



access-list 110 permit eigrp host eigrp_neighbor host 224.0.0.10

access-list 110 permit eigrp host eigrp_neighbor host local_ip

!--- Permit remote access by telnet and SSH.



access-list 110 permit tcp management_addresses host loopback eq 22

access-list 110 permit tcp management_addresses host loopback eq telnet

!--- Permit SNMP.



access-list 110 permit udp host NMS_stations host loopback eq snmp

!--- Permit Network Time Protocol (NTP).



access-list 110 permit udp host ntp_server host loopback eq ntp

!--- Router-originated traceroute:

!--- Each hop returns a message that time to live (ttl)

!--- has been exceeded (type 11, code 3);

!--- the final destination returns a message that

!--- the ICMP port is unreachable (type 3, code 0).



access-list 110 permit icmp any any ttl-exceeded

access-list 110 permit icmp any any port-unreachable

!--- Permit TACACS for router authentication.



access-list 110 permit tcp host tacacs_server router_src established

!--- Permit RADIUS.



access-list 110 permit udp host radius_server router_src log

!--- Permit FTP for IOS upgrades.



access-list 110 permit tcp host image_server eq ftp host router_ip_address

access-list 110 permit tcp host image_sever eq ftp-data host router_ip_address

access-list 110 permit tcp address mask any gt 10000

access-list 110 permit udp address mask any gt 10000

access-list 110 permit tcp address mask any eq 646

access-list 110 permit udp address mask any eq 646

access-list 110 permit udp address mask eq 1972 any eq

access-list 110 permit udp any eq 1985 host 224.0.0.2 eq 1985

access-list 110 permit udp address mask any eq 1967

access-list 110 permit udp address mask any eq 5000

rACLS and Fragmented Packets

ACLs have a fragments keyword that enables specialized fragmented packet-handling behavior. In general, noninitial 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. Note that the use of the fragments keyword can force ACLs to either deny or permit noninitial fragments with more granularity.

In the rACL context, filtering fragments adds an additional layer of protection against a DoS attack that uses only noninitial fragments (such as FO > 0). Using a deny statement for noninitial fragments at the beginning of the rACL denies all noninitial fragments from accessing the router. Under rare circumstances, a valid session might require fragmentation and therefore be filtered if a deny fragment statement exists in the rACL.

For example, consider the partial ACL shown in Example 5-6.

Example 5-6. Filtering Fragments

access-list 110 deny tcp any any fragments

access-list 110 deny udp any any fragments

access-list 110 deny icmp any any fragments

output omitted

Adding these entries to the beginning of an rACL denies any noninitial fragment access to the GRP, while nonfragmented packets or initial fragments pass to the next lines of the rACL unaffected by the deny fragment statements. The preceding rACL snippet also facilitates classification of the attack because each protocol?Universal Datagram Protocol (UDP), TCP, and ICMP?increments separate counters in the ACL. We recommend that you test this feature in the lab prior to deployment.

Deployment Guidelines

We recommend conservative deployment practices. To successfully deploy rACLs, the existing control and management plane access requirements must be well understood. In some networks, determining the exact traffic profile needed to build the filtering lists might be difficult. The following guidelines describe a very conservative approach for deploying rACLs using iterative rACL configurations to help identify and eventually filter traffic.

Some key best practice guidelines include:

Control Plane Policing

A router can be logically divided into three functional components or planes:

• Data plane

• Management plane

• Control plane

The vast majority of traffic generally travels through the router via the data plane; however, the route processor must handle certain packets, such as routing updates, keepalives, and network management. This is often referred to as control and management plane traffic.

The route processor is critical to network operation, so any service disruption to the route processor, and hence the control and management planes, can lead to business-impacting network outages. A denial of service (DoS) attack targeting the route processor, which can be perpetrated either inadvertently or maliciously, typically involves high rates of RP-destined traffic that result in excessive CPU utilization on the route processor itself. Such an attack can be devastating to network stability and availability and may include the following symptoms that can be addressed via the use of Control Plane Policing or CoPP:

• High route processor CPU utilization (near 100%)

• Loss of line protocol keepalives and routing protocol updates, leading to route flaps and major network transitions

• Interactive sessions via the Command Line Interface (CLI) being slow or completely unresponsive due to high CPU utilization

• Route processor resource exhaustion: resources such as memory and buffers unavailable for legitimate IP data packets

• Backing up of packet queues, leading to indiscriminate drops (or drops due to lack of buffer resources) of other incoming packets

CoPP addresses the need to protect the control and management planes, ultimately ensuring routing stability, reachability, and packet delivery. It uses a dedicated control-plane configuration via the modular quality of service (QoS) CLI (MQC) to provide filtering and rate limiting capabilities for control plane packets.

Command Syntax

CoPP leverages MQC to define traffic classification criteria and specify configurable policy actions for the classified traffic. Traffic of interest must first be identified via class maps, which are used to define packets for a particular traffic class. Once classified, enforceable policy actions for the identified traffic are created with policy maps. The control-plane global command allows the CP service policies to be attached to the control plane itself.

There are four steps required to configure CoPP:

router(config)#class-map traffic_class_name



router(config-cmap)#match access-list | protocol | ip prec | ip dscp | vlan

router(config-pmap)#policy-map service_policy_name



router(config-pmap)#class traffic_class_name



router(config-pmap-c)#police cir rate conform-action transmit exceed-action drop

router(config)#control-plane

service-policy    {input | output} service_policy_name



input  Assign policy-map to the input of an interface



output2     Assign policy-map to the output of an interface

Developing a CoPP Policy

Prior to developing the actual CoPP policy, required traffic must be identified and separated into different classes. One recommended methodology involves stratifying traffic into distinct groups based on relative importance. In the example discussed in this section, traffic is grouped into five different classes, as listed next. The actual number of classes needed might differ and should be selected based on local requirements, security policies, and a thorough analysis of the customer's baseline "normal" traffic.

• Critical

  - Traffic that is crucial to the operation of the router and the network.

  - Examples: Routing protocols such as Border Gateway Protocol (BGP) and Open Shortest Path First (OSPF).

  - Local site policy should dictate what traffic is deemed critical.

• Important

  - Necessary, frequently used traffic that is required during day-to-day operations.

  - Examples: Traffic used for remote network access and management, such as telnet, Secure Shell (SSH), Network Time Protocol (NTP), and Simple Network Management Protocol (SNMP).

• Normal

  - Traffic that is expected but not essential to network operation.

  - Examples: ICMP echo request (ping)

  - Normal traffic used to be particularly hard to address when designing control-plane protection schemes, as it should be permitted but should never pose a risk to the router. With CoPP, this traffic can be permitted but limited to a low rate

• Undesirable

  - Explicitly identifies "bad" or malicious traffic that should be dropped and denied access to the route processor.

  - Particularly useful when known traffic destined to the router should always be denied and not placed into a default category. Explicitly denying traffic allows the end user to collect rough statistics on this traffic via show commands and therefore offers some insight into the rate of denied traffic.

• Default

  - All remaining traffic destined to the route processor that has not been identified.

  - MQC provides the default class so the user can specify the treatment to be meted out to traffic not explicitly identified in the other user-defined classes. It is desirable to give such traffic access to the route processor but at a highly reduced rate.

  - With a default classification in place, statistics can be monitored to determine the rate of otherwise unidentified traffic destined to the control plane. Once this traffic is identified, further analysis can be performed to classify it, and if needed the other CoPP policy entries can be updated to account for this traffic.

Using the classification scheme defined above, commonly required traffic is identified with a series of ACLs:

• ACL 120: Critical traffic

• ACL 121: Important traffic

• ACL 122: Normal traffic

• ACL 123: Explicitly denies unwanted traffic (slammer worm traffic in this example)

The ACLs will then build classes of traffic that are used to define the policies.

In Example 5-11, the router IP address for control/management traffic will be 10.1.1.1.

Example 5-11. Sample Basic ACLs for CoPP Classification

! Sample basic ACLs for CoPP classification

! In this network, critical was defined at routing protocols: BGP and OSPF

access-list 120 remark CoPP ACL for critical traffic

! Allow BGP from a known peer to this router's BGP TCP port

access-list 120 permit tcp host 192.168.1.1 host 10.1.1.1 eq bgp

! Allow BGP from a peer's BGP port to this router

access-list 120 permit tcp host 192.168.1.1 eq bgp host 10.1.1.1

access-list 120 permit tcp host 192.168.2.1 host 10.1.1.1 eq bgp

access-list 120 permit tcp host 192.168.2.1 eq bgp host 10.1.1.1

! Permit OSPF

access-list 120 permit ospf any host 224.0.0.5

access-list 120 permit ospf any host 224.0.0.6

access-list 120 permit ospf any any

! Important is defined as traffic that is required for access to and management of the router

access-list 121 remark CoPP Important traffic

! Permit return traffic from TACACS host

access-list 121 permit tcp host 10.2.1.1 host 10.1.1.1 established

! SSH access to the router from a subnet

access-list 121 permit tcp 10.2.1.0 0.0.0.255 host 10.1.1.1 eq 22

! telnet access to the router from a specific subnet

access-list 121 permit tcp 10.86.183.0 0.0.0.255 any eq telnet

! SNMP access from the NMS host to the router

access-list 121 permit udp host 10.2.2.2 host 10.1.1.1 eq snmp

! Allow the router to receive NTP packets from a known clock source

access-list 121 permit udp host 10.2.2.3 host 10.1.1.1 eq ntp

! In this classification scheme, normal traffic is traffic that we expect to see destined to

the router and want to track and limit

access-list 122 remark CoPP normal traffic

! Permit router-originated traceroute

access-list 122 permit icmp any any ttl-exceeded

access-list 122 permit icmp any any port-unreachable

! Permit receipt of responses to router-originated pings

access-list 122 permit icmp any any echo-reply

! Allow pings to router

access-list 122 permit icmp any any echo

! This ACL identifies traffic that should always be blocked from accessing the route

 processor.

Once undesirable traffic flow is identified, an ACE entry classifying it can be added and

 mapped

to the undesirable traffic class. This can be used as a reaction tool.

access-list 123 remark explicitly defined "undesirable" traffic

! Permit, for policing, all traffic destined to UDP 1434

access-list 123 permit udp any any eq 1434

CoPP Deployment Guidelines

To successfully deploy CoPP, the existing control and management plane access requirements must be well understood. Determining the exact traffic profile required to build the filtering lists can be difficult. Following is a summary of the previous section:

• Start the deployment by defining liberal policies that allow most traffic through to the route processor (RP).

• Use show policy-map and show access-lists to figure out your traffic patterns.

• Use the statistics gathered in step 2 above to tune up your policies.

The following guidelines describe a very conservative approach for deploying CoPP using iterative ACL and policy configurations to help identify and eventually filter traffic:

Step 1. Determine Classification Scheme for Your Network

As described in the earlier section, a classification scheme can simplify the CoPP policy development. Enumerate the known protocols that access the route processor and divide them into categories:

• Example: critical, important, normal, undesirable, and default traffic classes for policy development.

• Select a scheme suited to the individual environment, which may require a greater or lesser number of classes.

Step 2. Classification ACLs and Policies

Develop an ACL that permits all known protocols requiring access to the route processor. Cisco recommends the use of distinct ACL numbers for each type of traffic defined in Step 1, in order to ease management. These "discovery" ACLs should have both the source and destination addresses set to "any". The final entry in the last ACL4 should be a permit IP any any. This will match traffic not explicitly permitted by other entries in the other ACLs.

Once the ACLs have been configured, apply them to a corresponding set of class maps using descriptive names, if possible. These class maps should be applied to a policy map that permits all traffic, regardless of classification. A default policy is not required at this stage of policy development.

The router(config-pmap) #class traffic_class_name command can ascertain which entries in the ACL are in use, as well as the number of packets permitted by the final ACL entry (that is, the match ip any any ACE). The objective is to identify the protocols used by a given network.

Ideally, the classification performed in Step 1 identified all required traffic destined to the router. Realistically, not all required traffic will be identified prior to deployment, and the permit ip any any access list entry will log a number of packet matches. Some form of analysis will be required to determine the exact nature of the unclassified packets. This extra classification step can be accomplished using several techniques: general ACL classification, as described in "Characterizing and tracing packet floods using Cisco Routers, packet analyzers, or using Receive ACLs (Cisco 7500 Series Router and Cisco 12000 Series Internet Router only)."

Once classified, the traffic can be either handled accordingly.

The router(config-pmap-c)# police cir <rate> conform-action transmit exceed-action drop command should be used to collect data about the actual policies in place: packet count and rate information will help develop a baseline for increasingly granular policy.

Step 3. Review Identified Packets and Begin to Filter Access to the Route Processor

Once the packets permitted by the ACLs in Step 2 have been identified and reviewed, a set of ACLs, updated if necessary, with a permit any any statement for the allowed protocols should be deployed. The permit any any in the final ACL should be removed. The key change in this step is the addition of the class-default policy: this default will apply to all traffic not otherwise identified by an ACL.

The objective is to test the range of protocols that need to communicate with the router without filtering the explicit range of IP source and destination addresses.

As with Step 2, show commands should be used to review the affect of the policy, particularly the rate data reported by the router(config)#control-plane command.

Step 4. Restrict a Macro Range of Source Addresses

Only allow the full range of the allocated CIDR block to be permitted as the source address. For example, if the network has been allocated 172.68.0.0/16, then permit the source address from just 172.68.0.0/16 where applicable.

This step limits the risk without breaking any services. It also provides data points of devices/people from outside the CIDR block that might be accessing the equipment.

The eBGP peer will require an exception; the permitted source addresses for the session will lie outside the CIDR block. This phase might be left on for a few days to collect data for the next phase of narrowing the ACL entries.

Step 5. Narrow the ACL Permit Statements to Only Allow Known Authorized Source Addresses

Increasingly limit the source address to only permit sources that communicate with the route processor. For instance, only network management station (NMS) workstations should be permitted to access the SNMP ports on a router. Note that filtering for the source address is recommended when one can safely assume that the source address cannot be spoofed.

Step 6. (Optional): Limit the Destination Addresses

Ideally, only allow specific protocols to use specific destination addresses on the router. This final phase is meant to limit the range of destination addresses that will accept traffic for a protocol. For instance, BGP peering typically occurs via loopback addresses, while BGP traffic can be permitted only to the loopback interface.

Risk Assessment

Care must be taken to ensure that the CoPP policy does not filter critical traffic such as routing protocols or interactive access to the routers. Filtering this traffic could prevent remote access to the router, thus requiring a console connection. For this reason, lab configurations should mimic the actual deployment as closely as possible.

We recommend that customers test this feature in their lab prior to deployment.

CoPP Summary

Infrastructure attacks are becoming increasingly common, highlighting the need for infrastructure protection. Control Plane Policing (CoPP) provides a hardware-independent mechanism for defining and implementing router protection schemes of varying sophistication. In its most basic form, CoPP can be used to permit or deny traffic destined to the router's processor. As operational experience grows, so does the complexity of the policy. The rate limiting features provide extremely flexible policy implementation.

CoPP deployment provides several key benefits:

• Protects against DoS attacks targeted toward the network infrastructure.

• Eases deployment: CoPP leverages the existing MQC infrastructure, which allows customers to preserve the existing interface configurations and add global commands to address the aforementioned security goals.

• Provides a consistent implementation strategy across all Cisco hardware.

• Increases the reliability, security, and availability of router services.

AutoSecure

Cisco AutoSecure is a Cisco IOS Security Command Line Interface (CLI) command. Customers can deploy one of its two modes, depending on their individual needs:

• Interactive mode? Prompts the user with options for enabling and disabling services and other security features.

• Noninteractive mode? Automatically executes the Cisco AutoSecure command with the recommended Cisco default settings.

Cisco AutoSecure performs the following functions:

• Disables the following Global Services

  - Finger

  - PAD

  - Small servers

  - Bootp

  - HTTP service

  - Identification service

  - CDP

  - NTP

  - Source routing

• Enables the following Global Services

  - Password-encryption service

  - Tuning of scheduler interval/allocation

  - TCP synwait-time

  - TCP-keepalives-in and tcp-kepalives-out

  - SPD configuration

  - No ip unreachables for null 0

• Disables the following services per interface

  - ICMP

  - Proxy-Arp

  - Directed Broadcast

  - Disables MOP service

  - Disables icmp unreachables

  - Disables icmp mask reply messages.

• Provides logging for security

  - Enables sequence numbers and timestamps

  - Provides a console log

  - Sets log buffered size

  - Provides an interactive dialogue to configure the logging server ip address.