|
|
< Day Day Up > |
|
General Router SecurityThis 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 RoutersAccess requirements to a given router may include:
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). NOTE Use of SSH should be a service provider decision, depending on the likelihood of someone sniffing the backbone circuits. The best practice recommendation is to use Authentication, Authorization, and Accounting (AAA) network security services to provide the primary framework for setting up the access control on a router access server. NOTE Recommendation The best practice recommendation is to implement password administration for SNMP (SNMPv3 particularly has enhanced security features as discussed in the IETF RFCs 2272, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)" and 2274, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)." 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 SSHrouter(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 accessLine 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. NOTE The safest way to copy files from and to a router is the Secure Copy (SCP) feature, which is available on every IOS image that supports SSH. SCP uses the same strong security mechanisms as SSH in terms of encryption and authentication and is the recommended transfer method. To use SCP, type the following, for example: copy scp: flash: NOTE Disabling ifindex persist Feature Some service providers have found it quite necessary for SP performance management systems to have this capability enabled and also that SNMP communities should always be protected by an ACL, even when the community "password" is hard to guess. Reason: The ACL code is very efficient while starting to process SNMP, and its ASN.1 coding is CPU intensive and could be used for a DoS against the route processor. Disabling Unnecessary Services for SecurityMany 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:
NOTE This filtering prevents only redirect attacks launched by remote attackers. It is still possible for attackers to cause significant trouble using redirects if their host is directly connected to the same segment as a host that's under attack. 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. NOTE There are many other types of filters or schemas that need to be implemented in order to prevent attacks or security leaks, such as a close-group design, which does not allow its own address access from the Internet; additionally, a customer can only have access from the defined prefixes. 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.
NOTE For a service provider, IP packets should not be permitted from outside of the network except the strictly necessary ports for key network protocols such as routing. The concept of "infrastructure ACLs" enforces this notion. It is discussed later in this chapter in the section "Infrastructure Access Lists (iACLs)." IP Source Address VerificationEgress 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. NOTE RFC 2827, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing," (May 2000) provides general guidelines for all service providers on ingress and egress filtering. 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:
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. SyntaxA 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 ExamplesThe 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 NOTE As with all Cisco ACLs, there is an implicit deny statement at the end of the access list, so any traffic that does not match an entry in the ACL will be denied. Also note that one may need to open more "reply" packets, such as DNS packets from DNS servers, with newer IOS versions such as 25S or 27S, as the IOS may be using high port numbers access-list 110 permit tcp address mask any gt 10000 access-list 110 permit udp address mask any gt 10000 One needs this in order to get BGP functioning in some cases. When configured on two core routers, the preceding example would permit TCP from port 179 to port 179 only. Some other useful ports as examples: UDP+TCP port 646 for LDP: access-list 110 permit tcp address mask any eq 646 access-list 110 permit udp address mask any eq 646 APS, HSRP, and RTR/SAA: 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 PacketsACLs 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 Fragmentsaccess-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 NOTE Fragments are further explained at Cisco.com: http://www.cisco.com/en/US/partner/tech/tk827/tk369/technologies_white_paper09186a00800949b8.shtml. 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 GuidelinesWe 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 PolicingA router can be logically divided into three functional components or planes:
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:
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 SyntaxCoPP 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:
Developing a CoPP PolicyPrior 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.
Using the classification scheme defined above, commonly required traffic is identified with a series of ACLs:
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 NOTE ACL 123 is a "permit" entry for classification and monitoring purposes. This traffic will then be dropped as a result of the CoPP policy. CoPP Deployment GuidelinesTo 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:
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 NetworkAs 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:
Step 2. Classification ACLs and PoliciesDevelop 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 ProcessorOnce 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 AddressesOnly 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 AddressesIncreasingly 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 AddressesIdeally, 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 AssessmentCare 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 SummaryInfrastructure 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:
AutoSecureCisco AutoSecure is a Cisco IOS Security Command Line Interface (CLI) command. Customers can deploy one of its two modes, depending on their individual needs:
Cisco AutoSecure performs the following functions:
NOTE Prior to deploying Cisco AutoSecure, please check your network management application requirements. Some applications require services that may be disabled by Cisco AutoSecure. Also refer to Cisco.com for current updates on this capability, which has caused problems in certain cases (http://www.cisco.com/en/US/customer/products/sw/iosswrel/ps5207/products_field_notice09186a00803e13e9.shtml). Denial of service, spoofing, and other forms of attacks are on the increase on the Internet. Many of these attacks can be thwarted by judiciously using ingress filtering (filtering of packets originating from your network) and egress filtering (filtering of packets arriving from the Internet), hence the importance of filtering. |
|
|
< Day Day Up > |
|
11000 when sending out TCP and UDP packets. For example, one ISP implements the following lines:
processor.
Once undesirable traffic flow is identified, an ACE entry classifying it can be added and