Word Fix Disable 1.0.0.0 serial key or number

Introduction

This document describes the information to help you secure your Cisco IOS^® system devices, which increases the overall security of your network. Structured around the three planes into which functions of a network device can be categorized, this document provides an overview of each included feature and references to related documentation.

Prerequisites

Requirements

There are no specific requirements for this document.

Components Used

This document is not restricted to specific software and hardware versions.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Background Information

The three functional planes of a network, the management plane, control plane, and data plane, each provide different functionality that needs to be protected.

• Management Plane - The management plane manages traffic that is sent to the Cisco IOS device and is made up of applications and protocols such as Secure Shell (SSH) and Simple Network Management Protocol (SNMP).
  
  
• Control Plane - The control plane of a network device processes the traffic that is paramount to maintain the functionality of the network infrastructure. The control plane consists of applications and protocols between network devices, which includes the Border Gateway Protocol (BGP), as well as the Interior Gateway Protocols (IGPs) such as the Enhanced Interior Gateway Routing Protocol (EIGRP) and Open Shortest Path First (OSPF).
  
  
• Data Plane - The data plane forwards data through a network device. The data plane does not include traffic that is sent to the local Cisco IOS device.

The coverage of security features in this document often provides enough detail for you to configure the feature. However, in cases where it does not, the feature is explained in such a way that you can evaluate whether additional attention to the feature is required. Where possible and appropriate, this document contains recommendations that, if implemented, help secure a network.

Secure Operations

Secure network operations is a substantial topic. Although most of this document is devoted to the secure configuration of a Cisco IOS device, configurations alone do not completely secure a network. The operational procedures in use on the network contribute as much to security as the configuration of the underlying devices.

These topics contain operational recommendations that you are advised to implement. These topics highlight specific critical areas of network operations and are not comprehensive.

Monitor Cisco Security Advisories and Responses

The Cisco Product Security Incident Response Team (PSIRT) creates and maintains publications, commonly referred to as PSIRT Advisories, for security-related issues in Cisco products. The method used for communication of less severe issues is the Cisco Security Response. Security advisories and responses are available at manicapital.com

Additional information about these communication vehicles is available in the Cisco Security Vulnerability Policy.

In order to maintain a secure network, you need to be aware of the Cisco security advisories and responses that have been released. You need to have knowledge of a vulnerability before the threat it can pose to a network can be evaluated. Refer to Risk Triage for Security Vulnerability Announcements for assistance this evaluation process.

Leverage Authentication, Authorization, and Accounting

The Authentication, Authorization, and Accounting (AAA) framework is vital to secure network devices. The AAA framework provides authentication of management sessions and can also limit users to specific, administrator-defined commands and log all commands entered by all users. See the Authentication, Authorization, and Accounting section of this document for more information about how to leverage AAA.

Centralize Log Collection and Monitoring

In order to gain knowledge about existing, emerging, and historic events related to security incidents, your organization must have a unified strategy for event logging and correlation. This strategy must leverage logging from all network devices and use pre-packaged and customizable correlation capabilities.

After centralized logging is implemented, you must develop a structured approach to log analysis and incident tracking. Based on the needs of your organization, this approach can range from a simple diligent review of log data to advanced rule-based analysis.

See the Logging Best Practices section of this document for more information about how to implement logging on Cisco IOS network devices.

Use Secure Protocols When Possible

Many protocols are used in order to carry sensitive network management data. You must use secure protocols whenever possible. A secure protocol choice includes the use of SSH instead of Telnet so that both authentication data and management information are encrypted. In addition, you must use secure file transfer protocols when you copy configuration data. An example is the use of the Secure Copy Protocol (SCP) in place of FTP or TFTP.

See the Secure Interactive Management Sessions section of this document for more information about the secure management of Cisco IOS devices.

Gain Traffic Visibility with NetFlow

NetFlow enables you to monitor traffic flows in the network. Originally intended to export traffic information to network management applications, NetFlow can also be used in order to show flow information on a router. This capability allows you to see what traffic traverses the network in real time. Regardless of whether flow information is exported to a remote collector, you are advised to configure network devices for NetFlow so that it can be used reactively if needed.

More information about this feature is available in the Traffic Identification and Traceback section of this document and at manicapital.com (registered customers only) .

Configuration Management

Configuration management is a process by which configuration changes are proposed, reviewed, approved, and deployed. Within the context of a Cisco IOS device configuration, two additional aspects of configuration management are critical: configuration archival and security.

You can use configuration archives to roll back changes that are made to network devices. In a security context, configuration archives can also be used in order to determine which security changes were made and when these changes occurred. In conjunction with AAA log data, this information can assist in the security auditing of network devices.

The configuration of a Cisco IOS device contains many sensitive details. Usernames, passwords, and the contents of access control lists are examples of this type of information. The repository that you use in order to archive Cisco IOS device configurations needs to be secured. Insecure access to this information can undermine the security of the entire network.

Management Plane

The management plane consists of functions that achieve the management goals of the network. This includes interactive management sessions that use SSH, as well as statistics-gathering with SNMP or NetFlow. When you consider the security of a network device, it is critical that the management plane be protected. If a security incident is able to undermine the functions of the management plane, it can be impossible for you to recover or stabilize the network.

These sections of this document detail the security features and configurations available in Cisco IOS software that help fortify the management plane.

