Free DISA STIG and SRG Library | Vaulted

Cisco IOS XE Release 3 RTR Security Technical Implementation Guide

Version 1 Release 53
2019-01-252018-04-27
U_Cisco_IOS_-XE_Release_3_RTR_STIG_V1R53_Manual-xccdf.xml
This Security Technical Implementation Guide is published as a tool to improve the security of Department of Defense (DoD) information systems. The requirements are derived from the National Institute of Standards and Technology (NIST) 800-53 and related documents. Comments or proposed revisions to this document should be sent via email to the following address: disa.stig_spt@mail.mil.

Compare Summary

Compare V1R5 to V1R3
  • All
  • Updated 1
  • Added 0
  • Removed 0

Vulnerabilities (23)

The Cisco IOS XE router must be configured to disable non-essential capabilities.

Finding ID
CISR-RT-000015
Rule ID
SV-88799r3_rule88799r2_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-NET-000131-RTR-000035
CCI
CCI-000381
Target Key
(None)
Documentable
No
Discussion

A compromised router introduces risk to the entire network infrastructure as well as data resources that are accessible via the network. The perimeter defense has no oversight or control of attacks by malicious users within the network. Preventing network breaches from within is dependent on implementing a comprehensive defense-in-depth strategy including securing each device connected to the network. This is accomplished by following and implementing all security guidance applicable for each node type. A fundamental step in securing each router is to enable only the capabilities required for operation.

Fix Text

Disable all unnecessary or non-secure ports, protocols and services. noIf ipany bootpof serverthe nofollowing ipcommands dnsare serverin nothe ipconfiguration, fingerremove nothem. ip http server no ip identd no ip rcmd rcp-enable no ip rcmd rsh-enable no service config no service udp-small-servers no service tcp-small-servers no service finger no service pad lineip vtydns 0server 4ip noidentd transportip inputfinger noip transporthttp-server outputip transportrcmd inputrcp-enable sship transportrcmd outputrsh-enable sship Note:bootp transportserver input and output for telnet service can’t be disabled individually; hence, ssh must be reinserted for access to the line vty configuration. config

Check Content

Verify that the Cisco IOS XE router does not have any unnecessary or non-secure ports, protocols and services enabled. For example, the following commands should not be in the configuration: ip bootp server ip dnsidentd server ip finger ip http -server ip identd ip rcmd rcp-enable ip rcmd rsh-enable service config service finger service tcp-small-servers service udp-small-servers service pad transport input telnet transport output telnet If any unnecessary or non-secure ports, protocols or services are enabled, this is a finding.

The Cisco IOS XE router must enforce approved authorizations for controlling the flow of information between interconnected networks in accordance with applicable policy.

Finding ID
CISR-RT-000001
Rule ID
SV-88769r2_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-NET-000019-RTR-000002
CCI
CCI-001414
Target Key
(None)
Documentable
No
Discussion

Information flow control regulates authorized information to travel within a network and between interconnected networks. Controlling the flow of network traffic is critical so it does not introduce any unacceptable risk to the network infrastructure or data. An example of a flow control restriction is blocking outside traffic claiming to be from within the organization. For most routers, internal information flow control is a product of system design.

Fix Text

Configure the Cisco IOS XE router to block all inbound packets with a source IP address belonging to the private network. The configuration would look similar to the example below: interface FastEthernet 0/0 description NIPRNet link ip address x.x.x.x 255.255.255.0 ip access-group INGRESS_ACL in ... ip access-list extended INGRESS_ACL deny ip 1.1.1.0 0.0.0.255 any log ...

Check Content

Review the Cisco IOS XE router configuration. Verify that the external interface blocks inbound traffic with a source IP address belonging to the internal network. The configuration should look similar to the example below where the private IP address space is 1.1.1.0/24: interface FastEthernet 0/0 description NIPRNet link ip address x.x.x.x 255.255.255.0 ip access-group INGRESS_ACL in ... ip access-list extended INGRESS_ACL deny ip 1.1.1.0 0.0.0.255 any log ... If the external interface of the Cisco IOS XE router has not been configured to block all inbound packets with a source IP address belonging to the private network, this is a finding.

The Cisco IOS XE router must disable Protocol Independent Multicast (PIM) on all interfaces that are not required to support multicast routing.

Finding ID
CISR-RT-000002
Rule ID
SV-88771r2_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-NET-000019-RTR-000003
CCI
CCI-001414
Target Key
(None)
Documentable
No
Discussion

If multicast traffic is forwarded beyond the intended boundary, it is possible that it can be intercepted by unauthorized or unintended personnel. Limiting where, within the network, a given multicast group's data is permitted to flow is an important first step in improving multicast security. A scope zone is an instance of a connected region of a given scope. Zones of the same scope cannot overlap while zones of a smaller scope will fit completely within a zone of a larger scope. For example, Admin-local scope is smaller than Site-local scope, so the administratively configured boundary fits within the bounds of a site. According to RFC 4007 IPv6 Scoped Address Architecture (section 5), scope zones are also required to be "convex from a routing perspective"; that is, packets routed within a zone must not pass through any links that are outside of the zone. This requirement forces each zone to be one contiguous island rather than a series of separate islands. As stated in the DoD IPv6 IA Guidance for MO3, "One should be able to identify all interfaces of a zone by drawing a closed loop on their network diagram, engulfing some routers and passing through some routers to include only some of their interfaces." Therefore, it is imperative that the network has documented their multicast topology and thereby knows which interfaces are enabled for multicast. Once this is done, the zones can be scoped as required.

Fix Text

Configure the Cisco IOS XE router so that PIM is disabled on interfaces that are not required to support it. The configuration would look similar to the example below: ISR4000 (config) #Interface GigabitEthernet 0/0/1 ISR4000 (config) #no ip PIM

Check Content

