Cisco IOS XR Router RTR Security Technical Implementation Guide
Pick two releases to diff their requirements.
Open a previous version of this STIG.
Digest of Updates No substantive changes
Comparison against the immediately-prior release (V1R3). Rule matching uses the Group Vuln ID. Content-change detection compares the rule’s description, check, and fix text after stripping inline markup — cosmetic-only edits aren’t flagged.
No substantive changes detected against the previous release. 89 rules matched cleanly.
- RMF Control
- AC-4
- Severity
- M
- CCI
- CCI-001368
- Version
- CISC-RT-000010
- Vuln IDs
-
- V-96677
- Rule IDs
-
- SV-105815r1_rule
Checks: C-95513r1_chk
This requirement is not applicable for the DODIN Backbone. Review the router configuration to verify that ACLs are configured to allow or deny traffic for specific source and destination addresses as well as ports and protocols. For example, the configuration below will allow only printer traffic into subnet 10.1.23.0/24 and SQL traffic into subnet 10.1.24.0/24. ICMP is allowed for troubleshooting and OSPF is the routing protocol used within the network. interface GigabitEthernet0/0/0/0 description link to core ipv4 address 10.1.12.2 255.255.255.0 ipv4 access-group FILTER_SERVER_TRAFFIC ingress … … … ipv4 access-list FILTER_SERVER_TRAFFIC 10 permit tcp any 10.1.23.0 0.0.0.255 eq lpd 20 permit tcp any 10.1.23.0 0.0.0.255 eq 631 30 permit tcp any 10.1.23.0 0.0.0.255 eq 9100 40 permit tcp any 10.1.24.0 0.0.0.255 eq 1433 50 permit tcp any 10.1.24.0 0.0.0.255 eq 1434 60 permit tcp any 10.1.24.0 0.0.0.255 eq 4022 70 permit icmp any any 80 permit ospf any any 90 deny ipv4 any any If the router is not configured to enforce approved authorizations for controlling the flow of information within the network based on organization-defined information flow control policies, this is a finding.
Fix: F-102351r1_fix
This requirement is not applicable for the DODIN Backbone. Configure ACLs to allow or deny traffic for specific source and destination addresses as well as ports and protocols between various subnets as required. The commands used below were used to create the configuration as shown in the check content. RP/0/0/CPU0:R2(config)#ipv4 access-list FILTER_SERVER_TRAFFIC RP/0/0/CPU0:R2(config-ipv4-acl)#permit tcp any 10.1.23.0 0.0.0.255 eq lpd RP/0/0/CPU0:R2(config-ipv4-acl)#permit tcp any 10.1.23.0 0.0.0.255 eq 631 RP/0/0/CPU0:R2(config-ipv4-acl)#permit tcp any 10.1.23.0 0.0.0.255 eq 9100 RP/0/0/CPU0:R2(config-ipv4-acl)#permit tcp any 10.1.24.0 0.0.0.255 eq 1433 RP/0/0/CPU0:R2(config-ipv4-acl)#permit tcp any 10.1.24.0 0.0.0.255 eq 1434 RP/0/0/CPU0:R2(config-ipv4-acl)#permit tcp any 10.1.24.0 0.0.0.255 eq 4022 RP/0/0/CPU0:R2(config-ipv4-acl)#permit icmp any any RP/0/0/CPU0:R2(config-ipv4-acl)#permit ospf any any RP/0/0/CPU0:R2(config-ipv4-acl)#deny ip any any RP/0/0/CPU0:R2(config-ipv4-acl)# RP/0/0/CPU0:R2(config-ipv4-acl)#exit RP/0/0/CPU0:R2(config)#int g0/0/0/0 RP/0/0/CPU0:R2(config-if)#ipv4 access-group FILTER_SERVER_TRAFFIC
- RMF Control
- CM-6
- Severity
- M
- CCI
- CCI-000366
- Version
- CISC-RT-000020
- Vuln IDs
-
- V-96679
- Rule IDs
-
- SV-105817r2_rule
Checks: C-95515r1_chk
Review the router configuration. Verify that the neighbor router authentication is enabled for all routing protocols. The configuration examples below depicts OSPF, EIGRP, IS-IS and BGP authentication. BGP Example router bgp nn address-family ipv4 unicast ! neighbor x.1.23.2 remote-as nn keychain BGP_KEY_CHAIN address-family ipv4 unicaast EIGRP Example router eigrp 1 address-family ipv4 interface GigabitEthernet0/0/0/2 authentication keychain EIGRP_KEY_CHAIN IS-IS Example router isis 1 net 49.0001.0001.0001.0002.00 lsp-password keychain ISIS_KEY_CHAIN interface GigabitEthernet0/0/0/2 hello-password keychain ISIS_KEY_CHAIN OSPF Example router ospf 1 area 0 authentication message-digest keychain OSPF_KEY_CHAIN RIP Example router rip interface GigabitEthernet0/0/0/2 authentication keychain RIP_KEY_CHAIN mode md5 If authentication is not enabled on all routing protocols, this is a finding.
Fix: F-102355r1_fix
Configure authentication to be enabled for every protocol that affects the routing or forwarding tables. The example configuration commands below enables OSPF, EIGRP, IS-IS, and BGP authentication. BGP Example RP/0/0/CPU0:R2(config)#router bgp nn RP/0/0/CPU0:R2(config-bgp)#neighbor x.1.23.3 keychain BGP_KEY_CHAIN EIGRP Example RP/0/0/CPU0:R3(config)#router eigrp 1 RP/0/0/CPU0:R3(config-eigrp)#address-family ipv4 RP/0/0/CPU0:R3(config-eigrp-af)#int g0/0/0/0 RP/0/0/CPU0:R3(config-eigrp-af-if)#authentication keychain EIGRP_KEY_CHAIN RP/0/0/CPU0:R3(config-eigrp-af-if)#end IS-IS Example RP/0/0/CPU0:R2(config)#router isis 1 RP/0/0/CPU0:R2(config-isis)#lsp-password keychain ISIS_KEY_CHAIN RP/0/0/CPU0:R2(config-isis)#int GigabitEthernet0/0/0/2 RP/0/0/CPU0:R2(config-isis-if)#hello-password keychain ISIS_KEY_CHAIN RP/0/0/CPU0:R2(config-isis-if)#end OSPF Example RP/0/0/CPU0:R3(config)#router ospf 1 RP/0/0/CPU0:R3(config-ospf)#area 0 RP/0/0/CPU0:R3(config-ospf-ar)#authentication message-digest keychain OSPF_KEY_CHAIN RP/0/0/CPU0:R3(config-ospf-ar)#end RIP Example RP/0/0/CPU0:R2(config)#router rip RP/0/0/CPU0:R2(config-rip)#int g0/0/0/2 RP/0/0/CPU0:R2(config-rip-if)#authentication keychain XXX_KEY_CHAIN mode md5 RP/0/0/CPU0:R2(config-rip-if)#end
- RMF Control
- CM-6
- Severity
- M
- CCI
- CCI-000366
- Version
- CISC-RT-000030
- Vuln IDs
-
- V-96681
- Rule IDs
-
- SV-105819r2_rule
Checks: C-95517r1_chk
This requirement is not applicable for the DODIN Backbone. Review the start times for each key within the configured key chains used for routing protocol authentication as shown in the example below. key chain BGP_KEY_CHAIN key 1 accept-lifetime 01:00:00 january 01 2019 01:00:00 april 01 2019 key-string password 104300150004 send-lifetime 01:00:00 january 01 2019 01:00:00 april 01 2019 cryptographic-algorithm HMAC-SHA1-12 ! key 2 accept-lifetime 01:00:00 april 01 2019 01:00:00 july 01 2019 key-string password 030654090416 send-lifetime 01:00:00 april 01 2019 01:00:00 july 01 2019 cryptographic-algorithm HMAC-SHA1-12 Note: Key chains must be configured to authenticate routing protocol messages as it is the only way to set an expiration. If any key has a lifetime of more than 180 days, this is a finding.
Fix: F-102357r1_fix
This requirement is not applicable for the DODIN Backbone. Configure each key used for routing protocol authentication to have a lifetime of no more than 180 days as shown in the example below. RP/0/0/CPU0:R2(config)#key chain OSPF_KEY_CHAIN RP/0/0/CPU0:R2(config-OSPF_KEY_CHAIN)#key 1 RP/0/0/CPU0:R2(config-OSPF_KEY_CHAIN-1)#accept-lifetime 01:00:00 jan 01 2019 01:00:00 april 01 2019 RP/0/0/CPU0:R2(config-OSPF_KEY_CHAIN-1)#key-string password xxxxxxxxxxxxxxxx RP/0/0/CPU0:R2(config-OSPF_KEY_CHAIN-1)#send-lifetime 01:00:00 jan 01 2019 01:00:00 april 01 2019 RP/0/0/CPU0:R2(config-OSPF_KEY_CHAIN-1)#cryptographic-algorithm hmac-md5 RP/0/0/CPU0:R2(config-OSPF_KEY_CHAIN-1)#key 2 RP/0/0/CPU0:R2(config-OSPF_KEY_CHAIN-2)#accept-lifetime 01:00:00 april 01 2019 01:00:00 july 01 2019 RP/0/0/CPU0:R2(config-OSPF_KEY_CHAIN-2)#key-string password xxxxxxxxxxxxxxxxxxx RP/0/0/CPU0:R2(config-OSPF_KEY_CHAIN-2)#send-lifetime 01:00:00 april 01 2019 01:00:00 july 01 2019 RP/0/0/CPU0:R2(config-OSPF_KEY_CHAIN-2)#cryptographic-algorithm hmac-md5 RP/0/0/CPU0:R2(config-OSPF_KEY_CHAIN-2)#end
- RMF Control
- IA-7
- Severity
- M
- CCI
- CCI-000803
- Version
- CISC-RT-000040
- Vuln IDs
-
- V-96683
- Rule IDs
-
- SV-105821r1_rule
Checks: C-95519r1_chk
Review the router configuration. For every routing protocol that affects the routing or forwarding tables, verify that neighbor router authentication is encrypting the authentication key as shown in the examples below. Step 1: Verify that the routing protocols are configured to use a key chain for authentication as shown in the examples below. BGP Example router bgp nn address-family ipv4 unicast ! neighbor x.1.23.2 remote-as nn keychain BGP_KEY_CHAIN address-family ipv4 unicaast EIGRP Example router eigrp 1 address-family ipv4 interface GigabitEthernet0/0/0/2 authentication keychain EIGRP_KEY_CHAIN IS-IS Example router isis 1 net 49.0001.0001.0001.0002.00 lsp-password keychain ISIS_KEY_CHAIN interface GigabitEthernet0/0/0/2 hello-password keychain ISIS_KEY_CHAIN OSPF Example router ospf 1 area 0 authentication message-digest keychain OSPF_KEY_CHAIN RIP Example router rip interface GigabitEthernet0/0/0/2 authentication keychain RIP_KEY_CHAIN mode md5 Step 2: Verify that the keys use an encryption algorithm as shown in the example below. key chain OSPF_KEY_CHAIN key 1 accept-lifetime 01:00:00 january 01 2019 01:00:00 april 01 2019 key-string password 104300150004 send-lifetime 01:00:00 january 01 2019 01:00:00 april 01 2019 cryptographic-algorithm HMAC-MD5 ! key 2 accept-lifetime 01:00:00 april 01 2019 01:00:00 july 01 2019 key-string password 030654090416 send-lifetime 01:00:00 april 01 2019 01:00:00 july 01 2019 cryptographic-algorithm HMAC-MD5 If the routing protocol is not encrypting the authentication key, this is a finding.
Fix: F-102359r1_fix
Configure the key chains used by the routing protocols to have the keys encrypted as shown in the example below. RP/0/0/CPU0:R2(config)#key chain OSPF_KEY_CHAIN RP/0/0/CPU0:R2(config-OSPF_KEY_CHAIN)#key 1 RP/0/0/CPU0:R2(config-OSPF_KEY_CHAIN-1)#accept-lifetime 01:00:00 jan 01 2019 01:00:00 april 01 2019 RP/0/0/CPU0:R2(config-OSPF_KEY_CHAIN-1)#key-string password xxxxxxxxxxxxxxx RP/0/0/CPU0:R2(config-OSPF_KEY_CHAIN-1)#send-lifetime 01:00:00 jan 01 2019 01:00:00 april 01 2019 RP/0/0/CPU0:R2(config-OSPF_KEY_CHAIN-1)#cryptographic-algorithm hmac-md5 RP/0/0/CPU0:R2(config-OSPF_KEY_CHAIN-1)#key 2 RP/0/0/CPU0:R2(config-OSPF_KEY_CHAIN-2)#accept-lifetime 01:00:00 april 01 2019 01:00:00 july 01 2019 RP/0/0/CPU0:R2(config-OSPF_KEY_CHAIN-2)#key-string password xxxxxxxxxxxxxxx RP/0/0/CPU0:R2(config-OSPF_KEY_CHAIN-2)#send-lifetime 01:00:00 april 01 2019 01:00:00 july 01 2019 RP/0/0/CPU0:R2(config-OSPF_KEY_CHAIN-2)#cryptographic-algorithm hmac-md5 RP/0/0/CPU0:R2(config-OSPF_KEY_CHAIN-2)#end
- RMF Control
- IA-7
- Severity
- M
- CCI
- CCI-000803
- Version
- CISC-RT-000050
- Vuln IDs
-
- V-96685
- Rule IDs
-
- SV-105823r1_rule
Checks: C-95521r2_chk
Review the router configuration to verify it is using a NIST-validated FIPS 198-1 message authentication code algorithm to authenticate routing protocol messages. key chain BGP_KEY_CHAIN key 1 accept-lifetime 01:00:00 january 01 2019 01:00:00 april 01 2019 key-string password xxxxxxxxxxxxxxxx send-lifetime 01:00:00 january 01 2019 01:00:00 april 01 2019 cryptographic-algorithm HMAC-SHA1-12 ! key 2 accept-lifetime 01:00:00 april 01 2019 01:00:00 july 01 2019 key-string password xxxxxxxxxxxxxxx send-lifetime 01:00:00 april 01 2019 01:00:00 july 01 2019 cryptographic-algorithm HMAC-SHA1-12 ! Note: OSPF, RIP, EIGRP, and IS-IS only support MD5. If a NIST-validated FIPS 198-1 message authentication code algorithm is not being used to authenticate routing protocol messages, this is a finding.
Fix: F-102361r1_fix
Configure routing protocol authentication to use a NIST-validated FIPS 198-1 message authentication code algorithm as shown in the example. RP/0/0/CPU0:R2(config)#key chain BGP_KEY_CHAIN RP/0/0/CPU0:R2(config-OSPF_KEY_CHAIN)#key 1 RP/0/0/CPU0:R2(config-OSPF_KEY_CHAIN-1)#accept-lifetime 01:00:00 jan 01 2019 01:00:00 april 01 2019 RP/0/0/CPU0:R2(config-OSPF_KEY_CHAIN-1)#key-string password xxxxxxxxxxx RP/0/0/CPU0:R2(config-OSPF_KEY_CHAIN-1)#send-lifetime 01:00:00 jan 01 2019 01:00:00 april 01 2019 RP/0/0/CPU0:R2(config-OSPF_KEY_CHAIN-1)#cryptographic-algorithm hmac-sha1-12 RP/0/0/CPU0:R2(config-OSPF_KEY_CHAIN-1)#key 2 RP/0/0/CPU0:R2(config-OSPF_KEY_CHAIN-2)#accept-lifetime 01:00:00 april 01 2019 01:00:00 july 01 2019 RP/0/0/CPU0:R2(config-OSPF_KEY_CHAIN-2)#key-string password xxxxxxxxxxxxxxxx RP/0/0/CPU0:R2(config-OSPF_KEY_CHAIN-2)#send-lifetime 01:00:00 april 01 2019 01:00:00 july 01 2019 RP/0/0/CPU0:R2(config-OSPF_KEY_CHAIN-2)#cryptographic-algorithm hmac-sha1-12 RP/0/0/CPU0:R2(config-OSPF_KEY_CHAIN-2)#end
- RMF Control
- AC-4
- Severity
- L
- CCI
- CCI-001414
- Version
- CISC-RT-000060
- Vuln IDs
-
- V-96687
- Rule IDs
-
- SV-105825r1_rule
Checks: C-95523r1_chk
Review the router configuration and verify that inactive interfaces have been disabled as shown below. interface GigabitEthernet0/0/1/0 shutdown ! interface GigabitEthernet0/0/1/1 shutdown If an interface is not being used but is configured or enabled, this is a finding.
Fix: F-102363r1_fix
Disable all inactive interfaces as shown below. R4(config)#interface GigabitEthernet3 R4(config-if)#shutdown R4(config)#interface GigabitEthernet4 R4(config-if)#shutdown
- RMF Control
- CM-7
- Severity
- L
- CCI
- CCI-000381
- Version
- CISC-RT-000070
- Vuln IDs
-
- V-96689
- Rule IDs
-
- SV-105827r1_rule
Checks: C-95525r1_chk
Review the router configuration to verify that the router does not have any unnecessary or non-secure services enabled. For example, the following commands should not be in the configuration: service ipv4 tcp-small-servers max-servers 10 service ipv4 udp-small-servers max-servers 10 http client vrf xxxxx telnet vrf default ipv4 server max-servers 1 If any unnecessary services are enabled, this is a finding.
Fix: F-102365r1_fix
Disable the following services if enabled as shown in the example below. RP/0/0/CPU0:R3(config)#no service ipv4 tcp-small-servers RP/0/0/CPU0:R3(config)#no service ipv4 udp-small-servers RP/0/0/CPU0:R3(config)#no http client vrf xxxxx RP/0/0/CPU0:R3(config)#no telnet ipv4 server
- RMF Control
- SC-7
- Severity
- M
- CCI
- CCI-002403
- Version
- CISC-RT-000080
- Vuln IDs
-
- V-96691
- Rule IDs
-
- SV-105829r2_rule
Checks: C-95527r1_chk
Review the router configuration to determine if the call home feature is enabled as shown in the example below. call-home contract-id Company1234 customer-id Customer1234 phone-number +1-800-555-4567 contact-email-addr username@example.com If the call home feature is enabled, this is a finding.
Fix: F-102367r1_fix
Disable the call home feature as shown below. RP/0/0/CPU0:R3(config)#no call-home
- RMF Control
- SC-7
- Severity
- H
- CCI
- CCI-001097
- Version
- CISC-RT-000130
- Vuln IDs
-
- V-96693
- Rule IDs
-
- SV-105831r1_rule
Checks: C-95529r1_chk
Review the external and internal ACLs to verify that the router is configured to only allow specific management and control plane traffic from specific sources destined to itself. Step 1: Verify ACLs has been configured as shown in the example below that matches expected control plane and management plane traffic. With the exception of ICMP, all other traffic destined to the router should be dropped. ipv4 access-list EXTERNAL_ACL_INBOUND 10 permit tcp host x.11.1.1 eq bgp host x.11.1.2 20 permit tcp host x.11.1.1 host x.11.1.2 eq bgp 30 permit icmp host x.11.1.1 host x.11.1.2 echo 40 permit icmp host x.11.1.1 host x.11.1.2 echo-reply 50 deny ipv4 any host x.11.1.1 log 60 permit tcp any any established … … … 140 deny ipv4 any any log ! ipv4 access-list INTERNAL_ACL_INBOUND 10 permit icmp any any 20 permit ospf host 10.1.12.1 host 10.1.12.2 30 permit tcp 10.2.1.0 0.0.0.255 host 10.1.12.2 eq ssh 40 permit tcp 10.2.1.0 0.0.0.255 host 10.1.12.2 eq tacacs 50 permit udp 10.2.1.0 0.0.0.255 host 10.1.12.2 eq snmp 60 permit udp 10.2.1.0 0.0.0.255 host 10.1.12.2 eq ntp 70 deny ipv4 any host 10.1.12.2 log 80 permit ipv4 any any Note: For the internal ACL example, all routers within the hypothetical network (10.1.0.0/16) have been configured to use the loopback address to source all management traffic (not shown); hence, the loopbacks are the only allowable destination address for management traffic. In addition, all management traffic destined to the router must originate from the management network (10.2.1.0/24). With the exception of link-local control plane traffic and ICMP, all other traffic destined to any physical interface address will be dropped. Step 2: Verify that the ACL has been applied to the appropriate interface as shown in the example below. interface GigabitEthernet0/0/0/1 ipv4 address x.11.1.2 255.255.255.252 ipv4 access-group EXTERNAL_ACL_INBOUND ingress ! interface GigabitEthernet0/0/0/2 ipv4 address 10.1.12.2 255.255.255.0 ipv4 access-group INTERNAL_ACL_INBOUND ingress If the router is not configured to restrict traffic destined to itself, this is a finding.
Fix: F-102369r1_fix
Configure the ACL for any external interfaces as shown in the example. RP/0/0/CPU0:R3(config)#ipv4 access-list EXTERNAL_ACL_INBOUND RP/0/0/CPU0:R3(config-ipv4-acl)#permit tcp host x.11.1.1 eq bgp host x.11.1.2 RP/0/0/CPU0:R3(config-ipv4-acl)#permit tcp host x.11.1.1 host x.11.1.2 eq bgp RP/0/0/CPU0:R3(config-ipv4-acl)#permit icmp host x.11.1.1 host x.11.1.2 echo RP/0/0/CPU0:R3(config-ipv4-acl)#permit icmp host x.11.1.1 host x.11.1.2 echo-reply RP/0/0/CPU0:R3(config-ipv4-acl)#deny ip any host x.11.1.1 log RP/0/0/CPU0:R3(config-ipv4-acl)#permit tcp any any established … … … RP/0/0/CPU0:R3(config-ipv4-acl)#deny ip any any log RP/0/0/CPU0:R3(config-ipv4-acl)#exit Configure the ACL for any external interfaces as shown in the example. RP/0/0/CPU0:R3(config)#ipv4 access-list INTERNAL_ACL_INBOUND RP/0/0/CPU0:R3(config-ipv4-acl)#permit icmp any any RP/0/0/CPU0:R3(config-ipv4-acl)#permit ospf host 10.1.12.1 host 10.1.12.2 RP/0/0/CPU0:R3(config-ipv4-acl)#permit tcp 10.2.1.0 0.0.0.255 host 10.1.12.2eq 22 RP/0/0/CPU0:R3(config-ipv4-acl)#permit tcp 10.2.1.0 0.0.0.255 host 10.1.12.2eq tacacs RP/0/0/CPU0:R3(config-ipv4-acl)#permit udp 10.2.1.0 0.0.0.255 host 10.1.12.2 eq snmp RP/0/0/CPU0:R3(config-ipv4-acl)#permit udp 10.2.1.0 0.0.0.255 host 10.1.12.2 eq ntp RP/0/0/CPU0:R3(config-ipv4-acl)#deny ip any host 10.1.12.2 log RP/0/0/CPU0:R3(config-ipv4-acl)#permit ip any any RP/0/0/CPU0:R3(config-ipv4-acl)#exit Note: best practice is to configure the ACL statements relative to traffic destined to the router first followed by ACL statements for transit traffic. Step 2: Apply the ACLs to the appropriate interface as shown in the example below. RP/0/0/CPU0:R3(config)#int g0/0/0/1 RP/0/0/CPU0:R3(config-if)#ipv4 access-group EXTERNAL_ACL_INBOUND in RP/0/0/CPU0:R3(config-if)#exit RP/0/0/CPU0:R3(config)#int g0/0/0/2 RP/0/0/CPU0:R3(config-if)#ipv4 access-group INTERNAL_ACL_INBOUND in
- RMF Control
- SC-7
- Severity
- M
- CCI
- CCI-001097
- Version
- CISC-RT-000140
- Vuln IDs
-
- V-96695
- Rule IDs
-
- SV-105833r2_rule
Checks: C-95531r2_chk
Review the external and internal ACLs to verify that the router is configured to drop all fragmented ICMP packets destined to itself. ipv4 access-list EXTERNAL_ACL_INBOUND 10 permit tcp host x.11.1.1 eq bgp host x.11.1.2 20 permit tcp host x.11.1.1 host x.11.1.2 eq bgp 25 deny icmp any host x.11.1.2 fragments log 30 permit icmp host x.11.1.1 host x.11.1.2 echo 40 permit icmp host x.11.1.1 host x.11.1.2 echo-reply 50 deny ipv4 any host x.11.1.1 log 60 permit tcp any any established … … … 140 deny ipv4 any any log ! ipv4 access-list INTERNAL_ACL_INBOUND 5 deny icmp any any fragments 10 permit icmp any host 10.1.12.2 fragments 20 permit ospf host 10.1.12.1 host 10.1.12.2 30 permit tcp 10.2.1.0 0.0.0.255 host 10.1.12.2 eq ssh 40 permit tcp 10.2.1.0 0.0.0.255 host 10.1.12.2 eq tacacs 50 permit udp 10.2.1.0 0.0.0.255 host 10.1.12.2 eq snmp 60 permit udp 10.2.1.0 0.0.0.255 host 10.1.12.2 eq ntp 70 deny ipv4 any host 10.1.12.2 log … … … 110 permit ip any any Note: Ensure the statement to deny ICMP fragments is before any permit statements for ICMP. If the router is not configured to drop all fragmented ICMP packets destined to itself, this is a finding.
Fix: F-102371r1_fix
Configure the external and internal ACLs to drop all fragmented ICMP packets destined to itself as shown in the example below. RP/0/0/CPU0:R3(config)#ipv4 access-list EXTERNAL_ACL_INBOUND RP/0/0/CPU0:R2(config-ipv4-acl)#25 deny icmp any host x.11.1.2 fragments log RP/0/0/CPU0:R3(config)#ipv4 access-list INTERNAL_ACL_INBOUND RP/0/0/CPU0:R2(config-ipv4-acl)#5 deny icmp any host 10.1.12.2 fragments log Note: Ensure the above statement is before any permit statements for ICMP.
- RMF Control
- SC-5
- Severity
- L
- CCI
- CCI-002385
- Version
- CISC-RT-000160
- Vuln IDs
-
- V-96697
- Rule IDs
-
- SV-105835r1_rule
Checks: C-95533r1_chk
Review the router configuration to determine if it is compliant with this requirement. IP directed broadcast command must not be found on any interface as shown in the example below. interface GigabitEthernet0/0/0/1 ipv4 address x.11.1.2 255.255.255.252 ipv4 directed-broadcast If IP directed broadcast is not disabled on all interfaces, this is a finding.
Fix: F-102373r1_fix
Disable IP directed broadcast on all interfaces as shown in the example below. RP/0/0/CPU0:R3(config)#int g0/0/0/1 RP/0/0/CPU0:R3(config-if)#no ipv4 directed-broadcast
- RMF Control
- SC-5
- Severity
- M
- CCI
- CCI-002385
- Version
- CISC-RT-000170
- Vuln IDs
-
- V-96699
- Rule IDs
-
- SV-105837r1_rule
Checks: C-95535r1_chk
Review the configuration to verify the ipv4 unreachables disable command has been configured on all external interfaces as shown in the configuration example below. interface GigabitEthernet0/0/0/1 ipv4 address x.11.1.2 255.255.255.252 ipv4 unreachables disable Note: ICMP unreachables must also be configured. On the Null0 interface if it is used to black hole traffic. If ICMP unreachable notifications are sent from any external or Null0 interface, this is a finding. Alternative – DODIN Backbone Verify that the PE router is configured to rate limit ICMP unreachable messages as shown in the example below. ip icmp ipv4 rate-limit unreachable 60000 ip icmp ipv4 rate-limit unreachable DF 1000 Note: In the example above, packet-too-big message (ICMP Type 3 Code 4) can be sent once every second, while all other destination unreachable messages can be sent once every minute. This will avoid disrupting Path MTU Discovery for traffic traversing the backbone while mitigating the risk of an ICMP unreachable denial of service attack. IF the PE router is not configured to rate limit ICMP unreachable messages, this is a finding.
Fix: F-102375r1_fix
Disable ip unreachables on all external interfaces as shown below. RP/0/0/CPU0:R3(config)#int g0/0/0/1 RP/0/0/CPU0:R3(config-if)#ipv4 unreachables disable Alternative – DODIN Backbone Configure the PE router to rate limit ICMP unreachable messages as shown in the example below. RP/0/0/CPU0:R3(config)#icmp ipv4 rate-limit unreachable df 1000 RP/0/0/CPU0:R3(config)#icmp ipv4 rate-limit unreachable 60000 RP/0/0/CPU0:R3(config)#end
- RMF Control
- SC-5
- Severity
- M
- CCI
- CCI-002385
- Version
- CISC-RT-000180
- Vuln IDs
-
- V-96701
- Rule IDs
-
- SV-105839r1_rule
Checks: C-95537r1_chk
Review the router configuration and verify that ipv4 mask-reply command is not enabled on any external interfaces as shown in the example below. interface GigabitEthernet0/0/0/1 ipv4 address x.11.1.2 255.255.255.252 ipv4 mask-reply If the router configuration has the ipv4 mask-reply command is enabled on any external interfaces, this is a finding.
Fix: F-102377r1_fix
Disable ipv4 mask-reply on all external interfaces as shown below. RP/0/0/CPU0:R3(config)#int g0/0/0/1 RP/0/0/CPU0:R3(config-if)#no ipv4 mask-reply
- RMF Control
- SC-5
- Severity
- M
- CCI
- CCI-002385
- Version
- CISC-RT-000190
- Vuln IDs
-
- V-96703
- Rule IDs
-
- SV-105841r1_rule
Checks: C-95539r1_chk
Review the router configuration to verify that ipv4 redirects command has not been configured on any external interface as shown in the example below. interface GigabitEthernet0/0/0/1 ipv4 address x.11.1.2 255.255.255.252 ipv4 redirects If ICMP Redirect messages are enabled on any external interfaces, this is a finding.
Fix: F-102379r1_fix
Disable ICMP redirects on all external interfaces as shown in the example below. RP/0/0/CPU0:R3(config)#int g0/0/0/1 RP/0/0/CPU0:R3(config-if)#no ipv4 redirects
- RMF Control
- AU-3
- Severity
- L
- CCI
- CCI-000134
- Version
- CISC-RT-000200
- Vuln IDs
-
- V-96705
- Rule IDs
-
- SV-105843r1_rule
Checks: C-95541r1_chk
Review all ACLs used to filter traffic and verify that packets being dropped are logged as shown in the configuration below. ipv4 access-list EXTERNAL_ACL_INBOUND 10 permit tcp host x.11.1.1 eq bgp host x.11.1.2 20 permit tcp host x.11.1.1 host x.11.1.2 eq bgp 25 deny icmp any host x.11.1.2 fragments log 30 permit icmp host x.11.1.1 host x.11.1.2 echo 40 permit icmp host x.11.1.1 host x.11.1.2 echo-reply 50 deny ipv4 any host x.11.1.1 log 60 permit tcp any any established … … … 140 deny ipv4 any any log If packets being dropped at interfaces are not logged, this is a finding.
Fix: F-102381r1_fix
Configure ACLs to log packets that are dropped as shown in the example below. RP/0/0/CPU0:R3(config)#ipv4 access-list EXTERNAL_ACL_INBOUND … … … RP/0/0/CPU0:R3(config-ipv4-acl)#deny ip any any log
- RMF Control
- AU-3
- Severity
- M
- CCI
- CCI-000132
- Version
- CISC-RT-000210
- Vuln IDs
-
- V-96707
- Rule IDs
-
- SV-105845r1_rule
Checks: C-95543r1_chk
Review the router configuration to verify that events are logged containing information to establish where the events occurred as shown in the example below. ipv4 access-list EXTERNAL_ACL_INBOUND 10 permit tcp host x.11.1.1 eq bgp host x.11.1.2 20 permit tcp host x.11.1.1 host x.11.1.2 eq bgp 25 deny icmp any host x.11.1.2 fragments log-input 30 permit icmp host x.11.1.1 host x.11.1.2 echo 40 permit icmp host x.11.1.1 host x.11.1.2 echo-reply 50 deny ipv4 any host x.11.1.1 log-input 60 permit tcp any any established … … … 140 deny ipv4 any any log-input Note: When the log-input parameter is configured on deny statements, the log record will contain the interface where ingress packet has been dropped. If the router is not configured to produce audit records containing information to establish to establish where the events occurred, this is a finding.
Fix: F-102383r1_fix
Configure the router to log events containing information to establish where the events occurred as shown in the example below. RP/0/0/CPU0:R3(config)#ipv4 access-list EXTERNAL_ACL_INBOUND … … … RP/0/0/CPU0:R3(config-ipv4-acl)#deny ip any any log-input
- RMF Control
- AU-3
- Severity
- M
- CCI
- CCI-000133
- Version
- CISC-RT-000220
- Vuln IDs
-
- V-96709
- Rule IDs
-
- SV-105847r1_rule
Checks: C-95545r1_chk
Review the router configuration to verify that events are logged containing information to establish the source of the events as shown in the example below. ipv4 access-list EXTERNAL_ACL_INBOUND 10 permit tcp host x.11.1.1 eq bgp host x.11.1.2 20 permit tcp host x.11.1.1 host x.11.1.2 eq bgp 25 deny icmp any host x.11.1.2 fragments log 30 permit icmp host x.11.1.1 host x.11.1.2 echo 40 permit icmp host x.11.1.1 host x.11.1.2 echo-reply 50 deny ipv4 any host x.11.1.1 log-input 60 permit tcp any any established … … … 140 deny ipv4 any any log-input Note: When the log-input parameter is configured on deny statements, the log record will contain the layer 2 address of the forwarding device for any packet being dropped. If the router is not configured to produce audit records containing information to establish the source of the events, this is a finding.
Fix: F-102387r1_fix
Configure the router to log events containing information to establish where the events occurred as shown in the example below. RP/0/0/CPU0:R3(config)#ipv4 access-list EXTERNAL_ACL_INBOUND … … … RP/0/0/CPU0:R3(config-ipv4-acl)#deny ip any any log-input
- RMF Control
- SC-7
- Severity
- H
- CCI
- CCI-001109
- Version
- CISC-RT-000240
- Vuln IDs
-
- V-96711
- Rule IDs
-
- SV-105849r1_rule
Checks: C-95547r1_chk
This requirement is not applicable for the DODIN Backbone. Review the router configuration to verify that the inbound ACL applied to all external interfaces is configured to allow specific ports and protocols and deny all other traffic. Step 1: Verify that an inbound ACL is applied to all external interfaces as shown in the example below. interface GigabitEthernet0/0/0/1 ipv4 address x.11.1.2 255.255.255.252 ipv4 access-group EXTERNAL_ACL_INBOUND ingress Step 2: Review inbound ACL to verify that it is configured to deny all other traffic that is not explicitly allowed. ipv4 access-list EXTERNAL_ACL_INBOUND 10 permit tcp host x.11.1.1 eq bgp host x.11.1.2 20 permit tcp host x.11.1.1 host x.11.1.2 eq bgp 30 permit icmp host x.11.1.1 host x.11.1.2 echo 40 permit icmp host x.11.1.1 host x.11.1.2 echo-reply 50 deny ipv4 any host x.11.1.1 log-input 60 permit tcp any any established … … … 140 deny ipv4 any any log-input If the ACL is not configured to allow specific ports and protocols and deny all other traffic, this is a finding. If the ACL is not configured inbound on all external interfaces, this is a finding.
Fix: F-102389r1_fix
This requirement is not applicable for the DODIN Backbone. Step 1: Configure an inbound ACL to deny all other traffic by default as shown in the example below. RP/0/0/CPU0:R3(config)#ipv4 access-list EXTERNAL_ACL_INBOUND RP/0/0/CPU0:R3(config-ipv4-acl)#permit tcp host x.11.1.1 eq bgp host x.11.1.2 RP/0/0/CPU0:R3(config-ipv4-acl)#permit tcp host x.11.1.1 host x.11.1.2 eq bgp RP/0/0/CPU0:R3(config-ipv4-acl)#permit icmp host x.11.1.1 host x.11.1.2 echo RP/0/0/CPU0:R3(config-ipv4-acl)#permit icmp host x.11.1.1 host x.11.1.2 echo-reply RP/0/0/CPU0:R3(config-ipv4-acl)#deny ip any host x.11.1.1 log-input RP/0/0/CPU0:R3(config-ipv4-acl)#permit tcp any any established … … … RP/0/0/CPU0:R3(config-ipv4-acl)#deny ip any any log-input RP/0/0/CPU0:R3(config-ipv4-acl)#exit Step 2: Apply the ingress filter to all external interfaces RP/0/0/CPU0:R3(config)#int g0/0/0/1 RP/0/0/CPU0:R3(config-if)#ipv4 access-group EXTERNAL_ACL_INBOUND in RP/0/0/CPU0:R3(config-if)#end
- RMF Control
- AC-4
- Severity
- M
- CCI
- CCI-001414
- Version
- CISC-RT-000250
- Vuln IDs
-
- V-96713
- Rule IDs
-
- SV-105851r2_rule
Checks: C-95549r3_chk
Review the router configuration to verify that ACLs are configured to allow or deny traffic for specific source and destination addresses as well as ports and protocols. In the example below, the router is peering BGP with DISN. ICMP echo and echo-reply packets are allowed for troubleshooting connectivity. WWW traffic is permitted inbound to the NIPRNet host-facing web server (x.12.1.22). ipv4 access-list EXTERNAL_ACL_INBOUND 10 permit tcp host x.11.1.1 eq bgp host x.11.1.2 20 permit tcp host x.11.1.1 host x.11.1.2 eq bgp 30 permit icmp host x.11.1.1 host x.11.1.2 echo 40 permit icmp host x.11.1.1 host x.11.1.2 echo-reply 50 deny ipv4 any host x.11.1.1 log 60 permit tcp any host x.12.1.22 eq www 70 permit tcp any any established 80 deny ipv4 any any log-input … … … interface GigabitEthernet0/0/0/1 ipv4 address x.11.1.2 255.255.255.252 ipv4 access-group EXTERNAL_ACL_INBOUND ingress If the router is not configured to enforce approved authorizations for controlling the flow of information between interconnected networks, this is a finding.
Fix: F-102391r2_fix
This requirement is not applicable for the DODIN Backbone. Step 1: Configure an ACL to allow or deny traffic as shown in the example below. RP/0/0/CPU0:R3(config)#ipv4 access-list EXTERNAL_ACL_INBOUND RP/0/0/CPU0:R3(config-ipv4-acl)#permit tcp host x.11.1.1 eq bgp host x.11.1.2 RP/0/0/CPU0:R3(config-ipv4-acl)#permit tcp host x.11.1.1 host x.11.1.2 eq bgp RP/0/0/CPU0:R3(config-ipv4-acl)#permit icmp host x.11.1.1 host x.11.1.2 echo RP/0/0/CPU0:R3(config-ipv4-acl)#permit icmp host x.11.1.1 host x.11.1.2 echo-reply RP/0/0/CPU0:R3(config-ipv4-acl)#deny ip any host x.11.1.1 log-input RP/0/0/CPU0:R3(config-ipv4-acl)#permit tcp any host x.12.1.22 eq www RP/0/0/CPU0:R3(config-ipv4-acl)#permit tcp any any established RP/0/0/CPU0:R3(config-ipv4-acl)#deny ip any any log-input RP/0/0/CPU0:R3(config-ipv4-acl)#exit Step 2: Apply the ACL inbound on all external interfaces. RP/0/0/CPU0:R3(config)#int g0/0/0/1 RP/0/0/CPU0:R3(config-if)#ipv4 access-group EXTERNAL_ACL_INBOUND in RP/0/0/CPU0:R3(config-if)#end
- RMF Control
- SC-7
- Severity
- M
- CCI
- CCI-002403
- Version
- CISC-RT-000260
- Vuln IDs
-
- V-96715
- Rule IDs
-
- SV-105853r1_rule
Checks: C-95551r1_chk
This requirement is not applicable for the DODIN Backbone. Review the router configuration to determine if the router allows only incoming communications from authorized sources to be routed to authorized destinations. The hypothetical example below allows inbound NTP from server x.1.12.9 only to host x.12.1.21. ipv4 access-list EXTERNAL_ACL_INBOUND … … … 60 permit udp host x.12.1.9 host x.12.1.21 eq ntp 70 permit tcp any any established 80 deny ipv4 any any log-input If the router does not restrict incoming communications to allow only authorized sources and destinations, this is a finding.
Fix: F-102393r1_fix
This requirement is not applicable for the DODIN Backbone. Configure the router to allow only incoming communications from authorized sources to be routed to authorized destinations. RP/0/0/CPU0:R3(config)#ipv4 access-list EXTERNAL_ACL_INBOUND … … … RP/0/0/CPU0:R3(config-ipv4-acl)#permit udp host x.12.1.9 host x.12.1.21 eq ntp RP/0/0/CPU0:R3(config-ipv4-acl)#permit tcp any any established RP/0/0/CPU0:R3(config-ipv4-acl)#deny ip any any log-input RP/0/0/CPU0:R3(config-ipv4-acl)#exit
- RMF Control
- SC-7
- Severity
- M
- CCI
- CCI-002403
- Version
- CISC-RT-000270
- Vuln IDs
-
- V-96717
- Rule IDs
-
- SV-105855r1_rule
Checks: C-95553r2_chk
This requirement is not applicable for the DODIN Backbone. Review the router configuration to verify that an ingress ACL applied to all external interfaces is blocking packets with Bogon source addresses. Step 1: Verify an ACL has been configured containing the current Bogon prefixes as shown in the example below. ipv4 access-list EXTERNAL_ACL_INBOUND 10 deny ipv4 0.0.0.0 0.255.255.255 any log-input 20 deny ipv4 10.0.0.0 0.255.255.255 any log-input 30 deny ipv4 100.64.0.0 0.63.255.255 any log-input 40 deny ipv4 127.0.0.0 0.255.255.255 any log-input 50 deny ipv4 169.254.0.0 0.0.255.255 any log-input 60 deny ipv4 172.16.0.0 0.15.255.255 any log-input 70 deny ipv4 192.0.0.0 0.0.0.255 any log-input 80 deny ipv4 192.0.2.0 0.0.0.255 any log-input 90 deny ipv4 192.168.0.0 0.0.255.255 any log-input 100 deny ipv4 198.18.0.0 0.1.255.255 any log-input 110 deny ipv4 198.51.100.0 0.0.0.255 any log-input 120 deny ipv4 203.0.113.0 0.0.0.255 any log-input 130 deny ipv4 224.0.0.0 31.255.255.255 any log-input 140 permit tcp any any established 150 permit tcp host x.12.1.9 host x.12.1.10 eq bgp 160 permit tcp host x.12.1.9 eq bgp host x.12.1.10 170 permit icmp host x.12.1.9 host x.12.1.10 echo 180 permit icmp host x.12.1.9 host x.12.1.10 echo-reply … … … 260 deny ipv4 any any log-input External Interfaces connected to the NIPRNet or SIPRNet Review the inbound ACLs on external facing interfaces attached to the NIPRNet or SIPRNet to validate access control lists are configured to block inbound packets with IP sources addresses as documented in RFC5735 and RFC6598. External Interfaces connected to a commercial ISP or other non-DoD network Review the inbound ACLs on external facing interfaces validate access control lists are configured to block inbound packets with IP sources addresses as documented in RFC5735 and RFC6598 as well as address space that has been allocated to the RIRs but not assigned by the RIR to an ISP or other enterprise network. The full list of bogons can be found at the following link: www.team-cymru.org/Services/Bogons/fullbogons-ipv4.txt Step 2: Verify that the inbound ACL applied to all external interfaces will block all traffic from Bogon source addresses. interface GigabitEthernet0/0/0/1 ipv4 address x.12.1.10 255.255.255.2 ipv4 access-group EXTERNAL_ACL_INBOUND ingress If the router is not configured to block inbound packets with source Bogon IP addresses, this is a finding.
Fix: F-102395r1_fix
This requirement is not applicable for the DODIN Backbone. Configure the perimeter to block inbound packets with Bogon source addresses. Step 1: Configure an ACL containing the current Bogon prefixes as shown below. RP/0/0/CPU0:R2(config)#ipv4 access-list EXTERNAL_ACL_INBOUND RP/0/0/CPU0:R2(config-ipv4-acl)#deny ip 0.0.0.0 0.255.255.255 any log-input RP/0/0/CPU0:R2(config-ipv4-acl)#deny ip 10.0.0.0 0.255.255.255 any log-input RP/0/0/CPU0:R2(config-ipv4-acl)#deny ip 100.64.0.0 0.63.255.255 any log-input RP/0/0/CPU0:R2(config-ipv4-acl)#deny ip 127.0.0.0 0.255.255.255 any log-input RP/0/0/CPU0:R2(config-ipv4-acl)#deny ip 169.254.0.0 0.0.255.255 any log-input RP/0/0/CPU0:R2(config-ipv4-acl)#deny ip 172.16.0.0 0.15.255.255 any log-input RP/0/0/CPU0:R2(config-ipv4-acl)#deny ip 192.0.0.0 0.0.0.255 any log-input RP/0/0/CPU0:R2(config-ipv4-acl)#deny ip 192.0.2.0 0.0.0.255 any log-input RP/0/0/CPU0:R2(config-ipv4-acl)#deny ip 192.168.0.0 0.0.255.255 any log-input RP/0/0/CPU0:R2(config-ipv4-acl)#deny ip 198.18.0.0 0.1.255.255 any log-input RP/0/0/CPU0:R2(config-ipv4-acl)#deny ip 198.51.100.0 0.0.0.255 any log-input RP/0/0/CPU0:R2(config-ipv4-acl)#deny ip 203.0.113.0 0.0.0.255 any log-input RP/0/0/CPU0:R2(config-ipv4-acl)#deny ip 224.0.0.0 31.255.255.255 any log-input RP/0/0/CPU0:R2(config-ipv4-acl)#permit tcp any any established RP/0/0/CPU0:R2(config-ipv4-acl)#permit tcp host x.12.1.9 host x.12.1.10 eq bgp RP/0/0/CPU0:R2(config-ipv4-acl)#permit tcp host x.12.1.9 eq bgp host x.12.1.10 RP/0/0/CPU0:R2(config-ipv4-acl)#permit icmp host x.12.1.9 host x.12.1.10 echo RP/0/0/CPU0:R2(config-ipv4-acl)#permit icmp host x.12.1.9 host x.12.1.10 echo-reply … … … RP/0/0/CPU0:R2(config-ipv4-acl)#deny ip any any log-input RP/0/0/CPU0:R2(config-ipv4-acl)#end Step 2: Apply the ACL inbound on all external interfaces. RP/0/0/CPU0:R3(config)#int g0/0/0/1 RP/0/0/CPU0:R3(config-if)#ipv4 access-group EXTERNAL_ACL_INBOUND in RP/0/0/CPU0:R3(config-if)#end
- RMF Control
- AC-4
- Severity
- H
- CCI
- CCI-001414
- Version
- CISC-RT-000280
- Vuln IDs
-
- V-96719
- Rule IDs
-
- SV-105857r2_rule
Checks: C-95555r2_chk
This requirement is not applicable for the DODIN Backbone. Step 1: Verify the interface connecting to ISP has an inbound ACL as shown in the example below. interface GigabitEthernet0/0/0/2 description Link to ISP ipv4 address x.22.1.15 255.255.255.252 ipv4 access-group ISP_ACL_INBOUND ingress Step 2: Verify that the ACL only allows traffic to specific destination addresses (i.e. enclave’s NIPRNet address space) as shown in the example below. ipv4 access-list ISP_ACL_INBOUND 10 permit tcp any any established 20 permit icmp host x.12.1.16 host x.12.1.17 echo 30 permit icmp host x.12.1.16 host x.12.1.17 echo-reply 40 permit tcp any host x.12.1.22 eq www 50 permit tcp any host x.12.1.23 eq www 60 permit esp any host x.12.1.24 70 permit ahp any host x.12.1.24 80 deny ipv4 any any log-input Note: An Approved Gateway (AG) is any external connection from a DoD NIPRNet enclave to an Internet Service Provider, or network owned by a contractor, or non-DoD federal agency that has been approved by either the DoD CIO or the DoD Component CIO. This AG requirement does not apply to commercial cloud connections when the Cloud Service Provider (CSP) network is connected via the NIPRNet Boundary Cloud Access Point (BCAP). If the ingress ACL bound to the interface connecting to an alternate gateway 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.
Fix: F-102397r1_fix
This requirement is not applicable for the DODIN Backbone. Step 1: Configure the ingress ACL of the perimeter router connected to an alternate gateway to only 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 as shown in the example below. RP/0/0/CPU0:R2(config)#ip access-list ISP_ACL_INBOUND RP/0/0/CPU0:R2(config-ipv4-acl)#permit tcp any any established RP/0/0/CPU0:R2(config-ipv4-acl)#permit icmp host x.12.1.16 host x.12.1.17 echo RP/0/0/CPU0:R2(config-ipv4-acl)#permit icmp host x.12.1.16 host x.12.1.17 echo-reply RP/0/0/CPU0:R2(config-ipv4-acl)#permit tcp any host x.12.1.22 eq www RP/0/0/CPU0:R2(config-ipv4-acl)#permit tcp any host x.12.1.23 eq www RP/0/0/CPU0:R2(config-ipv4-acl)#permit 50 any host x.12.1.24 RP/0/0/CPU0:R2(config-ipv4-acl)#permit 51 any host x.12.1.24 RP/0/0/CPU0:R2(config-ipv4-acl)#deny ip any any log-input RP/0/0/CPU0:R2(config-ipv4-acl)#end Step 2: Apply the ACL inbound on the ISP-facing interface. RP/0/0/CPU0:R3(config)#int g0/0/0/2 RP/0/0/CPU0:R3(config-if)#ipv4 access-group ISP_ACL_INBOUND in RP/0/0/CPU0:R3(config-if)#end
- RMF Control
- AC-4
- Severity
- H
- CCI
- CCI-001414
- Version
- CISC-RT-000290
- Vuln IDs
-
- V-96721
- Rule IDs
-
- SV-105859r2_rule
Checks: C-95557r1_chk
This requirement is not applicable for the DODIN Backbone. Step 1: Configure the ingress ACL of the perimeter router connected to an alternate gateway to only 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 as shown in the example below. RP/0/0/CPU0:R2(config)#ip access-list ISP_ACL_INBOUND RP/0/0/CPU0:R2(config-ipv4-acl)# permit tcp any any established RP/0/0/CPU0:R2(config-ipv4-acl)# permit icmp host x.12.1.16 host x.12.1.17 echo RP/0/0/CPU0:R2(config-ipv4-acl)# permit icmp host x.12.1.16 host x.12.1.17 echo-reply RP/0/0/CPU0:R2(config-ipv4-acl)# permit tcp any host x.12.1.22 eq www RP/0/0/CPU0:R2(config-ipv4-acl)# permit tcp any host x.12.1.23 eq www RP/0/0/CPU0:R2(config-ipv4-acl)# permit 50 any host x.12.1.24 RP/0/0/CPU0:R2(config-ipv4-acl)# permit 51 any host x.12.1.24 RP/0/0/CPU0:R2(config-ipv4-acl)# deny ip any any log-input RP/0/0/CPU0:R2(config-ipv4-acl)#end Step 2: Apply the ACL inbound on the ISP-facing interface. RP/0/0/CPU0:R3(config)#int g0/0/0/2 RP/0/0/CPU0:R3(config-if)#ipv4 access-group ISP_ACL_INBOUND in RP/0/0/CPU0:R3(config-if)#end If any BGP neighbors belonging to the alternate gateway service provider exist, this is a finding.
Fix: F-102399r1_fix
This requirement is not applicable for the DODIN Backbone. Remove any BGP neighbors belonging to the alternate gateway service provider and configure a static route to forward Internet bound traffic to the alternate gateway as shown in the example below. R5(config)#ip route 0.0.0.0 0.0.0.0 x.22.1.14
- RMF Control
- AC-4
- Severity
- L
- CCI
- CCI-001414
- Version
- CISC-RT-000300
- Vuln IDs
-
- V-96723
- Rule IDs
-
- SV-105861r1_rule
Checks: C-95559r1_chk
This requirement is not applicable for the DODIN Backbone. Step 1: Review the IGP and BGP configurations. If there are redistribute static statements configured as shown in examples below proceed to step 2. OSPF Example router ospf 1 redistribute static EIGRP example router eigrp 1 address-family ipv4 redistribute static RIP example router rip version 2 redistribute static BGP example router bgp n address-family ipv4 unicast redistribute static Step 2: Review the static routes that have been configured to determine if any contain the next hop address of the alternate gateway. If the static routes to the alternate gateway are being redistributed into BGP or any IGP peering to a NIPRNet gateway or any other autonomous system, this is a finding.
Fix: F-102401r2_fix
This requirement is not applicable for the DODIN Backbone. Configure the router so that static routes are not redistributed to an alternate gateway into either a BGP or any IGP peering with the NIPRNet or to any other autonomous systems. This can be done by excluding that route in the route policy as shown in the example below. Step 1: Configure a prefix list for any static routes with the alternate gateway as the next-hop address RP/0/0/CPU0:R3(config)#prefix-set ISP_PREFIX RP/0/0/CPU0:R3(config-pfx)#x.x.0.0/24 ge 8 le 32 RP/0/0/CPU0:R3(config-pfx)#end-set Step 2: Configure a route policy RP/0/0/CPU0:R3(config)#route-policy FILTER_ISP_ROUTES RP/0/0/CPU0:R3(config-rpl)#if destination in ISP_PREFIX then RP/0/0/CPU0:R3(config-rpl-if)#drop RP/0/0/CPU0:R3(config-rpl-if)#else RP/0/0/CPU0:R3(config-rpl-else)#pass RP/0/0/CPU0:R3(config-rpl-else)#endif RP/0/0/CPU0:R3(config-rpl)#end-pol Step 3: Apply the route policy to the IGP and BGP redistribute static commands as shown in the OSPF example. RP/0/0/CPU0:R3(config-ospf)#redistribute static route-policy FILTER_ISP_ROUTES
- RMF Control
- SC-5
- Severity
- H
- CCI
- CCI-001094
- Version
- CISC-RT-000310
- Vuln IDs
-
- V-96725
- Rule IDs
-
- SV-105863r2_rule
Checks: C-95561r1_chk
This requirement is not applicable for the DODIN Backbone. Review the router configuration to verify uRPF or an egress ACL has been configured on all internal interfaces to restrict the router from accepting outbound IP packets that contain an illegitimate address in the source address field. uRPF example interface GigabitEthernet0/0/0/1 description downstream link to LAN ipv4 address 10.1.34.3 255.255.255.0 ipv4 verify unicast source reachable-via rx Egress ACL example ipv4 access-list EGRESS_FILTER 10 permit udp 10.1.15.0 0.0.0.255 any eq domain 20 permit tcp 10.1.15.0 0.0.0.255 any eq ftp 30 permit tcp 10.1.15.0 0.0.0.255 any eq ftp-data 40 permit tcp 10.1.15.0 0.0.0.255 any eq www 50 permit icmp 10.1.15.0 0.0.0.255 any 60 permit icmp 10.1.15.0 0.0.0.255 any echo 70 deny ipv4 any any … … … interface GigabitEthernet0/0/0/1 description downstream link to LAN ipv4 address 10.1.34.3 255.255.255.0 ipv4 access-group EGRESS_FILTER ingress If uRPF or an egress ACL to restrict the router from accepting outbound IP packets that contain an illegitimate address in the source address field has not been configured on all internal interfaces in an enclave, this is a finding.
Fix: F-102403r1_fix
This requirement is not applicable for the DODIN Backbone. Configure the router to ensure that an egress ACL or uRPF is configured on internal interfaces to restrict the router from accepting any outbound IP packet that contains an illegitimate address in the source field. The example below enables uRPF. RP/0/0/CPU0:R3(config)#int g0/0/0/1 RP/0/0/CPU0:R3(config-if)#ipv4 verify unicast source reachable-via rx
- RMF Control
- SC-7
- Severity
- M
- CCI
- CCI-001097
- Version
- CISC-RT-000320
- Vuln IDs
-
- V-96727
- Rule IDs
-
- SV-105865r1_rule
Checks: C-95563r1_chk
This requirement is not applicable for the DODIN Backbone. Review the router configuration to verify that the ingress ACL is in accordance with DoD 8551.1. Step 1: Verify that an inbound ACL is configured on all external interfaces. interface GigabitEthernet0/0/0/1 ipv4 address x.11.1.2 255.255.255.252 ipv4 access-group EXTERNAL_ACL_INBOUND ingress Step 2. Review the inbound ACL to verify that it is filtering traffic in accordance with DoD 8551.1. ipv4 access-list EXTERNAL_ACL_INBOUND 10 permit tcp host x.11.1.1 eq bgp host x.11.1.2 20 permit tcp host x.11.1.1 host x.11.1.2 eq bgp 30 permit icmp host x.11.1.1 host x.11.1.2 echo 40 permit icmp host x.11.1.1 host x.11.1.2 echo-reply 50 deny ipv4 any host x.11.1.1 log 60 permit tcp any host x.12.1.22 eq www 70 permit tcp any any established … … < must be in accordance with DoD Instruction 8551.1> … 160 deny ipv4 any any log-input If the router does not filter traffic in accordance with the guidelines contained in DoD 8551.1, this is a finding.
Fix: F-102405r1_fix
This requirement is not applicable for the DODIN Backbone. Configure the router to use an inbound ACL on all external interfaces as shown in the example below to restrict traffic in accordance with the guidelines contained in DOD Instruction 8551.1. RP/0/0/CPU0:R3(config)#ipv4 access-list EXTERNAL_ACL_INBOUND RP/0/0/CPU0:R3(config-ipv4-acl)#permit tcp host x.11.1.1 eq bgp host x.11.1.2 RP/0/0/CPU0:R3(config-ipv4-acl)#permit tcp host x.11.1.1 host x.11.1.2 eq bgp RP/0/0/CPU0:R3(config-ipv4-acl)#permit icmp host x.11.1.1 host x.11.1.2 echo RP/0/0/CPU0:R3(config-ipv4-acl)#permit icmp host x.11.1.1 host x.11.1.2 echo-reply RP/0/0/CPU0:R3(config-ipv4-acl)#deny ip any host x.11.1.1 log-input RP/0/0/CPU0:R3(config-ipv4-acl)#permit tcp any host x.12.1.22 eq www RP/0/0/CPU0:R3(config-ipv4-acl)#permit tcp any any established … … < must be in accordance with DoD Instruction 8551.1> … RP/0/0/CPU0:R3(config-ipv4-acl)#deny ip any any log-input RP/0/0/CPU0:R3(config-ipv4-acl)#exit Step 2: Apply the ACL inbound on all applicable interfaces. RP/0/0/CPU0:R3(config)#int g0/0/0/1 RP/0/0/CPU0:R3(config-if)#ipv4 access-group EXTERNAL_ACL_INBOUND in RP/0/0/CPU0:R3(config-if)#end
- RMF Control
- SC-7
- Severity
- M
- CCI
- CCI-001097
- Version
- CISC-RT-000330
- Vuln IDs
-
- V-96729
- Rule IDs
-
- SV-105867r1_rule
Checks: C-95565r1_chk
This requirement is not applicable for the DODIN Backbone. Review the router configuration to verify that an inbound ACL is configured on all external interfaces as shown in the example below. interface GigabitEthernet0/0/0/1 ipv4 address x.11.1.2 255.255.255.252 ipv4 access-group EXTERNAL_ACL_INBOUND ingress If the router is not configured to filter traffic entering the network at all external interfaces in an inbound direction, this is a finding.
Fix: F-102407r1_fix
This requirement is not applicable for the DODIN Backbone. Configure the router to use an inbound ACL on all external interfaces as shown in the example below. RP/0/0/CPU0:R3(config)#int g0/0/0/1 RP/0/0/CPU0:R3(config-if)#ipv4 access-group EXTERNAL_ACL_INBOUND in RP/0/0/CPU0:R3(config-if)#end
- RMF Control
- SC-7
- Severity
- M
- CCI
- CCI-001097
- Version
- CISC-RT-000340
- Vuln IDs
-
- V-96731
- Rule IDs
-
- SV-105869r1_rule
Checks: C-95567r1_chk
This requirement is not applicable for the DODIN Backbone. Review the router configuration to verify that the egress ACL is bound to the internal interface in an inbound direction. interface GigabitEthernet0/0/0/1 description downstream link to LAN ipv4 address 10.1.34.3 255.255.255.0 ipv4 access-group EGRESS_FILTER ingress If the router is not configured to filter traffic leaving the network at the internal interface in an inbound direction, this is a finding.
Fix: F-102409r1_fix
This requirement is not applicable for the DODIN Backbone. Configure the router to use an inbound ACL on all internal interfaces as shown in the example below. RP/0/0/CPU0:R3(config)#int g0/0/0/1 RP/0/0/CPU0:R3(config-if)#ipv4 access-group EGRESS_FILTER in RP/0/0/CPU0:R3(config-if)#end
- RMF Control
- SC-7
- Severity
- M
- CCI
- CCI-002403
- Version
- CISC-RT-000350
- Vuln IDs
-
- V-96733
- Rule IDs
-
- SV-105871r2_rule
Checks: C-95569r1_chk
This requirement is not applicable for the DODIN Backbone. In Cisco IOS XR, all IPv4 packets with any header option other than the "source-route" header options are dropped. By default, ipv4 source routing is disabled. Verify that the following command is not configured: ipv4 source-route If the router is not configured to drop all packets with IP option source routing, this is a finding.
Fix: F-102411r1_fix
This requirement is not applicable for the DODIN Backbone. Configure the router to drop all packets with IP option source routing. RP/0/0/CPU0:R3(config)#no ipv4 source-route
- RMF Control
- SC-7
- Severity
- L
- CCI
- CCI-002403
- Version
- CISC-RT-000360
- Vuln IDs
-
- V-96735
- Rule IDs
-
- SV-105873r1_rule
Checks: C-95571r1_chk
This requirement is not applicable for the DODIN Backbone. Step 1: Verify LLDP is not enabled globally via the command lldp By default LLDP is not enabled globally. If LLDP is enabled, proceed to step 2. Step 2: Verify LLDP transmit is disabled on any external interface as shown in the example below. interface GigabitEthernet0/0/0/1 ipv4 address x.1.34.3 255.255.255.252 lldp transmit disable Note: LLDP is enabled by default on all interfaces once it is enabled globally; hence the commands lldp transmit and lldp receive will not be visible on the interface configuration. If LLDP transmit is enabled on any external interface, this is a finding.
Fix: F-102413r1_fix
Disable LLDP transmit on all external interfaces as shown in the example below. RP/0/0/CPU0:R3(config)#interface g0/0/0/1 RP/0/0/CPU0:R3(config-if)#lldp transmit disable
- RMF Control
- SC-7
- Severity
- L
- CCI
- CCI-002403
- Version
- CISC-RT-000370
- Vuln IDs
-
- V-96737
- Rule IDs
-
- SV-105875r1_rule
Checks: C-95573r1_chk
This requirement is not applicable for the DODIN Backbone. Step 1: Verify if CDP is enabled globally via the cdp command as shown below. hostname R3 cdp By default CDP is disabled globally; hence, the command cdp run will not be shown in the configuration. If CDP is enabled, proceed to step 2. Step 2: Verify CDP is not enabled on any external interface as shown in the example below. interface GigabitEthernet0/0/0/1 cdp ipv4 address x.1.34.3 255.255.255.252 If CDP is enabled on any external interface, this is a finding.
Fix: F-102415r1_fix
This requirement is not applicable for the DODIN Backbone. Disable CDP on all external interfaces via no cdp command or disable CDP globally via no cdp command.
- RMF Control
- SC-7
- Severity
- M
- CCI
- CCI-002403
- Version
- CISC-RT-000380
- Vuln IDs
-
- V-96739
- Rule IDs
-
- SV-105877r1_rule
Checks: C-95575r1_chk
This requirement is not applicable for the DODIN Backbone. Review the router configuration to determine if IP Proxy ARP is enabled on any external interfaces as shown in the example below. interface GigabitEthernet0/0/0/1 description link to DISN ipv4 address x.1.12.2 255.255.255.252 proxy-arp If IP Proxy ARP is enabled on any external interface, this is a finding.
Fix: F-102417r1_fix
This requirement is not applicable for the DODIN Backbone. Disable Proxy ARP on all external interfaces as shown in the example below. RP/0/0/CPU0:R3(config)#interface g0/0/0/1 RP/0/0/CPU0:R3(config-if)#no proxy-arp
- RMF Control
- SC-7
- Severity
- M
- CCI
- CCI-001097
- Version
- CISC-RT-000390
- Vuln IDs
-
- V-96741
- Rule IDs
-
- SV-105879r1_rule
Checks: C-95577r1_chk
This requirement is not applicable for the DODIN Backbone. The perimeter router of the managed network must be configured with an outbound ACL on the egress interface to block all management traffic as shown in the example below. Step 1: Verify that all external interfaces has been configured with an outbound ACL as shown in the example below. interface GigabitEthernet0/0/0/2 ipv4 address 10.1.35.3 255.255.255.0 ipv4 access-group EXTERNAL_ACL_OUTBOUND egress Step 2: Verify that the outbound ACL discards management traffic as shown in the example below. ipv4 access-list EXTERNAL_ACL_OUTBOUND 10 deny tcp any any eq tacacs log-input 20 deny tcp any any eq ssh log-input 30 deny udp any any eq snmp log-input 40 deny udp any any eq snmptrap log-input 50 deny udp any any eq syslog log-input 60 permit tcp any any eq www log-input 70 deny ipv4 any any log-input If management traffic is not blocked at the perimeter, this is a finding.
Fix: F-102419r2_fix
This requirement is not applicable for the DODIN Backbone. Configure the perimeter router of the managed network with an outbound ACL on the egress interface to block all management traffic. Step 1: Configure an ACL to block egress management traffic. RP/0/0/CPU0:R3(config)#Ipv4 access-list EXTERNAL_ACL_OUTBOUND RP/0/0/CPU0:R3(config-ipv4-acl)#deny tcp any any eq tacacs log-input RP/0/0/CPU0:R3(config-ipv4-acl)#deny tcp any any eq 22 log-input RP/0/0/CPU0:R3(config-ipv4-acl)#deny udp any any eq snmp log-input RP/0/0/CPU0:R3(config-ipv4-acl)#deny udp any any eq snmptrap log-input RP/0/0/CPU0:R3(config-ipv4-acl)#deny udp any any eq syslog log-input RP/0/0/CPU0:R3(config-ipv4-acl)#permit tcp any any eq www log-input RP/0/0/CPU0:R3(config-ipv4-acl)#deny ip any any log-input RP/0/0/CPU0:R3(config-ipv4-acl)#end Note: Permit commands would be configured to allow applicable outbound traffic. The example above is allowing web traffic. Step 2: Configure the external interfaces with the outbound ACL. RP/0/0/CPU0:R3(config)#int g0/0/0/2 RP/0/0/CPU0:R3(config-if)#ipv4 access-group EXTERNAL_ACL_OUTBOUND egress
- RMF Control
- SC-7
- Severity
- M
- CCI
- CCI-001097
- Version
- CISC-RT-000400
- Vuln IDs
-
- V-96743
- Rule IDs
-
- SV-105881r1_rule
Checks: C-95579r1_chk
This requirement is not applicable for the DODIN Backbone. Review the network topology diagram to determine connectivity between the managed network and the NOC. Review the OOBM gateway router configuration to validate the path and interface that the management traffic traverses. If an IPsec tunnel is used to transport the management traffic between the NOC and the managed network, review the configuration following the steps below. Step 1: Note the profile referenced for the IPsec tunnel to the NOC interface tunnel-ipsec 30 profile IPSEC_NOC_PROFILE tunnel source GigabitEthernet0/0/0/2 tunnel destination x.1.22.2 Step 2: Note the crypto ACL that was specified in the IPsec profile crypto isakmp keyring ISAKMP_KEYRING pre-shared-key address x.1.22.2 255.255.255.255 key encrypted 150A13141C32 ! crypto isakmp policy 10 hash sha256 encryption aes 256 authentication pre-share ! crypto ipsec transform-set IPSEC_TRANS esp-aes 256 esp-sha256-hmac mode tunnel ! crypto ipsec profile IPSEC_NOC_PROFILE set pfs group16 match address MGMT_TRAFFIC_ACL Step 3: Review the ACL defined in the crypto map and verify that the destination is the management network. ! ipv4 access-list MGMT_TRAFFIC_ACL 10 permit ipv4 10.1.34.0 0.0.0.255 10.22.2.0 0.0.0.255 ! Note: The management network is this example is 10.22.2.0/24 If management traffic is not transported between the managed network and the NOC via dedicated circuit, MPLS/VPN service, or IPsec tunnel, this is a finding.
Fix: F-102421r1_fix
This requirement is not applicable for the DODIN Backbone. Ensure that a dedicated circuit, MPLS/VPN service, or IPsec tunnel is deployed to transport management traffic between the managed network and the NOC. If an IPsec tunnel is to be used, the steps below can be used as a guideline. Step 1: Configure the ACL for the management network as the destination. This ACL will be defined in the crypto as the interesting traffic to be forwarded into the IPsec tunnel. RP/0/0/CPU0:R3(config)#Ipv4 access-list MGMT_TRAFFIC_ACL RP/0/0/CPU0:R3(config-ipv4-acl)#permit ip 10.1.34.0 0.0.0.255 10.22.2.0 0.0.0.255 Step 2: Create an ISAKMP policy for Phase 1 negotiations. RP/0/0/CPU0:R3(config)#crypto isakmp policy 10 RP/0/0/CPU0:R3(config-isakmp-policy)#authentication pre-share RP/0/0/CPU0:R3(config-isakmp-policy)#hash sha256 RP/0/0/CPU0:R3(config-isakmp-policy)#encryption aes 256 RP/0/0/CPU0:R3(config-isakmp-policy)#exit Step 3: Configure the keyring to be used for ISAKMP to authenticate the remote side during IKE negotiation. RP/0/0/CPU0:R3(config)#crypto isakmp keyring ISAKMP_KEYRING RP/0/0/CPU0:R3(config-crypto-keyring)#pre-shared-key address 255.255.255.255 key xxxxx RP/0/0/CPU0:R3(config-crypto-keyring)#exit Step 4: Configure the IPsec transform set. RP/0/0/CPU0:R3(config)#crypto ipsec transform-set IPSEC_TRANS esp-aes 256 esp-sha256-hmac RP/0/0/CPU0:R3(config-transform-set IPSEC_TRANS)#mode tunnel Step 5: Configure the IPsec profile. RP/0/0/CPU0:R3(config)#crypto ipsec profile IPSEC_NOC_PROFILE RP/0/0/CPU0:R3(config- IPSEC_NOC_PROFILE)#set pfs group 16 RP/0/0/CPU0:R3(config- IPSEC_NOC_PROFILE)#match MGMT_TRAFFIC_ACL transform-set IPSEC_TRANS RP/0/0/CPU0:R3(config- IPSEC_NOC_PROFILE)#exit Step 6: Configure the IPsec virtual interface. RP/0/0/CPU0:R3(config)#interface tunnel-ipsec 22 RP/0/0/CPU0:R3(config-if)#profile IPSEC_NOC_PROFILE RP/0/0/CPU0:R3(config-if)#tunnel source GigabitEthernet0/0/0/2 RP/0/0/CPU0:R3(config-if)#tunnel destination x.1.22.2 RP/0/0/CPU0:R3(config-if)#end
- RMF Control
- SC-7
- Severity
- M
- CCI
- CCI-001097
- Version
- CISC-RT-000410
- Vuln IDs
-
- V-96745
- Rule IDs
-
- SV-105883r1_rule
Checks: C-95581r2_chk
This requirement is not applicable for the DODIN Backbone. Review the network topology diagram to determine connectivity between the managed network and the NOC. Review the OOBM gateway router configuration to validate the path that the management traffic traverses. Verify that only management traffic is forwarded through the OOBM interface or IPsec tunnel. If an OOBM link is used, verify that the only authorized management traffic is transported to the NOC by reviewing the outbound ACL applied to the OOBM interface as shown in the example below. Step 1: Note the outbound ACL applied to the OOBM interface. interface GigabitEthernet0/0/0/2 description OOB link to NOC ipv4 address 10.11.1.8 255.255.255.0 ipv4 access-group MGMT_TRAFFIC_ACL egress Step 2: Review the outbound ACL and verify only management traffic is forwarded to the NOC. ipv4 access-list MGMT_TRAFFIC_ACL 10 permit tcp 10.1.34.0 0.0.0.255 10.22.2.0 0.0.0.255 eq tacacs 20 permit tcp 10.1.34.0 0.0.0.255 10.22.2.0 0.0.0.255 eq ssh 30 permit udp 10.1.34.0 0.0.0.255 10.22.2.0 0.0.0.255 eq snmp 40 permit udp 10.1.34.0 0.0.0.255 10.22.2.0 0.0.0.255 eq snmptrap 50 permit udp 10.1.34.0 0.0.0.255 10.22.2.0 0.0.0.255 eq syslog 60 permit icmp 10.1.34.0 0.0.0.255 10.22.22.0 0.0.0.255 echo 70 permit icmp 10.1.34.0 0.0.0.255 10.22.22.0 0.0.0.255 echo-reply 80 deny ipv4 any any log-input If an IPSec tunnel is used, verify that the only authorized management traffic is transported to the NOC. Step 1: Note the profile referenced for the IPSec tunnel to the NOC. interface tunnel-ipsec 30 profile IPSEC_NOC_PROFILE tunnel source GigabitEthernet0/0/0/2 tunnel destination x.1.22.2 Step 2: Note the crypto ACL that was specified in the IPSec profile. crypto isakmp keyring ISAKMP_KEYRING pre-shared-key address x.1.22.2 255.255.255.255 key encrypted 150A13141C32 ! crypto isakmp policy 10 hash sha256 encryption aes 256 authentication pre-share ! crypto ipsec transform-set IPSEC_TRANS esp-aes 256 esp-sha256-hmac mode tunnel ! crypto ipsec profile IPSEC_NOC_PROFILE set pfs group16 match address MGMT_TRAFFIC_ACL Step 3: Review the crypto ACL defined in the IPSec profile and verify only management traffic is forwarded to the NOC. ipv4 access-list MGMT_TRAFFIC_ACL 10 permit tcp 10.1.34.0 0.0.0.255 10.22.2.0 0.0.0.255 eq tacacs 20 permit tcp 10.1.34.0 0.0.0.255 10.22.2.0 0.0.0.255 eq ssh 30 permit udp 10.1.34.0 0.0.0.255 10.22.2.0 0.0.0.255 eq snmp 40 permit udp 10.1.34.0 0.0.0.255 10.22.2.0 0.0.0.255 eq snmptrap 50 permit udp 10.1.34.0 0.0.0.255 10.22.2.0 0.0.0.255 eq syslog 60 permit icmp 10.1.34.0 0.0.0.255 10.22.22.0 0.0.0.255 Note: ICMP is permitted for troubleshooting purposes. The IPSec SA can only identify interesting traffic via address, protocol, and port; hence, the ICMP traffic cannot be qualified via type attribute. If traffic other than authorized management traffic is permitted through the OOBM interface or IPsec tunnel, this is a finding.
Fix: F-102423r1_fix
This requirement is not applicable for the DODIN Backbone. Configure ACLs to permit only authorized management traffic into IPsec tunnels or the OOBM interface used for forwarding management data as shown in the examples below. OOBM Link RP/0/0/CPU0:R3(config)#ipv4 access-list MGMT_TRAFFIC_ACL RP/0/0/CPU0:R3(config-ipv4-acl)#permit tcp 10.1.34.0 0.0.0.255 10.22.2.0 0.0.0.255 eq tacacs RP/0/0/CPU0:R3(config-ipv4-acl)#permit tcp 10.1.34.0 0.0.0.255 10.22.2.0 0.0.0.255 eq ssh RP/0/0/CPU0:R3(config-ipv4-acl)#permit udp 10.1.34.0 0.0.0.255 10.22.2.0 0.0.0.255 eq snmp RP/0/0/CPU0:R3(config-ipv4-acl)#permit udp 10.1.34.0 0.0.0.255 10.22.2.0 0.0.0.255 eq snmptrap RP/0/0/CPU0:R3(config-ipv4-acl)#permit udp 10.1.34.0 0.0.0.255 10.22.2.0 0.0.0.255 eq syslog RP/0/0/CPU0:R3(config-ipv4-acl)#permit icmp 10.1.34.0 0.0.0.255 10.22.22.0 0.0.0.255 RP/0/0/CPU0:R3(config-ipv4-acl)#deny ipv4 any any log-input RP/0/0/CPU0:R3(config-ipv4-acl)#exit IPsec Tunnel RP/0/0/CPU0:R3(config)#ipv4 access-list MGMT_TRAFFIC_ACL RP/0/0/CPU0:R3(config-ipv4-acl)#permit tcp 10.1.34.0 0.0.0.255 10.22.2.0 0.0.0.255 eq tacacs RP/0/0/CPU0:R3(config-ipv4-acl)#permit tcp 10.1.34.0 0.0.0.255 10.22.2.0 0.0.0.255 eq ssh RP/0/0/CPU0:R3(config-ipv4-acl)#permit udp 10.1.34.0 0.0.0.255 10.22.2.0 0.0.0.255 eq snmp RP/0/0/CPU0:R3(config-ipv4-acl)#permit udp 10.1.34.0 0.0.0.255 10.22.2.0 0.0.0.255 eq snmptrap RP/0/0/CPU0:R3(config-ipv4-acl)#permit udp 10.1.34.0 0.0.0.255 10.22.2.0 0.0.0.255 eq syslog RP/0/0/CPU0:R3(config-ipv4-acl)#permit icmp 10.1.34.0 0.0.0.255 10.22.22.0 0.0.0.255 RP/0/0/CPU0:R3(config-ipv4-acl)#exit
- RMF Control
- AC-4
- Severity
- M
- CCI
- CCI-001414
- Version
- CISC-RT-000420
- Vuln IDs
-
- V-96747
- Rule IDs
-
- SV-105885r1_rule
Checks: C-95583r1_chk
This requirement is not applicable for the DODIN Backbone. Verify that the OOBM interface is an adjacency in the IGP domain for the management network via separate VRF as shown in the example below. router ospf 2 vrf MGMT area 0 interface GigabitEthernet0/0/0/0.2 ! ! ! ! router ospf 3 vrf PROD area 0 interface GigabitEthernet0/0/0/0.3 ! ! ! ! If the router is not configured to have separate IGP instances for the managed network and management network, this is a finding.
Fix: F-102425r1_fix
This requirement is not applicable for the DODIN Backbone. Configure the router to have a separate IGP instance for the management network as shown in the example below. RP/0/0/CPU0:R2(config)#router ospf 2 vrf MGMT RP/0/0/CPU0:R2(config-ospf-vrf)#area 0 RP/0/0/CPU0:R2(config-ospf-vrf-ar)#interface GigabitEthernet0/0/0/0.2 RP/0/0/CPU0:R2(config-ospf-vrf-ar-if)#exit RP/0/0/CPU0:R2(config-ospf-vrf-ar)#exit RP/0/0/CPU0:R2(config-ospf-vrf)#exit RP/0/0/CPU0:R2(config-ospf)#exit RP/0/0/CPU0:R2(config)#router ospf 3 vrf PROD RP/0/0/CPU0:R2(config-ospf-vrf)#area 0 RP/0/0/CPU0:R2(config-ospf-vrf-ar)#interface GigabitEthernet0/0/0/0.3 RP/0/0/CPU0:R2(config-ospf-vrf-ar-if)#end
- RMF Control
- AC-4
- Severity
- M
- CCI
- CCI-001414
- Version
- CISC-RT-000430
- Vuln IDs
-
- V-96749
- Rule IDs
-
- SV-105887r1_rule
Checks: C-95585r1_chk
This requirement is not applicable for the DODIN Backbone. Verify the Interior Gateway Protocol (IGP) instance used for the managed network does not redistribute routes into the IGP instance used for the management network, and vice versa. The example below imports OSPF routes from the production route table (VRF PROD) into the management route table (VRF MGMT) using BGP. vrf MGMT address-family ipv4 unicast import route-target 4:4 8:8 ! export route-target 4:4 ! ! ! vrf PROD address-family ipv4 unicast import route-target 8:8 ! export route-target 8:8 ! ! ! … … … router ospf 2 vrf MGMT redistribute bgp 64512 area 0 interface GigabitEthernet0/0/0/0.2 ! ! ! ! router ospf 3 vrf PROD area 0 interface GigabitEthernet0/0/0/0.3 ! ! ! ! router bgp 64512 address-family ipv4 unicast ! address-family vpnv4 unicast ! vrf MGMT rd 4:4 address-family ipv4 unicast redistribute ospf 2 ! ! vrf PROD rd 8:8 address-family ipv4 unicast redistribute ospf 3 ! ! ! If the IGP instance used for the managed network redistributes routes into the IGP instance used for the management network, or vice versa, this is a finding.
Fix: F-102427r1_fix
This requirement is not applicable for the DODIN Backbone. Remove the configuration that imports routes from the managed network into the management network or vice versa as shown in the example below. RP/0/0/CPU0:R2(config)#vrf MGMT RP/0/0/CPU0:R2(config-vrf)#address-family ipv4 unicast RP/0/0/CPU0:R2(config-vrf-af)#no import route-target 8:8 RP/0/0/CPU0:R2(config-vrf-af)#end
- RMF Control
- SC-7
- Severity
- M
- CCI
- CCI-001097
- Version
- CISC-RT-000440
- Vuln IDs
-
- V-96751
- Rule IDs
-
- SV-105889r1_rule
Checks: C-95587r1_chk
This requirement is not applicable for the DODIN Backbone. It is only applicable if the OOBM gateway router is not a dedicated device to the OOBM backbone. Verify that traffic destined to itself is only sourced by the OOBM or the NOC. In the example below, the OOBM backbone network is 10.11.1.0/24, the NOC address spaces is 10.12.1.0/24, and the OOBM LAN address space at remote site connecting to the managed network is 10.13.1.0/24. Step 1: Note the inbound ACL applied to the OOBM interfaces. interface GigabitEthernet0/0/0/2 description OOB link to NOC ip address 10.11.1.8 255.255.255.0 ipv4 access-group TRAFFIC_FROM_NOC ingress ! interface Giga GigabitEthernet0/0/0/3 description link to OOBM LAN access switch ip address 10.13.1.1 255.255.255.0 ipv4 access-group TRAFFIC_TO_NOC ingress Step 2: Review the inbound ACL bound to any OOB interface connecting to the OOBM backbone and verify traffic destined to itself is only from the OOBM or NOC address space. ipv4 access-list TRAFFIC_FROM_NOC 10 permit ipv4 10.11.1.0 0.255.255.255 host 10.11.1.8 20 permit ipv4 10.12.1.0 0.255.255.255 host 10.11.1.8 30 permit ipv4 10.11.1.0 0.255.255.255 host 10.13.1.1 40 permit ipv4 10.12.1.0 0.255.255.255 host 10.13.1.1 50 deny ipv4 any host 10.11.1.8 log-input 60 deny ipv4 any host 10.13.1.1 log-input 70 permit ipv4 10.11.1.0 0.0.0.255 10.13.1.0 0.0.0.255 80 permit ipv4 10.12.1.0 0.0.0.255 10.13.1.0 0.0.0.255 90 deny ipv4 any any log-input Step 3: Review the inbound ACL bound to any OOBM LAN interfaces and verify traffic destined to itself is from the OOBM LAN address space. ipv4 access-list TRAFFIC_TO_NOC 10 permit ipv4 10.13.1.0 0.255.255.255 host 10.13.1.1 20 permit ipv4 10.13.1.0 0.255.255.255 host 10.11.1.8 30 deny ipv4 any host 10.13.1.1 log-input 40 deny ipv4 any host 10.11.1.8 log-input 50 permit ipv4 10.13.1.0 0.255.255.255 10.11.1.0 0.0.0.255 60 permit ipv4 10.13.1.0 0.255.255.255 10.12.1.0 0.0.0.255 70 deny ipv4 any any log-input If the router does not block any traffic destined to itself that is not sourced from the OOBM network or the NOC, this is a finding.
Fix: F-102429r1_fix
This requirement is not applicable for the DODIN Backbone. It is only applicable if the OOBM gateway router is not a dedicated device to the OOBM backbone. Step 1: Configure the ACL to only allow traffic to the route processor from the OOBM backbone and the NOC. RP/0/0/CPU0:R2(config)#ipv4 access-list TRAFFIC_FROM_NOC RP/0/0/CPU0:R2(config-ipv4-acl)#permit ip 10.11.1.0 0.255.255.255 host 10.11.$ RP/0/0/CPU0:R2(config-ipv4-acl)#permit ip 10.12.1.0 0.255.255.255 host 10.11.$ RP/0/0/CPU0:R2(config-ipv4-acl)#permit ip 10.11.1.0 0.255.255.255 host 10.13.$ RP/0/0/CPU0:R2(config-ipv4-acl)#permit ip 10.12.1.0 0.255.255.255 host 10.13.$ RP/0/0/CPU0:R2(config-ipv4-acl)#deny ip any host 10.11.1.8 log-input RP/0/0/CPU0:R2(config-ipv4-acl)#deny ip any host 10.13.1.1 log-input RP/0/0/CPU0:R2(config-ipv4-acl)#permit ip 10.11.1.0 0.0.0.255 10.13.1.0 0.0.0$ RP/0/0/CPU0:R2(config-ipv4-acl)#permit ip 10.12.1.0 0.0.0.255 10.13.1.0 0.0.0$ RP/0/0/CPU0:R2(config-ipv4-acl)#deny ip any any log-input RP/0/0/CPU0:R2(config-ipv4-acl)#exit Step 2: Configure the ACL to only allow traffic to the route processor from the OOBM LAN. RP/0/0/CPU0:R2(config)#ipv4 access-list TRAFFIC_TO_NOC RP/0/0/CPU0:R2(config-ipv4-acl)#permit ip 10.13.1.0 0.255.255.255 host 10.13.$ RP/0/0/CPU0:R2(config-ipv4-acl)#permit ip 10.13.1.0 0.255.255.255 host 10.11.$ RP/0/0/CPU0:R2(config-ipv4-acl)#deny ip any host 10.13.1.1 log-input RP/0/0/CPU0:R2(config-ipv4-acl)#deny ip any host 10.11.1.8 log-input RP/0/0/CPU0:R2(config-ipv4-acl)#permit ip 10.13.1.0 0.255.255.255 10.11.1.0 0$ RP/0/0/CPU0:R2(config-ipv4-acl)#permit ip 10.13.1.0 0.255.255.255 10.12.1.0 0$ RP/0/0/CPU0:R2(config-ipv4-acl)#deny ip any any log-input RP/0/0/CPU0:R2(config-ipv4-acl)#exit Step 3: Apply the ACLs configured above to the appropriate OOBM interfaces as shown in the example below. RP/0/0/CPU0:R2(config)#int g0/0/0/2 RP/0/0/CPU0:R2(config-if)#ipv4 access-group TRAFFIC_FROM_NOC in RP/0/0/CPU0:R2(config)#int g0/0/0/3 RP/0/0/CPU0:R2(config-if)#access-group TRAFFIC_TO_NOC in RP/0/0/CPU0:R2(config-if)#end
- RMF Control
- SC-7
- Severity
- M
- CCI
- CCI-001097
- Version
- CISC-RT-000450
- Vuln IDs
-
- V-96753
- Rule IDs
-
- SV-105891r1_rule
Checks: C-95589r1_chk
This requirement is only applicable where management access to the router is via an OOBM interface which is not a true OOBM interface. Step 1: Verify that the managed interface has an inbound and outbound ACL configured. interface MgmtEth0/0/CPU0/0 ipv4 address 10.1.13.4 255.255.255.0 ipv4 access-group INGRESS_MANAGEMENT_ACL ingress ipv4 access-group EGRESS_MANAGEMENT_ACL egress Step 2: Verify that the ingress ACL only allows management and ICMP traffic. ipv4 access-list INGRESS_MANAGEMENT_ACL 10 permit tcp any host 10.11.1.22 eq tacacs 20 permit tcp any host 10.11.1.22 eq ssh 30 permit udp any host 10.11.1.22 eq snmp 40 permit udp any host 10.11.1.22 eq snmptrap 50 permit udp any host 10.11.1.22 eq ntp 60 permit icmp any host 10.11.1.22 70 deny ipv4 any any log-input Step 3: Verify that the egress ACL blocks any transit traffic. ipv4 access-list EGRESS_MANAGEMENT_ACL 10 deny ipv4 any any log-input Note: On Cisco routers, local generated packets are not inspected by outgoing interface access-lists. Hence, the above configuration would simply drop any packets not generated by the router; hence, blocking any transit traffic. If the router does not restrict traffic that ingresses and egresses the management interface, this is a finding.
Fix: F-102431r1_fix
If the management interface is not a dedicated OOBM interface, it must be configured with both an ingress and egress ACL. Step 1: Configure an ingress ACL a shown in the example below. RP/0/0/CPU0:R2(config)#Ipv4 access-list INGRESS_MANAGEMENT_ACL RP/0/0/CPU0:R2(config-ipv4-acl)#permit tcp any host 10.11.1.22 eq tacacs RP/0/0/CPU0:R2(config-ipv4-acl)#permit tcp any host 10.11.1.22 eq 22 RP/0/0/CPU0:R2(config-ipv4-acl)#permit udp any host 10.11.1.22 eq snmp RP/0/0/CPU0:R2(config-ipv4-acl)#permit udp any host 10.11.1.22 eq snmptrap RP/0/0/CPU0:R2(config-ipv4-acl)#permit udp any host 10.11.1.22 eq ntp RP/0/0/CPU0:R2(config-ipv4-acl)#permit icmp any host 10.11.1.22 RP/0/0/CPU0:R2(config-ipv4-acl)#deny ip any any log-input RP/0/0/CPU0:R2(config-ipv4-acl)#exit Step 2: Configure an egress ACL a shown in the example below. RP/0/0/CPU0:R2(config)#Ipv4 access-list EGRESS_MANAGEMENT_ACL RP/0/0/CPU0:R2(config-ipv4-acl)#deny ip any any log-input RP/0/0/CPU0:R2(config-ipv4-acl)#exit Step 3: Apply the ACLs to the OOBM interfaces. RP/0/0/CPU0:R2(config)#int MgmtEth0/0/CPU0/0 RP/0/0/CPU0:R2(config-if)#ipv4 access-group INGRESS_MANAGEMENT_ACL ingress RP/0/0/CPU0:R2(config-if)#ipv4 access-group EGRESS_MANAGEMENT_ACL egress
- RMF Control
- SC-7
- Severity
- M
- CCI
- CCI-001097
- Version
- CISC-RT-000460
- Vuln IDs
-
- V-96755
- Rule IDs
-
- SV-105893r1_rule
Checks: C-95591r1_chk
This requirement is not applicable for the DODIN Backbone. Verify that all traffic from the managed network to the management network or NOC and vice-versa is secured via IPsec tunnel. Step 1: Note the profile referenced for the IPSec tunnel to the NOC. interface tunnel-ipsec 30 profile IPSEC_NOC_PROFILE tunnel source GigabitEthernet0/0/0/2 tunnel destination x.1.22.2 Step 2: Note the crypto ACL that was specified in the IPSec profile. crypto isakmp keyring ISAKMP_KEYRING pre-shared-key address x.1.22.2 255.255.255.255 key encrypted 150A13141C32 ! crypto isakmp policy 10 hash sha256 encryption aes 256 authentication pre-share ! crypto ipsec transform-set IPSEC_TRANS esp-aes 256 esp-sha256-hmac mode tunnel ! crypto ipsec profile IPSEC_NOC_PROFILE set pfs group16 match address MGMT_TRAFFIC_ACL Step 3: Review the ACL defined in the crypto map and verify that the destination is the management network. ! ipv4 access-list MGMT_TRAFFIC_ACL 10 permit ipv4 10.1.34.0 0.0.0.255 10.22.2.0 0.0.0.255 ! Note: The management network is this example is 10.22.2.0/24. If the management traffic is not secured via IPsec tunnel, this is a finding.
Fix: F-102433r1_fix
This requirement is not applicable for the DODIN Backbone. Ensure that all traffic from the managed network to the management network is secured via IPsec tunnel as shown in the configuration examples below. Step 1: Configure the ACL for the management network as the destination. This ACL will be defined in the crypto as the interesting traffic to be forwarded into the IPsec tunnel. RP/0/0/CPU0:R3(config)#Ipv4 access-list MGMT_TRAFFIC_ACL RP/0/0/CPU0:R3(config-ipv4-acl)#permit ip 10.1.34.0 0.0.0.255 10.22.2.0 0.0.0.255 Step 2: Create an ISAKMP policy for Phase 1 negotiations. RP/0/0/CPU0:R3(config)#crypto isakmp policy 10 RP/0/0/CPU0:R3(config-isakmp-policy)#authentication pre-share RP/0/0/CPU0:R3(config-isakmp-policy)#hash sha256 RP/0/0/CPU0:R3(config-isakmp-policy)#encryption aes 256 RP/0/0/CPU0:R3(config-isakmp-policy)#exit Step 3: Configure the keyring to be used for ISAKMP to authenticate the remote side during IKE negotiation. RP/0/0/CPU0:R3(config)#crypto isakmp keyring ISAKMP_KEYRING RP/0/0/CPU0:R3(config-crypto-keyring)#pre-shared-key address 255.255.255.255 key xxxxx RP/0/0/CPU0:R3(config-crypto-keyring)#exit Step 4: Configure the IPSec transform set. RP/0/0/CPU0:R3(config)#crypto ipsec transform-set IPSEC_TRANS esp-aes 256 esp-sha256-hmac RP/0/0/CPU0:R3(config-transform-set IPSEC_TRANS)#mode tunnel Step 5: Configure the IPSec profile. RP/0/0/CPU0:R3(config)#crypto ipsec profile IPSEC_NOC_PROFILE RP/0/0/CPU0:R3(config- IPSEC_NOC_PROFILE)#set pfs group 16 RP/0/0/CPU0:R3(config- IPSEC_NOC_PROFILE)#match MGMT_TRAFFIC_ACL transform-set IPSEC_TRANS RP/0/0/CPU0:R3(config- IPSEC_NOC_PROFILE)#exit Step 6: Configure the IPSec virtual interface. RP/0/0/CPU0:R3(config)#interface tunnel-ipsec 22 RP/0/0/CPU0:R3(config-if)#profile IPSEC_NOC_PROFILE RP/0/0/CPU0:R3(config-if)#tunnel source GigabitEthernet0/0/0/2 RP/0/0/CPU0:R3(config-if)#tunnel destination x.1.22.2 RP/0/0/CPU0:R3(config-if)#end
- RMF Control
- SC-5
- Severity
- L
- CCI
- CCI-002385
- Version
- CISC-RT-000470
- Vuln IDs
-
- V-96757
- Rule IDs
-
- SV-105895r2_rule
Checks: C-95593r1_chk
Review the BGP configuration to verify that TTL security has been configured for each external neighbor as shown in the example below. router bgp n address-family ipv4 unicast ! neighbor x.1.23.3 remote-as n ttl-security address-family ipv4 unicast ! ! ! If the router is not configured to use GTSM for all Exterior Border Gateway Protocol peering sessions, this is a finding.
Fix: F-102435r1_fix
Configure TTL security on all external BGP neighbors as shown in the example below. RP/0/0/CPU0:R2(config)#router bgp n RP/0/0/CPU0:R2(config-bgp)#neighbor x.1.23.3 RP/0/0/CPU0:R2(config-bgp-nbr)#ttl-security
- RMF Control
- CM-6
- Severity
- M
- CCI
- CCI-000366
- Version
- CISC-RT-000480
- Vuln IDs
-
- V-96759
- Rule IDs
-
- SV-105897r2_rule
Checks: C-95595r1_chk
Review the BGP configuration to determine if it is peering with multiple autonomous systems. Interview the ISSM and router administrator to determine if unique keys are being used. router bgp n address-family ipv4 unicast ! neighbor x.1.23.3 remote-as y keychain YYY_KEY_CHAIN ttl-security address-family ipv4 unicast ! ! neighbor x.1.24.4 remote-as z keychain ZZZ_KEY_CHAIN ttl-security address-family ipv4 unicast ! ! If unique keys are not being used, this is a finding.
Fix: F-102437r1_fix
Configure the router to use unique keys for each AS that it peers with as shown in the example below. RP/0/0/CPU0:R2(config)#router bgp n RP/0/0/CPU0:R2(config-bgp)#neighbor x.1.23.3 RP/0/0/CPU0:R2(config-bgp-nbr)#keychain YYY_KEY_CHAIN RP/0/0/CPU0:R2(config-bgp-nbr)#neighbor x.1.24.4 RP/0/0/CPU0:R2(config-bgp-nbr)#keychain ZZZ_KEY_CHAIN RP/0/0/CPU0:R2(config-bgp-nbr)#end
- RMF Control
- AC-4
- Severity
- M
- CCI
- CCI-001368
- Version
- CISC-RT-000490
- Vuln IDs
-
- V-96761
- Rule IDs
-
- SV-105899r1_rule
Checks: C-95597r1_chk
Review the router configuration to verify that it will reject BGP routes for any Bogon prefixes. Step 1: verify that an inbound route policy has been configured for each external neighbor as shown in the example below. router bgp n address-family ipv4 unicast ! neighbor x.1.23.3 remote-as y keychain YYY_KEY_CHAIN ttl-security address-family ipv4 unicast route-policy BGP_FILTER in ! ! neighbor x.1.24.4 remote-as z keychain ZZZ_KEY_CHAIN ttl-security address-family ipv4 unicast route-policy BGP_FILTER in ! ! Step 2: Review the route policy to determine if it is filtering at a minimum BOGON prefixes as shown in the example below. route-policy BGP_FILTER if destination in BOGON_PREFIXES then drop else pass endif end-policy Step 3: Review the prefix set referenced in the route policy above has been configured containing the current Bogon prefixes as shown in the example below. prefix-set BOGON_PREFIXES 0.0.0.0/8 le 32, 10.0.0.0/8 le 32, 100.64.0.0/10 le 32, 127.0.0.0/8 le 32, 169.254.0.0/16 le 32, 172.16.0.0/12 le 32, 192.0.2.0/24 le 32, 192.88.99.0/24 le 32, 192.168.0.0/16 le 32, 198.18.0.0/15 le 32, 198.51.100.0/24 le 32, 203.0.113.0/24 le 32, 240.0.0.0/4 le 32, 224.0.0.0/4 le 32 end-set If the router is not configured to reject inbound route advertisements for any Bogon prefixes, this is a finding.
Fix: F-102439r1_fix
Configure the router to reject inbound route advertisements for any Bogon prefixes. Step 1: Configure a prefix set containing the current Bogon prefixes as shown below. RP/0/0/CPU0:R2(config)#prefix-set BOGON_PREFIXES RP/0/0/CPU0:R2(config-pfx)#0.0.0.0/8 le 32, RP/0/0/CPU0:R2(config-pfx)#10.0.0.0/8 le 32, RP/0/0/CPU0:R2(config-pfx)#100.64.0.0/10 le 32, RP/0/0/CPU0:R2(config-pfx)#127.0.0.0/8 le 32, RP/0/0/CPU0:R2(config-pfx)#169.254.0.0/16 le 32, RP/0/0/CPU0:R2(config-pfx)#172.16.0.0/12 le 32, RP/0/0/CPU0:R2(config-pfx)#192.0.2.0/24 le 32, RP/0/0/CPU0:R2(config-pfx)#192.88.99.0/24 le 32, RP/0/0/CPU0:R2(config-pfx)#192.168.0.0/16 le 32, RP/0/0/CPU0:R2(config-pfx)#198.18.0.0/15 le 32, RP/0/0/CPU0:R2(config-pfx)#198.51.100.0/24 le 32, RP/0/0/CPU0:R2(config-pfx)#203.0.113.0/24 le 32, RP/0/0/CPU0:R2(config-pfx)#240.0.0.0/4 le 32, RP/0/0/CPU0:R2(config-pfx)#224.0.0.0/4 le 32 RP/0/0/CPU0:R2(config-pfx)#end-set Step 2: Configure the route policy to drop routes with BOGON prefixes as shown in the example below. RP/0/0/CPU0:R2(config)#route-policy BGP_FILTER RP/0/0/CPU0:R2(config-rpl)#if destination in BOGON_PREFIXES then RP/0/0/CPU0:R2(config-rpl-if)#drop RP/0/0/CPU0:R2(config-rpl-if)#else pass endif RRP/0/0/CPU0:R2(config-rpl)#end-policy RP/0/0/CPU0:R2(config)#exit Step 3: Apply the route policy to each external BGP neighbor as shown in the example. RP/0/0/CPU0:R2(config)#router bgp xx RP/0/0/CPU0:R2(config-bgp)#neighbor x.1.23.3 RP/0/0/CPU0:R2(config-bgp-nbr)#address-family ipv4 unicast RP/0/0/CPU0:R2(config-bgp-nbr-af)#route-policy BGP_FILTER in RP/0/0/CPU0:R2(config-bgp)#neighbor x.1.24.4 RP/0/0/CPU0:R2(config-bgp-nbr)#address-family ipv4 unicast RP/0/0/CPU0:R2(config-bgp-nbr-af)#route-policy BGP_FILTER in
- RMF Control
- AC-4
- Severity
- M
- CCI
- CCI-001368
- Version
- CISC-RT-000500
- Vuln IDs
-
- V-96763
- Rule IDs
-
- SV-105901r1_rule
Checks: C-95599r2_chk
Review the router configuration to verify that it will reject routes belonging to the local AS. Step 1: verify that an inbound route policy has been configured for each external neighbor as shown in the example below. router bgp xx address-family ipv4 unicast ! neighbor x.1.23.3 remote-as yy keychain YYY_KEY_CHAIN ttl-security address-family ipv4 unicast route-policy BGP_FILTER_INBOUND in ! ! neighbor x.1.24.4 remote-as zz keychain ZZZ_KEY_CHAIN ttl-security address-family ipv4 unicast route-policy BGP_FILTER_INBOUND in ! ! Step 2: Review the route policy to determine if it is filtering at a minimum local prefixes as shown in the example below. route-policy BGP_FILTER_INBOUND if destination in LOCAL_PREFIX then drop else pass endif end-policy Note: If bogons are also filtered per previous requirement, the route policy would look similar to the following example: route-policy BGP_FILTER_INBOUND if destination in BOGON_PREFIXES then drop elseif destination in LOCAL_PREFIX then drop else pass endif end-policy Step 3: Review the prefix set referenced in the route policy above to determine if it includes the local global prefix as shown in the example below. prefix-set LOCAL_PREFIX x.13.1.0/24 le 32 end-set If the router is not configured to reject inbound route advertisements belonging to the local AS, this is a finding.
Fix: F-102441r1_fix
Step 1: Configure a prefix set containing the current Bogon prefixes as shown below. RP/0/0/CPU0:R2(config)#prefix-set Step 1: Configure a prefix set containing the current Bogon prefixes as shown below. RP/0/0/CPU0:R2(config)#prefix-set LOCAL_PREFIX RP/0/0/CPU0:R2(config-pfx)#x.13.1.0/24 le 32 RP/0/0/CPU0:R2(config-pfx)#end-set Step 2: Configure the route policy to drop routes with BOGON prefixes as shown in the example below. RP/0/0/CPU0:R2(config)#route-policy BGP_FILTER_INBOUND RP/0/0/CPU0:R2(config-rpl)#if destination in LOCAL_PREFIX then RP/0/0/CPU0:R2(config-rpl-if)#drop RP/0/0/CPU0:R2(config-rpl-if)#else pass endif RRP/0/0/CPU0:R2(config-rpl)#end-policy RP/0/0/CPU0:R2(config)#exit Step 3: Apply the route policy to each external BGP neighbor as shown in the example. RP/0/0/CPU0:R2(config)#router bgp xx RP/0/0/CPU0:R2(config-bgp)#neighbor x.1.23.3 RP/0/0/CPU0:R2(config-bgp-nbr)#address-family ipv4 unicast RP/0/0/CPU0:R2(config-bgp-nbr-af)#route-policy BGP_FILTER_INBOUND in RP/0/0/CPU0:R2(config-bgp)#neighbor x.1.24.4 RP/0/0/CPU0:R2(config-bgp-nbr)#address-family ipv4 unicast RP/0/0/CPU0:R2(config-bgp-nbr-af)#route-policy BGP_FILTER_INBOUND in
- RMF Control
- AC-4
- Severity
- M
- CCI
- CCI-001368
- Version
- CISC-RT-000510
- Vuln IDs
-
- V-96765
- Rule IDs
-
- SV-105903r1_rule
Checks: C-95601r1_chk
Review the router configuration to verify that there are ACLs defined to only accept routes for prefixes that belong to specific customers. Step 1: Verify that an inbound route policy has been configured for each customer neighbor as shown in the example below. router bgp xx address-family ipv4 unicast ! neighbor x.12.4.14 remote-as 64514 address-family ipv4 unicast route-policy CUST1_PREFIX_FILTER in ! ! neighbor x.12.4.16 remote-as 64516 address-family ipv4 unicast route-policy CUST2_PREFIX_FILTER in ! ! Step 2: Review the route policies to determine if it is accepting only prefixes belonging to each customer as shown in the example below. route-policy CUST1_PREFIX_FILTER if destination in CUST1_PREFIX then pass else drop endif end-policy ! route-policy CUST2_PREFIX_FILTER if destination in CUST2_PREFIX then pass else drop endif end-policy Step 3: Review the prefix sets referenced in the route policies above to determine if they include only prefixes belonging to each customer. prefix-set CUST1_PREFIX x.1.1.0/24 le 32 end-set ! prefix-set CUST2_PREFIX x.2.1.0/24 le 32 end-set Note: Routes to PE-CE links within a VPN are needed for troubleshooting end-to-end connectivity across the MPLS/IP backbone. Hence, these prefixes are an exception to this requirement. If the router is not configured to reject inbound route advertisements from each CE router for prefixes that are not allocated to that customer, this is a finding.
Fix: F-102443r1_fix
Configure the router to reject inbound route advertisements from each CE router for prefixes that are not allocated to that customer. Step 1: Configure a prefix set for each customer containing prefixes belonging to each as shown in the example. RP/0/0/CPU0:R2(config)#prefix-set CUST1_PREFIX RP/0/0/CPU0:R2(config-pfx)#x.1.1.0/24 le 32 RP/0/0/CPU0:R2(config-pfx)#end-set RP/0/0/CPU0:R2(config)#prefix-set CUST2_PREFIX RP/0/0/CPU0:R2(config-pfx)#x.2.1.0/24 le 32 RP/0/0/CPU0:R2(config-pfx)#end-set Step 2: Configure a route policy filter for each customer as shown in the example. RP/0/0/CPU0:R2(config)#route-policy CUST1_PREFIX_FILTER RP/0/0/CPU0:R2(config-rpl)#if destination in CUST1_PREFIX then RP/0/0/CPU0:R2(config-rpl-if)#pass RP/0/0/CPU0:R2(config-rpl-if)#else RP/0/0/CPU0:R2(config-rpl-else)#drop RP/0/0/CPU0:R2(config-rpl-else)#endif RP/0/0/CPU0:R2(config-rpl)#end-policy RP/0/0/CPU0:R2(config)#route-policy CUST2_PREFIX_FILTER RP/0/0/CPU0:R2(config-rpl)#if destination in CUST2_PREFIX then RP/0/0/CPU0:R2(config-rpl-if)#pass RP/0/0/CPU0:R2(config-rpl-if)#else RP/0/0/CPU0:R2(config-rpl-else)#drop RP/0/0/CPU0:R2(config-rpl-else)#endif RP/0/0/CPU0:R2(config-rpl)#end-policy Step 3: Apply the route policy to each customer neighbor as shown in the example. RP/0/0/CPU0:R2(config)#router bgp xx RP/0/0/CPU0:R2(config-bgp)#neighbor x.12.4.14 RP/0/0/CPU0:R2(config-bgp-nbr)#address-family ipv4 unicast RP/0/0/CPU0:R2(config-bgp-nbr-af)#route-policy CUST1_PREFIX_FILTER in RP/0/0/CPU0:R2(config-bgp)#neighbor x.12.4.16 RP/0/0/CPU0:R2(config-bgp-nbr)#address-family ipv4 unicast RP/0/0/CPU0:R2(config-bgp-nbr-af)#route-policy CUST2_PREFIX_FILTER in
- RMF Control
- AC-4
- Severity
- M
- CCI
- CCI-001368
- Version
- CISC-RT-000520
- Vuln IDs
-
- V-96767
- Rule IDs
-
- SV-105905r1_rule
Checks: C-95603r1_chk
This requirement is not applicable for the DODIN Backbone. Step 1: verify that an outbound route policy has been configured for each customer neighbor as shown in the example below. router bgp xx address-family ipv4 unicast ! neighbor x.12.4.14 remote-as 64514 address-family ipv4 unicast route-policy CE_ADVERTISEMENTS out ! ! neighbor x.12.4.16 remote-as 64516 address-family ipv4 unicast route-policy CE_ADVERTISEMENTS out ! ! Step 2: Review the route policy to determine if it is accepting only prefixes belonging to customers or the local autonomous system as shown in the example below. route-policy CE_ADVERTISEMENTS if destination in CE_PREFIX_ADVERTISEMENTS then pass else drop endif end-policy Step 3: Review the prefix sets referenced in the route policy above to determine if they include only prefixes belonging to customers or the local autonomous system as shown in the example below. prefix-set CE_PREFIX_ADVERTISEMENTS x.13.1.0/24 le 32, x.13.2.0/24 le 32, x.13.3.0/24 le 32, x.13.4.0/24 le 32 end-set If the router is not configured to reject outbound route advertisements that do not belong to any customers or the local AS, this is a finding.
Fix: F-102445r1_fix
This requirement is not applicable for the DODIN Backbone. Step 1: Configure a prefix set for customer and local autonomous system prefixes as shown in the example. RP/0/0/CPU0:R2(config)#prefix-set CE_PREFIX_ADVERTISEMENTS RP/0/0/CPU0:R2(config-pfx)#x.13.1.0/24 le 32, RP/0/0/CPU0:R2(config-pfx)#x.13.2.0/24 le 32, RP/0/0/CPU0:R2(config-pfx)#x.13.3.0/24 le 32, RP/0/0/CPU0:R2(config-pfx)#x.13.4.0/24 le 32 RP/0/0/CPU0:R2(config-pfx)#end-set Step 2: Configure a route policy filter for allow customer and local autonomous system prefixes as shown in the example. RP/0/0/CPU0:R2(config)#route-policy CE_ADVERTISEMENTS RP/0/0/CPU0:R2(config-rpl)#if destination in CE_PREFIX_ADVERTISEMENTS then RP/0/0/CPU0:R2(config-rpl-if)#pass RP/0/0/CPU0:R2(config-rpl-if)#else RP/0/0/CPU0:R2(config-rpl-else)#drop RP/0/0/CPU0:R2(config-rpl-else)#endif RP/0/0/CPU0:R2(config-rpl)#end-policy Step 3: Apply the route policy to each customer neighbor as shown in the example. RP/0/0/CPU0:R2(config)#router bgp xx RP/0/0/CPU0:R2(config-bgp)#neighbor x.12.4.14 RP/0/0/CPU0:R2(config-bgp-nbr)#address-family ipv4 unicast RP/0/0/CPU0:R2(config-bgp-nbr-af)#route-policy route-policy CE_ADVERTISEMENTS out RP/0/0/CPU0:R2(config-bgp)#neighbor x.12.4.16 RP/0/0/CPU0:R2(config-bgp-nbr)#address-family ipv4 unicast RP/0/0/CPU0:R2(config-bgp-nbr-af)#route-policy CE_ADVERTISEMENTS out RP/0/0/CPU0:R2(config-bgp-nbr-af)#end
- RMF Control
- SC-7
- Severity
- M
- CCI
- CCI-001097
- Version
- CISC-RT-000530
- Vuln IDs
-
- V-96769
- Rule IDs
-
- SV-105907r1_rule
Checks: C-95605r1_chk
Step 1: verify that an outbound route policy has been configured for each external neighbor as shown in the example below. router bgp xx address-family ipv4 unicast ! neighbor x.1.23.3 remote-as yy address-family ipv4 unicast route-policy BGP_FILTER_OUTBOUND out ! ! neighbor x.1.24.4 remote-as zz address-family ipv4 unicast route-policy BGP_FILTER_OUTBOUND out ! ! Step 2: Review the route policy to determine if it is filtering at a minimum IP core prefixes as shown in the example below. route-policy BGP_FILTER_OUTBOUND if destination in CORE_PREFIX then drop else pass endif end-policy Step 3: Review the prefix set referenced in the route policy above to determine if it includes the IP core prefix as shown in the example below. prefix-set CORE_PREFIX 10.1.1.0/24 le 32 end-set If the router is not configured to reject outbound route advertisements for prefixes belonging to the IP core, this is a finding.
Fix: F-102447r1_fix
Step 1: Configure a prefix set containing the IP core prefix as shown below. RP/0/0/CPU0:R2(config)#prefix-set Step 2: Configure a prefix set containing the current Bogon prefixes as shown below. RP/0/0/CPU0:R2(config)#prefix-set CORE_PREFIX RP/0/0/CPU0:R2(config-pfx)#10.1.1.0/24 le 32 RP/0/0/CPU0:R2(config-pfx)#end-set Step 3: Configure the route policy to drop route advertisements for IP core prefixes as shown in the example below. RP/0/0/CPU0:R2(config)#route-policy BGP_FILTER_OUTBOUND RP/0/0/CPU0:R2(config-rpl)#if destination in CORE_PREFIX then RP/0/0/CPU0:R2(config-rpl-if)#drop RP/0/0/CPU0:R2(config-rpl-if)#else RP/0/0/CPU0:R2(config-rpl-else)#pass RP/0/0/CPU0:R2(config-rpl-else)#endif RP/0/0/CPU0:R2(config-rpl)#end-policy Step 4: Apply the route policy to each external BGP neighbor as shown in the example. RP/0/0/CPU0:R2(config)#router bgp xx RP/0/0/CPU0:R2(config-bgp)#neighbor x.1.23.3 RP/0/0/CPU0:R2(config-bgp-nbr)#address-family ipv4 unicast RP/0/0/CPU0:R2(config-bgp-nbr-af)#route-policy BGP_FILTER_OUTBOUND out RP/0/0/CPU0:R2(config-bgp)#neighbor x.1.24.4 RP/0/0/CPU0:R2(config-bgp-nbr)#address-family ipv4 unicast RP/0/0/CPU0:R2(config-bgp-nbr-af)#route-policy BGP_FILTER_ OUTBOUND out
- RMF Control
- AC-4
- Severity
- L
- CCI
- CCI-000032
- Version
- CISC-RT-000540
- Vuln IDs
-
- V-96771
- Rule IDs
-
- SV-105909r1_rule
Checks: C-95607r1_chk
Review the router configuration to verify the router is configured to deny updates received from eBGP peers that do not list their AS number as the first AS in the AS_PATH attribute. By default Cisco IOS enforces the first AS in the AS_PATH attribute for all route advertisements. Review the router configuration to verify that the command bgp enforce-first-as disable is not configured as shown in the example below. router bgp nn bgp enforce-first-as disable If the router is not configured to reject updates from peers that do not list their AS number as the first AS in the AS_PATH attribute, this is a finding.
Fix: F-102449r1_fix
Configure the router to deny updates received from eBGP peers that do not list their AS number as the first AS in the AS_PATH attribute. RP/0/0/CPU0:R2(config)#router bgp 2 RP/0/0/CPU0:R2(config-bgp)#no bgp enforce-first-as disable
- RMF Control
- AC-4
- Severity
- L
- CCI
- CCI-000032
- Version
- CISC-RT-000550
- Vuln IDs
-
- V-96773
- Rule IDs
-
- SV-105911r1_rule
Checks: C-95609r2_chk
This requirement is not applicable for the DODIN Backbone. Review the router configuration to verify the router is configured to deny updates received from CE routers with an originating AS in the AS_PATH attribute that does not belong to that customer. Step 1: verify that an inbound route policy has been configured for each customer neighbor as shown in the example below. router bgp xx address-family ipv4 unicast ! neighbor x.12.4.14 remote-as 64514 address-family ipv4 unicast route-policy FILTER _64514_ROUTES in ! ! neighbor x.12.4.16 remote-as 64516 address-family ipv4 unicast route-policy FILTER_64516_ROUTES in ! Step 2: Verify that the route policy permits only routes from each CE router with an originating AS that does not belong to that customer. route-policy FILTER_64514_ROUTES if as-path originates-from 64514' then pass else drop endif end-policy ! route-policy FILTER_64516_ROUTES if as-path originates-from 64516' then pass else drop endif end-policy Note: The inbound route policy to filter customer prefixes can be nested with the above route policy as shown in the example below. route-policy CUST1_INBOUND_FILTER apply CUST1_FILTER apply FILTER_64514_ROUTES end-policy If the router is not configured to reject updates from CE routers with an originating AS in the AS_PATH attribute that does not belong to that customer, this is a finding.
Fix: F-102451r1_fix
This requirement is not applicable for the DODIN Backbone. Configure the router to reject updates from CE routers with an originating AS in the AS_PATH attribute that does not belong to that customer. Step 1: Configure an inbound route policy for each customer to only accept routes with an originating AS that belongs to that customer as shown in the example below. RP/0/0/CPU0:R2(config)#route-policy FILTER_64514_ROUTES RP/0/0/CPU0:R2(config-rpl)#if as-path originates-from '64514' then RP/0/0/CPU0:R2(config-rpl-if)#pass RP/0/0/CPU0:R2(config-rpl-if)#else RP/0/0/CPU0:R2(config-rpl-else)#drop RP/0/0/CPU0:R2(config-rpl-else)#endif RP/0/0/CPU0:R2(config-rpl)#end-policy RP/0/0/CPU0:R2(config)#route-policy FILTER_64516_ROUTES RP/0/0/CPU0:R2(config-rpl)#if as-path originates-from '64516' then RP/0/0/CPU0:R2(config-rpl-if)#pass RP/0/0/CPU0:R2(config-rpl-if)#else RP/0/0/CPU0:R2(config-rpl-else)#drop RP/0/0/CPU0:R2(config-rpl-else)#endif RP/0/0/CPU0:R2(config-rpl)#end-policy Step 2: Apply the appropriate inbound route policy with each peering CE router as shown in the example below. RP/0/0/CPU0:R2(config)#router bgp xx RP/0/0/CPU0:R2(config-bgp)#neighbor x.12.4.14 RP/0/0/CPU0:R2(config-bgp-nbr)#address-family ipv4 unicast RP/0/0/CPU0:R2(config-bgp-nbr-af)#route-policy route-policy FILTER_64514_ROUTES in RP/0/0/CPU0:R2(config-bgp)#neighbor x.12.4.16 RP/0/0/CPU0:R2(config-bgp-nbr)#address-family ipv4 unicast RP/0/0/CPU0:R2(config-bgp-nbr-af)#route-policy FILTER_64516_ROUTES in RP/0/0/CPU0:R2(config-bgp-nbr-af)#end
- RMF Control
- SC-5
- Severity
- M
- CCI
- CCI-002385
- Version
- CISC-RT-000560
- Vuln IDs
-
- V-96775
- Rule IDs
-
- SV-105913r1_rule
Checks: C-95611r1_chk
Review the router configuration to verify that the number of received prefixes from each eBGP neighbor is controlled. router bgp xx address-family ipv4 unicast ! neighbor x.1.23.3 remote-as yy ttl-security address-family ipv4 unicast route-policy BGP_FILTER in maximum-prefix nnnn 75 discard-extra-paths ! ! neighbor x.1.24.4 remote-as zz address-family ipv4 unicast route-policy BGP_FILTER in maximum-prefix nnnn 75 discard-extra-paths ! ! ! If the router is not configured to control the number of prefixes received from each peer to protect against route table flooding and prefix de-aggregation attacks, this is a finding.
Fix: F-102453r1_fix
Configure the router to use the maximum prefixes feature to protect against route table flooding and prefix de-aggregation attacks as shown in the example below. RP/0/0/CPU0:R2(config)#router bgp xx RP/0/0/CPU0:R2(config-bgp)#neighbor x1.24.4 RP/0/0/CPU0:R2(config-bgp-nbr)#address-family ipv4 unicast RP/0/0/CPU0:R2(config-bgp-nbr-af)#maximum-prefix 444 discard-extra-paths RP/0/0/CPU0:R2(config-bgp-nbr-af)#end
- RMF Control
- SC-5
- Severity
- L
- CCI
- CCI-002385
- Version
- CISC-RT-000570
- Vuln IDs
-
- V-96777
- Rule IDs
-
- SV-105915r1_rule
Checks: C-95613r1_chk
This requirement is not applicable for the DODIN Backbone. Review the router configuration to determine if it is compliant with this requirement. Step 1: Verify that an inbound route policy has been configured for each CE router as shown in the example below. router bgp xx address-family ipv4 unicast ! neighbor x.12.4.14 remote-as 64514 address-family ipv4 unicast route-policy FILTER_LONG_PREFIXES in ! ! neighbor x.12.4.16 remote-as 64516 address-family ipv4 unicast route-policy FILTER_LONG_PREFIXES in ! Step 2: Verify that the route policy permits only routes from each CE router with a prefix length of 24 or shorter or the least significant prefixes issued to the customer as shown in the example below. route-policy FILTER_LONG_PREFIXES if destination in PREFIX_LENGTH then pass else drop endif end-policy Note: The inbound route policy to filter customer prefixes can be nested with the above route policy as shown in the example below. route-policy CUST1_INBOUND_FILTER apply CUST1_FILTER apply FILTER_64514_ROUTES apply FILTER_LONG_PREFIXES end-policy Step 3: Review the prefix set referenced in the route policy above to determine if it only allows a prefix length 24 or shorter. prefix-set PREFIX_LENGTH 0.0.0.0/0 ge 8 le 24 end-set If the router is not configured to limit the prefix size on any inbound route advertisement to /24 or the least significant prefixes issued to the customer, this is a finding.
Fix: F-102457r1_fix
This requirement is not applicable for the DODIN Backbone. Configure the router to limit the prefix size on any route advertisement to /24 or the least significant prefixes issued to the customer. Step 1: Configure a prefix set to not include prefixes are longer than /24. RP/0/0/CPU0:R2(config)#prefix-set PREFIX_LENGTH RP/0/0/CPU0:R2(config-pfx)#0.0.0.0/0 ge 8 le 24 RP/0/0/CPU0:R2(config-pfx)#end-set Step 2: Configure a route policy to only accept prefixes that are /24 or shorter as shown in the example below. RP/0/0/CPU0:R2(config)#route-policy FILTER_LONG_PREFIXES RP/0/0/CPU0:R2(config-rpl)#if destination in PREFIX_LENGTH then RP/0/0/CPU0:R2(config-rpl-if)#pass RP/0/0/CPU0:R2(config-rpl-if)#else RP/0/0/CPU0:R2(config-rpl-else)#drop RP/0/0/CPU0:R2(config-rpl-else)#endif RP/0/0/CPU0:R2(config-rpl)#end-policy Step 3: Apply the route policy above inbound with each peering CE router as shown in the example below. RP/0/0/CPU0:R2(config)#router bgp xx RP/0/0/CPU0:R2(config-bgp)#neighbor x.12.4.14 RP/0/0/CPU0:R2(config-bgp-nbr)#address-family ipv4 unicast RP/0/0/CPU0:R2(config-bgp-nbr-af)#route-policy route-policy FILTER_LONG_PREFIXES in RP/0/0/CPU0:R2(config-bgp)#neighbor x.12.4.16 RP/0/0/CPU0:R2(config-bgp-nbr)#address-family ipv4 unicast RP/0/0/CPU0:R2(config-bgp-nbr-af)#route-policy FILTER_LONG_PREFIXES in RP/0/0/CPU0:R2(config-bgp-nbr-af)#end
- RMF Control
- CM-6
- Severity
- L
- CCI
- CCI-000366
- Version
- CISC-RT-000580
- Vuln IDs
-
- V-96779
- Rule IDs
-
- SV-105917r1_rule
Checks: C-95615r1_chk
Step 1: Review the router configuration to verify that a loopback address has been configured. interface Loopback0 ip address 10.1.1.1 255.255.255.255 Step 2: Verify that the loopback interface is used as the source address for all iBGP sessions. router bgp xx address-family ipv4 unicast ! neighbor 10.1.23.3 remote-as xx update-source Loopback0 If the router does not use its loopback address as the source address for all iBGP sessions, this is a finding.
Fix: F-102459r1_fix
Configure the router to use its loopback address as the source address for all iBGP peering. RP/0/0/CPU0:R2(config)#router bgp 2 RP/0/0/CPU0:R2(config-bgp)#neighbor 10.1.24.4 RP/0/0/CPU0:R2(config-bgp-nbr)#update-source lo0 RP/0/0/CPU0:R2(config-bgp-nbr)#end
- RMF Control
- CM-6
- Severity
- L
- CCI
- CCI-000366
- Version
- CISC-RT-000590
- Vuln IDs
-
- V-96781
- Rule IDs
-
- SV-105919r1_rule
Checks: C-95617r1_chk
Review the router configuration to determine if it is compliant with this requirement. Verify that a loopback address has been configured as shown in the following example: interface Loopback0 ip address 10.1.1.1 255.255.255.255 By default, routers will use its loopback address for LDP peering. If an address has not be configured on the loopback interface, it will use its physical interface connecting to the LDP peer. If the router-id command is specified that overrides this default behavior, verify that it is the IP address of the designated loopback interface as shown in the example below. mpls ldp router-id 10.1.1.1 If the router is not configured do use its loopback address for LDP peering, this is a finding.
Fix: F-102461r1_fix
Configure the router to use their loopback address as the source address for LDP peering sessions. As noted in the check content, the default behavior is to use its loopback address. RP/0/0/CPU0:R3(config)#mpls ldp router-id 10.1.1.1
- RMF Control
- CM-6
- Severity
- L
- CCI
- CCI-000366
- Version
- CISC-RT-000600
- Vuln IDs
-
- V-96783
- Rule IDs
-
- SV-105921r1_rule
Checks: C-95619r1_chk
OSPF Example router ospf 1 mpls ldp sync IS-IS Example router isis 1 net 49.0001.1234.1600.5531.00 interface GigabitEthernet0/0/0/1 address-family ipv4 unicast mpls ldp sync If the router is not configured to synchronize IGP and LDP, this is a finding.
Fix: F-102463r1_fix
Configure the MPLS router to synchronize IGP and LDP, minimizing packet loss when an IGP adjacency is established prior to LDP peers completing label exchange. OSPF Example RP/0/0/CPU0:R3(config)#router ospf 1 RP/0/0/CPU0:R3(config-ospf)#mpls ldp sync RP/0/0/CPU0:R3(config-ospf)#end IS-IS Example RP/0/0/CPU0:R3(config)#router isis 1 RP/0/0/CPU0:R3(config-isis)#interface g0/0/0/1 RP/0/0/CPU0:R3(config-isis-if)#address-family ipv4 unicast RP/0/0/CPU0:R3(config-isis-if-af)#mpls ldp sync RP/0/0/CPU0:R3(config-isis-if-af)#end
- RMF Control
- SC-5
- Severity
- L
- CCI
- CCI-001095
- Version
- CISC-RT-000610
- Vuln IDs
-
- V-96785
- Rule IDs
-
- SV-105923r1_rule
Checks: C-95621r1_chk
Review the router configuration to determine RSVP messages are rate limited. Step 1: Determine if MPLS TE is enabled on any interface as shown in the example below. mpls traffic-eng interface GigabitEthernet0/0/0/1 Step 2: If MPLS TE is enabled, verify that RSVP messages are rate limited on each interface. The example allows 50 messages per 500 milliseconds. rsvp interface GigabitEthernet0/0/0/1 signaling rate-limit rate 50 interval 500 Note: The command rsvp msg-pacing has been deprecated by the command ip rsvp signaling rate-limit command. If the router with RSVP-TE enabled does not have message pacing configured based on the link speed and input queue size of adjacent core routers, this is a finding.
Fix: F-102465r1_fix
Configure the router to rate limit RSVP messages as shown in the example. RP/0/0/CPU0:R3(config)#rsvp interface g0/0/0/1 RP/0/0/CPU0:R3(config-rsvp-if)#signaling rate-limit rate 50 interval 500 RP/0/0/CPU0:R3(config-rsvp-if)#end
- RMF Control
- CM-6
- Severity
- M
- CCI
- CCI-000366
- Version
- CISC-RT-000620
- Vuln IDs
-
- V-96787
- Rule IDs
-
- SV-105925r1_rule
Checks: C-95623r1_chk
Review the router configuration to verify that TTL propagation is disabled as shown in the example below. mpls ip-ttl-propagate disable If the MPLS router is not configured to disable TTL propagation, this is a finding.
Fix: F-102467r1_fix
Configure the MPLS router to disable TTL propagation as shown in the example below. RP/0/0/CPU0:R3(config)#mpls ip-ttl-propagate disable
- RMF Control
- CM-6
- Severity
- H
- CCI
- CCI-000366
- Version
- CISC-RT-000630
- Vuln IDs
-
- V-96789
- Rule IDs
-
- SV-105927r1_rule
Checks: C-95625r1_chk
Step 1: Review the design plan for deploying L3VPN and VRF-lite. Step 2: Review the design plan for deploying L3VPN and VRF-lite. Review all CE-facing interfaces and verify that the proper VRF is defined via the ip vrf forwarding command. In the example below, COI1 is bound to interface GigabitEthernet0/0/0/1, while COI2 is bound to GigabitEthernet0/0/0/2. interface GigabitEthernet0/0/0/1 description link to COI1 vrf COI1 ipv4 address x.1.34.12 255.255.255.252 ! interface GigabitEthernet0/0/0/2 description link to COI2 vrf COI2 ipv4 address x.1.22.12 255.255.255.252 If any VRFs are not bound to the appropriate physical or logical interface, this is a finding.
Fix: F-102469r1_fix
Configure the PE router to have each VRF bound to the appropriate physical or logical interfaces to maintain traffic separation between all MPLS L3VPNs.
- RMF Control
- CM-6
- Severity
- H
- CCI
- CCI-000366
- Version
- CISC-RT-000640
- Vuln IDs
-
- V-96791
- Rule IDs
-
- SV-105929r1_rule
Checks: C-95627r1_chk
Review the design plan for MPLS/L3VPN and VRF-lite to determine what RTs have been assigned for each VRF. Review the router configuration and verify that the correct RT is configured for each VRF. In the example below, route target 13:13 has been configured for COI1. vrf COI1 address-family ipv4 unicast import route-target 13:13 ! export route-target 13:13 ! ! ! If there are VRFs configured with the wrong RT, this is a finding.
Fix: F-102471r1_fix
Configure the router to have each VRF instance defined with the correct RT. RP/0/0/CPU0:R3(config)#vrf COI1 RP/0/0/CPU0:R3(config-vrf)#address-family ipv4 unicast RP/0/0/CPU0:R3(config-vrf-af)#import route-target 13:13 RP/0/0/CPU0:R3(config-vrf-af)#export route-target 13:13 RP/0/0/CPU0:R3(config-vrf-af)#end
- RMF Control
- CM-6
- Severity
- M
- CCI
- CCI-000366
- Version
- CISC-RT-000650
- Vuln IDs
-
- V-96793
- Rule IDs
-
- SV-105931r1_rule
Checks: C-95629r1_chk
Review the design plan for MPLS/L3VPN to determine what RD have been assigned for each VRF. Review the router configuration and verify that the correct RD is configured for each VRF. In the example below, route distinguisher 13:13 has been configured for COI1. router bgp nn address-family ipv4 unicast ! address-family vpnv4 unicast ! … … … ! vrf COI1 rd 13:13 address-family ipv4 unicast redistribute ospf 1 ! ! ! Note: This requirement is only applicable for MPLS VPN implementations. If the wrong RD has been configured for any VRF, this is a finding.
Fix: F-102473r1_fix
Configure the correct RD for each VRF. RP/0/0/CPU0:R3(config)#router bgp nn RP/0/0/CPU0:R3(config-bgp)#vrf COI1 RP/0/0/CPU0:R3(config-bgp-vrf)#rd 13:13
- RMF Control
- IA-3
- Severity
- M
- CCI
- CCI-001958
- Version
- CISC-RT-000660
- Vuln IDs
-
- V-96795
- Rule IDs
-
- SV-105933r1_rule
Checks: C-95631r1_chk
The Cisco router is not compliant with this requirement; hence, it is a finding. However, the severity level can be downgraded to a category 3 if the router is configured to authenticate targeted LDP sessions using MD5 as shown in the configuration example below. mpls ldp router-id 10.1.1.2 neighbor 10.1.1.1 password encrypted xxxxxxxxxxxxxxx neighbor 10.1.2.1 password encrypted xxxxxxxxxxxxxxx If the router is not configured to authenticate targeted LDP sessions using MD5, the finding will remain as a CAT II.
Fix: F-102475r1_fix
The severity level can be downgraded to a category 3 if the router is configured to authenticate targeted LDP sessions using MD5 as shown in the example below. RP/0/0/CPU0:R3(config)#mpls ldp RP/0/0/CPU0:R3(config-ldp)#neighbor 10.1.1.1 RP/0/0/CPU0:R3(config-ldp)#neighbor password clear xxxxxxxx RP/0/0/CPU0:R3(config-ldp)#neighbor 10.1.2.1 RP/0/0/CPU0:R3(config-ldp)#neighbor password clear xxxxxxxx RP/0/0/CPU0:R3(config-ldp)#commit
- RMF Control
- CM-6
- Severity
- H
- CCI
- CCI-000366
- Version
- CISC-RT-000670
- Vuln IDs
-
- V-96797
- Rule IDs
-
- SV-105935r1_rule
Checks: C-95633r1_chk
Verify that the correct pseudowire ID has been configured for the appropriate attachment circuit. In the example below GigabitEthernet0/0/0/1 is the CE-facing interface that is configured for VPWS. l2vpn pw-class ETHOM encapsulation mpls ! ! xconnect group COI1 p2p COI1-S1-S2 interface GigabitEthernet0/0/0/1 neighbor ipv4 10.1.12.4 pw-id 55 pw-class ETHOM ! ! ! ! If the correct pseudowire ID has not been configured on both routers, this is a finding.
Fix: F-102477r1_fix
Assign globally unique pseudowire IDs for each virtual circuit and configure the attachment circuits with the appropriate pseudowire ID. RP/0/0/CPU0:R3(config)#l2vpn RP/0/0/CPU0:R3(config-l2vpn)#xconnect group COI1 RP/0/0/CPU0:R3(config-l2vpn-xc)#p2p COI1-S1-S2 RP/0/0/CPU0:R3(config-l2vpn-xc-p2p)#interface g0/0/0/1 RP/0/0/CPU0:R3(config-l2vpn-xc-p2p)#neighbor 10.1.12.4 pw-id 55
- RMF Control
- CM-6
- Severity
- H
- CCI
- CCI-000366
- Version
- CISC-RT-000680
- Vuln IDs
-
- V-96799
- Rule IDs
-
- SV-105937r1_rule
Checks: C-95635r1_chk
Review the implementation plan and the VPN IDs assigned to customer VLANs for the VPLS deployment. Review the PE router configuration to verify that customer attachment circuits are associated to the appropriate VFI. In the example below, the attached circuit at interface GigabitEthernet0/0/0/2 is associated to VPN ID 110. interface GigabitEthernet0/0/0/2 l2transport … … … l2vpn pw-class ETH_O_MPLS encapsulation mpls transport-mode ethernet ! ! bridge group L2GROUP bridge-domain L2_BRIDGE_COI1 interface GigabitEthernet0/0/0/2 ! vfi VFI_COI1 vpn-id 101 neighbor 10.1.1.1 pw-id 55 pw-class ETH_O_MPLS ! neighbor 10.2.2.2 pw-id 55 pw-class ETH_O_MPLS ! ! ! ! If the attachment circuits have not been bound to VFI configured with the assigned VPN ID for each VLAN, this is a finding.
Fix: F-102479r1_fix
Assign globally unique VPN IDs for each customer using VPLS for carrier Ethernet services between multiple sites, and configure the attachment circuits to the appropriate VFI. RP/0/0/CPU0:R3(config)#l2vpn RP/0/0/CPU0:R3(config-l2vpn)#bridge group L2GROUP RP/0/0/CPU0:R3(config-l2vpn-bg)#bridge-domain L2_BRIDGE_COI1 RP/0/0/CPU0:R3(config-l2vpn-bg-bd)#interface GigabitEthernet0/0/0/2 RP/0/0/CPU0:R3(config-l2vpn-bg-bd-ac)#exit RP/0/0/CPU0:R3(config-l2vpn-bg-bd)#vfi VFI_COI1 RP/0/0/CPU0:R3(config-l2vpn-bg-bd-vfi)#vpn-id 101
- RMF Control
- CM-6
- Severity
- L
- CCI
- CCI-000366
- Version
- CISC-RT-000690
- Vuln IDs
-
- V-96801
- Rule IDs
-
- SV-105939r1_rule
Checks: C-95637r1_chk
Review the PE router configuration to verify that split horizon is enabled at each attachment circuit within each bridge domain as shown in the example below. bridge group L2GROUP bridge-domain L2_BRIDGE_COI1 interface GigabitEthernet0/0/0/2 split-horizon group ! If split horizon is not enabled, this is a finding. Note: This requirement is only applicable to a mesh VPLS topology. VPLS solves the loop problem by using a split-horizon rule which states that member PE routers of a VPLS must forward VPLS traffic only to the local attachment circuits when they receive the traffic from the other PE routers. In a ring VPLS, split horizon must be disabled so that a PE router can forward a packet received from one pseudowire to another pseudowire. To prevent the consequential loop, at least one span in the ring would not have a pseudowire for any given VPLS instance.
Fix: F-102481r1_fix
Enable split horizon on all PE routers deploying VPLS in a full-mesh configuration. RP/0/0/CPU0:R3(config)#l2vpn RP/0/0/CPU0:R3(config-l2vpn)#bridge group L2GROUP RP/0/0/CPU0:R3(config-l2vpn-bg)#bridge-domain L2_BRIDGE_COI1 RP/0/0/CPU0:R3(config-l2vpn-bg-bd)#interface GigabitEthernet0/0/0/2 RP/0/0/CPU0:R3(config-l2vpn-bg-bd-ac)#split-horizon group RP/0/0/CPU0:R3(config-l2vpn-bg-bd-ac)#end
- RMF Control
- SC-5
- Severity
- M
- CCI
- CCI-001095
- Version
- CISC-RT-000700
- Vuln IDs
-
- V-96803
- Rule IDs
-
- SV-105941r1_rule
Checks: C-95639r1_chk
Review the router configuration to verify that storm control is enabled on CE-facing interfaces deploying VPLS as shown in the example below. bridge group L2GROUP bridge-domain L2_BRIDGE_COI1 interface GigabitEthernet0/0/0/2 storm-control unknown-unicast kbps 1200 storm-control multicast kbps 1200 storm-control broadcast kbps 1200 split-horizon group ! If storm control is not enabled at a minimum for broadcast traffic, this is a finding.
Fix: F-102483r1_fix
Configure storm control for each CE-facing interface as shown in the example below. RP/0/0/CPU0:R3(config)#l2vpn RP/0/0/CPU0:R3(config-l2vpn)#bridge group L2GROUP RP/0/0/CPU0:R3(config-l2vpn-bg)# bridge-domain L2_BRIDGE_COI1 RP/0/0/CPU0:R3(config-l2vpn-bg-bd)#interface GigabitEthernet0/0/0/2 RP/0/0/CPU0:R3(config-l2vpn-bg-bd-ac)#storm-control broadcast kbps 1200 RP/0/0/CPU0:R3(config-l2vpn-bg-bd-ac)#storm-control multicast kbps 1200 RP/0/0/CPU0:R3(config-l2vpn-bg-bd-ac)#storm-control unknown-unicast kbps 1200 RP/0/0/CPU0:R3(config-l2vpn-bg-bd-ac)#end Note: The acceptable range is 10000000 -1000000000 for a gigabit ethernet interface, and 100000000-10000000000 for a ten gigabit interface. Storm control is not supported on most FastEthernet interfaces.
- RMF Control
- SC-5
- Severity
- L
- CCI
- CCI-002385
- Version
- CISC-RT-000710
- Vuln IDs
-
- V-96805
- Rule IDs
-
- SV-105943r1_rule
Checks: C-95641r1_chk
Review the router configuration to verify that IGMP or MLD snooping has been configured for IPv4 and IPv6 multicast traffic respectively for each VPLS bridge domain. l2vpn bridge group L2GROUP bridge-domain L2_BRIDGE_COI1 interface GigabitEthernet0/0/0/2 igmp snooping profile default If the router is not configured to implement IGMP or MLD snooping for each VPLS bridge domain, this is a finding.
Fix: F-102485r1_fix
Configure IGMP or MLD snooping for IPv4 and IPv6 multicast traffic respectively for each VPLS bridge domain. RP/0/0/CPU0:R3(config)#l2vpn RP/0/0/CPU0:R3(config-l2vpn)#bridge group L2GROUP RP/0/0/CPU0:R3(config-l2vpn-bg)# bridge-domain L2_BRIDGE_COI1 RP/0/0/CPU0:R3(config-l2vpn-bg-bd)#interface GigabitEthernet0/0/0/2 RP/0/0/CPU0:R3(config-l2vpn-bg-bd-ac)#igmp snooping profile default RP/0/0/CPU0:R3(config-l2vpn-bg-bd-ac)#end
- RMF Control
- SC-5
- Severity
- M
- CCI
- CCI-001094
- Version
- CISC-RT-000720
- Vuln IDs
-
- V-96807
- Rule IDs
-
- SV-105945r1_rule
Checks: C-95643r1_chk
Review the PE router configuration to determine if a MAC address limit has been set for each VPLS bridge domain. bridge group L2GROUP bridge-domain L2_BRIDGE_COI1 interface GigabitEthernet0/0/0/2 mac limit maximum nnnn ! ! If a limit has not been configured, this is a finding.
Fix: F-102487r1_fix
Configure a MAC address learning limit for each VPLS bridge domain. RP/0/0/CPU0:R3(config)#l2vpn RP/0/0/CPU0:R3(config-l2vpn)#bridge group L2GROUP RP/0/0/CPU0:R3(config-l2vpn-bg)#bridge-domain L2_BRIDGE_COI1 RP/0/0/CPU0:R3(config-l2vpn-bg-bd)#interface GigabitEthernet0/0/0/2 RP/0/0/CPU0:R3(config-l2vpn-bg-bd-ac)#mac limit maximum nnn RP/0/0/CPU0:R3(config-l2vpn-bg-bd-ac)#end
- RMF Control
- SC-7
- Severity
- H
- CCI
- CCI-001097
- Version
- CISC-RT-000730
- Vuln IDs
-
- V-96809
- Rule IDs
-
- SV-105947r1_rule
Checks: C-95645r1_chk
Step 1: Review the router configuration to verify that an ingress ACL is applied to all external or CE-facing interfaces. interface GigabitEthernet1/1/0/0 ipv4 address x.1.12.2 255.255.255.252 ipv4 access-group BLOCK_TO_CORE ingress Step 2: Verify that the ingress ACL discards and logs packets destined to the IP core address space. Ipv4 access-list BLOCK_TO_CORE 10 deny ipv4 any 10.1.x.0 0.0.255.255 log-input 20 permit ipv4 any any ! If the PE router is not configured to block any traffic with a destination address assigned to the IP core infrastructure, this is a finding. Note: Internet Control Message Protocol (ICMP) echo requests and traceroutes will be allowed to the edge from external adjacent neighbors.
Fix: F-102489r1_fix
Configure protection for the IP core to be implemented at the edges by blocking any traffic with a destination address assigned to the IP core infrastructure. Step 1: Configure an ingress ACL to discard and log packets destined to the IP core address space. RP/0/0/CPU0:R3(config)#Ipv4 access-list BLOCK_TO_CORE RP/0/0/CPU0:R3(config-ipv4-acl)#deny tcp any any eq tacacs log-input RP/0/0/CPU0:R3(config-ipv4-acl)#deny ipv4 any 10.1.x.0 0.0.255.255 log-input RP/0/0/CPU0:R3(config-ipv4-acl)#end Step 2: Apply the ACL inbound to all external or CE-facing interfaces. RP/0/0/CPU0:R3(config)#int g1/1/0/0 RP/0/0/CPU0:R3(config-if)#ipv4 access-group BLOCK_TO_CORE in RP/0/0/CPU0:R3(config-if)#end
- RMF Control
- SC-7
- Severity
- M
- CCI
- CCI-001097
- Version
- CISC-RT-000740
- Vuln IDs
-
- V-96811
- Rule IDs
-
- SV-105949r1_rule
Checks: C-95647r1_chk
Review the router configuration to determine if uRPF loose mode is enabled on all CE-facing interfaces. interface GigabitEthernet1/1/0/0 ip address x.1.12.2 255.255.255.252 ipv4 verify unicast source reachable-via any If uRPF loose mode is not enabled on all CE-facing interfaces, this is a finding.
Fix: F-102491r1_fix
Configure uRPF loose mode on all CE-facing interfaces as shown in the example RP/0/0/CPU0:R3(config)#int g1/1/0/0 RP/0/0/CPU0:R3(config-if)#ipv4 verify unicast source reachable-via any
- RMF Control
- SC-7
- Severity
- M
- CCI
- CCI-002403
- Version
- CISC-RT-000750
- Vuln IDs
-
- V-96813
- Rule IDs
-
- SV-105951r2_rule
Checks: C-95649r1_chk
In Cisco IOS XR, all IPv4 packets with any header option other than the "source-route" header options are dropped. By default, ipv4 source routing is disabled. Verify that the following command is not configured: ipv4 source-route If the router is not configured to drop all packets with IP options, this is a finding.
Fix: F-102493r1_fix
Configure the router to drop all packets with ipv4 source-route as shown below. RP/0/0/CPU0:R3(config)#no ipv4 source-route
- RMF Control
- SC-5
- Severity
- L
- CCI
- CCI-001095
- Version
- CISC-RT-000760
- Vuln IDs
-
- V-96815
- Rule IDs
-
- SV-105953r2_rule
Checks: C-95651r2_chk
Review the router configuration and verify that it has been configured to enforce a QoS policy in accordance with the QoS GIG Technical Profile (GTP-0009). Step 1: Verify that the class-maps are configured to match on DSCP values as shown in the configuration example below. class-map match-all VIDEO match dscp af41 end-class-map ! class-map match-all VOICE match dscp ef end-class-map ! class-map match-all C2_VOICE match dscp 47 end-class-map ! class-map match-all CONTROL_PLANE match dscp cs6 end-class-map ! class-map match-all PREFERRED_DATA match dscp af33 end-class-map ! Step 2: Verify that the policy map reserves the bandwidth for each traffic type as shown in the following example: policy-map QOS_POLICY class C2_VOICE bandwidth percent 10 ! class VOICE bandwidth percent 15 ! class VIDEO bandwidth percent 25 ! class CONTROL_PLANE bandwidth percent 10 ! class PREFERRED_DATA bandwidth percent 25 ! class class-default bandwidth percent 15 ! end-policy-map ! Step 3: Verify that an output service policy is bound to all interface as shown in the configuration example below. interface GigabitEthernet0/0/0/1 service-policy output QOS_POLICY ipv4 address x.1.24.2 255.255.255.252 ! interface GigabitEthernet0/0/0/2 service-policy output QOS_POLICY ipv4 address x.1.24.5 255.255.255.252 Note: Enclaves must mark or re-mark their traffic to be consistent with the DODIN backbone admission criteria to gain the appropriate level of service. A general DiffServ principle is to mark or trust traffic as close to the source as administratively and technically possible. However, certain traffic types might need to be re-marked before handoff to the DODIN backbone to gain admission to the correct class. If such re-marking is required, it is recommended that the re-marking be performed at the CE egress edge. Note: The GTP QOS document can be downloaded via the following link: https://intellipedia.intelink.gov/wiki/Portal:GIG_Technical_Guidance/GTG_GTPs/GTP_Development_List If the router is not configured to enforce a QoS policy in accordance with the QoS GIG Technical Profile, this is a finding.
Fix: F-102495r2_fix
Configure a QoS policy in accordance with the QoS GIG Technical Profile. Step 1: Configure class-maps to match on DSCP values as shown in the configuration example below. RP/0/0/CPU0:R2(config-cmap)#class-map match-all C2_VOICE RP/0/0/CPU0:R2(config-cmap)#match dscp 47 RP/0/0/CPU0:R2(config-cmap)#class-map match-all VOICE RP/0/0/CPU0:R2(config-cmap)#match dscp ef RP/0/0/CPU0:R2(config-cmap)#class-map match-all VIDEO RP/0/0/CPU0:R2(config-cmap)#match dscp af41 RP/0/0/CPU0:R2(config-cmap)#class-map match-all CONTROL_PLANE RP/0/0/CPU0:R2(config-cmap)#match dscp cs6 RP/0/0/CPU0:R2(config-cmap)#class-map match-all PREFERRED_DATA RP/0/0/CPU0:R2(config-cmap)#match dscp af33 RP/0/0/CPU0:R2(config-cmap)#exit Step 2: Configure a policy map to be applied to the core-layer-facing interface that reserves the bandwidth for each traffic type as shown in the example below. RP/0/0/CPU0:R2(config-pmap)#policy-map QOS_POLICY RP/0/0/CPU0:R2(config-pmap)#class C2_VOICE RP/0/0/CPU0:R2(config-pmap-c)#bandwidth percent 10 RP/0/0/CPU0:R2(config-pmap-c)#class VOICE RP/0/0/CPU0:R2(config-pmap-c)#bandwidth percent 15 RP/0/0/CPU0:R2(config-pmap-c)#class VIDEO RP/0/0/CPU0:R2(config-pmap-c)#bandwidth percent 25 RP/0/0/CPU0:R2(config-pmap-c)#class CONTROL_PLANE RP/0/0/CPU0:R2(config-pmap-c)#bandwidth percent 10 RP/0/0/CPU0:R2(config-pmap-c)#class PREFERRED_DATA RP/0/0/CPU0:R2(config-pmap-c)#bandwidth percent 25 RP/0/0/CPU0:R2(config-pmap-c)#class class-default RP/0/0/CPU0:R2(config-pmap-c)#bandwidth percent 15 RP/0/0/CPU0:R2(config-pmap-c)#exit Step 3: Apply the output service policy to the core-layer-facing interface as shown in the configuration example below. RP/0/0/CPU0:R2(config)#int g0/0/0/1 RP/0/0/CPU0:R2(config-if)#service-policy output QOS_POLICY RP/0/0/CPU0:R2(config-if)#exit RP/0/0/CPU0:R2(config)#int g0/0/0/2 RP/0/0/CPU0:R2(config-if)#service-policy output QOS_POLICY RP/0/0/CPU0:R2(config-if)#end Note: The GTP QOS document can be downloaded via the following link: https://intellipedia.intelink.gov/wiki/Portal:GIG_Technical_Guidance/GTG_GTPs/GTP_Development_List
- RMF Control
- SC-5
- Severity
- L
- CCI
- CCI-001095
- Version
- CISC-RT-000770
- Vuln IDs
-
- V-96817
- Rule IDs
-
- SV-105955r2_rule
Checks: C-95653r3_chk
Review the router configuration and verify that it has been configured to enforce a QoS policy in accordance with the QoS GIG Technical Profile (GTP-0009). Step 1: Verify that the class-maps are configured to match on DSCP values as shown in the configuration example below. class-map match-all VIDEO match dscp af41 end-class-map ! class-map match-all VOICE match dscp ef end-class-map ! class-map match-all C2_VOICE match dscp 47 end-class-map ! class-map match-all CONTROL_PLANE match dscp cs6 end-class-map ! class-map match-all PREFERRED_DATA match dscp af33 end-class-map ! Step 2: Verify that the policy map reserves the bandwidth for each traffic type as shown in the following example: policy-map QOS_POLICY class C2_VOICE bandwidth percent 10 ! class VOICE bandwidth percent 15 ! class VIDEO bandwidth percent 25 ! class CONTROL_PLANE bandwidth percent 10 ! class PREFERRED_DATA bandwidth percent 25 ! class class-default bandwidth percent 15 ! end-policy-map ! Step 3: Verify that an output service policy is bound to all interfaces as shown in the configuration example below. interface GigabitEthernet0/0/0/1 service-policy output QOS_POLICY ipv4 address x.1.24.2 255.255.255.252 ! interface GigabitEthernet0/0/0/2 service-policy output QOS_POLICY ipv4 address x.1.24.5 255.255.255.252 Note: Enclaves must mark or re-mark their traffic to be consistent with the DODIN backbone admission criteria to gain the appropriate level of service. A general DiffServ principle is to mark or trust traffic as close to the source as administratively and technically possible. However, certain traffic types might need to be re-marked before handoff to the DODIN backbone to gain admission to the correct class. If such re-marking is required, it is recommended that the re-marking be performed at the CE egress edge. Note: The GTP QOS document (GTP-0009) can be downloaded via the following link: https://intellipedia.intelink.gov/wiki/Portal:GIG_Technical_Guidance/GTG_GTPs/GTP_Development_List If the router is not configured to enforce a QoS policy in accordance with the QoS GIG Technical Profile, this is a finding.
Fix: F-102497r2_fix
Configure a QoS policy in accordance with the QoS GIG Technical Profile. Step 1: Configure class-maps to match on DSCP values as shown in the configuration example below. RP/0/0/CPU0:R2(config-cmap)#class-map match-all C2_VOICE RP/0/0/CPU0:R2(config-cmap)#match dscp 47 RP/0/0/CPU0:R2(config-cmap)#class-map match-all VOICE RP/0/0/CPU0:R2(config-cmap)#match dscp ef RP/0/0/CPU0:R2(config-cmap)#class-map match-all VIDEO RP/0/0/CPU0:R2(config-cmap)#match dscp af41 RP/0/0/CPU0:R2(config-cmap)#class-map match-all CONTROL_PLANE RP/0/0/CPU0:R2(config-cmap)#match dscp cs6 RP/0/0/CPU0:R2(config-cmap)#class-map match-all PREFERRED_DATA RP/0/0/CPU0:R2(config-cmap)#match dscp af33 RP/0/0/CPU0:R2(config-cmap)#exit Step 2: Configure a policy map to be applied to the core-layer-facing interface that reserves the bandwidth for each traffic type as shown in the example below. RP/0/0/CPU0:R2(config-pmap)#policy-map QOS_POLICY RP/0/0/CPU0:R2(config-pmap)#class C2_VOICE RP/0/0/CPU0:R2(config-pmap-c)#bandwidth percent 10 RP/0/0/CPU0:R2(config-pmap-c)#class VOICE RP/0/0/CPU0:R2(config-pmap-c)#bandwidth percent 15 RP/0/0/CPU0:R2(config-pmap-c)#class VIDEO RP/0/0/CPU0:R2(config-pmap-c)#bandwidth percent 25 RP/0/0/CPU0:R2(config-pmap-c)#class CONTROL_PLANE RP/0/0/CPU0:R2(config-pmap-c)#bandwidth percent 10 RP/0/0/CPU0:R2(config-pmap-c)#class PREFERRED_DATA RP/0/0/CPU0:R2(config-pmap-c)#bandwidth percent 25 RP/0/0/CPU0:R2(config-pmap-c)#class class-default RP/0/0/CPU0:R2(config-pmap-c)#bandwidth percent 15 RP/0/0/CPU0:R2(config-pmap-c)#exit Step 3: Apply the output service policy to the core-layer-facing interface as shown in the configuration example below. RP/0/0/CPU0:R2(config)#int g0/0/0/1 RP/0/0/CPU0:R2(config-if)#service-policy output QOS_POLICY RP/0/0/CPU0:R2(config-if)#exit RP/0/0/CPU0:R2(config)#int g0/0/0/2 RP/0/0/CPU0:R2(config-if)#service-policy output QOS_POLICY RP/0/0/CPU0:R2(config-if)#end Note: The GTP QOS document (GTP-0009) can be downloaded via the following link: https://intellipedia.intelink.gov/wiki/Portal:GIG_Technical_Guidance/GTG_GTPs/GTP_Development_List
- RMF Control
- SC-5
- Severity
- M
- CCI
- CCI-001095
- Version
- CISC-RT-000780
- Vuln IDs
-
- V-96819
- Rule IDs
-
- SV-105957r2_rule
Checks: C-95655r1_chk
Step 1: Verify that a class map has been configured for the Scavenger class as shown in the example below. class-map match-all SCAVENGER match dscp cs1 end-class-map Step 2: Verify that the policy map includes the SCAVENGER class with low priority as shown in the following example below. policy-map QOS_POLICY class C2_VOICE bandwidth percent 10 ! class VOICE bandwidth percent 15 ! class VIDEO bandwidth percent 25 ! class CONTROL_PLANE bandwidth percent 10 ! class PREFERRED_DATA bandwidth percent 25 ! class SCAVENGER bandwidth percent 5 ! class class-default bandwidth percent 10 ! end-policy-map Note: Traffic out of profile must be marked at the customer access layer or CE egress edge. If the policy map does not include the SCAVENGER class with low priority, this is a finding.
Fix: F-102499r1_fix
Step 1: Configure a class map for the SCAVENGER class. RP/0/0/CPU0:R2(config)#class-map match-all SCAVENGER RP/0/0/CPU0:R2(config-cmap)#match dscp cs1 RP/0/0/CPU0:R2(config-cmap)#exit Step 2: Add the SCAVENGER class to the policy map as shown in the example below. RP/0/0/CPU0:R2(config)#policy-map QOS_POLICY RP/0/0/CPU0:R2(config-pmap)#no class class-default RP/0/0/CPU0:R2(config-pmap)#class SCAVENGER RP/0/0/CPU0:R2(config-pmap-c)#bandwidth percent 5 RP/0/0/CPU0:R2(config-pmap-c)#class class-default RP/0/0/CPU0:R2(config-pmap-c)#bandwidth percent 10 RP/0/0/CPU0:R2(config-pmap-c)#end
- RMF Control
- AC-4
- Severity
- M
- CCI
- CCI-001414
- Version
- CISC-RT-000790
- Vuln IDs
-
- V-96821
- Rule IDs
-
- SV-105959r1_rule
Checks: C-95657r1_chk
Step 1: Review the network's multicast topology diagram. Step 2: Review the router configuration to verify that only the interfaces as shown in the multicast topology diagram are enabled as shown in the example below. ! router pim address-family ipv4 interface GigabitEthernet0/0/0/0 enable ! interface GigabitEthernet0/0/0/1 enable ! ! If an interface is not required to support multicast routing and it is enabled, this is a finding.
Fix: F-102501r1_fix
Document all enabled interfaces for PIM in the network's multicast topology diagram. Disable support for PIM on interfaces that are not required to support it. RP/0/0/CPU0:R2(config)#router pim RP/0/0/CPU0:R2(config-pim)#address-family ipv4 RP/0/0/CPU0:R2(config-pim-default-ipv4)#int g0/0/0/1 RP/0/0/CPU0:R2(config-pim-ipv4-if)#disable RP/0/0/CPU0:R2(config-pim-ipv4-if)#end
- RMF Control
- AC-4
- Severity
- M
- CCI
- CCI-001414
- Version
- CISC-RT-000800
- Vuln IDs
-
- V-96823
- Rule IDs
-
- SV-105961r1_rule
Checks: C-95659r2_chk
This requirement is not applicable for the DODIN Backbone. Step 1: Verify all interfaces enabled for PIM have a neighbor ACL bound to the interface as shown in the example below. router pim address-family ipv4 interface GigabitEthernet0/0/0/1 enable neighbor-filter PIM_NEIGHBOR_1 ! interface GigabitEthernet0/0/0/2 enable neighbor-filter PIM_NEIGHBOR_2 ! ! ! Step 2: Review the configured ACL for filtering PIM neighbors as shown in the example below. ipv4 access-list PIM_NEIGHBOR_1 10 permit ipv4 host 10.1.1.2 any ! ipv4 access-list PIM_NEIGHBOR_2 10 permit ipv4 host 10.1.2.8 any ! If PIM neighbor ACLs are not bound to all interfaces that have PIM enabled, this is a finding.
Fix: F-102503r1_fix
This requirement is not applicable for the DODIN Backbone. Configure neighbor ACLs to only accept PIM control plane traffic from documented PIM neighbors. Bind neighbor ACLs to all PIM enabled interfaces. Step 1: Configure ACL for PIM neighbors. RP/0/0/CPU0:R2(config)#ipv4 access-list PIM_NEIGHBOR_1 RP/0/0/CPU0:R2(config-ipv4-acl)#permit ipv4 host 10.1.1.2 any RP/0/0/CPU0:R2(config-ipv4-acl)#exit Step 2: Apply the ACL to all interfaces enabled for PIM. RP/0/0/CPU0:R2(config)#router pim RP/0/0/CPU0:R2(config-pim)#address-family ipv4 RP/0/0/CPU0:R2(config-pim-default-ipv4)#int g0/0/0/1 RP/0/0/CPU0:R2(config-pim-ipv4-if)#neighbor-filter PIM_NEIGHBOR_1 RP/0/0/CPU0:R2(config-pim-ipv4-if)#exit RP/0/0/CPU0:R2(config-pim-default-ipv4)#int g0/0/0/2 RP/0/0/CPU0:R2(config-pim-ipv4-if)#neighbor-filter PIM_NEIGHBOR_2 RP/0/0/CPU0:R2(config-pim-ipv4-if)#end
- RMF Control
- AC-4
- Severity
- L
- CCI
- CCI-001414
- Version
- CISC-RT-000810
- Vuln IDs
-
- V-96825
- Rule IDs
-
- SV-105963r1_rule
Checks: C-95661r1_chk
Review the router configuration and verify that admin-scope multicast traffic is blocked at the external edge as shown in the example below. ipv4 access-list MULTICAST_SCOPE 10 deny ipv4 239.0.0.0 0.255.255.255 any 20 permit ipv4 any any … … … multicast-routing address-family ipv4 interface GigabitEthernet0/0/0/1 enable boundary MULTICAST_SCOPE ! interface GigabitEthernet0/0/0/2 enable ! ! ! If the router is not configured to establish boundaries for administratively scoped multicast traffic, this is a finding.
Fix: F-102505r1_fix
Step 1: Configure the ACL to deny packets with multicast administratively scoped destination addresses as shown in the example below. RP/0/0/CPU0:R2(config)#Ipv4 access-list MULTICAST_SCOPE RP/0/0/CPU0:R2(config-ipv4-acl)#deny 239.0.0.0 0.255.255.255 RP/0/0/CPU0:R2(config-ipv4-acl)#permit any Step 2: Apply the multicast boundary at the appropriate interfaces as shown in the example below. RP/0/0/CPU0:R2(config)#multicast-routing RP/0/0/CPU0:R2(config-mcast)#address-family ipv4 RP/0/0/CPU0:R2(config-mcast-default-ipv4)#int g0/0/0/1 RP/0/0/CPU0:R2(config-mcast-default-ipv4-if)#boundary MULTICAST_SCOPE RP/0/0/CPU0:R2(config-mcast-default-ipv4-if)#end
- RMF Control
- SC-5
- Severity
- L
- CCI
- CCI-002385
- Version
- CISC-RT-000820
- Vuln IDs
-
- V-96827
- Rule IDs
-
- SV-105965r1_rule
Checks: C-95663r2_chk
The Cisco router does not have a mechanism to limit the multicast forwarding cache. However, the risk associated with this requirement can be fully mitigated by configuring the router to: 1. Filter PIM register messages. 2. Rate limiting the number of PIM register messages. 3. Accept MSDP packets only from known MSDP peers. Step 1: Verify that the RP router is configured to filter PIM register messages for any undesirable multicast groups and sources. The example below will deny any multicast streams for groups 239.5.0.0/16 and allow from only sources 10.1.2.6 and 10.1.2.7. ipv4 access-list PIM_REGISTER_FILTER 10 deny ipv4 any 239.5.0.0 0.0.255.255 20 permit ipv4 host 10.1.2.6 any 30 permit ipv4 host 10.1.2.7 any 40 deny ipv4 any any … … … router pim address-family ipv4 rp-address 2.2.2.2 accept-register PIM_REGISTER_FILTER Step 2: Verify that the router is configured to rate limiting the number of PIM register messages as shown in the example below. router pim address-family ipv4 allow-rp group-list FILTER_PIM_JOINS rp-address 10.2.2.2 accept-register PIM_REGISTER_FILTER maximum register-states 250 Note: The maximum register-states command is used to set an upper limit for PIM register states. When the limit is reached, PIM discontinues route creation from PIM register messages. If not configured, the default is 2000 which would be an overage for a small to average size multicast deployment. Step 3: Review the router configuration to determine if there is a receive path or interface filter to only accept MSDP packets from known MSDP peers as shown in the example below. Step 3a: Determine which interfaces would be peering MSDP with an external router by the configured peer addresses as shown in the example below. router msdp peer x.14.2.1 remote-as nn ! peer x.15.3.5 remote-as nn ! ! Step 3b: Verify that interfaces used for MSDP peering have an inbound ACL as shown in the example. interface GigabitEthernet0/0/0/1 ipv4 address x.14.2.2 255.255.255.252 ipv4 access-group EXTERNAL_ACL_INBOUND ingress Step 3c: Verify that the ACL restricts MSDP peering to only known sources. ipv4 access-list EXTERNAL_ACL_INBOUND 10 permit tcp host x.1.28.2 host x.1.28.8 eq 639 20 deny tcp any host x.1.28.8 eq 639 log 30 permit tcp host x.1.28.2 host x.1.28.8 eq bgp 40 permit tcp host x.1.28.2 eq bgp host x.1.28.8 50 permit pim host x.1.28.2 host x.1.28.8 60 permit tcp any any established … … … 140 deny ipv4 any any log Note: MSDP connections is via TCP port 639 If the RP router is not configured to filter PIM register messages, rate limiting the number of PIM register messages, and accept MSDP packets only from known MSDP peers, this is a finding.
Fix: F-102507r1_fix
The risk associated with this requirement can be fully mitigated by configuring the router to filter PIM register messages, rate limiting the number of PIM register messages, and accept MSDP packets only from known MSDP peers. Step 1: Configure the router to filter PIM register messages received from a multicast DR for any undesirable multicast groups and sources. The example below will deny any multicast streams for groups 239.5.0.0/16 and allow from only sources 10.1.2.6 and 10.1.2.7. RP/0/0/CPU0:R2(config)#ipv4 access-list PIM_REGISTER_FILTER RP/0/0/CPU0:R2(config-ipv4-acl)#deny ipv4 any 239.5.0.0 0.0.255.255 RP/0/0/CPU0:R2(config-ipv4-acl)#permit ipv4 host 10.1.2.6 any RP/0/0/CPU0:R2(config-ipv4-acl)#permit ipv4 host 10.1.2.7 any RP/0/0/CPU0:R2(config-ipv4-acl)#deny ipv4 any any RP/0/0/CPU0:R2(config-ipv4-acl)#exit RP/0/0/CPU0:R2(config)#router pim RP/0/0/CPU0:R2(config-pim)#address-family ipv4 RP/0/0/CPU0:R2(config-pim-default-ipv4)#accept-register PIM_REGISTER_FILTER RP/0/0/CPU0:R2(config-pim-default-ipv4)#end Step 2: Configure the RP to rate limit the number of multicast register messages. RP/0/0/CPU0:R2(config)#router pim RP/0/0/CPU0:R2(config-pim)#address-family ipv4 RP/0/0/CPU0:R2(config-pim-default-ipv4)#maximum register-states 250 RP/0/0/CPU0:R2(config-pim-default-ipv4)#end Step 3: Configure the receive path or interface ACLs to only accepts MSDP packets from known MSDP peers. RP/0/0/CPU0:R2(config)#ipv4 access-list EXTERNAL_ACL_INBOUND RP/0/0/CPU0:R2(config-ipv4-acl)#permit tcp host x.1.28.2 host x.1.28.8 eq 639 RP/0/0/CPU0:R2(config-ipv4-acl)#deny tcp any host x.1.28.8 eq 639 log RP/0/0/CPU0:R2(config-ipv4-acl)#permit tcp host x.1.28.2 host x.1.28.8 eq bgp RP/0/0/CPU0:R2(config-ipv4-acl)#permit tcp host x.1.28.2 eq bgp host x.1.28.8 RP/0/0/CPU0:R2(config-ipv4-acl)#permit pim host x.1.28.2 host x.1.28.8 RP/0/0/CPU0:R2(config-ipv4-acl)#permit tcp any any established … … … RP/0/0/CPU0:R2(config-ipv4-acl)#deny ip any any log
- RMF Control
- AC-4
- Severity
- L
- CCI
- CCI-001414
- Version
- CISC-RT-000830
- Vuln IDs
-
- V-96829
- Rule IDs
-
- SV-105967r1_rule
Checks: C-95665r1_chk
Verify that the RP router is configured to filter PIM register messages. The example below will deny any multicast streams for groups 239.5.0.0/16 and allow from only sources 10.1.2.6 and 10.1.2.7. ipv4 access-list PIM_REGISTER_FILTER 10 deny ipv4 any 239.5.0.0 0.0.255.255 20 permit ipv4 host 10.1.2.6 any 30 permit ipv4 host 10.1.2.7 any 40 deny ipv4 any any … … … router pim address-family ipv4 rp-address 2.2.2.2 accept-register PIM_REGISTER_FILTER If the RP router peering with PIM-SM routers is not configured with a policy to block registration messages for any undesirable multicast groups and sources, this is a finding.
Fix: F-102509r1_fix
Configure the router to filter PIM register messages received from a multicast DR for any undesirable multicast groups and sources. The example below will deny any multicast streams for groups 239.5.0.0/16 and allow from only sources 10.1.2.6 and 10.1.2.7. RP/0/0/CPU0:R2(config)#ipv4 access-list PIM_REGISTER_FILTER RP/0/0/CPU0:R2(config-ipv4-acl)#deny ipv4 any 239.5.0.0 0.0.255.255 RP/0/0/CPU0:R2(config-ipv4-acl)#permit ipv4 host 10.1.2.6 any RP/0/0/CPU0:R2(config-ipv4-acl)#permit ipv4 host 10.1.2.7 any RP/0/0/CPU0:R2(config-ipv4-acl)#deny ipv4 any any RP/0/0/CPU0:R2(config-ipv4-acl)#exit RP/0/0/CPU0:R2(config)#router pim RP/0/0/CPU0:R2(config-pim)#address-family ipv4 RP/0/0/CPU0:R2(config-pim-default-ipv4)#accept-register PIM_REGISTER_FILTER RP/0/0/CPU0:R2(config-pim-default-ipv4)#end
- RMF Control
- AC-4
- Severity
- L
- CCI
- CCI-001414
- Version
- CISC-RT-000840
- Vuln IDs
-
- V-96831
- Rule IDs
-
- SV-105969r1_rule
Checks: C-95667r1_chk
Verify that the RP router is configured to filter PIM join messages for any undesirable multicast groups. In the example below, groups from 239.8.0.0/16 are no allowed. ipv4 access-list FILTER_PIM_JOINS 10 deny ipv4 239.8.0.0 0.0.255.255 any 20 permit ipv4 any any … … … router pim address-family ipv4 allow-rp group-list FILTER_PIM_JOINS If the RP is not configured to filter join messages received from the DR for any undesirable multicast groups, this is a finding.
Fix: F-102511r1_fix
Configure the RP to filter PIM join messages for any undesirable multicast groups as shown in the example below. RP/0/0/CPU0:R2(config)#ipv4 access-list FILTER_PIM_JOINS RP/0/0/CPU0:R2(config-ipv4-acl)#deny 239.8.0.0 0.0.255.255 RP/0/0/CPU0:R2(config-ipv4-acl)#permit any RP/0/0/CPU0:R2(config-ipv4-acl)#exit RP/0/0/CPU0:R2(config)#router pim RP/0/0/CPU0:R2(config-pim)#address-family ipv4 RP/0/0/CPU0:R2(config-pim-default-ipv4)#allow-rp group-list FILTER_PIM_JOINS RP/0/0/CPU0:R2(config-pim-default-ipv4)#end
- RMF Control
- SC-5
- Severity
- M
- CCI
- CCI-002385
- Version
- CISC-RT-000850
- Vuln IDs
-
- V-96833
- Rule IDs
-
- SV-105971r1_rule
Checks: C-95669r1_chk
Review the configuration of the RP to verify that it is limiting the number of PIM register states as shown in the example. router pim address-family ipv4 allow-rp group-list FILTER_PIM_JOINS rp-address 10.2.2.2 accept-register PIM_REGISTER_FILTER maximum register-states 250 Note: The maximum register-states command is used to set an upper limit for PIM register states. When the limit is reached, PIM discontinues route creation from PIM register messages. If not configured, the default is 2000 which would be an overage for a small to average size multicast deployment. If the RP is not limiting PIM register states, this is a finding.
Fix: F-102513r1_fix
Configure the RP to rate limit the number of multicast register states. RP/0/0/CPU0:R2(config)#router pim RP/0/0/CPU0:R2(config-pim)#address-family ipv4 RP/0/0/CPU0:R2(config-pim-default-ipv4)#maximum register-states 250 RP/0/0/CPU0:R2(config-pim-default-ipv4)#end
- RMF Control
- SC-7
- Severity
- L
- CCI
- CCI-002403
- Version
- CISC-RT-000860
- Vuln IDs
-
- V-96835
- Rule IDs
-
- SV-105973r1_rule
Checks: C-95671r1_chk
Review the configuration of the DR to verify that it is filtering IGMP or MLD Membership Report messages, allowing hosts to join only those groups that have been approved. Step 1: Verify that all host facing interfaces are configured to filter IGMP Membership Report messages (IGMP joins) as shown in the example below. router igmp interface GigabitEthernet0/0/1/0 access-group IGMP_JOIN_FILTER ! interface GigabitEthernet0/0/1/1 access-group IGMP_JOIN_FILTER ! Step 2: Verify that the ACL denies unauthorized groups or permits only authorized groups. The example below denies all groups from 239.8.0.0/16 range. ipv4 access-list IGMP_JOIN_FILTER 10 deny ipv4 239.8.0.0 0.0.255.255 any 20 permit ipv4 any any ! Note: This requirement is only applicable to Source Specific Multicast (SSM) implementation. This requirement is not applicable to Any Source Multicast (ASM) since the filtering is being performed by the Rendezvous Point router. If the DR is not filtering IGMP or MLD Membership Report messages, this is a finding.
Fix: F-102515r1_fix
Configure the DR to filter the IGMP or MLD Membership Report messages to allow hosts to join only those multicast groups that have been approved. Step 1: Configure the ACL to filter IGMP Membership Report messages as shown in the example. RP/0/0/CPU0:R5(config)#ipv4 access-list IGMP_JOIN_FILTER RP/0/0/CPU0:R5(config-ipv4-acl)#deny 239.8.0.0 0.0.255.255 RP/0/0/CPU0:R5(config-ipv4-acl)#exit Step 2: Apply the filter to all host facing interfaces. RP/0/0/CPU0:R5(config)#router igmp RP/0/0/CPU0:R5(config-igmp)#interface g0/0/1/0 RP/0/0/CPU0:R5(config-igmp-default-if)#access-group IGMP_JOIN_FILTER RP/0/0/CPU0:R5(config-igmp-default-if)#exit RP/0/0/CPU0:R5(config-igmp)#interface g0/0/1/1 RP/0/0/CPU0:R5(config-igmp-default-if)#end
- RMF Control
- SC-7
- Severity
- M
- CCI
- CCI-002403
- Version
- CISC-RT-000870
- Vuln IDs
-
- V-96837
- Rule IDs
-
- SV-105975r1_rule
Checks: C-95673r1_chk
Review the configuration of the DR to verify that it is filtering IGMP or MLD report messages, allowing hosts to only join multicast groups from sources that have been approved. Step 1: Verify that all host facing interfaces are configured to filter IGMP Membership Report messages (IGMP joins) as shown in the example below. router igmp interface GigabitEthernet0/0/1/0 access-group IGMP_JOIN_FILTER ! interface GigabitEthernet0/0/1/1 access-group IGMP_JOIN_FILTER ! Step 2: Verify that the ACL denies unauthorized sources or allows only authorized sources. The example below denies all groups from 232.8.0.0/16 range and permits sources only from the x.0.0.0/8 network. ipv4 access-list IGMP_JOIN_FILTER 10 deny ipv4 any 232.8.0.0 0.0.255.255 20 permit ipv4 x.0.0.0 0.255.255.255 any 30 deny ipv4 any any ! Note: This requirement is only applicable to Source Specific Multicast (SSM) implementation. If the DR is not filtering IGMP or MLD report messages, this is a finding.
Fix: F-102517r1_fix
Configure the DR to filter the IGMP and MLD report messages to allow hosts to join only those multicast groups from sources that have been approved as shown in the example. Step 1: Configure the access list to filter multicast joins as shown in the example below. RP/0/0/CPU0:R2(config)#ipv4 access-list IGMP_JOIN_FILTER RP/0/0/CPU0:R2(config-ipv4-acl)#deny ip any 232.8.0.0 0.0.255.255 RP/0/0/CPU0:R2(config-ipv4-acl)#permit ip x.0.0.0 0.255.255.255 any RP/0/0/CPU0:R2(config-ipv4-acl)#deny ip any any Step 2: Apply the filter to all host facing interfaces. RP/0/0/CPU0:R5(config)#router igmp RP/0/0/CPU0:R5(config-igmp)#interface g0/0/1/0 RP/0/0/CPU0:R5(config-igmp-default-if)#access-group IGMP_JOIN_FILTER RP/0/0/CPU0:R5(config-igmp-default-if)#exit RP/0/0/CPU0:R5(config-igmp)#interface g0/0/1/1 RP/0/0/CPU0:R5(config-igmp-default-if)#end
- RMF Control
- SC-5
- Severity
- M
- CCI
- CCI-002385
- Version
- CISC-RT-000880
- Vuln IDs
-
- V-96839
- Rule IDs
-
- SV-105977r1_rule
Checks: C-95675r1_chk
Review the DR configuration to verify that it is limiting the number of mroute states via IGMP or MLD. Verify IGMP limits have been configured globally or on each host-facing interface via the ip igmp limit command as shown in the example. router igmp interface GigabitEthernet0/0/0/0 access-group IGMP_JOIN_FILTER ! interface GigabitEthernet0/0/0/1 access-group IGMP_JOIN_FILTER ! maximum groups 200 !Note: After the maximum groups value is met, all additional memberships learned are ignored. If not configured, the default is 5000 which would be an overage for a small to average size multicast deployment. If the DR is not limiting multicast join requests via IGMP or MLD on a global or interfaces basis, this is a finding.
Fix: F-102519r1_fix
Configure the DR on a global or interface basis to limit the number of mroute states resulting from IGMP or MLD membership reports. RP/0/0/CPU0:R5(config)#router igmp RP/0/0/CPU0:R2(config-igmp)#maximum groups 200 RP/0/0/CPU0:R5(config-igmp)#end
- RMF Control
- SC-5
- Severity
- M
- CCI
- CCI-002385
- Version
- CISC-RT-000890
- Vuln IDs
-
- V-96841
- Rule IDs
-
- SV-105979r1_rule
Checks: C-95677r1_chk
Review the DR configuration to verify that the SPT switchover threshold is increased (default is "0") or set to infinity (never switch over). router pim address-family ipv4 … … … spt-threshold infinity If the DR is not configured to increase the SPT threshold or set to infinity to minimalize (S, G) state, this is a finding.
Fix: F-102521r1_fix
Configure the DR to increase the SPT threshold or set it to infinity to minimalize (S, G) state within the multicast topology where ASM is deployed. RP/0/0/CPU0:R2(config)#router pim RP/0/0/CPU0:R2(config-pim)#address-family ipv4 RP/0/0/CPU0:R2(config-pim-default-ipv4)#spt-threshold infinity RP/0/0/CPU0:R2(config-pim-default-ipv4)#end
- RMF Control
- SC-7
- Severity
- M
- CCI
- CCI-002403
- Version
- CISC-RT-000900
- Vuln IDs
-
- V-96843
- Rule IDs
-
- SV-105981r1_rule
Checks: C-95679r1_chk
Review the router configuration to determine if there is a receive path or interface filter to only accept MSDP packets from known MSDP peers. Step 1: Determine which interfaces would be peering MSDP with an external router by the configured peer addresses as shown in the example below. router msdp peer x.14.2.1 remote-as nn ! peer x.15.3.5 remote-as nn ! ! Step 2: Verify that interfaces used for MSDP peering have an inbound ACL as shown in the example. interface GigabitEthernet0/0/0/1 ipv4 address x.14.2.2 255.255.255.252 ipv4 access-group EXTERNAL_ACL_INBOUND ingress Step 3: Verify that the ACL restricts MSDP peering to only known sources. ipv4 access-list EXTERNAL_ACL_INBOUND 10 permit tcp host x.1.28.2 host x.1.28.8 eq 639 20 deny tcp any host x.1.28.8 eq 639 log 30 permit tcp host x.1.28.2 host x.1.28.8 eq bgp 40 permit tcp host x.1.28.2 eq bgp host x.1.28.8 50 permit pim host x.1.28.2 host x.1.28.8 60 permit tcp any any established … … … 140 deny ipv4 any any log Note: MSDP connections is via TCP port 639 If the router is not configured to only accept MSDP packets from known MSDP peers, this is a finding.
Fix: F-102523r2_fix
Configure the interface ACLs to only accept MSDP packets from known MSDP peers. RP/0/0/CPU0:R2(config)#ipv4 access-list EXTERNAL_ACL_INBOUND RP/0/0/CPU0:R2(config-ipv4-acl)#permit tcp host x.1.28.2 host x.1.28.8 eq 639 RP/0/0/CPU0:R2(config-ipv4-acl)#deny tcp any host x.1.28.8 eq 639 log RP/0/0/CPU0:R2(config-ipv4-acl)#permit tcp host x.1.28.2 host x.1.28.8 eq bgp RP/0/0/CPU0:R2(config-ipv4-acl)#permit tcp host x.1.28.2 eq bgp host x.1.28.8 RP/0/0/CPU0:R2(config-ipv4-acl)#permit pim host x.1.28.2 host x.1.28.8 RP/0/0/CPU0:R2(config-ipv4-acl)#permit tcp any any established … … … RP/0/0/CPU0:R2(config-ipv4-acl)#deny ip any any log
- RMF Control
- IA-3
- Severity
- M
- CCI
- CCI-001958
- Version
- CISC-RT-000910
- Vuln IDs
-
- V-96845
- Rule IDs
-
- SV-105983r1_rule
Checks: C-95681r1_chk
Review the router configuration to determine if received MSDP packets are authenticated. router msdp peer x.14.2.1 password encrypted 094E410B1B1C remote-as nn ! peer x.15.3.5 password encrypted 04500A140A2F remote-as nn ! ! If the router does not require MSDP authentication, this is a finding.
Fix: F-102525r1_fix
Configure the router to authenticate MSDP messages as shown in the following example: RP/0/0/CPU0:R2(config)#router msdp RP/0/0/CPU0:R2(config-msdp)#peer x.14.2.1 RP/0/0/CPU0:R2(config-msdp-peer)#password clear xxxxxxxxxxxx RP/0/0/CPU0:R2(config-msdp-peer)#exit RP/0/0/CPU0:R2(config-msdp)#peer x.15.3.5 RP/0/0/CPU0:R2(config-msdp-peer)#password clear xxxxxxxxxxx RP/0/0/CPU0:R2(config-msdp-peer)#end
- RMF Control
- AC-4
- Severity
- L
- CCI
- CCI-001368
- Version
- CISC-RT-000920
- Vuln IDs
-
- V-96847
- Rule IDs
-
- SV-105985r1_rule
Checks: C-95683r1_chk
Review the router configuration to determine if there is import policy to block source-active multicast advertisements for any undesirable multicast groups, as well as any (S, G) states with undesirable source addresses. Step 1: Verify that an inbound source-active filter is bound to each MSDP peer. router msdp sa-filter in list INBOUND_MSDP_SA_FILTER Step 2: Review the access lists referenced by the source-active filter to verify that undesirable multicast groups, auto-RP, single source multicast (SSM) groups, and advertisements from undesirable sources are blocked. ipv4 access-list INBOUND_MSDP_SA_FILTER 10 deny ipv4 any host 224.0.1.3 20 deny ipv4 any host 224.0.1.24 30 deny ipv4 any host 224.0.1.22 40 deny ipv4 any host 224.0.1.2 50 deny ipv4 any host 224.0.1.35 60 deny ipv4 any host 224.0.1.60 70 deny ipv4 any host 224.0.1.39 80 deny ipv4 any host 224.0.1.40 90 deny ipv4 any 232.0.0.0 0.255.255.255 100 deny ipv4 any 239.0.0.0 0.255.255.255 110 deny ipv4 10.0.0.0 0.255.255.255 any 120 deny ipv4 127.0.0.0 0.255.255.255 any 130 deny ipv4 172.16.0.0 0.15.255.255 any 140 deny ipv4 192.168.0.0 0.0.255.255 any 150 permit ipv4 any any If the router is not configured with an import policy to filter undesirable SA multicast advertisements, this is a finding.
Fix: F-102527r1_fix
Configure the MSDP router to filter received source-active multicast advertisements for any undesirable multicast groups and sources as shown in the example below. RP/0/0/CPU0:R2(config)#ipv4 access-list INBOUND_MSDP_SA_FILTER RP/0/0/CPU0:R2(config-ipv4-acl)#deny ip any host 224.0.1.3 RP/0/0/CPU0:R2(config-ipv4-acl)#deny ipv4 any host 224.0.1.24 RP/0/0/CPU0:R2(config-ipv4-acl)#deny ipv4 any host 224.0.1.22 RP/0/0/CPU0:R2(config-ipv4-acl)#deny ipv4 any host 224.0.1.2 RP/0/0/CPU0:R2(config-ipv4-acl)#deny ipv4 any host 224.0.1.35 RP/0/0/CPU0:R2(config-ipv4-acl)#deny ipv4 any host 224.0.1.60 RP/0/0/CPU0:R2(config-ipv4-acl)#deny ipv4 any host 224.0.1.39 RP/0/0/CPU0:R2(config-ipv4-acl)#deny ipv4 any host 224.0.1.40 RP/0/0/CPU0:R2(config-ipv4-acl)#deny ipv4 any 232.0.0.0 0.255.255.255 RP/0/0/CPU0:R2(config-ipv4-acl)#deny ipv4 any 239.0.0.0 0.255.255.255 RP/0/0/CPU0:R2(config-ipv4-acl)#deny ipv4 10.0.0.0 0.255.255.255 any RP/0/0/CPU0:R2(config-ipv4-acl)#deny ipv4 127.0.0.0 0.255.255.255 any RP/0/0/CPU0:R2(config-ipv4-acl)#deny ipv4 172.16.0.0 0.15.255.255 any RP/0/0/CPU0:R2(config-ipv4-acl)#deny ipv4 192.168.0.0 0.0.255.255 any RP/0/0/CPU0:R2(config-ipv4-acl)#permit ipv4 any any RP/0/0/CPU0:R2(config-ipv4-acl)#exit RP/0/0/CPU0:R2(config)#router msdp RP/0/0/CPU0:R2(config-msdp)#sa-filter in list INBOUND_MSDP_SA_FILTER RP/0/0/CPU0:R2(config-msdp)#end
- RMF Control
- AC-4
- Severity
- L
- CCI
- CCI-001368
- Version
- CISC-RT-000930
- Vuln IDs
-
- V-96849
- Rule IDs
-
- SV-105987r1_rule
Checks: C-95685r1_chk
Review the router configuration to determine if there is export policy to block local source-active multicast advertisements. Step 1: Verify that an outbound source-active filter is bound to each MSDP peer as shown in the example below. router msdp sa-filter in list INBOUND_MSDP_SA_FILTER sa-filter out list OUTBOUND_MSDP_SA_FILTER Step 2: Review the access lists referenced by the source-active filters and verify that MSDP source-active messages being sent to MSDP peers do not leak advertisements that are local. ipv4 access-list OUTBOUND_MSDP_SA_FILTER 10 deny ipv4 10.0.0.0 0.255.255.255 any 20 permit ipv4 any any If the router is not configured with an export policy to filter local source-active multicast advertisements, this is a finding.
Fix: F-102529r1_fix
Configure the router with an export policy to avoid global visibility of local multicast (S, G) states. The example below will prevent exporting multicast active sources belonging to the private network. RP/0/0/CPU0:R2(config)#ipv4 access-list OUTBOUND_MSDP_SA_FILTER RP/0/0/CPU0:R2(config-ipv4-acl)#deny ipv4 10.0.0.0 0.255.255.255 any RP/0/0/CPU0:R2(config-ipv4-acl)#permit ip any any RP/0/0/CPU0:R2(config-ipv4-acl)#exit RP/0/0/CPU0:R2(config)#router msdp RP/0/0/CPU0:R2(config-msdp)#sa-filter out list OUTBOUND_MSDP_SA_FILTER RP/0/0/CPU0:R2(config-msdp)#end
- RMF Control
- AC-4
- Severity
- L
- CCI
- CCI-001368
- Version
- CISC-RT-000940
- Vuln IDs
-
- V-96851
- Rule IDs
-
- SV-105989r1_rule
Checks: C-95687r1_chk
Review the router configuration to determine if it is configured to limit the amount of source-active messages it accepts on a per-peer basis. router msdp … … … peer 4.4.4.4 remote-as 33 maximum external-sa 555 ! peer 5.5.5.5 remote-as 44 maximum external-sa 555 ! ! If the router is not configured to limit the source-active messages it accepts, this is a finding.
Fix: F-102531r1_fix
Configure the router to limit the amount of source-active messages it accepts from each peer. RP/0/0/CPU0:R2(config)#router msdp RP/0/0/CPU0:R2(config-msdp)#peer x.14.2.1 RP/0/0/CPU0:R2(config-msdp-peer)#maximum external-sa nnn RP/0/0/CPU0:R2(config-msdp-peer)#exit RP/0/0/CPU0:R2(config-msdp)#peer x.15.3.5 RP/0/0/CPU0:R2(config-msdp-peer)#maximum external-sa nnn RP/0/0/CPU0:R2(config-msdp-peer)#end
- RMF Control
- CM-6
- Severity
- L
- CCI
- CCI-000366
- Version
- CISC-RT-000950
- Vuln IDs
-
- V-96853
- Rule IDs
-
- SV-105991r1_rule
Checks: C-95689r1_chk
Verify that the loopback interface is used as the source address for all MSDP packets generated by the router. router msdp connect-source Loopback0 If the router does not use its loopback address as the source address when originating MSDP traffic, this is a finding.
Fix: F-102533r1_fix
Configure the router to use its loopback address is used as the source address when sending MSDP packets. RP/0/0/CPU0:R2(config)#router msdp RP/0/0/CPU0:R2(config-msdp)#connect-source lo0 RP/0/0/CPU0:R2(config-msdp)#end