General Management Plane Hardening

The management plane is used in order to access, configure, and manage a device, as well as monitor its operations and the network on which it is deployed. The management plane is the plane that receives and sends traffic for operations of these functions. You must secure both the management plane and control plane of a device, because operations of the control plane directly affect operations of the management plane. This list of protocols is used by the management plane:

• Simple Network Management Protocol
  
  
• Telnet
  
  
• Secure Shell Protocol
  
  
• File Transfer Protocol
  
  
• HyperText Transfer Protocol / Secure HyperText Transfer Protocol

• Trivial File Transfer Protocol
  
  
• Secure Copy Protocol
  
  
• TACACS+
  
  
• RADIUS
  
  
• NetFlow
  
  
• Network Time Protocol
  
  
• Syslog

Steps must be taken to ensure the survival of the management and control planes during security incidents. If one of these planes is successfully exploited, all planes can be compromised.

Password Management

Passwords control access to resources or devices. This is accomplished through the definition a password or secret that is used in order to authenticate requests. When a request is received for access to a resource or device, the request is challenged for verification of the password and identity, and access can be granted, denied, or limited based on the result. As a security best practice, passwords must be managed with a TACACS+ or RADIUS authentication server. However, note that a locally configured password for privileged access is still needed in the event of failure of the TACACS+ or RADIUS services. A device can also have other password information present within its configuration, such as an NTP key, SNMP community string, or Routing Protocol key.

The enable secret command is used in order to set the password that grants privileged administrative access to the Cisco IOS system. The enable secret command must be used, rather than the older enable password command. The enable password command uses a weak encryption algorithm.

If no enable secret is set and a password is configured for the console tty line, the console password can be used in order to receive privileged access, even from a remote virtual tty (vty) session. This action is almost certainly unwanted and is another reason to ensure configuration of an enable secret.

The service password-encryption global configuration command directs the Cisco IOS software to encrypt the passwords, Challenge Handshake Authentication Protocol (CHAP) secrets, and similar data that are saved in its configuration file. Such encryption is useful in order to prevent casual observers from reading passwords, such as when they look at the screen over the muster of an administrator. However, the algorithm used by the service password-encryption command is a simple Vigen re cipher. The algorithm is not designed to protect configuration files against serious analysis by even slightly sophisticated attackers and must not be used for this purpose. Any Cisco IOS configuration file that contains encrypted passwords must be treated with the same care that is used for a cleartext list of those same passwords.

While this weak encryption algorithm is not used by the enable secret command, it is used by the enable password global configuration command, as well as the password line configuration command. Passwords of this type must be eliminated and the enable secret command or the Enhanced Password Security feature needs to be used.

The enable secret command and the Enhanced Password Security feature use Message Digest 5 (MD5) for password hashing. This algorithm has had considerable public review and is not known to be reversible. However, the algorithm is subject to dictionary attacks. In a dictionary attack, an attacker tries every word in a dictionary or other list of candidate passwords in order to find a match. Therefore, configuration files must be securely stored and only shared with trusted individuals.

Enhanced Password Security

The feature Enhanced Password Security, introduced in Cisco IOS Software Release (8)T, allows an administrator to configure MD5 hashing of passwords for the username command. Prior to this feature, there were two types of passwords: Type 0, which is a cleartext password, and Type 7, which uses the algorithm from the Vigen re cipher. The Enhanced Password Security feature cannot be used with protocols that require the cleartext password to be retrievable, such as CHAP.

In order to encrypt a user password with MD5 hashing, issue the username secret global configuration command.

!

username <name> secret <password>

!

Refer toEnhanced Password Security for more information about this feature.

Login Password Retry Lockout

The Login Password Retry Lockout feature, added in Cisco IOS Software Release (14)T, allows you to lock out a local user account after a configured number of unsuccessful login attempts. Once a user is locked out, their account is locked until you unlock it. An authorized user who is configured with privilege level 15 cannot be locked out with this feature. The number of users with privilege level 15 must be kept to a minimum.

Note that authorized users can lock themselves out of a device if the number of unsuccessful login attempts is reached. Additionally, a malicious user can create a denial of service (DoS) condition with repeated attempts to authenticate with a valid username.

This example shows how to enable the Login Password Retry Lockout feature:

!

aaa new-model
aaa local authentication attempts max-fail <max-attempts>
aaa authentication login default local

!

username <name> secret <password>

!

This feature also applies to authentication methods such as CHAP and Password Authentication Protocol (PAP).

No Service Password-Recovery

In Cisco IOS Software Release (14)T and later, the No Service Password-Recovery feature does not allow anyone with console access to insecurely access the device configuration and clear the password. It also does not allow malicious users to change the configuration register value and access NVRAM.

!

no service password-recovery

!

Cisco IOS software provides a password recovery procedure that relies upon access to ROM Monitor Mode (ROMMON) using the Break key during system startup. In ROMMON, the device software can be reloaded in order to prompt a new system configuration that includes a new password.

The current password recovery procedure enables anyone with console access to access the device and its network. The No Service Password-Recovery feature prevents the completion of the Break key sequence and the entering of ROMMON during system startup.

If no service password-recovery is enabled on a device, it is recommended that an offline copy of the device configuration be saved and that a configuration archiving solution be implemented. If it is necessary to recover the password of a Cisco IOS device once this feature is enabled, the entire configuration is deleted.