Review the Cisco IOS XE router configuration to determine if IPv4 or IPv6 multicast routing is enabled. Verify all interfaces enabled for PIM are documented in the network's multicast topology diagram. Review the router configuration to determine if multicast routing is enabled and which interfaces are enabled for PIM. Following is an example of multicast globally enabled and PIM enabled on an interface. ip multicast-routing distributed ! … … … interface GigabitEthernet4 ip address 1.1.35.3 255.255.255.0 ip pim sparse-mode If an interface is not required to support multicast routing and it is enabled, this is a finding.

The Cisco IOS XE router must bind a Protocol Independent Multicast (PIM) neighbor filter to interfaces that have PIM enabled.

Finding ID
CISR-RT-000003
Rule ID
SV-88773r2_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-NET-000019-RTR-000004
CCI
CCI-001414
Target Key
(None)
Documentable
No
Discussion

Protocol Independent Multicast (PIM) is a routing protocol used to build multicast distribution trees for forwarding multicast traffic across the network infrastructure. Protocol Independent Multicast traffic must be limited to only known PIM neighbors by configuring and binding a PIM neighbor filter to those interfaces that have PIM enabled. If a PIM neighbor filter is not applied to those interfaces that have PIM enabled, an unauthorized routers can join the PIM domain and discover and use the rendezvous points, and also advertise their rendezvous points into the domain. This can result in a denial of service by traffic flooding or result in the unauthorized transfer of data.

Fix Text

Configure the Cisco IOS XE router with PIM neighbor filters on all PIM-enabled interfaces as shown in the example below: ip access-list standard PIM-NEIGHBORS permit 192.0.2.1 permit 192.0.2.3 ... ... ... interface GigabitEthernet0/3 ip address 192.0.2.2 255.255.255.0 ip pim sparse-mode ip pim neighbor-filter PIM-NEIGHBORS

Check Content

Step 1: Verify that an ACL is configured that will specify the allowable PIM neighbors similar to the following example: ip access-list standard PIM-NEIGHBORS permit 192.0.2.1 permit 192.0.2.3 Step 2: Verify that a pim neighbor-filter command is configured on all PIM enabled interfaces that is referencing the PIM neighbor ACL similar to the following example: interface GigabitEthernet0/3 ip address 192.0.2.2 255.255.255.0 ip pim sparse-mode pim neighbor-filter PIM-NEIGHBORS If the Cisco IOS XE router has not been configured with PIM neighbor filter on all PIM-enabled interfaces, this is a finding.

The Cisco IOS XE router must establish boundaries for IPv6 Admin-Local, IPv6 Site-Local, IPv6 Organization-Local scope, and IPv4 Local-Scope multicast traffic.

Finding ID
CISR-RT-000004
Rule ID
SV-88777r2_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-NET-000019-RTR-000005
CCI
CCI-001414
Target Key
(None)
Documentable
No
Discussion

If multicast traffic is forwarded beyond the intended boundary, it is possible that it can be intercepted by unauthorized or unintended personnel. Administrative scoped multicast addresses are locally assigned and are to be used exclusively by the enterprise network or enclave. Administrative scoped multicast traffic must not cross the enclave perimeter in either direction. Restricting multicast traffic makes it more difficult for a malicious user to access sensitive traffic. Admin-Local scope is encouraged for any multicast traffic within a network intended for network management, as well as for control plane traffic that must reach beyond link-local destinations.

Fix Text

Configure the Cisco IOS XE router with the appropriate IPv6 multicast boundary scopes and with the appropriate IPv4 access control lists, as seen in the example below: interface GigabitEthernet0/0/0 ip address 192.168.25.75 255.255.255.0 ip access-group V4_LOCAL_SCOPE out ipv6 address 2001:192:168:25::75/64 ipv6 multicast boundary scope 4 ! ip access list extended V4_LOCAL_SCOPE 10 deny ip 239.255.0.0 0.0.255.255 any log Note: The IPv6 scopes are defined as follows: subnet-local (3) admin-local (4) site-local (5) organization-local (8)

Check Content

Review the multicast topology diagram to determine if there are any documented Admin-Local (FFx4::/16), Site-Local (FFx5::/16), or Organization-Local (FFx8::/16) multicast boundaries for IPv6 traffic or any Local-Scope (239.255.0.0/16) boundaries for IPv4 traffic. Verify the appropriate boundaries are configured on the applicable multicast-enabled interfaces. The configuration should look similar to the example below: interface GigabitEthernet0/0/0 ip address 192.168.25.75 255.255.255.0 ip access-group v4_Local_Scope out ipv6 address 2001:192:168:25::75/64 ipv6 multicast boundary scope 4 end Extended IP access list v4_Local_Scope 10 deny ip 239.255.0.0 0.0.255.255 any log Note: The IPv6 scopes are defined as: admin-local Admin-local(4) organization-local Organization-local(8) site-local Site-local(5) If the appropriate boundaries are not configured on applicable multicast-enabled interfaces, this is a finding.

The Cisco IOS XE router must be configured so inactive interfaces are disabled.

Finding ID
CISR-RT-000005
Rule ID
SV-88779r2_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-NET-000019-RTR-000007
CCI
CCI-001414
Target Key
(None)
Documentable
No
Discussion

An inactive interface is rarely monitored or controlled and may expose a network to an undetected attack on that interface. Unauthorized personnel with access to the communication facility could gain access to a router by connecting to a configured interface that is not in use. If an interface is no longer used, the configuration must be deleted and the interface disabled. For sub-interfaces, delete sub-interfaces that are on inactive interfaces and delete sub-interfaces that are themselves inactive. If the sub-interface is no longer necessary for authorized communications, then it must be deleted.

Fix Text

Configure the Cisco IOS XE router so that all inactive sub-interfaces are deleted, and disable and delete the configuration of any inactive ports on the router. To shut down an interface see the following commands: ISR4000(config) #Interface GigabitEthernet 0/0/1 ISR4000(config-if) #shutdown To clear the configuration of an inactive interface, use the following command: ISR4000 (config) #default interface GigabitEthernet 0/0/1

