Contents
Introduction
Management Plane
Password Management
Password Policies
Disable Unused Services
Set EXEC Timeout
SSH Protocol
Passwordless SSH
Employ Management Plane Protection
Warning Banners
Authentication, Authorization, and Accounting
User Management
TACACS+ Authentication
Authentication Fallback
Redundant AAA Servers
SNMP Overview and Best Practices
SNMPv3
IOS XR SNMP Management Plane Protection
Logging Best Practices
AAA Logging
Access Control List Violation Logging
Logging Correlation
Send Logs to a Central Location
Secure Logging
Logging Levels
Disable Console or Monitor Sessions
Buffered Logging
Configure Logging Source Interface
Configure Logging Timestamps
Traffic Protection for Third-Party Applications/Linux Networking
Traffic Protection for Third Party Applications
Traffic Protection for Linux Networking
Best Practices with Traffic Protection
Control Plane
NTP Security and Design
Local Packet Transport Service (LPTS)
LPTS Best Practices
Secure Border Gateway Protocol
BGP Time-to-Live-Based Security Protection
BGP Peer Authentication with TCP AO
BGP Maximum Prefixes
Filter BGP Prefixes with RPL Policies
Data Plane
Disable General Data Plane Hardening
IP Source Routing
IP Directed Broadcast
ICMP Redirects
Proxy ARP
IP Fragmentation
IPv4 Fragmentation
IPv6 Fragmentation
IP Fragmentation Best Practice
Disk Encryption
Conclusion
Appendix: Cisco IOS XR Hardening Checklist
Revision History
Introduction
This document contains information that will help network administrators and security practitioners secure Cisco IOS XR-based routers to increase the overall security posture of the network. This document is structured around the three planes by which the functions of a network device are categorized.
The three functional planes of a router are the management plane, control plane, and data plane. Each provides a different functionality that must be protected.
- Management Plane: The management plane contains the logical group of all traffic that supports provisioning, maintenance, and monitoring functions for the Cisco IOS XR device and the network. Traffic in this group includes Secure Shell (SSH), Secure Copy Protocol (SCP), Simple Network Management Protocol (SNMP), Syslog, TACACS+, RADIUS, DNS, NetFlow, and Cisco Discovery Protocol. Management plane traffic is always destined to the local Cisco IOS XR device.
- Control Plane: The control plane contains the logical group of all routing, signaling, link-state, and other control protocols that are used to create and maintain the state of the network and its interfaces. These include Border Gateway Protocol (BGP), Open Shortest Path First (OSPF), Label Distribution Protocol (LDP), Intermediate System to Intermediate System (IS-IS), Network Time Protocol (NTP), Address Resolution Protocol (ARP), and Layer 2 keepalives. Control plane traffic is always destined to the local Cisco IOS XR device.
- Data Plane: The data plane contains the logical group of "customer" application traffic generated by hosts, clients, servers, and applications that are sourced from and destined to other similar devices supported by the network. Data plane features include IP source routing, IP directed broadcast, ICMP redirects, ICMP unreachables, and proxy ARP. Data plane traffic is mainly forwarded in the fast path and is never destined to the local Cisco IOS XR device.
Management Plane
Approach to This DocumentationSome features mentioned in this document may not be available in all software versions and platforms. For questions about feature support, consult your Cisco Account Team representatives and/or Cisco Customer Experience.
Password Management
In the context of hardening, the management of passwords, both at-rest and in-flight, is a crucial subject.
Security best practices mandate that during steady state operation, a TACACS+ or RADIUS authentication server controls user management session authentication and authorization. However, a password that is local to the network element is required for situations in which TACACS+ or RADIUS services fail. In either case, the goal is the same: to challenge a request for verification of password and identity when access to a network element is required. Access can be granted, denied, or limited based on the result.
Aside from user device management authentication and authorization use case, passwords are typically stored on the device to authenticate services.
All passwords stored on the device fall into two categories. It’s important to note this distinction because the best practice for obfuscation differs between the two. These two categories are:
- One-way: passwords that are used locally to authenticate and authorize a user.
- Two-way: key strings that have a reversibility requirement by a far-end peer. The peer must ultimately be able to glean (reverse) the key that has been sent to it to authenticate the session. Examples include passwords for AAA servers (TACACS+ and RADIUS), MACsec, BGP, OSPF, ISIS, LDP, IKE pre-shared-key, NTP, and others.
For one-way use-case for obfuscation of passwords, Cisco recommends using the Type 10 (SHA-512) hashed format. Alternatively, the Type 8 (SHA-256 with PBKDF2) format is also considered secure, should the Type 10 format not be available in your device.
For more information about the Type 10 method, see the Restrictions for Type 10 Password Usage section in the System Security Configuration Guide for Cisco NCS 540 Series Routers, IOS XR Release 7.2.x guide.
For more information about configuring Type 8 passwords, see the Configure Type 8 and Type 9 Passwords section in the System Security Configuration Guide for Cisco NCS 540 Series Routers, IOS XR Release 7.2.x guide.
For the two-way password use-case, Cisco strongly recommends that customers deploy Type -6 encryption. Older software offered users three different approaches, none of which should be considered secure:
- Type-0: plain text passwords that are stored at rest and are not obfuscated in any way.
- Type 7: a simple alphabetical substitution Vigenère cipher with a hardcoded key, which is easily reversible by leveraging widely available online tools.
- Type 5: MD5 encryption, which is stored as hashes within the configuration.
Older software used the three mentioned approaches for both the one-way and two-way obfuscation use-cases. Cisco recommends using a new encryption format, Type 6 encryption, for at-rest obfuscation of two-way reversable key strings.
Type 6 Encryption
Type 6 uses a secure, reversible, 128-bit Advanced Encryption Standard (AES) encryption algorithm that introduces the concept of a master key. To understand the master key, consider how a host-based password manager works: The user needs to know only the master key and is not required to know or remember any constituent passwords below it. The master key is required to restore a saved configuration offline.
TACACS+, RADIUS, BGP (TCP-MD5 and TCP-AO), IP SLA, IS-IS, MACsec, OSPF, RSVP-TE, and more are supported.
The Cisco IOS XR master key is protected in hardware, leveraging the Cisco Trust Anchor Module (TAm) found on modern Cisco platforms.
The following example shows a configuration of Type 6 encryption:
RP/0/RP0/CPU0:ios#key config-key password-encryption New password Requirements: Min-length 6, Max-length 64 Enter new key : [omitted] Enter confirm key : [omitted] Master key operation is started in background password6 encryption aes ! tacacs-server host 192.0.2.11 port 49 key 6 4d625f5961464e635e5867565352515767424d5b535e5f664b62675e4b5558514342574551615a60465f414142 ! radius-server host 192.0.2.12 auth-port 1645 acct-port 1646 key 6 6651535c655541504f65665e604f5d595f5a61625a41635b5a6350534c5f4a4169424d615a454c4e4458465b42 !
Type 6 does introduce a new operational requirement: the management of these master passwords, which must be unique per device, potentially at very large scale. That concept is beyond the scope of this document. For more information about this feature, see the Implementing Type 6 Password Encryption chapter in the System Security Configuration Guide for Cisco NCS 540 Series Routers, IOS XR Release 7.4.x.
Password Policies
In addition to adopting a stronger hashing mechanism, customers can now configure a password policy for each local user account. Below is a snippet of the password policy configuration and the options that are available under password policy. For more information, see the Configuring AAA Services chapter of the System Security Configuration Guide for Cisco NCS 540 Series Routers, IOS XR Release 7.4.x.
Configure a Password Policy
RP/0/RP0/CPU0:router(config)#aaa password-policy test-policy RP/0/RP0/CPU0:router(config-aaa)#min-length 8 RP/0/RP0/CPU0:router(config-aaa)#max-length 15 RP/0/RP0/CPU0:router(config-aaa)#lifetime months 3 RP/0/RP0/CPU0:router(config-aaa)#min-char-change 5 RP/0/RP0/CPU0:router(config-aaa)#authen-max-attempts 3 RP/0/RP0/CPU0:router(config-aaa)#lockout-time days 1 RP/0/RP0/CPU0:router(config-aaa)#commit
Disable Unused Services
As a security best practice, administrators should disable unnecessary services. Disabling unnecessary services enhances security by significantly reducing the attack surface of the network and minimizes the potential entry points that hackers may exploit, as each active service carries the risk of being vulnerable to attack.
The services below are disabled by default in Cisco IOS XR Software; however, these services can be enabled by issuing their respective configuration commands. Administrators are advised to disable the following services if they are not necessary for business operations:
- TCP and UDP small services (Echo, Discard, Daytime, Chargen)
- Cisco Discovery Protocol
- Simple Network Management Protocol (SNMP)
- TFTP
- DHCP
- HTTP/HTTPS Server
To disable TCP and UDP small services, issue the following command:
no service {ipv4|ipv6} tcp-small-servers
no service {ipv4|ipv6} udp-small-servers
Cisco Discovery Protocol can be disabled globally or under interface. To disable Cisco Discovery Protocol services, issue the following command:
no cdp
interface HundredGigE0/0/0/0
no cdp
To disable SNMP services, issue the following command:
no snmp-server
To disable TFTP services, issue the following command:
no tftp ipv4 server
no tftp ipv6 server
To disable DHCP services if DHCP relay services are not required, issue the following command:
no dhcp {ipv4|ipv6}The HTTP Web Server feature in Cisco IOS XR has been deprecated and is no longer supported. The recommended way to access the devices remotely is through more secure protocols such as NETCONF and gRPC.
Administrators can use the Management Plane Protection (MPP) feature to activate or deactivate a service on a specific interface as needed.
Set EXEC Timeout
Administrators should configure EXEC timeout on network devices to automatically disconnect idle user sessions after a specified period of inactivity. This practice helps enhance security by preventing unauthorized access through potentially abandoned sessions by users who have forgotten to log off and terminate their session properly.
By default, console, vty, and tty sessions disconnect after 10 minutes of inactivity. Administrators are advised to maintain this value at 10 minutes or less but greater than zero. A zero-minute value will prevent sessions from terminating.
To set an EXEC timeout value, issue the following command:
line {console|default|template} exec-timeout (minutes) (seconds)
To reinstate the default timeout value, issue the following command:
no line {console|default|template} exec-timeout
Secure Interactive Management Session
Because sensitive information can be disclosed during an interactive management session, traffic should be encrypted so that a malicious user cannot access the data that is being transmitted. Encrypting the traffic allows a secure remote access connection to the device. If the traffic for a management session is sent over the network in plain text, an attacker could obtain sensitive information about the device and the network. Additionally, if username/password info is sent over the network in plain text, an attacker could obtain network access credentials.
SSH Protocol
Users can establish an encrypted and secure remote access management connection to a device by using the SSH, SFTP, or HTTPS protocols. Cisco IOS XR Software supports SSH Version 1.0 (SSHv1), SSH Version 2.0 (SSHv2), and HTTPS that uses SSL and Transport Layer Security (TLS) for authentication and data encryption. It is recommended to generate a 4096-bit modulus RSA key and to only enable SSH version 2.0.
The following configuration example enables SSHv2 on a Cisco IOS XR device:
hostname test-1 domain name test.com ssh server v2
A SSH RSA key refers to a cryptographic key pair generated using the RSA algorithm, which is used to securely authenticate the device when establishing an SSH connection. It is the primary method for key-based authentication on Cisco IOS XR routers when using SSH, where a public key is shared with clients while the private key remains protected on the device itself.
To create an RSA key pair on a Cisco IOS XR device, use the command crypto key generate rsa in global configuration mode, as shown in the following example. By default, this command generates both a public and a private 2048-bit RSA key. It is recommended to use a 4096-bit RSA key, as a larger key modulus results in stronger encryption and is more difficult to compromise.
| RP/0/0/CPU0:R2#crypto key generate rsa Thu Jan 23 21:24:59.003 UTC The name for the keys will be: the_default |
| Choose the size of the key modulus in the range of 512 to 4096 for your General Purpose Keypair. Choosing a key modulus greater than 512 may take a few minutes. |
| How many bits in the modulus [2048]: 4096 Generating RSA keys ... Done w/ crypto generate keypair [OK] |
Passwordless SSH
To further harden the security posture of the devices using SSH, it’s recommended to move out of password-based authentication and adopt passwordless options for SSH connections. Cisco’s IOS XR releases later than Release 7.0 support public-key based SSH authentication. In addition to this, X.509v3 certificate-based SSH authentication is supported on Cisco IOS XR Release 7.3.1 and later.
For RSA public key-based authentication, Cisco IOS XR supports importing the public key of the users. for more information, see the Importing Public Key chapter of the System Security Configuration Guide for Cisco NCS 540 Series Routers, IOS XR Release 7.3.x.
Customers who want an alternative to managing keys for each user can use certificate-based authentication. The only restriction of the feature is that only local authentication is supported, but authorization can be through a remote TACACS server. For more information, see X.509v3 Certificate-based Authentication for SSH.
Employ Management Plane Protection
The MPP feature in Cisco IOS XR Software provides the capability to restrict the interfaces on which network management packets are allowed to enter a device. MPP allows a network operator to reserve a set of interfaces for management traffic either exclusively or along with regular data. MPP changes the default behavior of an interface by not listening to all the services traffic and allowing traffic only from applications that are explicitly configured on the interface.
MPP provides support for in-band and out-of-band management interfaces. An in-band interface shares management and forwarding traffic, whereas out-of-band management interface receives network management traffic only.
The advantage of this implementation is that network management traffic does not interfere with any forwarding or customer traffic, significantly reducing the possibility of potential side effects of processing network management traffic, such as garbled packet and a denial of service (DoS) condition.
MPP also supports peer-filtering mechanisms. Management traffic that belongs to the configured peer ip-addresses would be allowed on a specified interface; other traffic would be dropped.
Device management traffic may enter a device only through these management interfaces. After MPP is enabled, no interfaces except the designated management interfaces will accept network management traffic that is destined to the device. Restricting management packets to the designated interfaces provides greater control over the management of a device, providing more security for that device. If MPP is disabled and a protocol is activated, all interfaces can pass traffic.
Administrators are advised to use the peer-filtering option to control management traffic from specific peers or a range of peers.
MPP only controls the incoming management requests for the following protocols:
- SNMP
- Secure Shell (v1 and v2)
- TFTP
- Telnet
- Netconf
- XML
- HTTP/HTTPS
The following example shows how to enable the MPP to allow SSH and HTTP requests only from peer address 10.0.1.0 on the GigabitEthernet0/0/0/1 interface:
control-plane management-plane inband interface GigabitEthernet0/0/0/1 allow ssh peer address ipv4 10.0.1.0/24 allow http peer address ipv4 10.0.1.0/24
The following example shows how to configure GigabitEthernet0/2/0/0 as an out-of-band interface and allow a SSH request from peer address 10.10.10.10 only:
control-plane management-plane out-of-band interface GigabitEthernet0/2/0/0 allow SSH peer address ipv4 10.10.10.10
For more information on management plane protection, see the Implementing Management Plane Protection on Cisco IOS XR Software section in the System Security Configuration Guide for Cisco NCS 540 Series Routers, IOS XR Release 7.3.x.
Warning Banners
In certain jurisdictions, prosecuting malicious users may be unfeasible, and monitoring their activities could be deemed illegal unless they have been informed that their use of the system is prohibited. One method for notification is to place this information into a login banner message that is configured using the banner login command.
Login banners should not be confused with message-of-the-day (MOTD) banners or EXEC banners. Login banners appear before a user authenticates to a device. MOTD banners also appear before a user authenticates to a device, but MOTD banners are typically used to display a temporary notice such as system availability. EXEC banners are banners displayed after your access credentials have been accepted.
Legal notification requirements are complex, vary by jurisdiction and situation, and should be discussed with legal counsel. Legal opinions can vary within the same jurisdiction. In cooperation with legal counsel, a banner should provide some or all the following information:
- Notice that the system is to be logged into or used only by specifically authorized personnel with information about who can authorize to use
- Notice that unauthorized use of the system is unlawful and may be subject to civil and criminal penalties
- Notice that use of the system can be logged or monitored without further notice and that the resulting logs can be used as evidence in court
- Specific notices required by local laws
From a security point of view, a login banner should not contain any specific information about the router name, model, software, or ownership. This information can be exploited by malicious users. The following is an example of the banner configuration where "$" is the delimiting character:
banner login $ This is a private computer system. It is for authorized use only. $
Authentication, Authorization, and Accounting
The Authentication, Authorization, and Accounting (AAA) framework is critical to securing interactive access to network devices. The AAA framework provides a highly configurable environment that can be tailored depending on the needs of the network.
Authentication is the most important security process by which a principal (a user or an application) obtains access to the system. The principal is identified by a username or user ID that is unique across an administrative domain. The applications serving the user, such as EXEC or Management Agent, obtain the username and the credentials from the user. AAA performs the authentication based on the username and credentials that are passed to it by the applications. The role of an authenticated user is determined by the group (or groups) to which the user belongs. A user can be a member of one or more user groups.
A user is a root-lr user if they belong to the root-lr group. The root-lr user may be defined in the local or remote AAA database.
User Management
Administrators should control access to resources or devices. When a request for access to a resource or device is received, the request is challenged for verification of the password and identity, and access can be granted, denied, or limited based on the result. Cisco IOS XR Software provides tools to allow for multiple levels of permissions using the concepts of task and user groups. User groups are defined to have access to a certain set of capabilities. Some of these capabilities are debug commands, show commands, and configuration commands. Different user groups have configuration access to different parts of the router. A root–lr user must be created. The root-lr user is the most powerful user in the Cisco IOS XR scheme and is essentially the same as a fully enabled (privilege level 15) user in Cisco IOS Software. The configuration for a root-lr user follows:
usernamepassword group sysadmin
Cisco IOS XR Software allows the system administrator to configure groups of users and the job characteristics that are common to those groups. Groups must be explicitly assigned to users. Users are not assigned to groups by default. A user can be assigned to more than one group.
The following list of task groups defines privileges for different users in Cisco IOS XR Software. Each task group consists of the list of permitted tasks (read, write, execute, or debug permissions) for a user in the particular task group. Only root-lr users have, by default, permission to run all tasks except the ones defined in the cisco-support group.
- cisco-support: debugging and troubleshooting features, usually used by Cisco support personnel
- netadmin: configuration tasks, such as those for routing protocols
- operator: day-to-day monitoring activities and limited configuration rights
- root-lr: configuration and display rights for a specific secure domain router
- sysadmin: Administrative tasks such as maintaining the location for stored core dumps or setting up NTP
- serviceadmin: service administration tasks.
A user group can derive attributes from another user group. Similarly, a task group can derive attributes from another task group.
Task groups are defined by a collection of task IDs. Task groups contain task ID lists for each class of action. Each user group is associated with a set of task groups that are applicable to users in that group. A user’s task permissions are derived from the task groups that are associated with the user groups to which that user belongs.
The following example shows how to create a task group named mgmt that is inheriting attributes from the sysadmin task group. Read permissions are assigned for any CLI commands that are associated with task ID bgp.
taskgroup mgmt description backbone support functions inherit taskgroup sysadmin task read bgp
See the Configuring AAA Services section of the System Security Configuration Guide for Cisco ASR 9000 Series Routers, IOS XR Release 24.1.x, 24.2.x, 24.3.x, 24.4.x for more information about configuring task groups.
AAA can be enabled on a Cisco IOS XR device using a configuration such as the one in the following example:
aaa authentication login default group tacacs+ local
TACACS+ Authentication
Cisco IOS XR Software communicates with the remote AAA server using a standard IP-based security protocol, such as TACACS+ or RADIUS.
TACACS+ uses TCP port 49. TACACS+ provides reliable data transfer between the client and server. Benefits to using TACACS+ include the following:
- TACACS+ allows true command authorization. Users can create clear usage policies with TACACS+, whereas different users have access to different commands with administrative granularity. TACACS+ can do this because it separates the Authentication and Authorization functions. RADIUS combines these functions.
- TACACS+ encrypts the entire payload of the client-server exchange. This action is important for the protection of highly secure environments. In contrast, RADIUS encrypts only the password, allowing intercepted packets to reveal important information.
The following sample configuration shows how TACACS+ authentication can be enabled on a Cisco IOS XR device:
tacacs source-interfacevrf aaa group server tacacs+ ! server-private port 49 key 6 no single-connection ! aaa authentication login default group local
TACACS+ Over TLS 1.3
TACACS versions before TACACS+ over TLS1.3 use MD5 for data obfuscation and are therefore considered obsolete. Cisco strongly recommends that customers implement the updated TACACS+ over TLS 1.3 feature, which securely encrypts TACACS+ traffic. Support in IOS XR begins with Cisco IOS XR Release 25.3.1. For configuration details, see the TACACS+ with TLS protection chapter of the System Security Configuration Guide for Cisco ASR 9000 Series Routers, IOS XR Release 25.1.x, 25.2.x, 25.3.x.
This feature requires support from both the network device and the AAA server. If Cisco Identity Service Engine (ISE) is your AAA server, it is supported in Cisco ISE Release 3.4 Patch 2. For configuration details, see Configure TACACS+ over TLS 1.3 on an IOS XR Device with ISE.
Radius over TLS
To configure Radius over TLS, see the Radius with TLS protection chapter of the System Security Configuration Guide for Cisco ASR 9000 Series Routers, IOS XR Release 24.1.x, 24.2.x, 24.3.x, 24.4.x.
Authentication Fallback
If all configured TACACS+ servers become unavailable, a Cisco IOS XR device can rely on secondary authentication protocols. Typical configurations include the use of local database authentication if all configured TACACS+ servers are unavailable.
The complete list of options for on-device authentication includes local or line. Line authentication uses passwords that are configured under line device statements such as console or default templates, while local authentication sets passwords that can be used on all lines. Both options have advantages.
There are two options for password configuration: the use of clear text via the password command, and the use of encrypted secure password by configuring the secret option. The secret option is preferred.
If TACACS+ becomes completely unavailable, each administrator can use their local username and password. Although this action enhances the accountability of network administrators during TACACS+ outages, it significantly increases the administrative burden, because local user accounts on all network devices must be configured and subsequently maintained.
The following configuration example builds on the previous TACACS+ authentication example to include fallback authentication to the locally configured password, or to the line password if no local password is configured:
aaa authentication login default grouplocal line
Redundant AAA Servers
Whether TACACS+ or RADIUS servers are used, the AAA servers should be redundant and deployed in a fault-tolerant manner. These attributes can help ensure that interactive management access such as SSH is possible if an AAA server is not available. Administrators are advised to consider the following factors when designing AAA servers:
- Availability of AAA servers during potential network failures
- Geographically dispersed placement of AAA servers
- Load on individual AAA servers during steady-state and failure conditions
- Network latency between Network Access Servers and AAA servers
- AAA server databases synchronization
The following example shows how to create redundancy by configuring a total of three TACACS+ servers to be used by the Cisco IOS XR device:
server-private < AAA_Server_IP_Address_1> port 49 key 6no single-connection server-private < AAA_Server_IP_Address_2> port 49 key 6 no single-connection server-private < AAA_Server_IP_Address_3> port 49 key 6 no single-connection
SNMP Overview and Best Practices
The Simple Network Management Protocol (SNMP) is an application-layer protocol that provides a message format for communication between SNMP managers and agents. SNMP provides a standardized framework and a common language for monitoring and managing devices in a network. It is defined with Version 1 in RFC 1157, Version 2 in RFC 3416 and Version 3 in RFC 3414. The following list describes SNMP best practices:
- Only use SNMPv3.
- Use unique SNMP user/group combinations for access to devices.
- Use “authPriv” for access to devices. For authentication, HMAC-SHA and encryption AES is the most secure.
- Use SNMP views to restrict what information a given user/group has access to. Use read-only views unless absolutely necessary.
- Use ACLs if possible.
- Rotate auth/priv credentials on a suitable basis for your organization.
- Use Cisco IOS XR MPP to restrict which hosts can access the device through SNMP.
SNMP Components
A complete SNMP system consists of the following three parts:
- SNMP Manager
- SNMP Agent
- Management Information Base
SNMP Manager
The SNMP Manager is usually an application that runs in a central location. SNMP Manager can request (polls) information from SNMP managed devices or Agents (routers, switches, network servers, etc.). SNMP Manager can also receive unsolicited information, known as a "trap," from an SNMP-managed device, such as a router, switch, or network server.
SNMP Agent
SNMP Agent is the SNMP client software that runs on an SNMP-managed device such as a router, a switch, or a server. All types of data are gathered by the device itself and its activities are stored in a local database called Management Information Base (MIB). The agent can then respond to SNMP polls (requests) and queries with information from the database, and it can send unsolicited alerts or “traps” to an SNMP Manager.
Management Information Base
Management Information Base (MIB) is a database which contains a collection of information organized hierarchically (tree structure). The entire MIB is really a collection of variables (OIDs) that are stored in individual, more granular MIBs that form the branches of the tree.
There are multiple versions of SNMP (SNMPv1, SNMPv2, and SNMPv3). SNMPv1/SNMPv2 are considered legacy and should no longer be used by organizations. Using SNMPv3 is considered the current best practice.
SNMPv3
SNMPv3 provides significant enhancements to address the security weaknesses existing in the earlier versions by implementing three new major features:
- Message integrity: ensuring that a packet has not been modified in transit
- Authentication: ensuring that the message is from a valid source on the network
- Privacy (encryption): using encryption to encrypt the contents of a packet
SNMPv3 provides a far more secure communication using entities, users, and groups.
SNMPv3 Security Levels
The SNMPv3 Agent supports the following three security levels:
- noAuthnoPriv: communication without authentication and privacy.
- authNoPriv: communication with authentication and without privacy. The protocols used for authentication are MD5 and SHA (Secure Hash Algorithm)
- Communication with authentication and privacy. The protocols used for authentication are MD5 and SHA. The protocols used for privacy are DES (Data Encryption Standard) and AES (Advanced Encryption Standard).
To limit what information a user or system has access to, use SNMP views.
The following configuration enables SNMPv3 with the following parameters:
- User called “user1”
- Group called “group1”
- AES 256 encryption
- IPv4 and IPv6 ACLs named “acl1” and “acl2” respectively
- SNMP view that only enables needed MIBs
snmp-server user user1 group1 v3 auth sha-512 ******** priv aes 256 ******** IPv4 acl1 IPv6 acl2
snmp-server group group1 v3 priv read view1
snmp-server view view1 1.3.6.1.2.1.1.5 included
ipv4 access-list acl1
10 permit ipv4 host 192.0.2.1 any
ipv6 access-list acl2
10 permit ipv6 host 2001:db8::1/128 any
IOS XR SNMP Management Plane Protection
In addition to SNMP specific commands, MPP provides the capability to restrict the interfaces on which network management packets are allowed to enter a device. The MPP feature allows a network operator to designate one or more router interfaces as management interfaces.
The following example enables MPP and allows SNMP packets inbound on interface TenGigE0/0/0/0 from host 192.0.2.1:
control-plane
management-plane
inband
interface TenGigE0/0/0/0
allow snmp peer
address ipv4 192.0.2.1
Logging Best Practices
Event logging provides users visibility into the operation of a Cisco IOS XR device and the network on which the device is deployed. Cisco IOS XR Software provides several flexible logging options that can help achieve the network management and visibility goals of an organization.
The following sections provide some basic logging best practices to help administrators utilize logging successfully while minimizing the impact of logging on a Cisco IOS XR device.
For more information, see the Implementing System Logging chapter of the System Monitoring Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 24.1.x, 24.2.x, 24.3.x, 24.4.x.
AAA Logging
AAA logging collects information about user dial-in connections, logins, logouts, HTTP access, privilege-level changes, commands executed, and similar events. AAA log entries are sent to authentication servers using the TACACS+ and RADIUS protocols and are recorded locally by those servers, typically in disk files. If using a TACACS+ or RADIUS server, administrators are advised to enable AAA logging of various types; this is done using AAA configuration commands such as AAA accounting.
For more information, see the Configuring AAA Services chapter in the System Security Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.11.x.
Access Control List Violation Logging
When using access lists to filter traffic, administrators are advised to log some packets that violate the filtering criteria to find out what type of traffic is being sent to the router. Because access list log messages are rate-limited, the performance impact on Cisco IOS XR devices is minimal.
The following access control list (ACL) logging example is used to log access violation from class A address 10.0.0.0 to host 202.202.202.20 and includes input interface:
ipv4 access-list violation-log 10 deny ipv4 10.0.0.0 0.255.255.255 host 202.202.202.20 log-input 20 permit ipv4 any any !
Logging Correlation
Logging correlation can be used to isolate the most significant root messages for events affecting system performance.
For more information, see the Monitoring Alarms and Implementing Alarm Log Correlation section of the System Monitoring Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 24.1.x, 24.2.x, 24.3.x, 24.4.x for more information about logging.
Send Logs to a Central Location
Administrators are advised to send logging information to a remote syslog server to more effectively correlate and audit network and security events across network devices.
Note: Syslog messages are transmitted unreliably by UDP and are transmitted in plain text. Any protections that a network affords to management traffic, such as encryption or out-of-band access, should be extended to include syslog traffic.
The following example shows the configuration of a Cisco IOS XR device that is sending logging information to a remote syslog server with the IP address 10.1.1.1 with default udp port 514:
logging 10.1.1.1 port default !
Secure Logging
To guarantee secure transport of syslogs, Cisco IOS XR supports Secure Logging based on RFC 5425 (Transport Layer Security Transport Mapping for Syslog). With this feature, the router sends syslogs to a remote server over a trusted channel that implements the secure TLS encryption protocol.
TLS ensures secure transport of syslogs by:
- Authenticating the server and client
- Encrypting the syslog data transferred
- Verifying the integrity of data
Follow the configuration steps in the System Security Configuration Guide for Cisco ASR 9000 Series Routers, IOS XR Release 24.1.x, 24.2.x, 24.3.x, 24.4.x to set up the appropriate trustpoint, logging settings, and complete verification steps.
Logging Levels
Each log message generated by a Cisco IOS XR device is assigned one of eight severity levels that range from emergencies to debugging. Unless specifically required, administrators are advised to avoid logging at the debugging level. Logging at the debugging level produces an elevated CPU load that can lead to device and network instability.
The global configuration command logging trap level is used to specify the logging messages that are sent to remote syslog servers. The level specified indicates the lowest severity message that is sent. For buffered logging, the logging buffered level command is used.
The following configuration example shows how to send log messages (from informational through emergencies) to the local log buffer.
logging buffered informational
Disable Console or Monitor Sessions
Cisco IOS XR Software allows administrators to send log messages to monitor sessions. Monitor sessions are interactive management sessions in which the EXEC command, terminal monitor, is issued to the console. The use of the terminal monitor command is not recommended because it can increase the CPU load of a Cisco IOS XR device. Instead, administrators are advised to send logging information to the local log buffer that can be viewed by issuing the show logging command.
Administrators can use the global configuration commands logging console disable and logging monitor disable to disable logging to the console and monitor sessions, as shown in the following configuration:
logging console disable logging monitor disable
Buffered Logging
Cisco IOS XR Software supports the use of a local log buffer so that an administrator can view locally generated log messages. The use of buffered logging is recommended over the use of logging to either the console or monitor sessions.
There are two configuration options that are relevant when configuring buffered logging: the logging buffer size and the message severities that are stored in the buffer. The size of the logging buffer is configured with the global configuration command logging buffered size. The lowest severity included in the buffer is configured using the logging buffered severity command. An administrator can view the contents of the logging buffer through the show logging EXEC command.
The following example configures a logging buffer size of 4096000 bytes, as well as a logging severity of informational, indicating that messages at levels emergencies through informational will be stored:
logging buffered 4096000 logging buffered informational
Caution: Administrators are advised to use caution when increasing the logging buffer size. The buffer size should not be set to large numbers in comparison to the total memory available on the device.
Configure Logging Source Interface
To provide an increased level of consistency and reliability when collecting and reviewing log messages, administrators are advised to statically configure a source interface from which all syslog messages will be sent. Accomplished with the logging source interface command, statically configuring the logging source interface ensures that the same IP address appears in all logging messages that are sent from an individual Cisco IOS XR device. For added stability, it is advisable to use a loopback interface as the logging source.
The following configuration example illustrates the use of the logging source-interface interface global configuration command to specify that the IP address of the loopback 0 interface be used for all outgoing syslog messages:
logging source-interface loopback 0
Configure Logging Timestamps
The configuration of logging timestamps helps correlate events across network devices. It is important to implement a correct and consistent logging timestamp configuration so that logging data can be correlated. Logging timestamps should be configured to include the date and time to millisecond precision and to include the time zone in use on the device. Syslog servers and routers also need to be synchronized using the same Network Time Protocol (NTP) clock source.
The following example shows the configuration of logging timestamps with millisecond precision within the Coordinated Universal Time (UTC) zone:
service timestamps log datetime msec show-timezone
Alternatively, it is possible to configure a specific local time zone (instead of using UTC) and configure that information to be present in generated log messages. The following example shows the configuration of a device to use the Pacific Standard Time (PST) zone in the log message timestamp:
clock timezone PST -8 service timestamps log datetime msec localtime show-timezone
Traffic Protection for Third Party Applications
Traffic Protection for Third-Party Applications functions like MPP, but it secures management traffic sent from sources external to the router to applications running in Docker or natively in Linux on the router itself. If left unconfigured, Cisco IOS XR permits service traffic to pass through any interface with a network address to a service in Linux. This feature now also supports general Linux Networking in IOS XR, with two configuration methods available based on the platform and version.
Traffic Protection for Third-Party Applications enables rate limiting and throttling of traffic using the LPTS. It filters traffic based on several parameters, including VRF, IP address family, local port, interface, local address, and remote address.
Traffic Protection for Third Party Applications
The following example shows a configuration for protecting a third-party application:
tpa
vrf default
address-family ipv4
protection
allow protocol tcp local-port 57722 interface GigabitEthernet0/0/0/0 remote-address 192.0.2.0/24
!
!
!
!
Traffic Protection for Linux Networking
The following example shows a configuration for protecting a Linux networking application:
linux networking
vrf default
address-family ipv4
protection
protocol tcp local-port all default-action deny
!
protocol tcp local-port 57722 default-action deny
permit remote-address 192.0.2.0/24 interface HundredGigE0/0/0/25
!
!
!
!
Best Practices with Traffic Protection
Limit access to Linux-hosted applications with specific interface and source IP addresses. Specify a default-action of deny for all local-ports to limit access to all services that may be opened accidentally in the future. Note that a separate rule is needed for UDP and TCP.
Note: The gRPC service (default TCP port 57400) is included in Traffic Protection for Third-Party Applications/Linux Networking. If the service is enabled, you should include this port in your protection strategy.
For more information, see Application-hosting and Packet-IO on Cisco IOS XR : A Deep Dive.
Control Plane
NTP Security and Design
Synchronized time is critical for network security in the forensic and operational arena. It’s a common Tactics, Techniques and Procedures (TTP) for threat actors to manipulate device time to serve their purposes and attempt to cover their tracks.
It’s advisable to converge your network onto a common singular, yet redundant, time source. That’s not to say devices should be pointed at the same timing server destination, but instead at multiple, trusted low Stratum clock sources (closest to an authoritative Stratum 1 time source as possible). A common secondary and tertiary time source is also a best practice, with three clock sources specified per device. One clock is primary and the others serve as backups. The device will algorithmically determine the best source to use based on a number of factors. If designed correctly, all will be within milliseconds of each other, despite being diversely geolocated. This design approach provides a resilient, redundant time synchronization schema for your entire domain.
Furthermore, the use of NTP authentication to authenticate clients and servers, along with NTP ACLs, is recommended. It is also a best practice to only allow NTP on interfaces in which it is needed.
For more information about NTP design principles, see Use Best Practices for Network Time Protocol.
Local Packet Transport Service (LPTS)
Local Packet Transport Service (LPTS) is a key component of Cisco IOS XR, designed to enhance the handling and processing of control plane traffic. Here are the main aspects of LPTS:
- Purpose: LPTS is responsible for efficiently managing packets destined for the router's control plane. It ensures that the control plane is protected from excessive traffic load, which could potentially degrade the router's performance and stability.
- Functionality: LPTS acts as a policing mechanism by classifying and rate-limiting control packets. It ensures that only legitimate traffic reaches the control plane, preventing it from being overwhelmed by malicious or excessive packet flows.
- Components: LPTS consists of several components, including:
- Flow Managers: These are responsible for classifying incoming packets based on predefined rules and policies.
- Policers: These enforce rate limits on different types of traffic to ensure that no single traffic type can monopolize control plane resources.
- Benefits: By effectively managing control plane traffic, LPTS helps maintain the router's operational efficiency, security, and reliability. It prevents potential Denial of Service (DoS) attacks that target the control plane by limiting the rate of incoming packets.
RP/0/RP0/CPU0:ios#show lpts pifib hardware police location all
-------------------------------------------------------------
Node 0/RP0/CPU0:
-------------------------------------------------------------
FlowType Policer Type Cur. Rate Burst npu Domain
---------------------- ------- ------- --------- --------- --------- ---------
Fragment 32102 Static 1000 98 0 0-default
OSPF-mc-known 32103 Static 2000 2000 0 0-default
OSPF-mc-default 32104 Static 100 8 0 0-default
OSPF-uc-known 32105 Static 2000 2000 0 0-default
OSPF-uc-default 32106 Static 100 8 0 0-default
ISIS-known 32107 Static 2000 2000 0 0-default
ISIS-default 32108 Static 100 8 0 0-default
BGP-known 32116 Static 2500 2975 0 0-default
BGP-cfg-peer 32117 Static 2000 2000 0 0-default
BGP-default 32118 Static 100 8 0 0-default
...
LPTS Best Practices
When configuring and managing Local Packet Transport Service (LPTS) in Cisco IOS XR, it is important to follow best practices to ensure optimal performance and security of the network. It’s important to understand that LPTS has conservative settings by default, and changes may be necessary based on your network baseline. Here are some recommended best practices:
Understand Default Settings:
Familiarize yourself with the default LPTS rates/burst settings and policies on your device. This provides a baseline for any adjustments you may need to make.
Regular Monitoring:
Continuously monitor LPTS statistics and logs to identify any unusual patterns or anomalies in control plane traffic. This helps in detecting potential threats or misconfigurations early.
Adjust Rate Limits as Necessary:
Based on the traffic patterns and requirements of your network, adjust the rate limits for different types of control traffic. Ensure that essential traffic is prioritized and that the control plane is protected from excess load.
For more information, see Introduction to NCS55xx and NCS5xx LPTS . While this is written from the perspective of the NCS-5500 platform, its concepts apply across all platforms.
Secure Border Gateway Protocol
The Border Gateway Protocol (BGP) is the routing foundation of the Internet. As such, any organization with more than modest connectivity requirements often finds itself utilizing BGP. BGP is often targeted by attackers because of its ubiquity and the "set and forget" nature of BGP configurations in smaller organizations. However, there are many BGP security features that can be leveraged to increase the security of a BGP protocol.
This section provides an overview of the most important BGP security features. Where appropriate, configuration recommendations are made.
For more information, see the Implementing BGP section of the Routing Configuration Guide for Cisco ASR 9000 Series Routers, IOS XR Release 24.1.x, 24.2.x, 24.3.x, 24.4.x.
BGP Time-to-Live-Based Security Protection
The BGP Time to Live (TTL)-based security check is designed to protect BGP processes from CPU utilization-based attacks. The BGP protocol defines two types of sessions: "internal" BGP sessions (iBGP) that are established between peers within the same AS, and external BGP (eBGP) sessions that are established between peers in two different ASs. Of particular interest are the eBGP sessions, which are the type of BGP sessions that would be established between an enterprise and its upstream service provider.
By default, and per RFC 3682, when eBGP is configured, the IP header TTL for all neighbor session packets is set to "1." This configuration was originally assumed to be useful because it prevented the establishment of an eBGP session beyond a single hop; however, the configuration does not consider an attacker who could be located up to 255 hops away and could have the ability to send spoofed packets to BGP-speaking routers. For example, an attacker could send large amounts of TCP SYN packets to the BGP peer to overwhelm the BGP process. The BGP TTL security check leverages ISP eBGP peering sessions between routers that are adjacent to each other (either between directly connected interfaces or possibly between loopbacks). Because TTL spoofing is considered nearly impossible, a mechanism that is based on an expected TTL value was developed to provide a simple yet robust defense from infrastructure attacks that are based on forged BGP packets.
Note: This concept was originally defined in The BGP TTL Security Hack (BTSH) document and later extended beyond BGP in RFC 3682, The Generalized TTL Security Mechanism (GTSM).
When the BGP TTL security check is enabled, the initial value for eBGP is set to "255" (instead of "1"), and a minimum TTL value is enforced on all BGP packets that are associated with that eBGP session. Because the IP header TTL value is decremented by each hop (router interface) along its path to its final destination, using BTSH restricts possible attack origins to the directly connected routers.
Currently, Cisco IOS XR Software does not support GTSM for eBGP multi-hop scenarios; only directly connected or loopback-based eBGP peering sessions can use the GTSM feature. This feature is checked in hardware during packets ingress in LCs. GTSM for Cisco IOS XR BGP can be enabled using the following commands:
router bgpneighbor remote-as ttl-security !
For more information on how to configure TTL-security, see the BGP Commands chapter in the Routing Command Reference for Cisco ASR 9000 Series Routers guide.
BGP Peer Authentication with TCP AO
BGP neighbor sessions are established between two peers and then routes are exchanged between them. By enabling TCP-AO based neighbor authentication mechanism, administrators can ensure that only authorized peers establish this BGP neighbor relationship, and that the routing information exchanged between these two devices has not been altered en-route between the two systems. TCP Authentication Option (TCP-AO) replaces BGP Peer Authentication using message digest algorithm 5 (MD5), as MD5 is cryptographically less secure and changing a MD5 key normally disrupts the BGP session because it does not allow for dynamic key rollover, unlike TCP-AO.
TCP-AO has the following distinct features:
- Supports the use of stronger Message Authentication Codes (MACs) to enhance the security of long-lived TCP connections.
- Protects against replays for long-lived TCP connections and coordinates key changes between endpoints by providing more explicit key management.
The BGP neighbor authentication process is a symmetric technique. Therefore, when this process is turned on, it must be simultaneously enabled on both sides of the peering session. Neighbor authentication using TCP-AO creates a Message Authentication Code (MAC) for each packet that is sent as part of a BGP session. Specifically, portions of the IP and TCP headers, TCP payload that includes the BGP route advertisements, and the shared secret key are used to generate the MAC by the sending router. The created MAC is then stored in TCP option Kind 29, which was created specifically for this purpose in RFC 5925. The receiving BGP speaker neighbor uses the same algorithm and shared secret key to regenerate and compute its own version of the MAC. The receiving BGP speaker neighbor compares its own version with the one it received; if the received and computed MAC values are not identical, the packet is discarded. Otherwise, the packet is accepted and processed by BGP.
Peer authentication with TCP AO is configured by using a key chain and associating it to the BGP neighbor. The following example illustrates the use of this command:
key chainkey accept-lifetime send-lifetime key-string cryptographic-algorithm tcp ao keychain key-id send_id <0-255> receive_id <0-255> router bgp neighbor remote-as ao
BGP Maximum Prefixes
BGP prefixes are stored by a router in memory. The more prefixes a router must hold, the greater the memory consumed by BGP. Both malicious and inadvertent (misconfiguration) processes can cause excessive prefixes to be seen by a BGP peer. To prevent memory exhaustion, it is important to configure the maximum number of prefixes accepted on a per-peer basis. Administrators are advised to configure limits for each BGP peer.
When configuring BGP prefixes using the neighbor maximum-prefix BGP router configuration command, one argument is required: the maximum number of prefixes that are accepted before a peer is shut down. Optionally, a number from 1–100 can also be entered. This number represents the percentage of the maximum prefixes value at which point a log message can be sent. The following is an example of a BGP configuration:
! router bgpneighbor remote-as address-family unicast maximum-prefix [ipv4}[ipv6] [threshold] [warning-only] !
The BGP maximum-prefix feature allows users to control the number of prefixes that can be installed from a neighbor. When configured, this feature will bring down a neighbor relationship when the number of received prefixes from that peer exceeds the configured maximum-prefix limit. Typically, the maximum-prefix threshold would be set with some margin of error over a target value to accommodate some degree of unexpected changes in topology. The other warning-only option does not cause the neighbor relationship to be brought down, but simply issues a message when the threshold is exceeded. This feature is commonly used for external BGP peers but can also be applied to internal BGP peers. For more information, see the Routing Command Reference for Cisco ASR 9000 Series Routers guide.
Filter BGP Prefixes with RPL policies
In Cisco IOS XR devices, BGP allows users to filter prefixes that are based on network prefixes, as-paths, and community or ext-community values.
Prefix sets allow a network administrator to permit or deny specific prefixes that are sent or received by way of BGP. Prefix sets should be used when possible to ensure that network traffic is sent over the intended paths. Prefix lists should be applied to each eBGP peer in both the inbound and outbound directions.
Configured prefix sets limit the prefixes that are sent or received to prefixes that are specifically permitted by the routing policy of a network. If this is not feasible because of many prefixes received, a prefix set should be configured to specifically block known bad prefixes. These known bad prefixes include unallocated IP address space and networks that are reserved for internal or testing purposes by RFC 3330. Outbound prefix lists should be configured to specifically permit only the prefixes that an organization intends to advertise.
The following is a simple example of the BGP route policy using a prefix set to drop 10.0.2.0/24 and 10.0.3.0/24 incoming prefixes. It uses prefix-set and the policy is attached to the neighbor inbound attach point.
! prefix-set10.0.2.0/24, 10.0.3.0/24 end-set ! route-policy if destination in then drop endif end-policy ! router bgp neighbor address-family ipv4 unicast route-policy in !
The following configuration uses as-path-set to permit inbound prefixes, which include AS path 12 or 13, but to drop other prefixes:
! as-path-setios-regex ‘12$’, ios-regex ‘13$’ end-set route-policy if as-path in then pass else drop endif end-policy ! router bgp neighbor address-family ipv4 unicast route-policy in !
For more information about RPL BGP, see the Implementing Routing Policy section of the Routing Configuration Guide for Cisco ASR 9000 Series Routers, IOS XR Release 24.1.x, 24.2.x, 24.3.x, 24.4.x.
Secure Interior Gateway Protocols
Interior Gateway Protocols (IGPs) are dynamic and discover additional routers that communicate with the particular IGP in use. IGPs also discover routes that can be used during a network link failure.
IGP TTL Security
The Generalized TTL Security Mechanism (GTSM) (RFC 3682) is designed to protect the control plane of a router from CPU utilization-based attacks. Because TTL spoofing is considered nearly impossible, a mechanism that is based on an expected TTL value can provide a simple and reasonably robust defense from infrastructure attacks that are based on forged protocol packets. GTSM is equally applicable to both TTL (IPv4) and Hop Limit (IPv6) values.
OSPF is a link state protocol that requires networking devices to detect topological changes in the network; flood Link State Advertisement (LSA) updates to neighbors; and quickly converge on a new view of the topology. However, while receiving LSAs from neighbors, network attacks can occur, because no checks occur to distinguish whether unicast or multicast packets are originating from a neighbor that is one hop away or multiple hops away over virtual links. For virtual links, OSPF packets travel multiple hops across the network; therefore, the TTL value can be decremented several times. For virtual links, a minimum TTL value must be allowed and accepted for multiple hop packets.
The following is a sample configuration of GTSM for OSPF. GTSM can be configured on a per-interface basis or globally for all OSPF peers. In the following example, GTSM is configured for a specific interface, “Interface”. The number of hops is the parameter that changes the default expected TTL value of incoming packets.
! router ospfarea interface security ttl hops !
For more information on IGP TTL Security refer to Path Computation Element for OSPFv2 in the Routing Configuration Guide for Cisco ASR 9000 Series Routers, IOS XR Release 24.1.x, 24.2.x, 24.3.x, 24.4.x.
IGP Peer Authentication with MD5
Failure to secure the exchange of routing information could allow an attacker to introduce false routing information into the network. By using password authentication with routing protocols between routers, administrators can help secure the network. Because this authentication is sent as plain text, however, the attacker could easily subvert this security control. By adding MD5 hash capabilities to the authentication process, the routing updates no longer contain plaintext passwords, and the entire contents of the routing update are more resistant to tampering.
MD5 authentication is still susceptible to brute force and dictionary attacks if weak passwords are chosen. Administrators are advised to use passwords with sufficient randomization. MD5 authentication is more secure than password authentication.
The following subsections detail the specific implementations of the OSPF and IS-IS protocols.
OSPF Authentication with MD5
All OSPF routing protocol exchanges should be authenticated, and the method used can vary depending on how authentication is configured. When using cryptographic authentication, the OSPF routing protocol uses the MD5 authentication algorithm to authenticate packets that are transmitted between neighbors in the network. For each OSPF protocol packet, a key is used to generate and verify a message digest that is appended to the end of the OSPF packet. The message digest is a one-way function of the OSPF protocol packet and the secret key. Each key is identified by the combination of the interface used and the key identification.
The following configuration example shows OSPF authentication with MD5 Configuration:
! router ospfarea authentication message-digest interface message-digest-key md5 !
Intermediate System to Intermediate System Authentication with MD5
Authentication should be configured to limit the establishment of adjacencies by using the hello-password command and limit the exchange of LSPs by using the lsp-password command. Intermediate System to Intermediate System (IS-IS) supports plaintext authentication, which does not provide security against unauthorized users. The password is exchanged as plain text and is potentially visible to an agent who can view the IS-IS packets. When an HMAC-MD5 password is configured, the password is never sent over the network and, instead, is used to calculate a cryptographic checksum to ensure the integrity of the exchanged data.
To set the domain password, configure the lsp-password command for Level 2; to set the area password, configure the lsp-password command for Level 1.
The following configuration example shows IS-IS authentication with MD5 configuration:
! router isislsp-password hmac-md5 interface hello-password hmac-md5 !
Open Shortest Path First Authentication with Keychain
The following examples show the OSPF configuration, which establishes a keychain to set the password at the global, area, and interface levels.
Router-level configuration:
! router ospfauthentication message-digest keychain !
Area-level configuration:
! router ospfarea 0 authentication message-digest keychain
Interface-level configuration:
! router ospfarea 0 interface authentication message-digest keychain !
IS-IS Authentication with Keychain
The following example shows IS-IS configuration, which configures a keychain to set the domain and area passwords at the global and interface levels.
! router isislsp-password keychain interface hello-password keychain -keys !
Passive Interface
The use of the passive interface capabilities within IGPs has two benefits. First, such capabilities reduce the CPU load on the router by suppressing the generation and processing of IGP protocol messages on the identified interface(s). Second, these capabilities could help mitigate information leaks by not advising IGP protocol information to networks beyond administrative control.
The following example shows the use of the passive command for the OSPF protocol for a specific interface (“Interface”). If the passive command is not configured, the interface generates and receives normal OSPF traffic flow (default behavior).
! router ospfarea interface passive ! The following shows the ISIS configuration example: ! router isis interface passive !
IGP Route Filtering
IGP Routing Process Resource Consumption
Routing protocol prefixes are stored by a router in memory, and resource consumption increases with the additional prefixes that a router must hold. To prevent resource exhaustion, it is important to set protocol limits for the number of accepted and stored prefixes.
For more information, see Routing Configuration Guide for Cisco ASR 9000 Series Routers, IOS XR Release 24.1.x, 24.2.x, 24.3.x, 24.4.x.
OSPF Maximum Redistributed Prefix Limit
To limit the aggregate number of routes that may be redistributed into an OSPF process, administrators are advised to use the maximum redistributed-prefix command in the appropriate mode. The following example shows how to configure a maximum number of routes that can be redistributed for an OSPF routing process:
! router ospfmaximum redistributed-prefixes !
IS-IS Redistributed Prefix Limit
To specify an upper limit on the number of external prefixes (subject to summarization) that the IS-IS protocol advertises, use the maximum-redistributed-prefixes command in address family mode.
! router isisaddress-family ipv4 unicast maximum-redistributed-prefixes level !
Data Plane
Disable General Data Plane Hardening
Protection of the data plane of a network device is critical because the data plane is responsible for routing packets throughout the infrastructure. If the data plane has unneeded features enabled, then it could increase the available attack surface for unwanted attacks.
In many cases, you can disable the reception and transmission of certain message types on an interface to minimize the number of features and to reduce the load required to process unneeded packets.
IP Source Routing
Source routing refers to a configuration where the sending device (source) explicitly determines the path that a packet should take by including the necessary route information within the packet header. This configuration instructs the routers along the way about which path to follow rather than relying on the standard routing protocol calculations done by the router. It is defined in the IP RFC 791.
Source routing is disabled by default in Cisco IOS XR. It is considered a legacy technique and should not be used. More modern techniques such as Segment Routing MPLS and Segment Routing IPv6 should be considered.
To ensure source routing is disabled, globally configure the following:
no ipv4 source-route
IP Directed Broadcast
A directed broadcast is a packet sent to a specific network address on a segment that gets sent to all hosts in the segment. In modern network designs, there is no need for this functionality.
In Cisco IOS XR, IPv4 directed broadcast is disabled per interface by default. It is considered a legacy technique and should not be used.
To ensure IP directed broadcast is disabled, configure the following command on each interface. (The following command uses interface TenGigE0/0/0/0 as an example.)
interface TenGigE0/0/0/0 no ipv4 directed-broadcast
ICMP Redirects
ICMP redirect functionality is explained in RFC 792. ICMP redirects are sent by a device when there is a better path between a host and a destination. For example:
A gateway, G1, receives an Internet datagram from a host on a network to which the gateway is attached. The gateway, G1, checks its routing table and obtains the address of the next gateway, G2, on the route to the destination network X.
If G2 and the host that is identified by the IP source address of the datagram are on the same network, a redirect message is sent to the host. The redirect message advises the host to send its traffic for network X directly to gateway G2 as this is a shorter path to the destination.
The gateway forwards the original datagram data to its Internet destination.
ICMP redirects are disabled by default in Cisco IOS-XR.
- Disable or leave disabled ICMP redirects unless your network design dictates the need for them.
- In most modern network designs, multiple L3 devices on a given segment usually run a redundancy protocol (VRRP/HSRP/etc.) designed to make network failures or optimal routing decisions so that the host gateway does not need to change.
To ensure ICMP redirects are disabled, configure the following command on each interface. (The following command uses interface TenGigE0/0/0/0 as an example.)
interface TenGigE0/0/0/0 no ipv4 redirects
ICMP Unreachables
Internet Control Message Protocol (ICMP) was designed to report or propagate a small set of error conditions for IP forwarding. ICMP messages are sent in several situations: when a datagram cannot reach its destination, when the gateway does not have the buffering capacity to forward a datagram, and when the gateway can direct the host to send traffic on a shorter route.
ICMP Unreachable Error Messages
Type 3 error messages are sent when a message cannot be delivered completely to the application at a destination host. Six codes contained in the ICMP header describe the unreachable condition as follows:
- 0 - Network unreachable
- 1 - Host unreachable
- 2 - Protocol unreachable
- 3 - Port unreachable
- 4 - Fragmentation needed and the “don’t fragment” (DF) bit is set
- 5 - Source route failed
Note: ICMP Unreachables are enabled by default in Cisco IOS XR.
To disable ICMP unreachables, configure the following command on each interface. (The following command uses interface TenGigE0/0/0/0 as an example.)
interface TenGigE0/0/0/0 no ipv4 unreachables disable
Proxy ARP
Proxy ARP is the technique by which one device, usually a router, answers ARP requests that are intended for another device. By acting on behalf of the other device, the router accepts responsibility for routing packets to the real destination. Proxy ARP can help networked devices on one subnet reach devices on remote subnets without configuring routing or a default gateway. Proxy ARP is defined in RFC 1027.
There are several disadvantages to using proxy ARP. The use of proxy ARP can result in increased ARP traffic on the network, segment and resource exhaustion, and man-in-the-middle attacks. Proxy ARP can be used by a resource exhaustion attack vector because each proxy ARP request consumes a small amount of memory. An attacker could exhaust all available memory by sending many ARP requests. Man-in-the-middle attacks enable a host on the network to spoof the MAC address of the router, resulting in unsuspecting hosts sending traffic to the attacker.
Proxy ARP is disabled by default in Cisco IOS XR software.
To ensure Proxy ARP is disabled, configure the following command on each interface. (The following command uses interface TenGigE0/0/0/0 as an example.)
interface TenGigE0/0/0/0 no proxy-arp
IP Fragmentation
IP Fragmentation is a process used in networking to break down large packets of data into smaller pieces, called fragments, so they can be transmitted across networks with varying Maximum Transmission Unit (MTU) sizes. Each fragment is sent separately and reassembled at the destination.
IP fragmentation allows data to traverse networks that have different MTU sizes without being dropped. When a packet larger than the MTU is detected, it is split into smaller fragments, each with its own IP header. Fragments are reassembled into the original packet at the destination before being processed further.
IPv4 Fragmentation
IPv4 fragmentation, specifically, poses several security challenges:
Evasion of Security Measures:
- Overlapping Fragments: Attackers can send overlapping fragments to confuse the reassembly process, potentially allowing malicious payloads to bypass security mechanisms. For example, a fragment may overwrite portions of TCP headers or segments of data to bypass access control lists.
- Firewalls and Intrusion Detection Systems (IDS): These may struggle to inspect fragmented packets efficiently, allowing threats to slip through unnoticed.
Resource Exhaustion:
- Handling fragmented packets requires additional processing power and memory, which can be exploited to exhaust network resources.
IPv6 Fragmentation
IPv6 handles fragmentation differently compared to IPv4, primarily to enhance efficiency and security. Here are the key differences:
Fragmentation by End Hosts Only:
- In IPv6, fragmentation is performed only by the source device, not by routers along the path. This contrasts with IPv4, where routers can fragment packets.
- IPv6 uses a Fragment Extension Header to handle fragmentation. This header contains necessary information to reassemble the original packet at the destination.
- IPv6 relies on Path MTU Discovery (ICMPv6 packet too big messages) to ensure that packets are sent at the maximum size supported by the entire path without requiring fragmentation by routers.
No Fragmentation in the Network Layer:
- IPv6 requires that packets are sent in sizes that fit the smallest MTU on the path, eliminating the need for routers to perform fragmentation, thus reducing processing overhead and potential security risks.
IP Fragmentation Best Practice
To address these issues, consider implementing the following strategies:
- Enforce MTU Consistency: Use Path MTU Discovery to ensure that packets are appropriately sized for the network path. If MTU changes do occur, do this at the peering connections of your network. As explained in the ICMP Unreachables section of this hardening guide, leave unreachables enabled and unfiltered to ensure that Path MTU Discovery functions without fragmentation.
- Filtering fragments at the edge via infrastructure access control lists (ACLs): ACLs can be applied to the edge of the network. In the case of a service provider, this may be the edge of the Autonomous System (AS). This ACL explicitly filters traffic destined for infrastructure address space. Deployment of edge infrastructure ACLs requires that you clearly define your infrastructure space and the required/authorized protocols that access this space. The ACL is applied at ingress to your network on all externally facing connections, such as peering connections, customer connections, and so forth. Fragments not destined to internal infrastructure should be allowed. If fragments are necessary, police them using modular QoS configurations.
- Police “for-us” packets, destined for infrastructure devices using Local Packet Transport Services (LPTS): LPTS is explained in the Control Plane section of this hardening guide.
Cisco IOS XR differentiates between three types of packets: non-fragmented packets (with Layer 4 port information), initial fragments (with Layer 4 information), and non-initial fragments (without Layer 4 port information).
To police fragmented UDP packets, for example, configure the following:
ipv4 access-list ACL_UDP_FRAGMENTS 10 permit udp 192.0.2.0/24 198.51.100.0/24 fragments ! class-map match-all UDP_FRAGMENTS match access-group ipv4 ACL_UDP_FRAGMENTS end-class-map ! policy-map PEER_INPUT class UDP_FRAGMENTS police rate percent 1 ! lpts pifib hardware police flow fragment rate 10
The fragments keyword matches non-initial fragments and cannot be configured for an access-list entry that contains any Layer 4 port information.
For more information, see the ACL IP Fragments Matching - NCS55xx and NCS5xx guide. While it is written for the NCS-5500 platform in mind, some of its concepts apply to all platforms that run Cisco IOS XR.
Disk Encryption
Protection of sensitive data on persistent storage media is recommended in the form of disk encryption. Disk encryption can guarantee data confidentiality.
Cisco IOS XR Software introduces SSD encryption that allows for encryption of sensitive data at the disk level. SSD encryption also ensures that the encrypted data is specific to a system and is accessible only with a specific key to decrypt them.
Disk encryption encrypts the partition of the disk which holds the router’s configuration data. Encryption is an automatic process and can be achieved through the following:
- DM-Crypt
- CPU with AES-NI support
- CryptSetup
- DM-Crypt
- AES-NI Support
- CryptSetup
For more information, see SSD Encryption from the System Security Configuration Guide for Cisco NCS 5500 Series Routers, Cisco IOS XR Release 7.5.x.
Conclusion
This document provides a broad overview of the methods that can be used to secure a Cisco IOS XR system device. By securing the individual devices, you increase the overall security of the networks that you manage. In this overview, protection of the management, control, and data planes is discussed, and recommendations for configuration are supplied. Where possible, sufficient detail is provided for the configuration of each associated feature. However, in all cases, comprehensive references are provided to supply you with the information needed for further evaluation.
Appendix: Cisco IOS XR Hardening Checklist
This checklist is a collection of all the hardening steps that are presented in this guide. Administrators can use it as a reminder of all the hardening features used and considered for a Cisco IOS XR device, even if a feature was not implemented because it did not apply. Administrators are advised to evaluate each option for its potential risk before they implement the option.
Management Plane
- Use Type 10 (SHA-512) or Type 8 (SHA-256 with PBKDF2) hashed format strings for one-way passwords
- Deploy Type 6 encryption for 2-way passwords
- Configure password policies for each local account
- Disable unused services
- Set EXEC timeout
- Enable SSH, SFTP, or HTTPS protocols
- Adopt passwordless SSH
- Enable MPP
- Configure a warning banner
- Configure user groups to control access to resources or devices
- Deploy TACACS+ over TLS 1.3 or RADIUS protocols
- Configure Radius over TLS
- Create redundancy in AAA servers
- Use SNMPv3 with unique user/group combinations and ACLs
- Enable AAA logging
- Log ACL violators
- Employ logging correlation
- Send logs to a central location
- Employ Secure logging
- Configure logging levels to informational
- Disable console or monitor sessions
- Use buffered logging
- Configure logging source interface
- Configure logging timestamps
- Avoid using HTTP/HTTPS web server feature
- Limit third party application access via Traffic Protection
Control Plane
- Use NTP to authenticate clients and servers
- Leverage LPTS and understand, monitor, and adjust rate limits as necessary
- Employ BGP Time-to-Live-based security protection
- Authenticate BGP peer sessions with TCP AO
- Set BGP maximum prefixes
- Filter BGP prefixes with RPL policies
- Employ IGP Time-to-Live-based security protection
- Authenticate IGP peer sessions with MD5
- Use Passive Interface on interfaces where no adjacency is needed
- Filter IGP prefixes with RPL Policies
- Set IGP maximum prefixes
Data Plane
- Disable IP source routing, IP directed broadcast, ICMP redirects, and proxy ARP
- Protect sensitive information with data encryption
Revision History
| Updated Date | Comments |
|---|---|
| 08-Oct-2025 | Added information about TACACS+ over TLS 1.3. |
| 17-Feb-2025 | Initial Release |
This document is part of the Cisco Security portal. Cisco provides the official information contained on the Cisco Security portal in English only.
This document is provided on an “as is” basis and does not imply any kind of guarantee or warranty, including the warranties of merchantability or fitness for a particular use. Your use of the information in the document or materials linked from the document is at your own risk. Cisco reserves the right to change or update this document without notice at any time.