Refer toSecure ROMMON Configuration Example for more information about this feature.

Disable Unused Services

As a security best practice, any unnecessary service must be disabled. These unneeded services, especially those that use User Datagram Protocol (UDP), are infrequently used for legitimate purposes but can be used in order to launch DoS and other attacks that are otherwise prevented by packet filtering.

The TCP and UDP small services must be disabled. These services include:

• echo (port number 7)
  
  
• discard (port number 9)
  
  
• daytime (port number 13)
  
  
• chargen (port number 19)

Although abuse of the small services can be avoided or made less dangerous by anti-spoofing access lists, the services must be disabled on any device accessible within the network. The small services are disabled by default in Cisco IOS Software Releases and later. In earlier software, the no service tcp-small-servers and no service udp-small-servers global configuration commands can be issued in order to disable them.

This is a list of additional services that must be disabled if not in use:

• Issue the no ip finger global configuration command in order to disable Finger service. Cisco IOS software releases later than (5) and (5)T disable this service by default.
  
  
• Issue the no ip bootp server global configuration command in order to disable Bootstrap Protocol (BOOTP).
  
  
• In Cisco IOS Software Release (8)T and later, issue the ip dhcp bootp ignore command in global configuration mode in order to disable BOOTP. This leaves Dynamic Host Configuration Protocol (DHCP) services enabled.
  
  
• DHCP services can be disabled if DHCP relay services are not required. Issue the no service dhcp command in global configuration mode.
  
  
• Issue the no mop enabled command in interface configuration mode in order to disable the Maintenance Operation Protocol (MOP) service.
  
  
• Issue the no ip domain-lookup global configuration command in order to disable Domain Name System (DNS) resolution services.
  
  
• Issue the no service pad command in global configuration mode in order to disable Packet Assembler/Disassembler (PAD) service, which is used for X networks.
  
  
• The HTTP server can be disabled with the no ip http server command in global configuration mode, and Secure HTTP (HTTPS) server can be disabled with the no ip http secure-server global configuration command.
  
  
• Unless Cisco IOS devices retrieve configurations from the network during startup, the no service config global configuration command must be used. This prevents the Cisco IOS device from an attempt to locate a configuration file on the network with TFTP.
  
  
• Cisco Discovery Protocol (CDP) is a network protocol that is used in order to discover other CDP enabled devices for neighbor adjacency and network topology. CDP can be used by Network Management Systems (NMS) or during troubleshooting. CDP must be disabled on all interfaces that are connected to untrusted networks. This is accomplished with the no cdp enable interface command. Alternatively, CDP can be disabled globally with the no cdp run global configuration command. Note that CDP can be used by a malicious user for reconnaissance and network mapping.
  
  
• Link Layer Discovery Protocol (LLDP) is an IEEE protocol that is defined in AB. LLDP is similar to CDP. However, this protocol allows interoperability between other devices that do not support CDP. LLDP must be treated in the same manner as CDP and disabled on all interfaces that connect to untrusted networks. In order to accomplish this, issue the no lldp transmit and no lldp receive interface configuration commands. Issue the no lldp run global configuration command in order to disable LLDP globally. LLDP can also be used by a malicious user for reconnaissance and network mapping.

• For switches that support booting from sdflash, security can be enhanced by booting from flash and disabling sdflash with the “no sdflash” configuration command.

EXEC Timeout

In order to set the interval that the EXEC command interpreter waits for user input before it terminates a session, issue the exec-timeout line configuration command. The exec-timeout command must be used in order to logout sessions on vty or tty lines that are left idle. By default, sessions are disconnected after ten minutes of inactivity.

!

line con 0
exec-timeout <minutes> [seconds]
line vty 0 4
exec-timeout <minutes> [seconds]
!

Keepalives for TCP Sessions

The service tcp-keepalives-in and service tcp-keepalives-out global configuration commands enable a device to send TCP keepalives for TCP sessions. This configuration must be used in order to enable TCP keepalives on inbound connections to the device and outbound connections from the device. This ensures that the device on the remote end of the connection is still accessible and that half-open or orphaned connections are removed from the local Cisco IOS device.

!

service tcp-keepalives-in
service tcp-keepalives-out
!

Management Interface Use

The management plane of a device is accessed in-band or out-of-band on a physical or logical management interface. Ideally, both in-band and out-of-band management access exists for each network device so that the management plane can be accessed during network outages.

One of the most common interfaces that is used for in-band access to a device is the logical loopback interface. Loopback interfaces are always up, whereas physical interfaces can change state, and the interface can potentially not be accessible. It is recommended to add a loopback interface to each device as a management interface and that it be used exclusively for the management plane. This allows the administrator to apply policies throughout the network for the management plane. Once the loopback interface is configured on a device, it can be used by management plane protocols, such as SSH, SNMP, and syslog, in order to send and receive traffic.

!
interface Loopback0
 ip address
!

Memory Threshold Notifications

The feature Memory Threshold Notification, added in Cisco IOS Software Release (4)T, allows you to mitigate low-memory conditions on a device. This feature uses two methods in order to accomplish this: Memory Threshold Notification and Memory Reservation.