Check Content

View the configuration of the Cisco IOS XE router. The configuration should look similar to the example below: interface GigabitEthernet0/0/0 no ip address shutdown If an interface is not being used, but is configured or enabled, this is a finding.

The Cisco IOS XE router must protect an enclave connected to an Alternate Gateway by using an inbound filter that only permits packets with destination addresses within the sites address space.

Finding ID
CISR-RT-000006
Rule ID
SV-88781r2_rule
Severity
Cat I
CCE
(None)
Group Title
SRG-NET-000019-RTR-000009
CCI
CCI-001414
Target Key
(None)
Documentable
No
Discussion

Enclaves with Alternate Gateway connections must take additional steps to ensure there is no compromise on the enclave network or NIPRNet. Without verifying the destination address of traffic coming from the site's Alternate Gateway, the perimeter router could be routing transit data from the Internet into the NIPRNet. This could also make the perimeter router vulnerable to a DoS attack as well as provide a backdoor into the NIPRNet. The DoD enclave must ensure the ingress filter applied to external interfaces on a perimeter router connecting to an Approved Gateway is secure through filters permitting packets with a destination address belonging to the DoD enclave's address block.

Fix Text

Configure the Cisco IOS XE router to permit packets with destination addresses of the site's NIPRNet address space or a destination address belonging to the address block assigned by the Alternate Gateway network service provider. The configuration would look similar to the example below: interface GigabitEthernet 0/0/1 description Alternate Gateway link ip address x.x.x.x 255.255.255.0 ip access-group Alternate_Gateway_ACL in ... ip access-list extended Alternate_Gateway_ACL permit ip 1.1.1.0 0.0.0.255 any log ...

Check Content

Review the configuration of each router interface connecting to an Alternate Gateway on the Cisco IOS XE router. Verify each permit statement of the ingress filter only permits packets with destination addresses of the site's NIPRNet address space or a destination address belonging to the address block assigned by the Alternate Gateway network service provider. If the ingress filter permits packets with addresses other than those specified, such as destination addresses of the site's NIPRNet address space or a destination address belonging to the address block assigned by the Alternate Gateway network service provider, this is a finding.

The Cisco IOS XE router must not be a BGP peer with a router from an Autonomous System belonging to any Alternate Gateway.

Finding ID
CISR-RT-000007
Rule ID
SV-88783r2_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-NET-000019-RTR-000010
CCI
CCI-001414
Target Key
(None)
Documentable
No
Discussion

The perimeter router will not use a routing protocol to advertise NIPRNet addresses to Alternate Gateways. Most ISPs use Border Gateway Protocol (BGP) to share route information with other autonomous systems, that is, any network under a different administrative control and policy than a local site. If BGP is configured on the perimeter router, no BGP neighbors will be defined to peer routers from an AS belonging to any Alternate Gateway. The only allowable method is a static route to reach the Alternate Gateway.

Fix Text

Configure a static route on the perimeter Cisco IOS XE router to reach the AS of a router connecting to an Alternate Gateway, using the following command: ISR4000 (config) #ip route <Destination Prefix> <Destination Prefix mask> <Forwarding routers address> The configuration would look similar to the example below: ip route 1.1.1.0 255.255.255.0 2.2.2.2

Check Content

Review the configuration of the Cisco IOS XE router connecting to the Alternate Gateway. Verify there are no BGP neighbors configured to the remote AS that belongs to the Alternate Gateway service provider. If there are BGP neighbors connecting the remote AS of the Alternate Gateway service provider, this is a finding.

The Cisco IOS XE router must not redistribute static routes to alternate gateway service provider into an Exterior Gateway Protocol or Interior Gateway Protocol to the NIPRNet or to other Autonomous System.

Finding ID
CISR-RT-000008
Rule ID
SV-88785r2_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-NET-000019-RTR-000011
CCI
CCI-001414
Target Key
(None)
Documentable
No
Discussion

If the static routes to the alternate gateway are being redistributed into an Exterior Gateway Protocol or Interior Gateway Protocol to a NIPRNet gateway, this could make traffic on NIPRNet flow to that particular router and not to the Internet Access Point routers. This could not only wreak havoc with traffic flows on NIPRNet, but it could overwhelm the connection from the router to the NIPRNet gateway(s) and also cause traffic destined for outside of NIPRNet to bypass the defenses of the Internet Access Points.

Fix Text

Configure the Cisco IOS XE router so that static routes are not redistributed to an Alternate Gateway into either an Exterior Gateway Protocol or Interior Gateway Protocol to the NIPRNet or to other Autonomous System. Use the "NO" command to disable redistribution of static routers; example below: ISR4000(config-router)#no redistribute static

Check Content

Review the configuration of the route connecting to the Alternate Gateway on the Cisco IOS XE router to verify that redistribution of static routes to the Alternate Gateway is not occurring by reviewing the BGP and OSPF configurations. If the "redistribute static" command is in the configurations, this is a finding.

The Cisco IOS XE router must enforce that Interior Gateway Protocol instances configured on the out-of-band management gateway router only peer with their own routing domain.

Finding ID
CISR-RT-000009
Rule ID
SV-88787r2_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-NET-000019-RTR-000012
CCI
CCI-001414
Target Key
(None)
Documentable
No
Discussion

If the gateway router is not a dedicated device for the out-of-band management network, implementation of several safeguards for containment of management and production traffic boundaries must occur. Since the managed and management network are separate routing domains, configuration of separate Interior Gateway Protocol routing instances is critical on the router to segregate traffic from each network.

Fix Text

Ensure that multiple IGP instances configured on the OOBM gateway router peer only with their appropriate routing domain. Verify that the all interfaces are configured for the appropriate IGP instance.

Check Content

Verify that the OOBM interface is an adjacency only in the IGP routing domain for the management network. The following would be an example where EIGRP is run on the management network 10.0.0.0 and OSPF in the managed network 172.20.0.0. The network 10.1.20.0/24 is the OOBM backbone and 10.1.1.0 is the local management LAN connecting to the OOBM interfaces of the managed network (i.e., the private and service network) elements. interface Serial0/0 description to_OOBM_Backbone ip address 10.1.20.3 255.255.255.0 ! interface FastEthernet 0/0 description Enclave_Management_LAN ip address 10.1.1.1 255.255.255.0 ! interface FastEthernet 0/1 description to_our_PrivateNet ip address 172.20.4.2 255.255.255.0 ! interface FastEthernet 0/2 description to_our_ServiceNet ip address 172.20.5.2 255.255.255.0 ! router ospf 1 network 172.20.0.0 ! router eigrp 12 network 10.0.0.0 If the OOBM interface is not an adjacency only in the IGP routing domain for the management network, this is a finding.

The Cisco IOS XE router must enforce that the managed network domain and the management network domain are separate routing domains and the Interior Gateway Protocol instances are not redistributed or advertised to each other.

Finding ID
CISR-RT-000010
Rule ID
SV-88789r2_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-NET-000019-RTR-000013
CCI
CCI-001414
Target Key
(None)
Documentable
No
Discussion

If the gateway router is not a dedicated device for the out-of-band management network, several safeguards must be implemented for containment of management and production traffic boundaries, otherwise, it is possible that management traffic will not be separated from production traffic. Since the managed network and the management network are separate routing domains, separate Interior Gateway Protocol routing instances must be configured on the router, one for the managed network and one for the out-of-band management network. In addition, the routes from the two domains must not be redistributed to each other.

Fix Text

On the Cisco IOS XE router configure the Interior Gateway Protocol instance used for the managed network to prohibit redistribution of routes into the Interior Gateway Protocol instance used for the management network, and vice versa. Use the “NO” form of the redistribute command to disable redistribution of the management network. For example: ISR4000(config-router)#no redistribute ospf 1 vrf Mgmt

Check Content

Verify the Interior Gateway Protocol instance used for the managed network on the Cisco IOS XE router does not redistribute routes into the Interior Gateway Protocol instance used for the management network, and vice versa. The configuration will look similar to the example below: router ospf 1 area 1 authentication message-digest redistribute ospf 1 vrf Mgmt passive-interface default no passive-interface GigabitEthernet0/0 no passive-interface GigabitEthernet0/1 network 200.30.3.0 0.0.0.255 area 1 If the Interior Gateway Protocol instance used for the managed network redistributes routes into the Interior Gateway Protocol instance used for the management network, or vice versa, this is a finding.

The Cisco IOS XE router must enforce that any interface used for out-of-band management traffic is configured to be passive for the Interior Gateway Protocol that is utilized on that management interface.

Finding ID
CISR-RT-000011
Rule ID
SV-88791r2_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-NET-000019-RTR-000014
CCI
CCI-001414
Target Key
(None)
Documentable
No
Discussion

The out-of-band management access switch will connect to the management interface of the managed network elements. The management interface can be a true out-of-band management interface or a standard interface functioning as the management interface. In either case, the management interface of the managed network element will directly connect to the out-of-band management network. An out-of-band management interface does not forward transit traffic, thereby, providing complete separation of production and management traffic. Since all management traffic is immediately forwarded into the management network, it is not exposed to possible tampering. The separation also ensures that congestion or failures in the managed network do not affect the management of the device. If the device does not have an out-of-band management port, the interface functioning as the management interface must be configured so that management traffic, both data plane and control plane, does not leak into the managed network and that production traffic does not leak into the management network.

Fix Text

Configure the management interface of the Cisco IOS XE router as passive for the Interior Gateway Protocol instance configured for the managed network. The configuration will look similar to the example below: outer ospf 1 area 1 authentication message-digest passive-interface GigabitEthernet0/0 network 200.30.3.0 0.0.0.255 area 1

Check Content

Review the configuration of the Cisco IOS XE router to verify the management interface is configured as passive for the Interior Gateway Protocol instance for the managed network. The configuration would look similar to the following example: router ospf 1 area 1 authentication message-digest passive-interface GigabitEthernet0/0 network 200.30.3.0 0.0.0.255 area 1 If the management interface is not configured as passive for the Interior Gateway Protocol instance for the managed network, this is a finding.

The Cisco IOS XE router must enable neighbor router authentication for control plane protocols.

Finding ID
CISR-RT-000012
Rule ID
SV-88793r2_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-NET-000025-RTR-000020
CCI
CCI-002205
Target Key
(None)
Documentable
No
Discussion

A rogue router could send a fictitious routing update to convince a site's perimeter router to send traffic to an incorrect or even a rogue destination. This diverted traffic could be analyzed to learn confidential information about the site's network, or merely used to disrupt the network's ability to communicate with other networks. This is known as a "traffic attraction attack" and is prevented by configuring neighbor router authentication for routing updates. This requirement applies to all IPv4 and IPv6 protocols that are used to exchange routing or packet forwarding information; this includes all Interior Gateway Protocols (such as OSPF, EIGRP, and IS-IS) and Exterior Gateway Protocols (such as BGP), MPLS-related protocols (such as LDP), and Multicast-related protocols.

Fix Text

Configure neighbor router authentication for all control plane protocols. The configuration will look similar to the example below: OSPF Example: router ospf 1 area 1 authentication message-digest interface GigabitEthernet0/0 ip ospf message-digest-key 1 md5 <authentication key> BGP Example: router bgp 65001 bgp log-neighbor-changes neighbor 2200:31:3::1 remote-as 65000 neighbor 2200:31:3::1 password <password> neighbor 200.31.3.1 remote-as 65000 neighbor 200.31.3.1 password <password>

Check Content