Memory Threshold Notification generates a log message in order to indicate that free memory on a device has fallen lower than the configured threshold. This configuration example shows how to enable this feature with the memory free low-watermark global configuration command. This enables a device to generate a notification when available free memory falls lower than the specified threshold, and again when available free memory rises to five percent higher than the specified threshold.

!

memory free low-watermark processor <threshold>
memory free low-watermark io <threshold>
!

Memory Reservation is used so that sufficient memory is available for critical notifications. This configuration example demonstrates how to enable this feature. This ensures that management processes continue to function when the memory of the device is exhausted.

!
memory reserve critical <value> !

Refer toMemory Threshold Notifications for more information about this feature.

CPU Thresholding Notification

Introduced in Cisco IOS Software Release (4)T, the CPU Thresholding Notification feature allows you to detect and be notified when the CPU load on a device crosses a configured threshold. When the threshold is crossed, the device generates and sends an SNMP trap message. Two CPU utilization thresholding methods are supported on Cisco IOS software: Rising Threshold and Falling Threshold.

This example configuration shows how to enable the Rising and Falling Thresholds that trigger a CPU threshold notification message:

!

snmp-server enable traps cpu threshold
!

snmp-server host <host-address> <community-string> cpu
!

process cpu threshold type <type> rising <percentage> interval <seconds>
[falling <percentage> interval <seconds>]
process cpu statistics limit entry-percentage <number> [size <seconds>]
!

Refer toCPU Thresholding Notification for more information about this feature.

Reserve Memory for Console Access

In Cisco IOS Software Release (15)T and later, the Reserve Memory for Console Access feature can be used in order to reserve enough memory to ensure console access to a Cisco IOS device for administrative and troubleshooting purposes. This feature is especially beneficial when the device runs low on memory. You can issue the memory reserve console global configuration command in order to enable this feature. This example configures a Cisco IOS device to reserve kilobytes for this purpose.

!
memory reserve console
!

Refer toReserve Memory for Console Access for more information about this feature.

Memory Leak Detector

Introduced in Cisco IOS Software Release (8)T1, the Memory Leak Detector feature allows you to detect memory leaks on a device. Memory Leak Detector is able to find leaks in all memory pools, packet buffers, and chunks. Memory leaks are static or dynamic allocations of memory that do not serve any useful purpose. This feature focuses on memory allocations that are dynamic. You can use the show memory debug leaks EXEC command in order to detect if a memory leak exists.

Buffer Overflow: Detection and Correction of Redzone Corruption

In Cisco IOS Software Release (7)T and later, the Buffer Overflow: Detection and Correction of Redzone Corruption feature can be enabled by on a device in order to detect and correct a memory block overflow and to continue operations.

These global configuration commands can be used in order to enable this feature. Once configured, the show memory overflow command can be used in order to display the buffer overflow detection and correction statistics.

!
exception memory ignore overflow io
exception memory ignore overflow processor
!

Enhanced Crashinfo File Collection

The Enhanced Crashinfo File Collection feature automatically deletes old crashinfo files. This feature, added in Cisco IOS Software Release (11)T, allows a device to reclaim space in order to create new crashinfo files when the device crashes. This feature also allows configuration of the number of crashinfo files to be saved.

!
exception crashinfo maximum files <number-of-files>
!

Network Time Protocol

The Network Time Protocol (NTP) is not an especially dangerous service, but any unneeded service can represent an attack vector. If NTP is used, it is important to explicitly configure a trusted time source and to use proper authentication. Accurate and reliable time is required for syslog purposes, such as during forensic investigations of potential attacks, as well as for successful VPN connectivity when depending on certificates for Phase 1 authentication.

• NTP Time Zone - When you configure NTP, the time zone needs to be configured so that timestamps can be accurately correlated. There are usually two approaches to configure the time zone for devices in a network with a global presence. One method is to configure all network devices with the Coordinated Universal Time (UTC) (previously Greenwich Mean Time (GMT)). The other approach is to configure network devices with the local time zone. More information on this feature can be found in “clock timezone” in the Cisco product documentation.
  
  
• NTP Authentication - If you configure NTP authentication, it provides assurance that NTP messages are exchanged between trusted NTP peers.

Sample configuration using NTP authentication:

Client:

(config)#ntp authenticate
(config)#ntp authentication-key 5 md5 ciscotime
(config)#ntp trusted-key 5
(config)#ntp server key 5

Server:

(config)#ntp authenticate
(config)#ntp authentication-key 5 md5 ciscotime
(config)#ntp trusted-key 5

Disable Smart Install

Security best practices around the Cisco Smart Install (SMI) feature depend on how the feature is used in a specific customer environment. Cisco differentiates these use cases:

• Customers who do not use the the Smart Install feature.
• Customers who leverage the Smart Install feature only for zero-touch deployment.
• Customers who leverage the Smart Install feature for more than zero-touch deployment (configuration and image management).

These sections describe each scenario in detail:

• Customers who do not use the Smart Install feature.
• Customers who do not use the Cisco Smart Install feature, and run a release of Cisco IOS and Cisco IOS XE software where the command is available, should disable the Smart Install feature with the no vstack command.

Note: The vstack command was introduced in Cisco IOS Release (55)SE

This is sample output from the show vstack command on a Cisco Catalyst Switch with the Smart Install client feature disabled:

switch# show vstack
config Role: Client (SmartInstall disabled)
Vstack Director IP address:

Customers Who Leverage the Smart Install Feature Only for Zero-Touch Deployment

Disable the Smart Install client functionality after the zero-touch installation is complete or use the no vstack command.

In order to propagate the no vstack command into the network, use one of these methods:

• Enter the no vstack command on all client switches either manually or with a script.
• Add the no vstack command as part of the Cisco IOS configuration that is pushed into each Smart Install client as part of the zero-touch installation.
• In the releases that do not support the vstack command (Cisco IOS Release (55)SE02 and earlier releases), apply an access control list (ACL) on client switches in order to block the traffic on TCP port

In order to enable the Smart Install client functionality later, enter the vstack command on all client switches either manually or with a script.

Customers Who Leverage the Smart Install Feature for More Than Zero-Touch Deployment

In the design of a Smart Install architecture, care should be taken such that the infrastructure IP address space is not accessible to untrusted parties. In releases that do not support the vstack command, ensure that only the Smart Install director has TCP connectivity to all Smart Install clients on port

Administrators can use these security best practices for Cisco Smart Install deployments on affected devices:

• Interface ACLs
• Control Plane Policing (CoPP). This feature is not available in all Cisco IOS software releases.

This example shows an interface ACL with the Smart Install director IP address as and the Smart Install client IP address as

ip access-list extended SMI_HARDENING_LIST
Permit tcp host host eq
deny tcp any any eq
permit ip any any

This ACL must be deployed on all IP interfaces on all clients. It can also be pushed via the director when switches are first deployed.

In order to further restrict access to all the clients within the infrastructure, administrators can use these security best practices on other devices in the network:

• Infrastructure access control lists (iACLs)
• VLAN access control lists (VACLs)

Limit Access to the Network with Infrastructure ACLs

Devised to prevent unauthorized direct communication to network devices, infrastructure access control lists (iACLs) are one of the most critical security controls that can be implemented in networks. Infrastructure ACLs leverage the idea that nearly all network traffic traverses the network and is not destined to the network itself.

An iACL is constructed and applied in order to specify connections from hosts or networks that need to be allowed to network devices. Common examples of these types of connections are eBGP, SSH, and SNMP. After the required connections have been permitted, all other traffic to the infrastructure is explicitly denied. All transit traffic that crosses the network and is not destined to infrastructure devices is then explicitly permitted.

The protections provided by iACLs are relevant to both the management and control planes. The implementation of iACLs can be made easier through the use of distinct addressing for network infrastructure devices. Refer toA Security Oriented Approach to IP Addressing for more information on the security implications of IP addressing.

This example iACL configuration illustrates the structure that must be used as a starting point when you begin the iACL implementation process:

!

ip access-list extended ACL-INFRASTRUCTURE-IN
!
! Permit required connections for routing protocols and
! network management
!

permit tcp host <trusted-ebgp-peer> host <local-ebgp-address> eq
permit tcp host <trusted-ebgp-peer> eq host <local-ebgp-address>
permit tcp host <trusted-management-stations> any eq 22
permit udp host <trusted-netmgmt-servers> any eq
!
! Deny all other IP traffic to any network device
!

deny ip any <infrastructure-address-space> <mask>
!
! Permit transit traffic
!

permit ip any any
!

Once created, the iACL must be applied to all interfaces that face non-infrastructure devices. This includes interfaces that connect to other organizations, remote access segments, user segments, and segments in data centers.

Refer toProtecting Your Core: Infrastructure Protection Access Control Lists for more information about Infrastructure ACLs.

ICMP Packet Filtering

The Internet Control Message Protocol (ICMP) is designed as an IP control protocol. As such, the messages it conveys can have far-reaching ramifications to the TCP and IP protocols in general. While the network troubleshooting tools ping and traceroute use ICMP, external ICMP connectivity is rarely needed for the proper operation of a network.

Cisco IOS software provides functionality in order to specifically filter ICMP messages by name or type and code. This example ACL, which must be used with the access control entries (ACEs) from previous examples, allows pings from trusted management stations and NMS servers and blocks all other ICMP packets:

!

ip access-list extended ACL-INFRASTRUCTURE-IN
!
! Permit ICMP Echo (ping) from trusted management stations and servers
!

permit icmp host <trusted-management-stations> any echo
permit icmp host <trusted-netmgmt-servers> any echo
!
! Deny all other IP traffic to any network device
!

deny ip any <infrastructure-address-space> <mask>
!
! Permit transit traffic
!

permit ip any any
!

Filter IP Fragments

The filter process for fragmented IP packets can pose a challenge to security devices. This is because the Layer 4 information that is used in order to filter TCP and UDP packets is only present in the initial fragment. Cisco IOS software uses a specific method in order to check non-initial fragments against configured access lists. Cisco IOS software evaluates these non-initial fragments against the ACL and ignores any Layer 4 filtering information. This causes non-initial fragments to be evaluated solely on the Layer 3 portion of any configured ACE.

In this example configuration, if a TCP packet destined to on port 22 is fragmented in transit, the initial fragment is dropped as expected by the second ACE based on the Layer 4 information within the packet. However, all remaining (non-initial) fragments are allowed by the first ACE based completely on the Layer 3 information in the packet and ACE. This scenario is shown in this configuration:

!

ip access-list extended ACL-FRAGMENT-EXAMPLE
permit tcp any host eq 80
deny tcp any host eq 22
!

Due to the nonintuitive nature of fragment handling, IP fragments are often inadvertently permitted by ACLs. Fragmentation is also often used in attempts to evade detection by intrusion detection systems. It is for these reasons that IP fragments are often used in attacks, and why they must be explicitly filtered at the top of any configured iACLs. This example ACL includes comprehensive filtering of IP fragments. The functionality from this example must be used in conjunction with the functionality of the previous examples.

!

ip access-list extended ACL-INFRASTRUCTURE-IN
!
! Deny IP fragments using protocol-specific ACEs to aid in
! classification of attack traffic
!

deny tcp any any fragments
deny udp any any fragments
deny icmp any any fragments
deny ip any any fragments
!
! Deny all other IP traffic to any network device
!

deny ip any <infrastructure-address-space> <mask>
!
! Permit transit traffic
!

permit ip any any
!

Refer toAccess Control Lists and IP Fragments for more information about how ACL handles fragmented IP packets.

ACL Support for Filtering IP Options

Cisco IOS Software Release (4)T added support for the use of ACLs to filter IP packets based on the IP options that are contained in the packet. IP options present a security challenge for network devices because these options must be processed as exception packets. This requires a level of CPU effort that is not required for typical packets that traverse the network. The presence of IP options within a packet can also indicate an attempt to subvert security controls in the network or otherwise alter the transit characteristics of a packet. It is for these reasons that packets with IP options must be filtered at the edge of the network.

This example must be used with the ACEs from previous examples in order to include complete filtering of IP packets that contain IP options:

!

ip access-list extended ACL-INFRASTRUCTURE-IN
!
! Deny IP packets containing IP options
!

deny ip any any option any-options
!
! Deny all other IP traffic to any network device
!

deny ip any <infrastructure-address-space> <mask>
!
! Permit transit traffic
!

permit ip any any
!

ACL Support to Filter on TTL Value

Cisco IOS Software Release (2)T added ACL support to filter IP packets based on the Time to Live (TTL) value. The TTL value of an IP datagram is decremented by each network device as a packet flows from source to destination. Although initial values vary by operating system, when the TTL of a packet reaches zero, the packet must be dropped. The device that decrements the TTL to zero, and therefore drops the packet, is required in order to generate and send an ICMP Time Exceeded message to the source of the packet.

The generation and transmission of these messages is an exception process. Routers can perform this function when the number of IP packets that are due to expire is low, but if the number of packets due to expire is high, generation and transmission of these messages can consume all available CPU resources. This presents a DoS attack vector. It is for this reason that devices need to be hardened against DoS attacks that utilize a high rate of IP packets that are due to expire.

It is recommended that organizations filter IP packets with low TTL values at the edge of the network. Completely filtering packets with TTL values insufficient to traverse the network mitigates the threat of TTL-based attacks.

This example ACL filters packets with TTL values less than six. This provides protection against TTL expiry attacks for networks up to five hops in width.

!

ip access-list extended ACL-INFRASTRUCTURE-IN
!
! Deny IP packets with TTL values insufficient to traverse the network
!

deny ip any any ttl lt 6
!
! Deny all other IP traffic to any network device
!

deny ip any <infrastructure-address-space> <mask>
!
! Permit transit traffic
!

permit ip any any
!

Note: Some protocols make legitimate use of packets with low TTL values. eBGP is one such protocol. Refer to TTL Expiry Attack Identification and Mitigation for more information on mitigating TTL expiry-based attacks.

Refer toACL Support for Filtering on TTL Value for more information about this functionality.

Secure Interactive Management Sessions

Management sessions to devices allow you the ability to view and collect information about a device and its operations. If this information is disclosed to a malicious user, the device can become the target of an attack, compromised, and used in order to perform additional attacks. Anyone with privileged access to a device has the capability for full administrative control of that device. It is imperative to secure management sessions in order to prevent information disclosure and unauthorized access.

Management Plane Protection

In Cisco IOS Software Release (6)T and later, the feature Management Plane Protection (MPP) allows an administrator to restrict on which interfaces management traffic can be received by a device. This allows the administrator additional control over a device and how the device is accessed.

This example shows how to enable the MPP in order to only allow SSH and HTTPS on the GigabitEthernet0/1 interface:

!

control-plane host
management-interface GigabitEthernet 0/1 allow ssh https
!

Refer toManagement Plane Protection for more information about MPP.

Control Plane Protection

Control Plane Protection (CPPr) builds on the functionality of Control Plane Policing in order to restrict and police control plane traffic that is destined to the route processor of the IOS device. CPPr, added in Cisco IOS Software Release (4)T, divides the control plane into separate control plane categories that are known as subinterfaces. Three control plane subinterfaces exist: Host, Transit and CEF-Exception. In addition, CPPr includes these additional control plane protection features:

• Port-filtering feature - This feature provides for the policing or dropping of packets that go to closed or non-listening TCP and UDP ports.
  
  
• Queue-threshold policy feature - This feature limits the number of packets for a specified protocol that are allowed in the control plane IP input queue.

CPPr allows an administrator to classify, police, and restrict traffic that is sent to a device for management purposes with the host subinterface. Examples of packets that are classified for the host subinterface category include management traffic such as SSH or Telnet and routing protocols.