Review the Cisco IOS XE router configuration and verify that neighbor router authentication is configured for all control plane protocols. The configuration should look similar to the examples below: OSPF Example: router ospf 1 area 1 authentication message-digest interface GigabitEthernet0/0 ip ospf message-digest-key 1 md5 <authentication key> BGP Example: router bgp 65001 bgp log-neighbor-changes neighbor 2200:31:3::1 remote-as 65000 neighbor 2200:31:3::1 password <password> neighbor 200.31.3.1 remote-as 65000 neighbor 200.31.3.1 password <password> If authentication is not enabled, this is a finding.

The Cisco IOS XE router must be configured so that any key used for authenticating Interior Gateway Protocol peers does not have a duration exceeding 180 days.

Finding ID
CISR-RT-000013
Rule ID
SV-88795r2_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-NET-000025-RTR-000085
CCI
CCI-002205
Target Key
(None)
Documentable
No
Discussion

If the keys used for routing protocol authentication are guessed, the malicious user could create havoc within the network by advertising incorrect routes and redirecting traffic. Some routing protocols allow the use of key chains for authentication. A key chain is a set of keys that are used in succession, with each having a lifetime of no more than 180 days. Changing the keys frequently reduces the risk of them eventually being guessed. Keys cannot be used during time periods for which they are not activated. If a time period occurs during which no key is activated, neighbor authentication cannot occur, and therefore routing updates will fail. Therefore, you should ensure that for a given key chain, key activation times overlap to avoid any period of time during which no key is activated.

Fix Text

Configure all key chain used for IGP authentication to have keys that will not have a duration exceeding “180” days as shown in the example below: key chain KEY_CHAIN key 1 key-string willow accept-lifetime 22:45:00 Feb 10 2016 22:45:00 Aug 10 2016 send-lifetime 23:00:00 Feb 10 2016 22:45:00 Aug 10 2016 key 2 key-string birch accept-lifetime 22:45:00 Aug 9 2016 22:45:00 Feb 10 2006 send-lifetime 23:00:00 Aug 9 2016 22:45:00 Feb 10 2006 key 3 key-string maple accept-lifetime 22:45:00 Feb 10 2006 22:45:00 Aug 10 2006 send-lifetime 23:00:00 Feb 10 2006 22:45:00 Aug 10 2006

Check Content

Review the Cisco IOS XE router configuration to verify that all IGPs deployed on the router utilizing a key chain do not have a key with a duration exceeding “180” days. The configuration should look similar to the example below: interface Ethernet 0 ip authentication mode eigrp 1 md5 ip authentication key-chain eigrp 1 KEY_CHAIN ... router eigrp 1 network x.x.x.x ... key chain KEY_CHAIN key 1 key-string willow accept-lifetime 22:45:00 Feb 10 2016 22:45:00 Aug 10 2016 send-lifetime 23:00:00 Feb 10 2016 22:45:00 Aug 10 2016 key 2 key-string birch accept-lifetime 22:45:00 Aug 9 2016 22:45:00 Feb 10 2006 send-lifetime 23:00:00 Aug 9 2016 22:45:00 Feb 10 2006 key 3 key-string maple accept-lifetime 22:45:00 Feb 10 2006 22:45:00 Aug 10 2006 send-lifetime 23:00:00 Feb 10 2006 22:45:00 Aug 10 2006 If the Cisco IOS XE router is configured with a key chain with a duration exceeding “180” days, this is a finding.

The Cisco IOS XE router must be configured to restrict it from accepting outbound IP packets that contain an illegitimate address in the source address field via egress filter or by enabling Unicast Reverse Path Forwarding.

Finding ID
CISR-RT-000014
Rule ID
SV-88797r2_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-NET-000026-RTR-000031
CCI
CCI-001094
Target Key
(None)
Documentable
No
Discussion

A compromised host in an enclave can be used by a malicious actor as a platform to launch cyber attacks on third parties. This is a common practice in "botnets", which are a collection of compromised computers using malware to attack (usually DDoS) other computers or networks. DDoS attacks frequently leverage IP source address spoofing, in which packets with false source IP addresses send traffic to multiple hosts, which then send return traffic to the hosts with the IP addresses that were forged. This can generate significant, even massive, amounts of traffic. Therefore, protection measures to counteract IP source address spoofing must be taken. The router must not accept any outbound IP packets that contain an illegitimate address in the source address field by enabling Unicast Reverse Path Forwarding (uRPF) strict mode or by implementing an egress ACL. Unicast Reverse Path Forwarding (uRPF) provides an IP address spoof protection capability. When uRPF is enabled in strict mode, the packet must be received on the interface that the device would use to forward the return packet.

Fix Text

Configure the Cisco IOS XE router with uRPF strict mode or an ACL inbound on all internal interfaces as shown in the examples below: uRPF Example: interface FastEthernet 0/0 description downstream link to enclave LAN ip address x.x.x.x 255.255.255.0 ip verify unicast source reachable-via rx 102 access-list 102 deny ip any any log ACL Example: interface FastEthernet 0/0 description downstream link to our network ip address 199.36.90.1 255.255.255.0 ip access-group 102 in ... access-list 102 permit tcp any any established access-list 102 permit tcp [internal network] [wildcard mask] any eq ftp-data access-list 102 permit tcp [internal network] [wildcard mask] any eq ftp access-list 102 permit tcp [internal network] [wildcard mask] any eq http access-list 102 permit . . . access-list 102 deny any

Check Content

Review the Cisco IOS XE router configuration to validate uRPF or an ACL on an inbound direction has been configured on all internal interfaces as shown in the example below: uRPF Example: interface FastEthernet 0/0 description downstream link to enclave LAN ip address x.x.x.x 255.255.255.0 ip verify unicast source reachable-via rx 102 access-list 102 deny ip any any log ACL Example: interface FastEthernet 0/0 description downstream link to our network ip address 199.36.90.1 255.255.255.0 ip access-group 102 in ... access-list 102 permit tcp any any established access-list 102 permit tcp [internal network] [wildcard mask] any eq ftp-data access-list 102 permit tcp [internal network] [wildcard mask] any eq ftp access-list 102 permit tcp [internal network] [wildcard mask] any eq http access-list 102 permit . . . access-list 102 deny any If the Cisco IOS XE router has not been configured with uRPF strict mode or an ACL inbound on all internal interfaces, this is a finding.