Note: CPPr does not support IPv6 and is restricted to the IPv4 input path.

Refer toControl Plane Protection Feature Guide - T and Understanding Control Plane Protection for more information about the Cisco CPPr feature.

Encrypt Management Sessions

Because information can be disclosed in an interactive management session, this traffic must be encrypted so that a malicious user cannot gain access to the data that is transmitted. Traffic encryption allows a secure remote access connection to the device. If the traffic for a management session is sent over the network in cleartext, an attacker can obtain sensitive information about the device and the network.

An administrator is able to establish an encrypted and secure remote access management connection to a device with the SSH or HTTPS (Secure Hypertext Transfer Protocol) features. Cisco IOS software supports SSH Version (SSHv1), SSH Version (SSHv2), and HTTPS that uses Secure Sockets Layer (SSL) and Transport Layer Security (TLS) for authentication and data encryption. SSHv1 and SSHv2 are not compatible. SSHv1 is insecure and not standardized, so it is not recommended if SSHv2 is an option.

Cisco IOS software also supports the Secure Copy Protocol (SCP), which allows an encrypted and secure connection in order to copy device configurations or software images. SCP relies on SSH. This example configuration enables SSH on a Cisco IOS device:

!

ip domain-name manicapital.com
!

crypto key generate rsa modulus
!

ip ssh time-out 60
ip ssh authentication-retries 3
ip ssh source-interface GigabitEthernet 0/1
!

line vty 0 4
transport input ssh
!

This configuration example enables SCP services:

!

ip scp server enable
!

This is a configuration example for HTTPS services:

!

crypto key generate rsa modulus
!

ip http secure-server
!

Refer toConfiguring Secure Shell on Routers and Switches Running Cisco IOS and Secure Shell (SSH) FAQ for more information about the Cisco IOS software SSH feature.

SSHv2

The SSHv2 support feature introduced in Cisco IOS Software Release (4)T allows a user to configure SSHv2. (SSHv1 support was implemented in an earlier release of Cisco IOS Software.) SSH runs on top of a reliable transport layer and provides strong authentication and encryption capabilities. The only reliable transport that is defined for SSH is TCP. SSH provides a means to securely access and securely execute commands on another computer or device over a network. The Secure Copy Protocol (SCP) feature that is tunneled over SSH allows for the secure transfer of files.

If the ip ssh verson 2 command is not explicitly configured, then Cisco IOS enables SSH Version SSH Version allows both SSHv1 and SSHv2 connections. SSHv1 is considered to be insecure and can have adverse effects on the system. If SSH is enabled, it is recommended to disable SSHv1 by using the ip ssh version 2 command.

This example configuration enables SSHv2 (with SSHv1 disabled) on a Cisco IOS device:

!

hostname router

!

ip domain-name manicapital.com

!

crypto key generate rsa modulus

!

ip ssh time-out 60
ip ssh authentication-retries 3
ip ssh source-interface GigabitEthernet 0/1

!

ip ssh version 2

!

line vty 0 4
transport input ssh

!

Refer toSecure Shell Version 2 Support for more information on the use of SSHv2.

SSHv2 Enhancements for RSA Keys

Cisco IOS SSHv2 supports keyboard-interactive and password-based authentication methods. The SSHv2 Enhancements for RSA Keys feature also supports RSA-based public key authentication for the client and server.

For user authentication, RSA-based user authentication uses a private/public key pair associated with each user for authentication. The user must generate a private/public key pair on the client and configure a public key on the Cisco IOS SSH server in order to complete the authentication.

An SSH user who tries to establish the credentials provides an encrypted signature with the private key. The signature and the user's public key are sent to the SSH server for authentication. The SSH server computes a hash over the public key provided by the user. The hash is used in order to determine if the server has an entry that matches. If a match is found, RSA-based message verification is performed with the public key. Hence, the user is authenticated or denied access based on the encrypted signature.

For server authentication, the Cisco IOS SSH client must assign a host key for each server. When the client tries to establish an SSH session with a server, it receives the signature of the server as part of the key exchange message. If the strict host key checking flag is enabled on the client, the client checks whether it has the host key entry that corresponds to the server preconfigured. If a match is found, the client tries to validate the signature with the server host key. If the server is successfully authenticated, the session establishment continues; otherwise it is terminated and displays a Server Authentication Failed message.

This example configuration enables the use of RSA keys with SSHv2 on a Cisco IOS device:

!
! Configure a hostname for the device
!

hostname router
!
! Configure a domain name
!

ip domain-name manicapital.com
!
! Specify the name of the RSA key pair (in this case, "sshkeys") to use for SSH
!

ip ssh rsa keypair-name sshkeys
!
! Enable the SSH server for local and remote authentication on the router using
! the "crypto key generate" command
! For SSH version 2, the modulus size must be at least bits
!

crypto key generate rsa usage-keys label sshkeys modulus
!
! Configure an ssh timeout (in seconds)
!
! The following enables a timeout of seconds for SSH connections
!

ip ssh time-out
!
! Configure a limit of five (5) authentication retries
!

ip ssh authentication-retries 5
!
! Configure SSH version 2
!

ip ssh version 2
!

  

Refer toSecure Shell Version 2 Enhancements for RSA Keys for more information on the use of RSA keys with SSHv2.