The Cisco IOS XE router must encrypt all methods of configured authentication for routing protocols.

Finding ID
CISR-RT-000016
Rule ID
SV-88801r2_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-NET-000168-RTR-000077
CCI
CCI-000803
Target Key
(None)
Documentable
No
Discussion

A rogue router could send a fictitious routing update to convince a site's perimeter router to send traffic to an incorrect or even a rogue destination. This diverted traffic could be analyzed to learn confidential information about the site's network, or merely used to disrupt the network's ability to communicate with other networks. This is known as a "traffic attraction attack" and is prevented by configuring neighbor router authentication for routing updates. However, using clear-text authentication provides little benefit since an attacker can intercept traffic and view the authentication key. This would allow the attacker to use the authentication key in an attack. This requirement applies to all IPv4 and IPv6 protocols that are used to exchange routing or packet forwarding information; this includes all Interior Gateway Protocols (such as OSPF, EIGRP, and IS-IS) and Exterior Gateway Protocols (such as BGP), MPLS-related protocols (such as LDP), and Multicast-related protocols.

Fix Text

Configure the Cisco IOS XE router to use an encrypted HMAC authentication for all routing protocols.

Check Content

Review the configuration of the Cisco IOS XE router. Verify that an encrypted HMAC authentication is being used for all routing protocols as shown in the following configuration examples: key chain OSPF_KEY key 1 key-string OSPFKEY cryptographic-algorithm hmac-sha-1 ! interface GigabitEthernet3 ip address 1.1.35.3 255.255.255.0 ip ospf authentication key-chain OSPF_KEY ------------------------------------------- key chain EIGRP_KEY key 1 key-string EIGRPKEY ! interface GigabitEthernet3 ip address 1.1.35.3 255.255.255.0 ip authentication mode eigrp 22 md5 ip authentication key-chain eigrp 22 EIGRP_KEY ---------------------------------------- key chain ISIS_KEY key 1 key-string ISISKEY ! interface GigabitEthernet3 ip address 1.1.35.3 255.255.255.0 ip router isis isis authentication mode md5 isis authentication key-chain ISIS_KEY --------------------------------------------- router bgp 44 neighbor 1.1.1.1 remote-as 44 neighbor 1.1.1.1 password xxxxx --------------------------------------------- If not all routing protocols are configured to authenticate all routing protocol messages using an encrypted HMAC, this is a finding.

The Cisco IOS XE router must ensure all Exterior Border Gateway Protocol (eBGP) routers are configured to use Generalized TTL Security Mechanism (GTSM).

Finding ID
CISR-RT-000018
Rule ID
SV-88803r2_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-NET-000191-RTR-000081
CCI
CCI-002385
Target Key
(None)
Documentable
No
Discussion

As described in RFC 3682, Generalized TTL Security Mechanism (GTSM) is designed to protect a router's IP-based control plane from DoS attacks. Many attacks focused on CPU load and line-card overload can be prevented by implementing GTSM on all Exterior Border Gateway Protocol speaking routers. GTSM is based on the fact that the vast majority of control plane peering is established between adjacent routers; that is, the Exterior Border Gateway Protocol peers are either between connecting interfaces or between loopback interfaces. Since TTL spoofing is considered nearly impossible, a mechanism based on an expected TTL value provides a simple and reasonably robust defense from infrastructure attacks based on forged control plane traffic.

Fix Text

Configure all eBGP neighbors with GTSM. The configuration would look similar to the following: router bgp 100 neighbor 10.1.1.1 remote-as 222 neighbor 10.1.1.1 ttl-security hops 1

Check Content

Review the Cisco IOS XE router configuration and verify that the neighbor command "ttl-security" is configured for all eBGP peering sessions. The configuration would look similar to the following: router bgp 100 neighbor 10.1.1.1 remote-as 222 neighbor 10.1.1.1 ttl-security hops 1 If the "ttl-security" command is not configured for all eBGP peering sessions, this is a finding.

The Cisco IOS XE router must manage excess bandwidth to limit the effects of packet flooding types of denial of service (DoS) attacks.

Finding ID
CISR-RT-000019
Rule ID
SV-88805r2_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-NET-000193-RTR-000111
CCI
CCI-001095
Target Key
(None)
Documentable
No
Discussion

Denial of service is a condition when a resource is not available for legitimate users. Packet flooding DDoS attacks are referred to as volumetric attacks and have the objective of overloading a network or circuit to deny or seriously degrade performance, which denies access to the services that normally traverse the network or circuit. Volumetric attacks have become relatively easy to launch using readily available tools such as Low Orbit Ion Cannon or by botnets. Measures to mitigate the effects of a successful volumetric attack must be taken to ensure that sufficient capacity is available for mission-critical traffic. Managing capacity may include, for example, establishing selected network usage priorities or quotas and enforcing them using rate limiting, Quality of Service (QoS), or other resource reservation control methods. These measures may also mitigate the effects of sudden decreases in network capacity that are the result of accidental or intentional physical damage to telecommunications facilities (such as cable cuts or weather-related outages).

Fix Text

Configure a QOS policy on the Cisco IOS XE router to ensure capacity is available for mission-critical, voice, and control plane traffic during periods of congestion. The configuration should look similar to the following: class-map match-all CONTROL_PLANE match ip dscp 48 class-map match-all C2_VOICE match ip dscp 47 class-map match-all VOICE match ip dscp ef class-map match-all VIDEO match ip dscp af4 class-map match-all CRITICAL_DATA match ip dscp af3 … … … policy-map QOS_POLICY class CONTROL_PLANE priority percent 10 class C2_VOICE priority percent 10 class VOICE priority percent 15 class VIDEO bandwidth percent 25 class CRITICAL_DATA bandwidth percent 25 class class-default bandwidth percent 15 … … … interface GigabitEthernet1/1 ip address x.x.x.x 255.255.255.0 service-policy output QOS_POLICY

Check Content

Review the Cisco IOS XE router configuration. Interview the system administrator to verify that Quality of Service (QoS) has been implemented to ensure capacity is available for mission-critical, voice, and control plane traffic during periods of congestion. The following steps should be used to verify the configuration. Step 1: Verify that the class-maps are configured to match on DSCP values that have been set at the edges as shown in the configuration example below: class-map match-all CONTROL_PLANE match ip dscp 48 class-map match-all C2_VOICE match ip dscp 47 class-map match-all VOICE match ip dscp ef class-map match-all VIDEO match ip dscp af4 class-map match-all CRITICAL_DATA match ip dscp af3 Step 2: Verify that the policy map applied to the core-layer-facing interface reserves the bandwidth for each traffic type as shown in the following example: policy-map QOS_POLICY class CONTROL_PLANE priority percent 10 class C2_VOICE priority percent 10 class VOICE priority percent 15 class VIDEO bandwidth percent 25 class CRITICAL_DATA bandwidth percent 25 class class-default bandwidth percent 15 Step 3: Verify that an output service policy is bound to the core-layer-facing interface as shown in the configuration example below: interface GigabitEthernet1/1 ip address x.x.x.x 255.255.255.0 service-policy output QOS_POLICY If QoS policy has not been implemented to ensure there is capacity available for critical, voice, and control plane traffic during periods of congestion, this is a finding.

The Cisco IOS XE router must have IP source routing disabled.

Finding ID
CISR-RT-000020
Rule ID
SV-88807r2_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-NET-000195-RTR-000084
CCI
CCI-002403
Target Key
(None)
Documentable
No
Discussion

Source routing is a feature of IP, whereby individual packets can specify routes. This feature is used in several different network attacks by bypassing perimeter and internal defense mechanisms.

Fix Text

Configure the Cisco IOS XE router to disable IP source routing, using the command below: ISR4000(config)#no ip source-route

Check Content

Review the configuration of the Cisco IOS XE router to determine if source routing is enabled. If "ip source-routing" is in the configuration then it is enabled, this is a finding.

The Cisco IOS XE router must restrict BGP connections to known IP addresses of neighbor routers from trusted Autonomous Systems (AS).

Finding ID
CISR-RT-000021
Rule ID
SV-88809r2_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-NET-000195-RTR-000086
CCI
CCI-002403
Target Key
(None)
Documentable
No
Discussion

Advertisement of routes by an Autonomous System for networks that do not belong to any of its trusted peers pulls traffic away from the authorized network. This causes a DoS on the network that allocated the block of addresses and may cause a DoS on the network that is inadvertently advertising it as the originator. It is also possible that a misconfigured or compromised router within the network could redistribute Interior Gateway Protocol routes into Border Gateway Protocol, thereby leaking internal routes.

Fix Text

Configure each BGP peering session to the specific IP address of the peer router and remote Autonomous System Number (ASN) assigned to the organization controlling that peer.

Check Content

Review the router configuration and compare it against the network documentation (topology diagrams and peering agreements). Verify that each BGP peering session is configured with the correct IP address and remote Autonomous System Number (ASN). If any BGP peering session is not configured with the correct IP address and remote Autonomous System Number (ASN), this is a finding.

The Cisco IOS XE router must configure the maximum hop limit value to at least 32.

Finding ID
CISR-RT-000022
Rule ID
SV-88811r2_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-NET-000205-RTR-000108
CCI
CCI-001097
Target Key
(None)
Documentable
No
Discussion

The Neighbor Discovery protocol allows a hop limit value to be advertised by routers in a Router Advertisement message to be used by hosts instead of the standardized default value. If a very small value was configured and advertised to hosts on the LAN segment, communications would fail due to the hop limit reaching zero before the packets sent by a host reached their destination.

Fix Text

Configure the Cisco IOS XE router IPv6 Neighbor Discovery maximum hop limit value to at least "32". The configuration would look similar to the example below: ipv6 hop-limit 32

Check Content

Review the Cisco IOS XE router configuration to determine if the maximum hop limit for IPv6 Neighbor Discovery has been configured. The configuration would look similar to the example below: ipv6 hop-limit 32 If the router does not have the maximum hop limit value set to at least "32", this is a finding. If it has been configured, then it must be set to at least "32". If it has not been configured, it must be determined what the default value is. If the default value is below "32" and the maximum hop limit value has not been configured (set to at least "32"), this is a finding. In any case, maximum hop limit must be at least "32".

The Cisco IOS XE router must protect against or limit the effects of denial of service (DoS) attacks by employing control plane protection.

Finding ID
CISR-RT-000024
Rule ID
SV-88813r2_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-NET-000362-RTR-000110
CCI
CCI-002385
Target Key
(None)
Documentable
No
Discussion

The Route Processor (RP) is critical to all network operations because it is the component used to build all forwarding paths for the data plane via control plane processes. It is also instrumental with ongoing network management functions that keep the routers and links available for providing network services. Any disruption to the Route Processor or the control and management planes can result in mission-critical network outages. A DoS attack targeting the Route Processor can result in excessive CPU and memory utilization. To maintain network stability and Route Processor security, the router must be able to handle specific control plane and management plane traffic that is destined to the Route Processor. In the past, one method of filtering was to use ingress filters on forwarding interfaces to filter both forwarding path and receiving path traffic. However, this method does not scale well as the number of interfaces grows and the size of the ingress filters grow. Control plane policing increases the security of routers and multilayer switches by protecting the Route Processor from unnecessary or malicious traffic. Filtering and rate limiting the traffic flow of control plane packets can be implemented to protect routers against reconnaissance and DoS attacks, allowing the control plane to maintain packet forwarding and protocol states despite an attack or heavy load on the router or multilayer switch.

Fix Text