This example configuration enables the Cisco IOS SSH server to perform RSA-based user authentication. The user authentication is successful if the RSA public key stored on the server is verified with the public or the private key pair stored on the client.

!
! Configure a hostname for the device
!

hostname router
!
! Configure a domain name
!

ip domain-name manicapital.com
!
! Generate RSA key pairs using a modulus of bits
!

crypto key generate rsa modulus
!
! Configure SSH-RSA keys for user and server authentication on the SSH server
!

ip ssh pubkey-chain
!
! Configure the SSH username
!

username ssh-user
!
! Specify the RSA public key of the remote peer
!
! You must then configure either the key-string command
! (followed by the RSA public key of the remote peer) or the
! key-hash command (followed by the SSH key type and version.)
!

Refer toConfiguring the Cisco IOS SSH Server to Perform RSA-Based User Authentication for more information on the use of RSA keys with SSHv2.

This example configuration enables the Cisco IOS SSH client to perform RSA-based server authentication.

!
!

hostname router
!
ip domain-name cisco.c
!
! Generate RSA key pairs
!

crypto key generate rsa
!
! Configure SSH-RSA keys for user and server authentication on the SSH server
!

ip ssh pubkey-chain
!
! Enable the SSH server for public-key authentication on the router
!

server SSH-server-name
!
! Specify the RSA public-key of the remote peer
!
! You must then configure either the key-string command
! (followed by the RSA public key of the remote peer) or the
! key-hash <key-type> <key-name> command (followed by the SSH key
! type and version.)
!
! Ensure that server authentication takes place - The connection will be
! terminated on a failure
!

ip ssh stricthostkeycheck
!

Refer toConfiguring the Cisco IOS SSH Client to Perform RSA-Based Server Authentication for more information on the use of RSA keys with SSHv2.

Console and AUX Ports

In Cisco IOS devices, console and auxiliary (AUX) ports are asynchronous lines that can be used for local and remote access to a device. You must be aware that console ports on Cisco IOS devices have special privileges. In particular, these privileges allow an administrator to perform the password recovery procedure. In order to perform password recovery, an unauthenticated attacker would need to have access to the console port and the ability to interrupt power to the device or to cause the device to crash.

Any method used in order to access the console port of a device must be secured in a manner that is equal to the security that is enforced for privileged access to a device. Methods used in order to secure access must include the use of AAA, exec-timeout, and modem passwords if a modem is attached to the console.

If password recovery is not required, then an administrator can remove the ability to perform the password recovery procedure using the no service password-recovery global configuration command; however, once the no service password-recovery command has been enabled, an administrator can no longer perform password recovery on a device.

In most situations, the AUX port of a device must be disabled in order to prevent unauthorized access. An AUX port can be disabled with these commands:

!

line aux 0
transport input none
transport output none
no exec
exec-timeout 0 1
no password
!

Control vty and tty Lines

Interactive management sessions in Cisco IOS software use a tty or virtual tty (vty). A tty is a local asynchronous line to which a terminal can be attached for local access to the device or to a modem for dialup access to a device. Note that ttys can be used for connections to console ports of other devices. This function allows a device with tty lines to act as a console server where connections can be established across the network to the console ports of devices connected to the tty lines. The tty lines for these reverse connections over the network must also be controlled.

A vty line is used for all other remote network connections supported by the device, regardless of protocol (SSH, SCP, or Telnet are examples). In order to ensure that a device can be accessed via a local or remote management session, proper controls must be enforced on both vty and tty lines. Cisco IOS devices have a limited number of vty lines; the number of lines available can be determined with the show line EXEC command. When all vty lines are in use, new management sessions cannot be established, which creates a DoS condition for access to the device.

The simplest form of access control to a vty or tty of a device is through the use of authentication on all lines regardless of the device location within the network. This is critical for vty lines because they are accessible via the network. A tty line that is connected to a modem that is used for remote access to the device, or a tty line that is connected to the console port of other devices are also accessible via the network. Other forms of vty and tty access controls can be enforced with the transport input or access-class configuration commands, with the use of the CoPP and CPPr features, or if you apply access lists to interfaces on the device.

Authentication can be enforced through the use of AAA, which is the recommended method for authenticated access to a device, with the use of the local user database, or by simple password authentication configured directly on the vty or tty line.

The exec-timeout command must be used in order to logout sessions on vty or tty lines that are left idle. The service tcp-keepalives-in command must also be used in order to enable TCP keepalives on incoming connections to the device. This ensures that the device on the remote end of the connection is still accessible and that half-open or orphaned connections are removed from the local IOS device.

Control Transport for vty and tty Lines

A vty and tty should be configured in order to accept only encrypted and secure remote access management connections to the device or through the device if it is used as a console server. This section addresses ttys because such lines can be connected to console ports on other devices, which allow the tty to be accessible over the network. In an effort to prevent information disclosure or unauthorized access to the data that is transmitted between the administrator and the device, transport input ssh should be used instead of clear-text protocols, such as Telnet and rlogin. The transport input none configuration can be enabled on a tty, which in effect disables the use of the tty line for reverse-console connections.

Both vty and tty lines allow an administrator to connect to other devices. In order to limit the type of transport that an administrator can use for outgoing connections, use the transport output line configuration command. If outgoing connections are not needed, then