Implement control plane protection by classifying traffic types based on importance and configure filters to restrict and rate limit the traffic directed to and processed by the route processor according to each class. The configuration would look similar to the one below: class-map match-any CoPP_UNDESIRABLE match access-group name CoPP_UNDESIRABLE class-map match-any CoPP_IMPORTANT match access-group name CoPP_IMPORTANT match protocol arp class-map match-all CoPP_DEFAULT match access-group name CoPP_DEFAULT policy-map CONTROL_PLANE_POLICY class CoPP_CRITICAL police 512000 8000 conform-action transmit exceed-action transmit class CoPP_IMPORTANT police 256000 4000 conform-action transmit exceed-action drop class CoPP_NORMAL police 128000 2000 conform-action transmit exceed-action drop class CoPP_UNDESIRABLE police 8000 1000 conform-action drop exceed-action drop class CoPP_DEFAULT police 64000 1000 conform-action transmit exceed-action drop

Check Content

Step 1: Verify traffic types have been classified based on importance levels. The following is an example configuration: class-map match-all CoPP_CRITICAL match access-group name CoPP_CRITICAL class-map match-any CoPP_IMPORTANT match access-group name CoPP_IMPORTANT match protocol arp class-map match-all CoPP_NORMAL match access-group name CoPP_NORMAL class-map match-any CoPP_UNDESIRABLE match access-group name CoPP_UNDESIRABLE class-map match-all CoPP_DEFAULT match access-group name CoPP_DEFAULT Step 2: Review the ACLs referenced by the match access-group commands to determine if the traffic is being classified appropriately. The following is an example configuration: ip access-list extended CoPP_CRITICAL remark our control plane adjacencies are critical permit ospf host [OSPF neighbor A] any permit ospf host [OSPF neighbor B] any permit pim host [PIM neighbor A] any permit pim host [PIM neighbor B] any permit pim host [RP addr] any permit igmp any 224.0.0.0 15.255.255.255 permit tcp host [BGP neighbor] eq bgp host [local BGP addr] permit tcp host [BGP neighbor] host [local BGP addr] eq bgp deny ip any any ! ip access-list extended CoPP_IMPORTANT permit tcp host [TACACS server] eq tacacs any permit tcp [management subnet] 0.0.0.255 any eq 22 permit udp host [SNMP manager] any eq snmp permit udp host [NTP server] eq ntp any deny ip any any ! ip access-list extended CoPP_NORMAL remark we will want to rate limit ICMP traffic permit icmp any any echo permit icmp any any echo-reply permit icmp any any time-exceeded permit icmp any any unreachable deny ip any any ! ip access-list extended CoPP_UNDESIRABLE remark other management plane traffic that should not be received permit udp any any eq ntp permit udp any any eq snmptrap permit tcp any any eq 22 permit tcp any any eq 23 remark other control plane traffic not configured on router permit eigrp any any permit udp any any eq rip deny ip any any ! ip access-list extended CoPP_DEFAULT permit ip any any Note: Explicitly defining undesirable traffic with ACL entries enables the network operator to collect statistics. Excessive ARP packets can potentially monopolize Route Processor resources, starving other important processes. Currently, ARP is the only Layer 2 protocol that can be specifically classified using the match protocol command. Step 3: Review the policy-map to determine if the traffic is being policed appropriately for each classification. The following is an example configuration: policy-map CONTROL_PLANE_POLICY class CoPP_CRITICAL police 512000 8000 conform-action transmit exceed-action transmit class CoPP_IMPORTANT police 256000 4000 conform-action transmit exceed-action drop class CoPP_NORMAL police 128000 2000 conform-action transmit exceed-action drop class CoPP_UNDESIRABLE police 8000 1000 conform-action drop exceed-action drop Step 4: Verify that the CoPP policy is enabled. The following is an example configuration: control-plane service-policy input CONTROL_PLANE_POLICY If the Cisco IOS XE router does not have control plane protection implemented, this is a finding.

The Cisco IOS XE router must only allow incoming communications from authorized sources to be routed to authorized destinations.

Finding ID
CISR-RT-000025
Rule ID
SV-88815r2_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-NET-000364-RTR-000109
CCI
CCI-002403
Target Key
(None)
Documentable
No
Discussion

Unrestricted traffic may contain malicious traffic that poses a threat to an enclave or to other connected networks. Additionally, unrestricted traffic may transit a network, which uses bandwidth and other resources. Traffic can be restricted directly by an ACL (which is a firewall function) or by Policy Routing. Policy Routing is a technique used to make routing decisions based on a number of different criteria other than just the destination network, including source or destination network, source or destination address, source or destination port, protocol, packet size, and packet classification. This overrides the router's normal routing procedures used to control the specific paths of network traffic. It is normally used for traffic engineering, but can also be used to meet security requirements; for example, traffic that is not allowed can be routed to the Null0 or discard interface. Policy Routing can also be used to control which prefixes appear in the routing table. Traffic can be restricted directly by an ACL (which is a firewall function), or by Policy Routing. This requirement is intended to allow network administrators the flexibility to use whatever technique is most effective.

Fix Text

Configure the Cisco IOS XE router to only allow incoming communications from authorized sources to be routed to authorized destinations. The configuration would look similar to the example below: interface GigabitEthernet 0/0/1 description NIPRNet link ip address x.x.x.x 255.255.255.0 ip access-group Authorized_Sources_ACL in ... ip access-list extended Authorized_Sources_ACL deny ip 1.1.1.0 0.0.0.255 any log ...

Check Content

Review the Cisco IOS XE router configuration to determine if the router only allows incoming communications from authorized sources to be routed to authorized destinations. The configuration should look similar to the following example: interface GigabitEthernet 0/0/1 description NIPRNet link ip address x.x.x.x 255.255.255.0 ip access-group Authorized_Sources_ACL in ... ip access-list extended Authorized_Sources_ACL deny ip 1.1.1.0 0.0.0.255 any log ... If the Cisco IOS XE router does not restrict incoming communications to allow only authorized sources and destinations, this is a finding.