Cisco NX OS Switch RTR Security Technical Implementation Guide

  • Version/Release: V3R2
  • Published: 2024-08-22
  • Released: 2024-10-24
  • Expand All:
  • Severity:
  • Sort:
Compare

Select any two versions of this STIG to compare the individual requirements

View

Select any old version/release of this STIG to view the previous requirements

This Security Technical Implementation Guide is published as a tool to improve the security of Department of Defense (DOD) information systems. The requirements are derived from the National Institute of Standards and Technology (NIST) 800-53 and related documents. Comments or proposed revisions to this document should be sent via email to the following address: disa.stig_spt@mail.mil.
b
The Cisco switch must be configured to enforce approved authorizations for controlling the flow of information within the network based on organization-defined information flow control policies.
AC-4 - Medium - CCI-001368 - V-221071 - SV-221071r999679_rule
RMF Control
AC-4
Severity
Medium
CCI
CCI-001368
Version
CISC-RT-000010
Vuln IDs
  • V-221071
  • V-101857
Rule IDs
  • SV-221071r999679_rule
  • SV-110961
Information flow control regulates where information is allowed to travel within a network and between interconnected networks. The flow of all network traffic must be monitored and controlled so it does not introduce any unacceptable risk to the network infrastructure or data. Information flow control policies and enforcement mechanisms are commonly employed by organizations to control the flow of information between designated sources and destinations (e.g., networks, individuals, and devices) within information systems. Enforcement occurs, for example, in boundary protection devices (e.g., gateways, switches, guards, encrypted tunnels, and firewalls) that employ rule sets or establish configuration settings that restrict information system services, provide a packet-filtering capability based on header information, or provide a message-filtering capability based on message content (e.g., implementing key word searches or using document characteristics).
Checks: C-22786r409702_chk

Review the switch 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.12.0/24 and SQL traffic into subnet 10.1.13.0/24. ICMP is allowed for troubleshooting and OSPF is the routing protocol used within the network. interface Ethernet2/3 no switchport ip access-group FILTER_SERVER_TRAFFIC in ip address 10.1.23.2/24 no shutdown … … … ip access-list FILTER_SERVER_TRAFFIC 10 permit tcp any 10.1.12.0/24 eq lpd 20 permit tcp any 10.1.12.0/24 eq 631 30 permit tcp any 10.1.12.0/24 eq 9100 40 permit tcp any 10.1.13.0/24 eq 1433 50 permit tcp any 10.1.13.0/24 eq 1434 60 permit tcp any 10.1.13.0/24 eq 4022 70 permit icmp any any 80 permit ospf any any 90 deny ip any any Alternate: Inter-VLAN routing interface Vlan12 ip address 10.1.12.1 255.255.255.0 ip access-group FILTER_PRINTER_VLAN out ! interface Vlan13 ip address 10.1.13.1 255.255.255.0 ip access-group FILTER_SQL_VLAN out … … … ip access-list FILTER_PRINTER_VLAN 10 permit tcp any any eq lpd 20 permit tcp any any eq 631 30 permit tcp any any eq 9100 40 permit icmp any any 50 deny ip any any ip access-list FILTER_SQL_VLAN 10 permit tcp any any eq 1433 20 permit tcp any any eq 1434 30 permit tcp any any eq 4033 40 permit icmp any any 50 deny ip any any If the switch 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-22775r409703_fix

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. SW1(config)# ip access-list FILTER_SERVER_TRAFFIC SW1(config-acl)# permit tcp any 10.1.12.0 0.0.0.255 eq lpd SW1(config-acl)# permit tcp any 10.1.12.0 0.0.0.255 eq 631 SW1(config-acl)# permit tcp any 10.1.12.0 0.0.0.255 eq 9100 SW1(config-acl)# permit tcp any 10.1.13.0 0.0.0.255 eq 1433 SW1(config-acl)# permit tcp any 10.1.13.0 0.0.0.255 eq 1434 SW1(config-acl)# permit tcp any 10.1.13.0 0.0.0.255 eq 4022 SW1(config-acl)# permit icmp any any SW1(config-acl)# permit ospf any any SW1(config-acl)# deny ip any any SW1(config-acl)# exit SW1(config)# int e2/3 SW1(config-if)# ip access-group FILTER_SERVER_TRAFFIC in SW1(config-if)# end Alternate: Inter-VLAN routing SW1(config)# ip access-list FILTER_PRINTER_VLAN SW1(config-acl)# permit tcp any any eq lpd SW1(config-acl)# permit tcp any any eq 631 SW1(config-acl)# permit tcp any any eq 9100 SW1(config-acl)# permit icmp any any SW1(config-acl)# deny ip any any SW1(config-acl)# exit SW1(config)# ip access-list FILTER_SQL_VLAN SW1(config-acl)# permit tcp any any eq 1433 SW1(config-acl)# permit tcp any any eq 1434 SW1(config-acl)# permit tcp any any eq 4033 SW1(config-acl)# permit icmp any any SW1(config-acl)# deny ip any any SW1(config-acl)# exit SW1(config)# int vlan 12 SW1(config-if)# ip access-group FILTER_PRINTER_VLAN out SW1(config-if)# exit SW1(config)# int vlan 13 SW1(config-if)# ip access-group FILTER_SQL_VLAN out SW1(config-if)# end

b
The Cisco switch must be configured to implement message authentication for all control plane protocols.
CM-6 - Medium - CCI-000366 - V-221072 - SV-221072r999681_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
CISC-RT-000020
Vuln IDs
  • V-221072
  • V-101859
Rule IDs
  • SV-221072r999681_rule
  • SV-110963
A rogue switch could send a fictitious routing update to convince a site's perimeter switch to send traffic to an incorrect or even a rogue destination. This diverted traffic could be analyzed to learn confidential information about the site's network, or used to disrupt the network's ability to communicate with other networks. This is known as a "traffic attraction attack" and is prevented by configuring neighbor switch authentication for routing updates. This requirement applies to all IPv4 and IPv6 protocols that are used to exchange routing or packet forwarding information; this includes all Interior Gateway Protocols (such as OSPF, EIGRP, and IS-IS) and Exterior Gateway Protocols (such as BGP), MPLS-related protocols (such as LDP), and multicast-related protocols.
Checks: C-22787r999680_chk

Review the switch configuration. Verify that neighbor switch authentication is enabled for all routing protocols. The configuration examples below depicts BGP, EIGRP, IS-IS and OSPF authentication. BGP Example router bgp 1 router-id 1.1.1.1 address-family ipv4 unicast neighbor 10.1.12.2 remote-as 2 password 3 3ec66c90c104ad13 EIGRP Example key chain EIGRP_KEY key 1 key-string xxxxxxx … … … interface Ethernet2/21 no switchport ip router eigrp 1 ip authentication mode eigrp 1 md5 ip authentication key-chain eigrp 1 EIGRP_KEY or router eigrp 1 authentication mode md5 authentication key-chain EIGRP_KEY Note: Interface authentication overrides process authentication. IS-IS Example interface Ethernet2/20 no switchport isis authentication-type md5 level-1 isis authentication key-chain xxxxx level-1 ip router isis 1 OSPF Example interface Ethernet2/2 no switchport ip ospf authentication ip ospf authentication key-chain OSPF_KEY ip router ospf 1 area 0.0.0.0 RIP Example interface Ethernet2/8 no switchport ip rip authentication mode md5 ip rip authentication key-chain RIP_KEY If authentication is not enabled on all routing protocols, this is a finding.

Fix: F-22776r409706_fix

Configure authentication to be enabled for every protocol that affects the routing or forwarding tables. The example configuration commands below enable OSPF, EIGRP, IS-IS, and BGP authentication. BGP Example SW1(config)# switch bgp nn SW1(config-router)# neighbor 10.1.12.2 SW1(config-router-neighbor)# password xxxxxxxx SW1(config-router-neighbor)# end EIGRP Example Step 1: Configure the key chain. SW1(config)# key chain EIGRP_KEY SW1(config-keychain)# key 1 SW1(config-keychain-key)# key-string xxxxxx SW1(config-keychain-key)# exit SW1(config-keychain)# exit Step 2: Apply the key chain to the EIGRP process or each neighbor. Authentication for the EIGRP process SW1(config)# router eigrp 1 SW1(config-router)# authentication mode md5 SW1(config-router)# authentication key-chain XXXXXX SW1(config-router)# end or Authentication for the EIGRP neighbor SW1(config)# int e2/21 SW1(config-if)# ip authentication mode eigrp 1 md5 SW1(config-if)# ip authentication key-chain eigrp 1 xxxxx SW1(config-if)# end Note: Interface authentication overrides process authentication. IS-IS Example Step 1: Configure the key chain. SW1(config)# key chain ISIS_KEY SW1(config-keychain)# key 1 SW1(config-keychain-key)# key-string xxxxxx SW1(config-keychain-key)# exit SW1(config-keychain)# exit Step 2: Apply the key chain to each ISIS neighbor. SW1(config)# int e2/20 SW1(config-if)# isis authentication-type md5 level-1 SW1(config-if)# isis authentication key-chain xxxxx level-1 OSPF Example Step 1: Configure the key chain. SW1(config)# key chain OSPF_KEY SW1(config-keychain)# key 1 SW1(config-keychain-key)# key-string xxxxxx SW1(config-keychain-key)# exit SW1(config-keychain)# exit Step 2: Apply the key chain to each OSPF neighbor. SW1(config)# int e2/2 SW1(config-if)# ip ospf authentication SW1(config-if)# ip ospf authentication key-chain OSPF_KEY RIP Example Step 1: Configure the key chain. SW1(config)# key chain RIP_KEY SW1(config-keychain)# key 1 SW1(config-keychain-key)# key-string xxxxxx SW1(config-keychain-key)# exit SW1(config-keychain)# exit Step 2: Apply the key chain to each RIP neighbor. SW1(config)# int e2/8 SW1(config-if)# ip rip authentication mode md5 SW1(config-if)# ip rip authentication key-chain RIP_KEY

b
The Cisco switch must be configured to use keys with a duration not exceeding 180 days for authenticating routing protocol messages.
CM-6 - Medium - CCI-000366 - V-221073 - SV-221073r999682_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
CISC-RT-000030
Vuln IDs
  • V-221073
  • V-101861
Rule IDs
  • SV-221073r999682_rule
  • SV-110965
If the keys used for routing protocol authentication are guessed, the malicious user could create havoc within the network by advertising incorrect routes and redirecting traffic. Some routing protocols allow the use of key chains for authentication. A key chain is a set of keys that is used in succession, with each having a lifetime of no more than 180 days. Changing the keys frequently reduces the risk of them eventually being guessed. Keys cannot be used during time periods for which they are not activated. If a time period occurs during which no key is activated, neighbor authentication cannot occur, and therefore routing updates will fail. Therefore, ensure that for a given key chain, key activation times overlap to avoid any period of time during which no key is activated.
Checks: C-22788r409708_chk

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 OSPF_KEY key 1 key-string 7 070d2e4e4c10 accept-lifetime 00:00:00 Oct 01 2019 01:05:00 Jan 01 2020 send-lifetime 00:00:00 Oct 01 2019 23:59:59 Dec 31 2019 key 2 key-string 7 0704205e4b07 accept-lifetime 23:55:00 Dec 31 2019 01:05:00 Apr 01 2020 send-lifetime 00:00:00 Jan 01 2020 23:59:59 Mar 31 2020 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-22777r409709_fix

Configure each key used for routing protocol authentication to have a lifetime of no more than 180 days as shown in the example below: SW1(config)# key chain OSPF_KEY SW1(config-keychain)# key 1 SW1(config-keychain-key)# key-string xxxxxxxxxxxx SW1(config-keychain-key)# send-lifetime 00:00:00 Oct 1 2019 23:59:59 Dec 31 2019 SW1(config-keychain-key)# accept-lifetime 00:00:00 Oct 1 2019 01:05:00 Jan 1 2020 SW1(config-keychain-key)# key 2 SW1(config-keychain-key)# key-string kxxxxxxxxxxxxx SW1(config-keychain-key)# send-lifetime 00:00:00 Jan 1 2020 23:59:59 Mar 31 2020 SW1(config-keychain-key)# accept-lifetime 23:55:00 Dec 31 2019 01:05:00 Apr 1 2020 SW1(config-keychain-key)# end

b
The Cisco switch must be configured to use encryption for routing protocol authentication.
IA-7 - Medium - CCI-000803 - V-221074 - SV-221074r999683_rule
RMF Control
IA-7
Severity
Medium
CCI
CCI-000803
Version
CISC-RT-000040
Vuln IDs
  • V-221074
  • V-101863
Rule IDs
  • SV-221074r999683_rule
  • SV-110967
A rogue switch could send a fictitious routing update to convince a site's perimeter switch to send traffic to an incorrect or even a rogue destination. This diverted traffic could be analyzed to learn confidential information about the site's network or used to disrupt the network's ability to communicate with other networks. This is known as a "traffic attraction attack" and is prevented by configuring neighbor switch authentication for routing updates. However, using clear-text authentication provides little benefit since an attacker can intercept traffic and view the authentication key. This would allow the attacker to use the authentication key in an attack. This requirement applies to all IPv4 and IPv6 protocols that are used to exchange routing or packet forwarding information; this includes all Interior Gateway Protocols (such as OSPF, EIGRP, and IS-IS) and Exterior Gateway Protocols (such as BGP), MPLS-related protocols (such as LDP), and multicast-related protocols.
Checks: C-22789r409711_chk

Review the switch configuration. For every routing protocol that affects the routing or forwarding tables, verify that neighbor switch authentication is encrypting the authentication key as shown in the examples below: BGP Example router bgp 1 router-id 1.1.1.1 address-family ipv4 unicast neighbor 10.1.12.2 remote-as 2 password 3 3ec66c90c104ad13 Note: BGP authentication uses MD5. EIGRP Example interface Ethernet2/21 no switchport ip router eigrp 1 ip authentication mode eigrp 1 md5 or router eigrp 1 authentication mode md5 Note: Interface authentication overrides process authentication. IS-IS Example interface Ethernet2/20 no switchport isis authentication-type md5 level-1 OSPF Example interface Ethernet2/2 no switchport mac-address 0000.0000.002f ip ospf authentication message-digest ip ospf message-digest-key 1 md5 3 3ec66c90c104ad13 RIP Example interface Ethernet2/8 no switchport ip rip authentication mode md5 If the routing protocol is not encrypting the authentication key, this is a finding.

Fix: F-22778r409712_fix

Configure all routing protocol authentications to encrypt the authentication key. BGP Example SW1(config)#switch bgp nn SW1(config-switch)#neighbor x.x.x.x password xxxxxx EIGRP Example SW1(config)# router eigrp 1 SW1(config-router)# authentication mode md5 SW1(config-router)# end or Authentication for the EIGRP neighbor SW1(config)# int e2/21 SW1(config-if)# ip authentication mode eigrp 1 md5 SW1(config-if)# end Note: Interface authentication overrides process authentication. IS-IS Example SW1(config)# int e2/20 SW1(config-if)# isis authentication-type md5 level-1 OSPF Example SW1(config)# int e2/2 SW1(config-if)# ip ospf authentication message-digest SW1(config-if)# ip ospf message-digest-key 1 md5 xxxxxxxxxxx RIP Example SW1(config)# int e2/8 SW1(config-if)# ip rip authentication mode md5

b
The Cisco switch must be configured to authenticate all routing protocol messages using NIST-validated FIPS 198-1 message authentication code algorithm.
IA-7 - Medium - CCI-000803 - V-221075 - SV-221075r999684_rule
RMF Control
IA-7
Severity
Medium
CCI
CCI-000803
Version
CISC-RT-000050
Vuln IDs
  • V-221075
  • V-101865
Rule IDs
  • SV-221075r999684_rule
  • SV-110969
A rogue switch could send a fictitious routing update to convince a site's perimeter switch to send traffic to an incorrect or even a rogue destination. This diverted traffic could be analyzed to learn confidential information about the site's network or used to disrupt the network's ability to communicate with other networks. This is known as a "traffic attraction attack" and is prevented by configuring neighbor switch authentication for routing updates. However, using clear-text authentication provides little benefit since an attacker can intercept traffic and view the authentication key. This would allow the attacker to use the authentication key in an attack. Since MD5 is vulnerable to "birthday" attacks and may be compromised, routing protocol authentication must use FIPS 140-2 validated algorithms and modules to encrypt the authentication key. This requirement applies to all IPv4 and IPv6 protocols that are used to exchange routing or packet forwarding information; this includes all Interior Gateway Protocols (such as OSPF, EIGRP, and IS-IS) and Exterior Gateway Protocols (such as BGP), MPLS-related protocols (such as LDP), and multicast-related protocols.
Checks: C-22790r409714_chk

Review the switch configuration to verify it is using a NIST-validated FIPS 198-1 message authentication code algorithm to authenticate routing protocol messages. OSPF Example key chain OSPF_KEY key 1 key-string 7 070d2e4e4c10 accept-lifetime 00:00:00 Oct 01 2019 01:05:00 Jan 01 2020 send-lifetime 00:00:00 Oct 01 2019 23:59:59 Dec 31 2019 cryptographic-algorithm hmac-sha-256 key 2 key-string 7 0704205e4b07 accept-lifetime 23:55:00 Dec 31 2019 01:05:00 Apr 01 2020 send-lifetime 00:00:00 Jan 01 2020 23:59:59 Mar 31 2020 cryptographic-algorithm hmac-sha-256 … … … interface Ethernet2/2 no switchport ip ospf authentication key-chain OSPF_KEY Note: BGP, RIP, EIGRP, IS-IS do not support any FIPS 198-1 HMAC algorithms. 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-22779r409715_fix

Configure routing protocol authentication to use a NIST-validated FIPS 198-1 message authentication code algorithm as shown in the example below: SW1(config)# key chain OSPF_KEY SW1(config-keychain)# key 1 SW1(config-keychain-key)# key-string xxxxxxxxxxxx SW1(config-keychain-key)# send-lifetime 00:00:00 Oct 1 2019 23:59:59 Dec 31 2019 SW1(config-keychain-key)# accept-lifetime 00:00:00 Oct 1 2019 01:05:00 Jan 1 2020 SW1(config-keychain-key)# cryptographic-algorithm hmac-sha-256 SW1(config-keychain-key)# key 2 SW1(config-keychain-key)# key-string kxxxxxxxxxxxxx SW1(config-keychain-key)# send-lifetime 00:00:00 Jan 1 2020 23:59:59 Mar 31 2020 SW1(config-keychain-key)# accept-lifetime 23:55:00 Dec 31 2019 01:05:00 Apr 1 2020 SW1(config-keychain-key)# cryptographic-algorithm hmac-sha-256 SW1(config-keychain-key)# end SW1(config)# int e2/2 SW2(config-if)# ip ospf authentication key-chain OSPF_KEY

a
The Cisco switch must be configured to have all inactive layer 3 interfaces disabled.
AC-4 - Low - CCI-001414 - V-221076 - SV-221076r999685_rule
RMF Control
AC-4
Severity
Low
CCI
CCI-001414
Version
CISC-RT-000060
Vuln IDs
  • V-221076
  • V-101867
Rule IDs
  • SV-221076r999685_rule
  • SV-110971
An inactive interface is rarely monitored or controlled and may expose a network to an undetected attack on that interface. Unauthorized personnel with access to the communication facility could gain access to a switch by connecting to a configured interface that is not in use. If an interface is no longer used, the configuration must be deleted and the interface disabled. For sub-interfaces, delete sub-interfaces that are on inactive interfaces and delete sub-interfaces that are themselves inactive. If the sub-interface is no longer necessary for authorized communications, it must be deleted.
Checks: C-22791r409717_chk

Review the switch configuration and verify that inactive interfaces have been disabled as shown below: interface Ethernet4/12 shutdown no switchport interface Ethernet4/13 shutdown no switchport … … … interface Ethernet4/48 shutdown no switchport If an interface is not being used but is configured or enabled, this is a finding.

Fix: F-22780r409718_fix

Disable all inactive interfaces as shown below: SW1(config)# int e4/1 - 11 SW1(config-if-range)# shutdown SW1(config-if-range)# end

b
The Cisco switch must not be configured to have any feature enabled that calls home to the vendor.
SC-7 - Medium - CCI-002403 - V-221078 - SV-221078r999687_rule
RMF Control
SC-7
Severity
Medium
CCI
CCI-002403
Version
CISC-RT-000080
Vuln IDs
  • V-221078
  • V-101871
Rule IDs
  • SV-221078r999687_rule
  • SV-110975
Call home services will routinely send data such as configuration and diagnostic information to the vendor for routine or emergency analysis and troubleshooting. There is a risk that transmission of sensitive data sent to unauthorized persons could result in data loss or downtime due to an attack.
Checks: C-22793r409723_chk

Review the switch configuration to determine if the call home service is enabled as shown in the example below: callhome contract-id CompanyXYZ customer-id CompanyXYZ email-contact netadmin@CompanyXYZ.com phone-contact +1-800-555-4567 enable If the call home feature is configured to call home to the vendor, this is a finding.

Fix: F-22782r409724_fix

Disable the call home feature as shown below: SW1(config)# callhome SW1(config-callhome)# no enable SW1(config-callhome)# end

b
The Cisco switch must be configured to protect against or limit the effects of denial-of-service (DoS) attacks by employing control plane protection.
SC-5 - Medium - CCI-002385 - V-221079 - SV-221079r1015495_rule
RMF Control
SC-5
Severity
Medium
CCI
CCI-002385
Version
CISC-RT-000120
Vuln IDs
  • V-221079
  • V-101873
Rule IDs
  • SV-221079r1015495_rule
  • SV-110977
The Route Processor (RP) is critical to all network operations because it is the component used to build all forwarding paths for the data plane via control plane processes. It is also instrumental with ongoing network management functions that keep the switches and links available for providing network services. Any disruption to the RP or the control and management planes can result in mission-critical network outages. A DoS attack targeting the RP can result in excessive CPU and memory utilization. To maintain network stability and RP security, the switch must be able to handle specific control plane and management plane traffic that is destined to the RP. In the past, one method of filtering was to use ingress filters on forwarding interfaces to filter both forwarding path and receiving path traffic. However, this method does not scale well as the number of interfaces grows and the size of the ingress filters grows. Control plane policing increases the security of switches and multilayer switches by protecting the RP from unnecessary or malicious traffic. Filtering and rate limiting the traffic flow of control plane packets can be implemented to protect switches against reconnaissance and DoS attacks, allowing the control plane to maintain packet forwarding and protocol states despite an attack or heavy load on the switch or multilayer switch.
Checks: C-22794r1015495_chk

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

Fix: F-22783r409727_fix

Configure the Cisco switch protect against known types of DoS attacks on the route processor. Implementing a CoPP policy as shown in the example below is a best practice method. Step 1: Configure ACLs specific traffic types. SW1(config)# ip access-list CoPP_CRITICAL SW1(config-acl)# remark our control plane adjacencies are critical SW1(config-acl)# permit ospf host 10.1.12.1 any SW1(config-acl)# permit ospf host 10.1.22.1 any SW1(config-acl)# permit pim host 10.1.12.1 any SW1(config-acl)# permit pim host 10.1.22.1 any SW1(config-acl)# permit pim host 10.1.33.4 any SW1(config-acl)# permit igmp any 224.0.0.0 15.255.255.255 SW1(config-acl)# permit tcp host 10.2.33.3 eq bgp host 10.2.33.4 SW1(config-acl)# permit tcp host 10.2.33.3 host 10.2.33.4 eq bgp SW1(config-acl)# deny ip any any SW1(config-acl)# exit SW1(config)# ip access-list CoPP_IMPORTANT SW1(config-acl)# permit tcp host 10.1.33.5 eq tacacs any SW1(config-acl)# permit tcp 10.1.33.0 0.0.0.255 any eq 22 SW1(config-acl)# permit udp host 10.1.33.7 any eq snmp SW1(config-acl)# permit udp host 10.1.33.9 eq ntp any SW1(config-acl)# deny ip any any SW1(config-acl)# exit SW1(config)# ip access-list CoPP_NORMAL SW1(config-acl)# remark we will want to rate limit ICMP traffic SW1(config-acl)# permit icmp any any echo SW1(config-acl)# permit icmp any any echo-reply SW1(config-acl)# permit icmp any any time-exceeded SW1(config-acl)# permit icmp any any unreachable SW1(config-acl)# deny ip any any SW1(config-acl)# exit SW1(config)# ip access-list CoPP_UNDESIRABLE SW1(config-acl)# remark other management plane traffic that should not be received SW1(config-acl)# permit udp any any eq ntp SW1(config-acl)# permit udp any any eq snmp SW1(config-acl)# permit tcp any any eq 22 SW1(config-acl)# permit tcp any any eq 23 SW1(config-acl)# remark other control plane traffic not configured on switch SW1(config-acl)# permit eigrp any any SW1(config-acl)# permit udp any any eq rip SW1(config-acl)# deny ip any any SW1(config-acl)# exit SW1(config)# ip access-list CoPP_DEFAULT SW1(config-acl)# permit ip any any SW1(config-acl)# exit Step 2: Configure class maps referencing each of the ACLs. SW1(config)# class-map match-all CoPP_CRITICAL SW1(config-cmap)# match access-group name CoPP_CRITICAL SW1(config-cmap)# class-map match-any CoPP_IMPORTANT SW1(config-cmap)# match access-group name CoPP_IMPORTANT SW1(config-cmap)# match protocol arp SW1(config-cmap)# class-map match-all CoPP_NORMAL SW1(config-cmap)# match access-group name CoPP_NORMAL SW1(config-cmap)# class-map match-any CoPP_UNDESIRABLE SW1(config-cmap)# match access-group name CoPP_UNDESIRABLE SW1(config-cmap)# class-map match-all CoPP_DEFAULT SW1(config-cmap)# match access-group name CoPP_DEFAULT SW1(config-cmap)# exit Step 3: Configure a policy map referencing the configured class maps and apply appropriate bandwidth allowance and policing attributes. SW1(config)# policy-map CONTROL_PLANE_POLICY SW1(config-pmap)# class CoPP_CRITICAL SW1(config-pmap-c)# police 512000 8000 conform-action transmit exceed-action transmit SW1(config-pmap-c-police)# class CoPP_IMPORTANT SW1(config-pmap-c)# police 256000 4000 conform-action transmit exceed-action drop SW1(config-pmap-c-police)# class CoPP_NORMAL SW1(config-pmap-c)# police 128000 2000 conform-action transmit exceed-action drop SW1(config-pmap-c-police)# class CoPP_UNDESIRABLE SW1(config-pmap-c)# police 8000 1000 conform-action drop exceed-action drop SW1(config-pmap-c-police)# class CoPP_DEFAULT SW1(config-pmap-c)# police 64000 1000 conform-action transmit exceed-action drop SW1(config-pmap-c-police)# exit SW1(config-pmap-c)# exit SW1(config-pmap)# exit Step 4: Apply the policy map to the control plane. SW1(config)# control-plane SW1(config-cp)# service-policy input CONTROL_PLANE_POLICY SW1(config-cp)# end

c
The Cisco switch must be configured to restrict traffic destined to itself.
SC-7 - High - CCI-001097 - V-221080 - SV-221080r999689_rule
RMF Control
SC-7
Severity
High
CCI
CCI-001097
Version
CISC-RT-000130
Vuln IDs
  • V-221080
  • V-101875
Rule IDs
  • SV-221080r999689_rule
  • SV-110979
The route processor handles traffic destined to the switch—the key component used to build forwarding paths and is instrumental with all network management functions. Hence, any disruption or DoS attack to the route processor can result in mission critical network outages.
Checks: C-22795r409729_chk

Review the external and internal ACLs to verify that the switch 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 switch should be dropped. ip access-list EXTERNAL_ACL 10 permit tcp x.11.1.1/32 eq bgp x.11.1.2/32 20 permit tcp x.11.1.1/32 x.11.1.2/32 eq bgp 30 permit icmp x.11.1.1/32 x.11.1.2/32 echo 40 permit icmp x.11.1.1/32 x.11.1.2/32 echo-reply 50 deny ip any x.11.1.1/32 log 60 permit … … … … 90 deny ip any any log ip access-list INTERNAL_ACL 10 permit icmp any any 20 permit ospf 10.1.12.1/32 10.1.12.2/32 30 permit tcp 10.2.1.0/24 10.1.12.2/32 eq 22 40 permit tcp 10.2.1.0/24 10.1.12.2/32 eq tacacs 50 permit udp 10.2.1.0/24 10.1.12.2/32 eq snmp 60 permit udp 10.2.1.0/24 10.1.12.2/32 eq ntp 70 deny ip any 10.1.12.2/32 log 80 permit …. 90 deny ip any any log Note: For the internal ACL example, all switches 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 switch 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 Ethernet1/2 no switchport ip access-group EXTERNAL_ACL in ip address x.11.1.2 255.255.255.254 interface Ethernet1/3 no switchport ip access-group INTERNAL_ACL in ip address 10.1.12.2 255.255.255.0 If the switch is not configured to restrict traffic destined to itself, this is a finding.

Fix: F-22784r409730_fix

Step 1: Configure the ACL for any external interfaces as shown in the example below: SW1(config)# ip access-list EXTERNAL_ACL SW1(config-acl)# permit tcp host x.11.1.1 eq bgp host x.11.1.2 SW1(config-acl)# permit tcp host x.11.1.1 host x.11.1.2 eq bgp SW1(config-acl)# permit icmp host x.11.1.1 host x.11.1.2 echo SW1(config-acl)# permit icmp host x.11.1.1 host x.11.1.2 echo-reply SW1(config-acl)# deny ip any host x.11.1.1 log SW1(config-acl)# permit … … … … SW1(config-acl)# deny ip any any log Configure the ACL for any external interfaces as shown in the example below: SW1(config)# ip access-list INTERNAL_ACL SW1(config-acl)# permit ospf host 10.1.12.1 host 10.1.12.2 SW1(config-acl)# permit tcp 10.2.1.0 0.0.0.255 host 10.1.12.2 eq 22 SW1(config-acl)# permit tcp 10.2.1.0 0.0.0.255 host 10.1.12.2 eq tacacs SW1(config-acl)# permit udp 10.2.1.0 0.0.0.255 host 10.1.12.2 eq snmp SW1(config-acl)# permit udp 10.2.1.0 0.0.0.255 host 10.1.12.2 eq ntp SW1(config-acl)# deny ip any host 10.1.12.2 log SW1(config-acl)# permit … … … … SW1(config-acl)# permit ip any any log SW1(config-acl)# exit Note: best practice is to configure the ACL statements relative to traffic destined to the switch first followed by ACL statements for transit traffic. Step 2: Apply the ACLs to the appropriate interface as shown in the example below: SW1(config)# int e1/2 SW1(config-if)# ip access-group EXTERNAL_ACL in SW1(config)# int e1/3 SW1(config-if)# ip access-group INTERNAL_ACL in

b
The Cisco switch must be configured to drop all fragmented Internet Control Message Protocol (ICMP) packets destined to itself.
SC-7 - Medium - CCI-001097 - V-221081 - SV-221081r999690_rule
RMF Control
SC-7
Severity
Medium
CCI
CCI-001097
Version
CISC-RT-000140
Vuln IDs
  • V-221081
  • V-101877
Rule IDs
  • SV-221081r999690_rule
  • SV-110981
Fragmented ICMP packets can be generated by hackers for DoS attacks such as Ping O' Death and Teardrop. It is imperative that all fragmented ICMP packets are dropped.
Checks: C-22796r409732_chk

Review the external and internal ACLs to verify that the switch is configured drop all fragmented ICMP packets destined to itself. ip access-list EXTERNAL_ACL 10 permit tcp x.11.1.1/32 eq bgp x.11.1.2/32 20 permit tcp x.11.1.1/32 x.11.1.2/32 eq bgp 30 deny icmp any x.11.1.2/32 fragments log 40 permit icmp x.11.1.1/32 x.11.1.2/32 echo … … … 90 deny ip any any log ip access-list INTERNAL_ACL 10 deny icmp any host 10.1.12.2/32 fragments 20 permit icmp any any Note: Ensure the statement to deny ICMP fragments is before any permit statements for ICMP. If the switch is not configured to drop all fragmented ICMP packets destined to itself, this is a finding.

Fix: F-22785r409733_fix

Configure the external and internal ACLs to drop all fragmented ICMP packets destined to itself as shown in the example below: SW1(config)# ip access-list EXTERNAL_ACL SW1(config-acl)# 35 deny icmp any host x.11.1.2 fragments log SW1(config-acl)# exit SW1(config)# ip access-list INTERNAL_ACL SW1(config-acl)# 25 deny icmp any host 10.1.12.2 fragments log SW1(config-acl)# end Note: Ensure the above statement is before any permit statements for ICMP.

b
The Cisco switch must be configured to have Gratuitous ARP disabled on all external interfaces.
SC-5 - Medium - CCI-002385 - V-221082 - SV-221082r999691_rule
RMF Control
SC-5
Severity
Medium
CCI
CCI-002385
Version
CISC-RT-000150
Vuln IDs
  • V-221082
  • V-101879
Rule IDs
  • SV-221082r999691_rule
  • SV-110983
A gratuitous ARP is an ARP broadcast in which the source and destination MAC addresses are the same. It is used to inform the network about a host IP address. A spoofed gratuitous ARP message can cause network mapping information to be stored incorrectly, causing network malfunction.
Checks: C-22797r409735_chk

Review the configuration to determine if gratuitous ARP is disabled on all external interfaces as shown in the example below: interface Ethernet2/7 no switchport ip address x.22.4.2/30 no ip arp gratuitous request Note: Gratuitous ARP is enabled on all interfaces by default. If gratuitous ARP is enabled on any external interface, this is a finding.

Fix: F-22786r409736_fix

Disable Gratuitous ARP as shown in the example below: SW1(config)# int e2/7 SW1(config-if)# no ip arp gratuitous request SW1(config-if)# end

a
The Cisco switch must be configured to have IP directed broadcast disabled on all interfaces.
SC-5 - Low - CCI-002385 - V-221083 - SV-221083r999692_rule
RMF Control
SC-5
Severity
Low
CCI
CCI-002385
Version
CISC-RT-000160
Vuln IDs
  • V-221083
  • V-101881
Rule IDs
  • SV-221083r999692_rule
  • SV-110985
An IP directed broadcast is a datagram sent to the broadcast address of a subnet that is not directly attached to the sending machine. The directed broadcast is routed through the network as a unicast packet until it arrives at the target subnet, where it is converted into a link-layer broadcast. Because of the nature of the IP addressing architecture, only the last switch in the chain, which is connected directly to the target subnet, can conclusively identify a directed broadcast. IP directed broadcasts are used in the extremely common and popular smurf, or denial-of-service (DoS), attacks. In a smurf attack, the attacker sends Internet Control Message Protocol (ICMP) echo requests from a falsified source address to a directed broadcast address, causing all the hosts on the target subnet to send replies to the falsified source. By sending a continuous stream of such requests, the attacker can create a much larger stream of replies, which can completely inundate the host whose address is being falsified. This service should be disabled on all interfaces when not needed to prevent smurf and DoS attacks. Directed broadcast can be enabled on internal facing interfaces to support services such as Wake-On-LAN. Case scenario may also include support for legacy applications where the content server and the clients do not support multicast. The content servers send streaming data using UDP broadcast. Used in conjunction with the IP multicast helper-map feature, broadcast data can be sent across a multicast topology. The broadcast streams are converted to multicast and vice versa at the first-hop switches and last-hop switches before entering and leaving the multicast transit area respectively. The last-hop switch must convert the multicast to broadcast. Hence, this interface must be configured to forward a broadcast packet (i.e., a directed broadcast address is converted to the all nodes broadcast address).
Checks: C-22798r409738_chk

Review the switch 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 Ethernet2/2 no switchport ip address 10.1.12.1/24 ip directed-broadcast If IP directed broadcast is not disabled on all interfaces, this is a finding.

Fix: F-22787r409739_fix

Disable IP directed broadcast on all interfaces as shown in the example below: SW1(config)# int e2/2 SW1(config-if)# no ip directed-broadcast SW1(config-if)# end

b
The Cisco switch must be configured to have Internet Control Message Protocol (ICMP) unreachable messages disabled on all external interfaces.
SC-5 - Medium - CCI-002385 - V-221084 - SV-221084r999693_rule
RMF Control
SC-5
Severity
Medium
CCI
CCI-002385
Version
CISC-RT-000170
Vuln IDs
  • V-221084
  • V-101883
Rule IDs
  • SV-221084r999693_rule
  • SV-110987
The ICMP supports IP traffic by relaying information about paths, routes, and network conditions. Switches automatically send ICMP messages under a wide variety of conditions. Host unreachable ICMP messages are commonly used by attackers for network mapping and diagnosis.
Checks: C-22799r409741_chk

Review the switch configuration to determine if it is compliant with this requirement. The ip unreachables command must not be found on any interface as shown in the example below: interface Ethernet2/7 no switchport ip address x.22.4.2/30 ip unreachables If ICMP unreachable notifications are sent from any external interfaces, this is a finding.

Fix: F-22788r409742_fix

Disable ip unreachables on all external interfaces as shown below: SW1(config)# int e2/7 SW1(config-if)# no ip unreachables SW1(config-if)# end

b
The Cisco switch must be configured to have Internet Control Message Protocol (ICMP) redirect messages disabled on all external interfaces.
SC-5 - Medium - CCI-002385 - V-221085 - SV-221085r999694_rule
RMF Control
SC-5
Severity
Medium
CCI
CCI-002385
Version
CISC-RT-000190
Vuln IDs
  • V-221085
  • V-101885
Rule IDs
  • SV-221085r999694_rule
  • SV-110989
The ICMP supports IP traffic by relaying information about paths, routes, and network conditions. Switches automatically send ICMP messages under a wide variety of conditions. Redirect ICMP messages are commonly used by attackers for network mapping and diagnosis.
Checks: C-22800r409744_chk

Review the switch configuration to verify that the no ip redirects command has been configured on all external interfaces as shown in the example below: interface Ethernet2/7 no switchport ip address x.22.4.2/30 no ip redirects If ICMP Redirect messages are enabled on any external interfaces, this is a finding.

Fix: F-22789r409745_fix

Disable ICMP redirects on all external interfaces as shown in the example below: SW1(config)# int e2/7 SW1(config-if)# no ip redirects

a
The Cisco switch must be configured to log all packets that have been dropped at interfaces via an ACL.
AU-3 - Low - CCI-000134 - V-221086 - SV-221086r999695_rule
RMF Control
AU-3
Severity
Low
CCI
CCI-000134
Version
CISC-RT-000200
Vuln IDs
  • V-221086
  • V-101887
Rule IDs
  • SV-221086r999695_rule
  • SV-110991
Auditing and logging are key components of any security architecture. It is essential for security personnel to know what is being done or attempted to be done, and by whom, to compile an accurate risk assessment. Auditing the actions on network devices provides a means to recreate an attack or identify a configuration mistake on the device.
Checks: C-22801r409747_chk

Review all ACLs used to filter traffic and verify that packets being dropped are logged as shown in the configuration below: ip access-list EXTERNAL_ACL 10 permit tcp x.11.1.1/32 eq bgp x.11.1.2/32 20 permit tcp x.11.1.1/32 x.11.1.2/32 eq bgp 30 permit icmp x.11.1.1/32 x.11.1.2/32 echo … … … 90 deny ip any any log If packets being dropped at an interface are not logged, this is a finding.

Fix: F-22790r409748_fix

Configure ACLs to log packets that are dropped as shown in the example below: SW1(config)# ip access-list EXTERNAL_ACL SW1(config-acl)# 90 deny ip any any log SW1(config-acl)# end

c
The Cisco perimeter switch must be configured to deny network traffic by default and allow network traffic by exception.
SC-7 - High - CCI-001109 - V-221087 - SV-221087r999696_rule
RMF Control
SC-7
Severity
High
CCI
CCI-001109
Version
CISC-RT-000240
Vuln IDs
  • V-221087
  • V-101889
Rule IDs
  • SV-221087r999696_rule
  • SV-110993
A deny-all, permit-by-exception network communications traffic policy ensures that only connections that are essential and approved are allowed. This requirement applies to both inbound and outbound network communications traffic. All inbound and outbound traffic must be denied by default. Firewalls and perimeter switches should only allow traffic through that is explicitly permitted. The initial defense for the internal network is to block any traffic at the perimeter that is attempting to make a connection to a host residing on the internal network. In addition, allowing unknown or undesirable outbound traffic by the firewall or switch will establish a state that will permit the return of this undesirable traffic inbound.
Checks: C-22802r409750_chk

Review the switch 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 Ethernet1/2 no switchport ip access-group EXTERNAL_ACL in ip address x.11.1.2 255.255.255.254 Step 2: Review inbound ACL to verify that it is configured to deny all other traffic that is not explicitly allowed. ip access-list EXTERNAL_ACL 10 permit tcp x.11.1.1/32 eq bgp x.11.1.2/32 20 permit tcp x.11.1.1/32 x.11.1.2/32 eq bgp 30 permit icmp x.11.1.1/32 x.11.1.2/32 echo 40 permit icmp x.11.1.1/32 x.11.1.2/32 echo-reply 50 permit tcp any x.11.2.3/32 eq www 60 permit … … … … 90 deny ip any any log 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-22791r409751_fix

Step 1: Configure an inbound ACL to deny all other traffic by default as shown in the example below: SW1(config)# ip access-list EXTERNAL_ACL SW1(config-acl)# permit tcp host x.11.1.1 eq bgp host x.11.1.2 SW1(config-acl)# permit tcp host x.11.1.1 host x.11.1.2 eq bgp SW1(config-acl)# permit icmp host x.11.1.1 host x.11.1.2 echo SW1(config-acl)# permit icmp host x.11.1.1 host x.11.1.2 echo-reply SW1(config-acl)# permit tcp any x.11.2.3/32 eq www SW1(config-acl)# permit … … … … SW1(config-acl)# deny ip any any log Step 2: Apply the ingress filter to all external interfaces. SW1(config)#int e1/2 SW1(config-if)#ip access-group EXTERNAL_ACL in

b
The Cisco perimeter switch must be configured to enforce approved authorizations for controlling the flow of information between interconnected networks in accordance with applicable policy.
AC-4 - Medium - CCI-001414 - V-221088 - SV-221088r999697_rule
RMF Control
AC-4
Severity
Medium
CCI
CCI-001414
Version
CISC-RT-000250
Vuln IDs
  • V-221088
  • V-101891
Rule IDs
  • SV-221088r999697_rule
  • SV-110995
Information flow control regulates authorized information to travel within a network and between interconnected networks. Controlling the flow of network traffic is critical so it does not introduce any unacceptable risk to the network infrastructure or data. An example of a flow control restriction is blocking outside traffic claiming to be from within the organization. For most switches, internal information flow control is a product of system design.
Checks: C-22803r409753_chk

Review the switch configuration to verify that ACLs are configured to allow or deny traffic for specific destination addresses as well as ports and protocols. In the example below, the switch 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.11.2.3). Step 1: Verify that an inbound ACL is applied to all external interfaces as shown in the example below: interface Ethernet2/2 description link to DISN no switchport ip access-group EXTERNAL_ACL in ip address x.11.1.2 255.255.255.254 Step 2: Review inbound ACL to verify that it is configured to deny all other traffic that is not explicitly allowed. ip access-list EXTERNAL_ACL 10 permit tcp any any established 20 permit tcp x.11.1.1/32 eq bgp x.11.1.2/32 30 permit tcp x.11.1.1/32 x.11.1.2/32 eq bgp 40 permit icmp x.11.1.1/32 x.11.1.2/32 echo 50 permit icmp x.11.1.1/32 x.11.1.2/32 echo-reply 60 permit tcp any x.11.2.3/32 eq www 70 permit … … … … 90 deny ip any any log If the switch is not configured to enforce approved authorizations for controlling the flow of information between interconnected networks, this is a finding.

Fix: F-22792r409754_fix

Step 1: Configure an ACL to allow or deny traffic as shown in the example below: SW2(config)# ip access-list EXTERNAL_ACL SW2(config-acl)# permit tcp any any established SW2(config-acl)# permit tcp x.11.1.1/32 eq bgp x.11.1.2/32 SW2(config-acl)# permit tcp x.11.1.1/32 x.11.1.2/32 eq bgp SW2(config-acl)# permit icmp x.11.1.1/32 x.11.1.2/32 echo SW2(config-acl)# permit icmp x.11.1.1/32 x.11.1.2/32 echo-reply SW2(config-acl)# permit tcp any x.11.2.3/32 eq www SW2(config-acl)# deny ip any any log SW2(config-acl)# exit Step 2: Apply the ACL inbound on all applicable interfaces. SW1(config)#int e2/2 SW1(config-if)# ip access-group EXTERNAL_ACL in

b
The Cisco perimeter switch must be configured to only allow incoming communications from authorized sources to be routed to authorized destinations.
SC-7 - Medium - CCI-002403 - V-221089 - SV-221089r999698_rule
RMF Control
SC-7
Severity
Medium
CCI
CCI-002403
Version
CISC-RT-000260
Vuln IDs
  • V-221089
  • V-101893
Rule IDs
  • SV-221089r999698_rule
  • SV-110997
Unrestricted traffic may contain malicious traffic that poses a threat to an enclave or to other connected networks. Additionally, unrestricted traffic may transit a network, which uses bandwidth and other resources. Traffic can be restricted directly by an access control list (ACL), which is a firewall function, or by Policy Routing. Policy Routing is a technique used to make routing decisions based on a number of different criteria other than just the destination network, including source or destination network, source or destination address, source or destination port, protocol, packet size, and packet classification. This overrides the switch's normal routing procedures used to control the specific paths of network traffic. It is normally used for traffic engineering but can also be used to meet security requirements; for example, traffic that is not allowed can be routed to the Null0 or discard interface. Policy Routing can also be used to control which prefixes appear in the routing table. This requirement is intended to allow network administrators the flexibility to use whatever technique is most effective.
Checks: C-22804r409756_chk

Review the switch configuration to determine if the switch 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. ip access-list EXTERNAL_ACL 10 permit tcp any any established 20 permit tcp x.11.1.1/32 eq bgp x.11.1.2/32 30 permit tcp x.11.1.1/32 x.11.1.2/32 eq bgp 40 permit icmp x.11.1.1/32 x.11.1.2/32 echo 50 permit icmp x.11.1.1/32 x.11.1.2/32 echo-reply 60 permit tcp any x.11.2.3/32 eq www 70 permit udp x.12.1.9/32 x.12.1.21/32 eq ntp … … … 90 deny ip any any log If the switch does not restrict incoming communications to allow only authorized sources and destinations, this is a finding.

Fix: F-22793r409757_fix

Configure the switch to allow only incoming communications from authorized sources to be routed to authorized destinations. SW2(config)# ip access-list EXTERNAL_ACL SW2(config-acl)# permit tcp any any established … … … SW2(config-acl)# permit udp host x.12.1.9 host x.12.1.21 eq ntp SW2(config-acl)# deny ip any any log SW2(config-acl)# end

b
The Cisco perimeter switch must be configured to block inbound packets with source Bogon IP address prefixes.
SC-7 - Medium - CCI-002403 - V-221090 - SV-221090r999699_rule
RMF Control
SC-7
Severity
Medium
CCI
CCI-002403
Version
CISC-RT-000270
Vuln IDs
  • V-221090
  • V-101895
Rule IDs
  • SV-221090r999699_rule
  • SV-110999
Packets with Bogon IP source addresses should never be allowed to traverse the IP core. Bogon IP networks are RFC1918 addresses or address blocks that have never been assigned by the IANA or have been reserved.
Checks: C-22805r409759_chk

Review the switch 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: ip access-list EXTERNAL_ACL 10 deny ip 0.0.0.0/8 any log 20 deny ip 10.0.0.0/8 any log 30 deny ip 100.64.0.0/10 any log 40 deny ip 127.0.0.0/8 any log 50 deny ip 169.254.0.0/16 any log 60 deny ip 172.16.0.0/12 any log 70 deny ip 192.0.0.0/24 any log 80 deny ip 192.0.2.0/24 any log 90 deny ip 192.168.0.0/16 any log 100 deny ip 198.18.0.0/15 any log 110 deny ip 198.51.100.0/24 any log 120 deny ip 203.0.113.0/24 any log 130 deny ip 224.0.0.0/3 any log 140 permit tcp any any established 150 permit … … … … 210 deny ip any any log Step 2: Verify that the inbound ACL applied to all external interfaces will block all traffic from Bogon source addresses. interface Ethernet2/2 description link to DISN no switchport ip access-group EXTERNAL_ACL in If the switch is not configured to block inbound packets with source Bogon IP address prefixes, this is a finding.

Fix: F-22794r409760_fix

Configure the perimeter to block inbound packets with Bogon source addresses. Step 1: Configure an ACL containing the current Bogon prefixes as shown below: SW1(config)# ip access-list EXTERNAL_ACL SW1(config-acl)# deny ip 0.0.0.0 0.255.255.255 any log SW1(config-acl)# deny ip 10.0.0.0 0.255.255.255 any log SW1(config-acl)# deny ip 100.64.0.0 0.63.255.255 any log SW1(config-acl)# deny ip 127.0.0.0 0.255.255.255 any log SW1(config-acl)# deny ip 169.254.0.0 0.0.255.255 any log SW1(config-acl)# deny ip 172.16.0.0 0.15.255.255 any log SW1(config-acl)# deny ip 192.0.0.0 0.0.0.255 any log SW1(config-acl)# deny ip 192.0.2.0 0.0.0.255 any log SW1(config-acl)# deny ip 192.168.0.0 0.0.255.255 any log SW1(config-acl)# deny ip 198.18.0.0 0.1.255.255 any log SW1(config-acl)# deny ip 198.51.100.0 0.0.0.255 any log SW1(config-acl)# deny ip 203.0.113.0 0.0.0.255 any log SW1(config-acl)# deny ip 224.0.0.0 31.255.255.255 any log SW1(config-acl)# deny ip 240.0.0.0 31.255.255.255 any log SW1(config-acl)# permit tcp any any established SW1(config-acl)# permit … … … … SW1(config-acl)# deny ip any any log SW1(config-acl)# end Step 2: Apply the ACL inbound on all external interfaces. SW1(config)#int e2/2 SW1(config-if)# ip access-group EXTERNAL_ACL in SW1(config-if)# end

c
The Cisco perimeter switch must be configured to restrict it from accepting outbound IP packets that contain an illegitimate address in the source address field via egress filter or by enabling Unicast Reverse Path Forwarding (uRPF).
SC-5 - High - CCI-001094 - V-221091 - SV-221091r999700_rule
RMF Control
SC-5
Severity
High
CCI
CCI-001094
Version
CISC-RT-000310
Vuln IDs
  • V-221091
  • V-101897
Rule IDs
  • SV-221091r999700_rule
  • SV-111001
A compromised host in an enclave can be used by a malicious platform to launch cyberattacks on third parties. This is a common practice in "botnets", which are a collection of compromised computers using malware to attack other computers or networks. DDoS attacks frequently leverage IP source address spoofing to send packets to multiple hosts that in turn will then send return traffic to the hosts with the IP addresses that were forged. This can generate significant amounts of traffic. Therefore, protection measures to counteract IP source address spoofing must be taken. When uRPF is enabled in strict mode, the packet must be received on the interface that the device would use to forward the return packet, thereby mitigating IP source address spoofing.
Checks: C-22806r409762_chk

Review the switch configuration to verify uRPF or an egress ACL has been configured on all internal interfaces to restrict the switch from accepting outbound IP packets that contain an illegitimate address in the source address field. uRPF example interface Ethernet2/4 description downstream link to LAN no switchport ip address 10.1.12.1/24 ip verify unicast source reachable-via rx Egress ACL example ip access-list EGRESS_FILTER 10 permit udp 10.1.15.0/24 any eq domain 20 permit tcp 10.1.15.0/24 any eq ftp 30 permit tcp 10.1.15.0/24 any eq ftp-data 40 permit tcp 10.1.15.0/24 any eq www 50 permit icmp 10.1.15.0/24 any 60 permit icmp 10.1.15.0/24 any echo 70 deny ip any any … … … interface Ethernet2/4 description downstream link to LAN no switchport ip access-group EGRESS_FILTER in ip address 10.1.12.1/24 If uRPF or an egress ACL to restrict the switch 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-22795r409763_fix

Configure the switch to ensure that an egress ACL or uRPF is configured on internal interfaces to restrict the switch from accepting any outbound IP packet that contains an illegitimate address in the source field. The example below enables uRPF. SW1(config)# int e2/4 SW1(config-if)# ip verify unicast source reachable-via rx SW1(config-if)# end

b
The Cisco perimeter switch must be configured to filter traffic destined to the enclave in accordance with the guidelines contained in DoD Instruction 8551.1.
SC-7 - Medium - CCI-001097 - V-221092 - SV-221092r999701_rule
RMF Control
SC-7
Severity
Medium
CCI
CCI-001097
Version
CISC-RT-000320
Vuln IDs
  • V-221092
  • V-101899
Rule IDs
  • SV-221092r999701_rule
  • SV-111003
Vulnerability assessments must be reviewed by the System Administrator, and protocols must be approved by the Information Assurance (IA) staff before entering the enclave. ACLs are the first line of defense in a layered security approach. They permit authorized packets and deny unauthorized packets based on port or service type. They enhance the posture of the network by not allowing packets to reach a potential target within the security domain. The lists provided are highly susceptible ports and services that should be blocked or limited as much as possible without adversely affecting customer requirements. Auditing packets attempting to penetrate the network that are stopped by an ACL will allow network administrators to broaden their protective ring and more tightly define the scope of operation. If the perimeter is in a Deny-by-Default posture and what is allowed through the filter is in accordance with DoD Instruction 8551.1, and if the permit rule is explicitly defined with explicit ports and protocols allowed, then all requirements related to PPS being blocked would be satisfied.
Checks: C-22807r409765_chk

Review the switch 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 Ethernet2/2 description link to DISN no switchport ip access-group EXTERNAL_ACL in Step 2. Review the inbound ACL to verify that it is filtering traffic in accordance with DoD 8551.1. ip access-list EXTERNAL_ACL 10 permit tcp any any established 20 permit tcp x.11.1.1/32 eq bgp x.11.1.2/32 30 permit tcp x.11.1.1/32 x.11.1.2/32 eq bgp 40 permit icmp x.11.1.1/32 x.11.1.2/32 echo 50 permit icmp x.11.1.1/32 x.11.1.2/32 echo-reply 60 permit tcp any x.11.2.3/32 eq www 70 permit udp x.12.1.9/32 x.12.1.21/32 eq ntp … … < must be in accordance with DoD Instruction 8551.1> … 140 deny ip any any log If the switch does not filter traffic in accordance with the guidelines contained in DoD 8551, this is a finding.

Fix: F-22796r409766_fix

Configure the switch 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. SW2(config)# ip access-list EXTERNAL_ACL SW2(config-acl)# permit tcp any any established SW2(config-acl)# permit tcp x.11.1.1/32 eq bgp x.11.1.2/32 SW2(config-acl)# permit tcp x.11.1.1/32 x.11.1.2/32 eq bgp SW2(config-acl)# permit icmp x.11.1.1/32 x.11.1.2/32 echo SW2(config-acl)# permit icmp x.11.1.1/32 x.11.1.2/32 echo-reply SW2(config-acl)# permit tcp any x.11.2.3/32 eq www … … < must be in accordance with DoD Instruction 8551.1> … SW2(config-acl)# deny ip any any log SW2(config-acl)# exit SW1(config)#int e2/2 SW1(config-if)# ip access-group EXTERNAL_ACL in SW1(config-if)# end

b
The Cisco perimeter switch must be configured to filter ingress traffic at the external interface on an inbound direction.
SC-7 - Medium - CCI-001097 - V-221093 - SV-221093r999702_rule
RMF Control
SC-7
Severity
Medium
CCI
CCI-001097
Version
CISC-RT-000330
Vuln IDs
  • V-221093
  • V-101901
Rule IDs
  • SV-221093r999702_rule
  • SV-111005
Access lists are used to separate data traffic into that which it will route (permitted packets) and that which it will not route (denied packets). Secure configuration of switches makes use of access lists for restricting access to services on the switch itself as well as for filtering traffic passing through the switch. Inbound versus Outbound: It should be noted that some operating systems default access lists are applied to the outbound queue. The more secure solution is to apply the access list to the inbound queue for three reasons: - The switch can protect itself before damage is inflicted. - The input port is still known and can be filtered upon. - It is more efficient to filter packets before routing them.
Checks: C-22808r409768_chk

Review the switch configuration to verify that an inbound ACL is configured on all external interfaces as shown in the example below: interface Ethernet2/2 description link to DISN no switchport ip access-group EXTERNAL_ACL in If the switch is not configured to filter traffic entering the network at all external interfaces in an inbound direction, this is a finding.

Fix: F-22797r409769_fix

Configure the switch to use an inbound ACL on all external interfaces as shown in the example below: SW1(config)#int e2/2 SW1(config-if)# ip access-group EXTERNAL_ACL in SW1(config-if)# end

b
The Cisco perimeter switch must be configured to filter egress traffic at the internal interface on an inbound direction.
SC-7 - Medium - CCI-001097 - V-221094 - SV-221094r999703_rule
RMF Control
SC-7
Severity
Medium
CCI
CCI-001097
Version
CISC-RT-000340
Vuln IDs
  • V-221094
  • V-101903
Rule IDs
  • SV-221094r999703_rule
  • SV-111007
Access lists are used to separate data traffic into that which it will route (permitted packets) and that which it will not route (denied packets). Secure configuration of switches makes use of access lists for restricting access to services on the switch itself as well as for filtering traffic passing through the switch. Inbound versus Outbound: It should be noted that some operating systems default access lists are applied to the outbound queue. The more secure solution is to apply the access list to the inbound queue for three reasons: - The switch can protect itself before damage is inflicted. - The input port is still known and can be filtered upon. - It is more efficient to filter packets before routing them.
Checks: C-22809r409771_chk

Review the switch configuration to verify that the egress ACL is bound to the internal interface in an inbound direction. interface Ethernet2/4 description downstream link to LAN no switchport ip access-group EGRESS_FILTER in ip address 10.1.12.1/24 If the switch is not configured to filter traffic leaving the network at the internal interface in an inbound direction, this is a finding.

Fix: F-22798r409772_fix

Configure the switch to use an inbound ACL on all internal interfaces as shown in the example below: SW1(config)# int e2/4 SW1(config-if)# ip access-group EGRESS_FILTER in SW1(config-if)# end

b
The Cisco perimeter switch must be configured to block all packets with any IP options.
SC-7 - Medium - CCI-002403 - V-221095 - SV-221095r999704_rule
RMF Control
SC-7
Severity
Medium
CCI
CCI-002403
Version
CISC-RT-000350
Vuln IDs
  • V-221095
  • V-101905
Rule IDs
  • SV-221095r999704_rule
  • SV-111009
Packets with IP options are not fast switched and henceforth must be punted to the switch processor. Hackers who initiate denial-of-service (DoS) attacks on switches commonly send large streams of packets with IP options. Dropping the packets with IP options reduces the load of IP options packets on the switch. The end result is a reduction in the effects of the DoS attack on the switch and on downstream switches.
Checks: C-22810r409774_chk

In Cisco NX-OS, all packets with any header option other than the “source-route” header option are dropped. By default, ipv4 source routing is enabled. Verify that source routing is disabled via the following command: no ip source-route If the switch is not configured to drop all packets with IP option source routing, this is a finding.

Fix: F-22799r409775_fix

Configure the switch to drop all packets with IP option source routing. SW1(config)# no ip source-route SW1(config)# end

a
The Cisco perimeter switch must be configured to have Link Layer Discovery Protocol (LLDP) disabled on all external interfaces.
SC-7 - Low - CCI-002403 - V-221096 - SV-221096r999705_rule
RMF Control
SC-7
Severity
Low
CCI
CCI-002403
Version
CISC-RT-000360
Vuln IDs
  • V-221096
  • V-101907
Rule IDs
  • SV-221096r999705_rule
  • SV-111011
LLDP is a neighbor discovery protocol used to advertise device capabilities, configuration information, and device identity. LLDP is media-and-protocol-independent as it runs over layer 2; therefore, two network nodes that support different layer 3 protocols can still learn about each other. Allowing LLDP messages to reach external network nodes provides an attacker a method to obtain information of the network infrastructure that can be useful to plan an attack.
Checks: C-22811r409777_chk

Step 1: Verify LLDP is not enabled globally via the command feature lldp. By default the LLDP feature is not enabled. If LLDP is enabled, proceed to Step 2. Step 2: Verify LLDP is not enabled on any external interface as shown in the example below: interface Ethernet2/2 description link to DISN no switchport no lldp transmit Note: LLDP is enabled by default on all interfaces once it is enabled globally; hence the command lldp transmit will not be visible on the interface configuration. If LLDP transmit is enabled on any external interface, this is a finding.

Fix: F-22800r409778_fix

Disable LLDP transmit on all external interfaces as shown in the example below: SW2(config)# int e2/2 SW2(config-if)# no lldp transmit SW2(config-if)# end

a
The Cisco perimeter switch must be configured to have Cisco Discovery Protocol (CDP) disabled on all external interfaces.
SC-7 - Low - CCI-002403 - V-221097 - SV-221097r999706_rule
RMF Control
SC-7
Severity
Low
CCI
CCI-002403
Version
CISC-RT-000370
Vuln IDs
  • V-221097
  • V-101909
Rule IDs
  • SV-221097r999706_rule
  • SV-111013
CDP is a Cisco proprietary neighbor discovery protocol used to advertise device capabilities, configuration information, and device identity. CDP is media-and-protocol-independent as it runs over layer 2; therefore, two network nodes that support different layer 3 protocols can still learn about each other. Allowing CDP messages to reach external network nodes provides an attacker a method to obtain information of the network infrastructure that can be useful to plan an attack.
Checks: C-22812r409780_chk

Step 1: Verify CDP is not enabled globally via the command no cdp enable By default CDP is enabled globally; hence, the command cdp enable 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 Ethernet2/2 description link to DISN no switchport no cdp enable Note: By default CDP is enabled on all interfaces if CDP is enabled globally. If CDP is enabled on any external interface, this is a finding.

Fix: F-22801r409781_fix

Disable CDP on all external interfaces via no cdp enable interface command or disable CDP globally via no cdp enable command.

b
The Cisco perimeter switch must be configured to have Proxy ARP disabled on all external interfaces.
SC-7 - Medium - CCI-002403 - V-221098 - SV-221098r999707_rule
RMF Control
SC-7
Severity
Medium
CCI
CCI-002403
Version
CISC-RT-000380
Vuln IDs
  • V-221098
  • V-101911
Rule IDs
  • SV-221098r999707_rule
  • SV-111015
When Proxy ARP is enabled on a switch, it allows that switch to extend the network (at Layer 2) across multiple interfaces (LAN segments). Because proxy ARP allows hosts from different LAN segments to look like they are on the same segment, proxy ARP is only safe when used between trusted LAN segments. Attackers can leverage the trusting nature of proxy ARP by spoofing a trusted host and then intercepting packets. Proxy ARP should always be disabled on switch interfaces that do not require it, unless the switch is being used as a LAN bridge.
Checks: C-22813r409783_chk

Review the switch configuration to determine if IP Proxy ARP is enabled on any external interface as shown in the example below: interface Ethernet2/2 description link to DISN no switchport ip address x.1.12.2/24 ip proxy-arp no shutdown Note: By default Proxy ARP is disabled on all interfaces. If IP Proxy ARP is enabled on any external interface, this is a finding.

Fix: F-22802r409784_fix

Disable Proxy ARP on all external interfaces as shown in the example below: SW1(config)#int e2/2 SW1(config-if)# no ip proxy-arp SW1(config-if)# end

b
The Cisco perimeter switch must be configured to block all outbound management traffic.
SC-7 - Medium - CCI-001097 - V-221099 - SV-221099r999708_rule
RMF Control
SC-7
Severity
Medium
CCI
CCI-001097
Version
CISC-RT-000390
Vuln IDs
  • V-221099
  • V-101913
Rule IDs
  • SV-221099r999708_rule
  • SV-111017
For in-band management, the management network must have its own subnet in order to enforce control and access boundaries provided by Layer 3 network nodes, such as switches and firewalls. Management traffic between the managed network elements and the management network is routed via the same links and nodes as that used for production or operational traffic. Safeguards must be implemented to ensure that the management traffic does not leak past the perimeter of the managed network.
Checks: C-22814r409786_chk

The perimeter switch 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 Ethernet2/2 description link to DISN no switchport ip access-group EXTERNAL_ACL_OUTBOUND out ip address x.11.1.2 255.255.255.254 Step 2: Verify that the outbound ACL discards management traffic as shown in the example below: ip access-list EXTERNAL_ACL_OUTBOUND 10 deny tcp any any eq tacacs log 20 deny tcp any any eq 22 log 30 deny udp any any eq snmp log 40 deny udp any any eq snmptrap log 50 deny udp any any eq syslog log 60 permit tcp any any eq www log 70 deny ip any any log If management traffic is not blocked at the perimeter, this is a finding.

Fix: F-22803r409787_fix

Configure the perimeter switch 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. SW1(config)# ip access-list EXTERNAL_ACL_OUTBOUND SW1(config-acl)# deny tcp any any eq tacacs log SW1(config-acl)# deny tcp any any eq 22 log SW1(config-acl)# deny udp any any eq snmp log SW1(config-acl)# deny udp any any eq snmptrap log SW1(config-acl)# deny udp any any eq syslog log SW1(config-acl)# permit tcp any any eq www SW1(config-acl)# deny ip any any log SW1(config-acl)# exit 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. SW1(config)#int e2/2 SW1(config-if)# ip access-group EXTERNAL_ACL_OUTBOUND out

b
The Cisco switch must be configured to only permit management traffic that ingresses and egresses the out-of-band management (OOBM) interface.
SC-7 - Medium - CCI-001097 - V-221100 - SV-221100r999709_rule
RMF Control
SC-7
Severity
Medium
CCI
CCI-001097
Version
CISC-RT-000450
Vuln IDs
  • V-221100
  • V-101915
Rule IDs
  • SV-221100r999709_rule
  • SV-111019
The OOBM access switch will connect to the management interface of the managed network elements. The management interface can be a true OOBM interface or a standard interface functioning as the management interface. In either case, the management interface of the managed network element will be directly connected to the OOBM network. An OOBM interface does not forward transit traffic, thereby providing complete separation of production and management traffic. Since all management traffic is immediately forwarded into the management network, it is not exposed to possible tampering. The separation also ensures that congestion or failures in the managed network do not affect the management of the device. If the device does not have an OOBM port, the interface functioning as the management interface must be configured so that management traffic does not leak into the managed network and that production traffic does not leak into the management network.
Checks: C-22815r409789_chk

This requirement is only applicable where management access to the switch 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 Ethernet2/7 description link to OOBM access switch no switchport ip address 10.11.1.22 255.255.255.0 ip access-group INGRESS_MANAGEMENT_ACL in ip access-group EGRESS_MANAGEMENT_ACL in Step 2: Verify that the ingress ACL only allows management and ICMP traffic. ip access-list INGRESS_MANAGEMENT_ACL 10 permit tcp any 10.11.1.22/32 eq tacacs 20 permit tcp any 10.11.1.22/32 eq 22 30 permit udp any 10.11.1.22/32 eq snmp 40 permit udp any 10.11.1.22/32 eq snmptrap 50 permit udp any 10.11.1.22/32 eq ntp 60 permit icmp any 10.11.1.22/32 70 deny ip any any log Step 3: Verify that the egress ACL blocks any transit traffic. ip access-list MGMT_TRAFFIC_ACL 10 deny ip any any log Note: On Cisco switches, local generated packets are not inspected by outgoing interface access-lists. Hence, the above configuration would simply drop any packets not generated by the switch; hence, blocking any transit traffic. If the switch does not restrict traffic that ingresses and egresses the management interface, this is a finding.

Fix: F-22804r409790_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: SW1(config)#ip access-list INGRESS_MANAGEMENT_ACL SW1(config-acl)# permit tcp any host 10.11.1.22 eq tacacs SW1(config-acl)# permit tcp any host 10.11.1.22 eq 22 SW1(config-acl)# permit udp any host 10.11.1.22 eq snmp SW1(config-acl)# permit udp any host 10.11.1.22 eq snmptrap SW1(config-acl)# permit udp any host 10.11.1.22 eq ntp SW1(config-acl)# permit icmp any host 10.11.1.22 SW1(config-acl)# deny ip any any log SW1(config-acl)# exit Step 2: Configure an egress ACL a shown in the example below: SW1(config)# ip access-list EGRESS_MANAGEMENT_ACL SW1(config-acl)# deny ip any any log SW1(config-acl)# exit Step 3: Apply the ACLs to the OOBM interfaces. SW1(config)#int e2/7 SW1(config-if) ip access-group INGRESS_MANAGEMENT_ACL in SW1(config-if) ip access-group EGRESS_MANAGEMENT_ACL out

a
The Cisco BGP switch must be configured to check whether a single-hop eBGP peer is directly connected.
SC-5 - Low - CCI-002385 - V-221101 - SV-221101r999710_rule
RMF Control
SC-5
Severity
Low
CCI
CCI-002385
Version
CISC-RT-000470
Vuln IDs
  • V-221101
  • V-101917
Rule IDs
  • SV-221101r999710_rule
  • SV-111021
As described in RFC 3682, GTSM is designed to protect a switch's IP-based control plane from DoS attacks. Many attacks focused on CPU load and line-card overload can be prevented by implementing GTSM on all Exterior Border Gateway Protocol-speaking switches. GTSM is based on the fact that the vast majority of control plane peering is established between adjacent switches; that is, the Exterior Border Gateway Protocol peers are either between connecting interfaces or between loopback interfaces. Since TTL spoofing is considered nearly impossible, a mechanism based on an expected TTL value provides a simple and reasonably robust defense from infrastructure attacks based on forged control plane traffic.
Checks: C-22816r409792_chk

Review the BGP configuration to verify that checking whether a single-hop eBGP peer is directly connected. The example below disables this mechanism. router bgp xx router-id 10.1.1.1 neighbor x.1.12.2 remote-as xx disable-connected-check address-family ipv4 unicast Note: BGP triggers a connection check automatically for all eBGP peers that are known to be a single hop away, unless this check is disabled with the disable-connected-check command. BGP does not bring up sessions if the check fails. If the switch is configured to disable checking whether a single-hop eBGP peer is directly connected, this is a finding.

Fix: F-22805r409793_fix

Remove the command that disables checking whether a single-hop eBGP peer is directly connected for all external BGP neighbors as shown in the example below: SW1(config)# router bgp xx SW1(config-router)# neighbor x.1.12.2 SW1(config-router-neighbor)# no disable-connected-check SW1(config-router-neighbor)# end

b
The Cisco BGP switch must be configured to use a unique key for each autonomous system (AS) that it peers with.
CM-6 - Medium - CCI-000366 - V-221102 - SV-221102r999711_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
CISC-RT-000480
Vuln IDs
  • V-221102
  • V-101919
Rule IDs
  • SV-221102r999711_rule
  • SV-111023
If the same keys are used between eBGP neighbors, the chance of a hacker compromising any of the BGP sessions increases. It is possible that a malicious user exists in one autonomous system who would know the key used for the eBGP session. This user would then be able to hijack BGP sessions with other trusted neighbors.
Checks: C-22817r409795_chk

Review the BGP configuration to determine if it is peering with multiple autonomous systems. Interview the ISSM and switch administrator to determine if unique keys are being used. router bgp xx router-id 10.1.1.1 neighbor x.1.12.2 remote-as 2 password 3 7b07d1b3023056a9 address-family ipv4 unicast neighbor x.2.44.4 remote-as xx password 3 f07a10cb41db8bb6f8f0a340049a9b02 address-family ipv4 unicast If unique keys are not being used, this is a finding.

Fix: F-22806r409796_fix

Configure the switch to use unique keys for each AS that it peers with as shown in the example below: SW1(config)# router bgp xx SW1(config-router)# neighbor x.1.12.2 SW1(config-router-neighbor)# password yyyyyyyyy SW1(config-router-neighbor)# exit SW1(config-router)# neighbor x.2.44.4 SW1(config-router-neighbor)# password zzzzzzzzzz SW1(config-router-neighbor)# end

b
The Cisco BGP switch must be configured to reject inbound route advertisements for any Bogon prefixes.
AC-4 - Medium - CCI-001368 - V-221103 - SV-221103r999712_rule
RMF Control
AC-4
Severity
Medium
CCI
CCI-001368
Version
CISC-RT-000490
Vuln IDs
  • V-221103
  • V-101921
Rule IDs
  • SV-221103r999712_rule
  • SV-111025
Accepting route advertisements for Bogon prefixes can result in the local autonomous system (AS) becoming a transit for malicious traffic as it will in turn advertise these prefixes to neighbor autonomous systems.
Checks: C-22818r409798_chk

Review the switch configuration to verify that it will reject BGP routes for any Bogon prefixes. Step 1: Verify a prefix list has been configured containing the current Bogon prefixes as shown in the example below: ip prefix-list PREFIX_FILTER seq 5 deny 0.0.0.0/8 le 32 ip prefix-list PREFIX_FILTER seq 10 deny 10.0.0.0/8 le 32 ip prefix-list PREFIX_FILTER seq 15 deny 100.64.0.0/10 le 32 ip prefix-list PREFIX_FILTER seq 20 deny 127.0.0.0/8 le 32 ip prefix-list PREFIX_FILTER seq 25 deny 169.254.0.0/16 le 32 ip prefix-list PREFIX_FILTER seq 30 deny 172.16.0.0/12 le 32 ip prefix-list PREFIX_FILTER seq 35 deny 192.0.2.0/24 le 32 ip prefix-list PREFIX_FILTER seq 40 deny 192.88.99.0/24 le 32 ip prefix-list PREFIX_FILTER seq 45 deny 192.168.0.0/16 le 32 ip prefix-list PREFIX_FILTER seq 50 deny 198.18.0.0/15 le 32 ip prefix-list PREFIX_FILTER seq 55 deny 198.51.100.0/24 le 32 ip prefix-list PREFIX_FILTER seq 60 deny 203.0.113.0/24 le 32 ip prefix-list PREFIX_FILTER seq 65 deny 224.0.0.0/4 le 32 ip prefix-list PREFIX_FILTER seq 70 deny 240.0.0.0/4 le 32 ip prefix-list PREFIX_FILTER seq 75 permit 0.0.0.0/0 ge 8 Step 2: Verify that the prefix list has been applied to all external BGP peers as shown in the example below: router bgp xx router-id 10.1.1.1 neighbor x.1.12.2 remote-as xx password 3 7b07d1b3023056a9 address-family ipv4 unicast prefix-list PREFIX_FILTER in neighbor x.2.44.4 remote-as xx password 3 f07a10cb41db8bb6f8f0a340049a9b02 address-family ipv4 unicast prefix-list PREFIX_FILTER in Route Map Alternative Verify that the route map applied to the external neighbors references the configured Bogon prefix list shown above. route-map FILTER_PREFIX_MAP permit 10 match ip address prefix-list PREFIX_FILTER … … … router bgp xx router-id 10.1.1.1 neighbor x.1.12.2 remote-as xx password 3 7b07d1b3023056a9 address-family ipv4 unicast route-map FILTER_PREFIX_MAP in neighbor x.2.44.4 remote-as xx password 3 f07a10cb41db8bb6f8f0a340049a9b02 address-family ipv4 unicast route-map FILTER_PREFIX_MAP in If the switch is not configured to reject inbound route advertisements for any Bogon prefixes, this is a finding.

Fix: F-22807r409799_fix

Configure the switch to reject inbound route advertisements for any Bogon prefixes. Step 1: Configure a prefix list containing the current Bogon prefixes as shown below: SW1(config)# ip prefix-list PREFIX_FILTER seq 5 deny 0.0.0.0/8 le 32 SW1(config)# ip prefix-list PREFIX_FILTER seq 10 deny 10.0.0.0/8 le 32 SW1(config)# ip prefix-list PREFIX_FILTER seq 15 deny 100.64.0.0/10 le 32 SW1(config)# ip prefix-list PREFIX_FILTER seq 20 deny 127.0.0.0/8 le 32 SW1(config)# ip prefix-list PREFIX_FILTER seq 25 deny 169.254.0.0/16 le 32 SW1(config)# ip prefix-list PREFIX_FILTER seq 30 deny 172.16.0.0/12 le 32 SW1(config)# ip prefix-list PREFIX_FILTER seq 35 deny 192.0.2.0/24 le 32 SW1(config)# ip prefix-list PREFIX_FILTER seq 40 deny 192.88.99.0/24 le 32 SW1(config)# ip prefix-list PREFIX_FILTER seq 45 deny 192.168.0.0/16 le 32 SW1(config)# ip prefix-list PREFIX_FILTER seq 50 deny 198.18.0.0/15 le 32 SW1(config)# ip prefix-list PREFIX_FILTER seq 55 deny 198.51.100.0/24 le 32 SW1(config)# ip prefix-list PREFIX_FILTER seq 60 deny 203.0.113.0/24 le 32 SW1(config)# ip prefix-list PREFIX_FILTER seq 65 deny 224.0.0.0/4 le 32 SW1(config)# ip prefix-list PREFIX_FILTER seq 70 deny 240.0.0.0/4 le 32 SW1(config)# ip prefix-list PREFIX_FILTER seq 75 permit 0.0.0.0/0 ge 8 Step 2: Apply the prefix list filter inbound to each external BGP neighbor as shown in the example below: SW1(config)# router bgp xx SW1(config-router)# neighbor x.1.12.2 SW1(config-router-neighbor)# address-family ipv4 unicast SW1(config-router-neighbor-af)# prefix-list PREFIX_FILTER in SW1(config-router-neighbor-af)# exit SW1(config-router-neighbor)# exit SW1(config-router)# neighbor x.2.44.4 SW1(config-router-neighbor)# address-family ipv4 unicast SW1(config-router-neighbor-af)# prefix-list PREFIX_FILTER in SW1(config-router-neighbor-af)# end Route Map Alternative Step 1: Configure the route map referencing the configured prefix list above. SW1(config)# route-map FILTER_PREFIX_MAP permit 10 SW1(config-route-map)# match ip address prefix-list PREFIX_FILTER SW1(config-route-map)# exit Step 2: Apply the route-map inbound to each external BGP neighbor as shown in the example below: SW1(config)# router bgp xx SW1(config-router)# neighbor x.1.12.2 SW1(config-router-neighbor)# address-family ipv4 unicast SW1(config-router-neighbor-af)# route-map FILTER_PREFIX_MAP in SW1(config-router-neighbor-af)# exit SW1(config-router-neighbor)# exit SW1(config-router)# neighbor x.2.44.4 SW1(config-router-neighbor)# address-family ipv4 unicast SW1(config-router-neighbor-af)# route-map FILTER_PREFIX_MAP in SW1(config-router-neighbor-af)# end

b
The Cisco BGP switch must be configured to reject inbound route advertisements for any prefixes belonging to the local autonomous system (AS).
AC-4 - Medium - CCI-001368 - V-221104 - SV-221104r999713_rule
RMF Control
AC-4
Severity
Medium
CCI
CCI-001368
Version
CISC-RT-000500
Vuln IDs
  • V-221104
  • V-101923
Rule IDs
  • SV-221104r999713_rule
  • SV-111027
Accepting route advertisements belonging to the local AS can result in traffic looping or being black-holed, or at a minimum, using a non-optimized path.
Checks: C-22819r409801_chk

Review the switch configuration to verify that it will reject routes belonging to the local AS. Step 1: Verify a prefix list has been configured containing prefixes belonging to the local AS. In the example below x.13.1.0/24 is the global address space allocated to the local AS. ip prefix-list PREFIX_FILTER seq 5 deny 0.0.0.0/8 le 32 … … … ip prefix-list PREFIX_FILTER seq 74 deny x.13.1.0/24 le 32 ip prefix-list PREFIX_FILTER seq 75 permit 0.0.0.0/0 ge 8 Step 2: Verify that the prefix list has been applied to all external BGP peers as shown in the example below: router bgp xx router-id 10.1.1.1 neighbor x.1.12.2 remote-as xx password 3 7b07d1b3023056a9 address-family ipv4 unicast prefix-list PREFIX_FILTER in neighbor x.2.44.4 remote-as xx password 3 f07a10cb41db8bb6f8f0a340049a9b02 address-family ipv4 unicast prefix-list PREFIX_FILTER in If the switch is not configured to reject inbound route advertisements belonging to the local AS, this is a finding.

Fix: F-22808r409802_fix

Configure the switch to reject inbound route advertisements for any prefixes belonging to the local AS. Step 1: Add to the prefix filter list those prefixes belonging to the local autonomous system. SW1(config)# ip prefix-list PREFIX_FILTER seq 74 deny x.13.1.0/24 le 32 Step 2: If not already completed to be compliant with previous requirement, apply the prefix list filter inbound to each external BGP neighbor as shown in the example below: SW1(config)# router bgp xx SW1(config-router)# neighbor x.1.12.2 SW1(config-router-neighbor)# address-family ipv4 unicast SW1(config-router-neighbor-af)# prefix-list PREFIX_FILTER in SW1(config-router-neighbor-af)# exit SW1(config-router-neighbor)# exit SW1(config-router)# neighbor x.2.44.4 SW1(config-router-neighbor)# address-family ipv4 unicast SW1(config-router-neighbor-af)# prefix-list PREFIX_FILTER in SW1(config-router-neighbor-af)# end

b
The Cisco BGP switch must be configured to reject inbound route advertisements from a customer edge (CE) switch for prefixes that are not allocated to that customer.
AC-4 - Medium - CCI-001368 - V-221105 - SV-221105r999714_rule
RMF Control
AC-4
Severity
Medium
CCI
CCI-001368
Version
CISC-RT-000510
Vuln IDs
  • V-221105
  • V-101925
Rule IDs
  • SV-221105r999714_rule
  • SV-111029
As a best practice, a service provider should only accept customer prefixes that have been assigned to that customer and any peering autonomous systems. A multi-homed customer with BGP speaking switches connected to the Internet or other external networks could be breached and used to launch a prefix de-aggregation attack. Without ingress route filtering of customers, the effectiveness of such an attack could impact the entire IP core and its customers.
Checks: C-22820r409804_chk

Review the switch configuration to verify that there are ACLs defined to only accept routes for prefixes that belong to specific customers. Step 1: Verify prefix list has been configured for each customer containing prefixes belonging to each customer as shown in the example below: ip prefix-list PREFIX_FILTER_CUST1 seq 5 permit x.13.1.0/24 le 32 ip prefix-list PREFIX_FILTER_CUST1 seq 10 deny 0.0.0.0/0 ge 8 ip prefix-list PREFIX_FILTER_CUST2 seq 5 permit x.13.2.0/24 le 32 ip prefix-list PREFIX_FILTER_CUST2 seq 10 deny 0.0.0.0/0 ge 8 Step 2: Verify that the prefix lists has been applied to all to the applicable CE peers as shown in the example below: router bgp xx router-id 10.1.1.1 neighbor x.55.14.2 remote-as 64514 password 3 7b07d1b3023056a9 address-family ipv4 unicast prefix-list FILTER_PREFIXES_CUST1 in neighbor x.55.14.4 remote-as 64516 password 3 f07a10cb41db8bb6f8f0a340049a9b02 address-family ipv4 unicast prefix-list FILTER_PREFIXES_CUST1 in 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 switch is not configured to reject inbound route advertisements from each CE switch for prefixes that are not allocated to that customer, this is a finding.

Fix: F-22809r409805_fix

Configure the switch to reject inbound route advertisements from each CE switch for prefixes that are not allocated to that customer. Step 1: Configure a prefix list for each customer containing prefixes belonging to each. SW1(config)# ip prefix-list PREFIX_FILTER_CUST1 permit x.13.1.0/24 le 32 SW1(config)# ip prefix-list PREFIX_FILTER_CUST1 deny 0.0.0.0/0 ge 8 SW1(config)# ip prefix-list PREFIX_FILTER_CUST2 permit x.13.2.0/24 le 32 SW1(config)# ip prefix-list PREFIX_FILTER_CUST2 deny 0.0.0.0/0 ge 8 Step 2: Apply the prefix list filter inbound to each CE neighbor as shown in the example below: SW1(config)# router bgp xx SW1(config-router)# neighbor x.55.14.2 SW1(config-router-neighbor)# address-family ipv4 unicast SW1(config-router-neighbor-af)# prefix-list PREFIX_FILTER_CUST1 in SW1(config-router-neighbor-af)# exit SW1(config-router-neighbor)# exit SW1(config-router)# neighbor x.55.14.4 SW1(config-router-neighbor)# address-family ipv4 unicast SW1(config-router-neighbor-af)# prefix-list PREFIX_FILTER_CUST2 in SW1(config-router-neighbor-af)# end

b
The Cisco BGP switch must be configured to reject outbound route advertisements for any prefixes that do not belong to any customers or the local autonomous system (AS).
AC-4 - Medium - CCI-001368 - V-221106 - SV-221106r999715_rule
RMF Control
AC-4
Severity
Medium
CCI
CCI-001368
Version
CISC-RT-000520
Vuln IDs
  • V-221106
  • V-101927
Rule IDs
  • SV-221106r999715_rule
  • SV-111031
Advertisement of routes by an autonomous system for networks that do not belong to any of its customers pulls traffic away from the authorized network. This causes a denial of service (DoS) on the network that allocated the block of addresses and may cause a DoS on the network that is inadvertently advertising it as the originator. It is also possible that a misconfigured or compromised switch within the GIG IP core could redistribute Interior Gateway Protocol (IGP) routes into BGP, thereby leaking internal routes.
Checks: C-22821r409807_chk

Step 1: Verify that a prefix list has been configured containing prefixes belonging to customers as well as the local AS as shown in the example below: ip prefix-list CE_PREFIX_ADVERTISEMENTS seq 5 permit x.13.1.0/24 le 32 ip prefix-list CE_PREFIX_ADVERTISEMENTS seq 10 permit x.13.2.0/24 le 32 ip prefix-list CE_PREFIX_ADVERTISEMENTS seq 15 permit x.13.3.0/24 le 32 ip prefix-list CE_PREFIX_ADVERTISEMENTS seq 20 permit x.13.4.0/24 le 32 … … … ip prefix-list CE_PREFIX_ADVERTISEMENTS seq 80 deny 0.0.0.0/0 ge 8 Step 2: Verify that the prefix lists has been applied to all CE peers as shown in the example below: router bgp xx router-id 10.1.1.1 neighbor x.55.14.2 remote-as 64514 password 3 7b07d1b3023056a9 address-family ipv4 unicast prefix-list CE_PREFIX_ADVERTISEMENTS out neighbor x.55.14.4 remote-as 64516 password 3 f07a10cb41db8bb6f8f0a340049a9b02 address-family ipv4 unicast prefix-list CE_PREFIX_ADVERTISEMENTS out If the switch 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-22810r409808_fix

Step 1: Configure a prefix list for containing all customer and local AS prefixes as shown in the example below: SW1(config)#ip prefix-list CE_PREFIX_ADVERTISEMENTS permit x.13.1.0/24 le 32 SW1(config)#ip prefix-list CE_PREFIX_ADVERTISEMENTS permit x.13.2.0/24 le 32 SW1(config)#ip prefix-list CE_PREFIX_ADVERTISEMENTS permit x.13.3.0/24 le 32 SW1(config)#ip prefix-list CE_PREFIX_ADVERTISEMENTS permit x.13.4.0/24 le 32 … … … SW1(config)#ip prefix-list CE_PREFIX_ADVERTISEMENTS deny 0.0.0.0/0 ge 8 Step 2: Apply the prefix list filter outbound to each CE neighbor as shown in the example below: SW1(config)#switch bgp 64512 SW1(config-switch)# neighbor x.12.4.14 prefix-list CE_PREFIX_ADVERTISEMENTS out SW1(config-switch)# neighbor x.12.4.16 prefix-list CE_PREFIX_ADVERTISEMENTS out

b
The Cisco BGP switch must be configured to reject outbound route advertisements for any prefixes belonging to the IP core.
SC-7 - Medium - CCI-001097 - V-221107 - SV-221107r999716_rule
RMF Control
SC-7
Severity
Medium
CCI
CCI-001097
Version
CISC-RT-000530
Vuln IDs
  • V-221107
  • V-101929
Rule IDs
  • SV-221107r999716_rule
  • SV-111033
Outbound route advertisements belonging to the core can result in traffic either looping or being black holed, or at a minimum, using a non-optimized path.
Checks: C-22822r409810_chk

Step 1: Verify that a prefix list has been configured containing prefixes belonging to the IP core. ip prefix-list FILTER_CORE_PREFIXES seq 5 deny x.1.1.0/24 le 32 ip prefix-list FILTER _CORE_PREFIXES seq 10 deny x.1.2.0/24 le 32 ip prefix-list FILTER _CORE_PREFIXES seq 15 permit 0.0.0.0/0 ge 8 Step 2: Verify that the prefix lists has been applied to all external BGP peers as shown in the example below: router bgp xx router-id 10.1.1.1 neighbor x.1.12.2 remote-as xx password 3 7b07d1b3023056a9 address-family ipv4 unicast FILTER _CORE_PREFIXES out neighbor x.2.44.4 remote-as xx password 3 f07a10cb41db8bb6f8f0a340049a9b02 address-family ipv4 unicast prefix-list FILTER _CORE_PREFIXES out If the switch is not configured to reject outbound route advertisements for prefixes belonging to the IP core, this is a finding.

Fix: F-22811r409811_fix

Step 1: Configure a prefix list for containing all customer and local AS prefixes as shown in the example below: SW1(config)# ip prefix-list FILTER_CORE_PREFIXES deny x.1.1.0/24 le 32 SW1(config)# ip prefix-list FILTER _CORE_PREFIXES deny x.1.2.0/24 le 32 SW1(config)# ip prefix-list FILTER _CORE_PREFIXES permit 0.0.0.0/0 ge 8 Step 2: Apply the prefix list filter outbound to each CE neighbor as shown in the example below: SW1(config)# router bgp xx SW1(config-router)# neighbor x.1.12.2 SW1(config-router-neighbor)# address-family ipv4 unicast SW1(config-router-neighbor-af)# prefix-list FILTER _CORE_PREFIXES out SW1(config-router-neighbor-af)# exit SW1(config-router-neighbor)# exit SW1(config-router)# neighbor x.2.44.4 SW1(config-router-neighbor)# address-family ipv4 unicast SW1(config-router-neighbor-af)# prefix-list FILTER _CORE_PREFIXES out SW1(config-router-neighbor-af)# end

a
The Cisco BGP switch must be configured to reject route advertisements from BGP peers that do not list their autonomous system (AS) number as the first AS in the AS_PATH attribute.
AC-4 - Low - CCI-000032 - V-221108 - SV-221108r999717_rule
RMF Control
AC-4
Severity
Low
CCI
CCI-000032
Version
CISC-RT-000540
Vuln IDs
  • V-221108
  • V-101931
Rule IDs
  • SV-221108r999717_rule
  • SV-111035
Verifying the path a route has traversed will ensure the IP core is not used as a transit network for unauthorized or possibly even internet traffic. All autonomous system boundary switches (ASBRs) must ensure updates received from eBGP peers list their AS number as the first AS in the AS_PATH attribute.
Checks: C-22823r409813_chk

Review the switch configuration to verify the switch 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 switch configuration to verify that the command no enforce-first-as is not configured. router bgp xx router-id 10.1.1.1 no enforce-first-as If the switch 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-22812r409814_fix

Configure the switch to deny updates received from eBGP peers that do not list their AS number as the first AS in the AS_PATH attribute. SW1(config)# router bgp xx SW1(config-router)# enforce-first-as SW1(config-router)# end

a
The Cisco BGP switch must be configured to reject route advertisements from CE switches with an originating AS in the AS_PATH attribute that does not belong to that customer.
AC-4 - Low - CCI-000032 - V-221109 - SV-221109r999718_rule
RMF Control
AC-4
Severity
Low
CCI
CCI-000032
Version
CISC-RT-000550
Vuln IDs
  • V-221109
  • V-101933
Rule IDs
  • SV-221109r999718_rule
  • SV-111037
Verifying the path a route has traversed will ensure that the local AS is not used as a transit network for unauthorized traffic. To ensure that the local AS does not carry any prefixes that do not belong to any customers, all PE switches must be configured to reject routes with an originating AS other than that belonging to the customer.
Checks: C-22824r409816_chk

Review the switch configuration to verify the switch 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. Step 1: Review switch configuration and verify that there is an as-path access-list statement defined to only accept routes from a CE switch whose AS did not originate the route. The configuration should look similar to the following: ip as-path access-list AS_PATH permit ^yy$ ip as-path access-list 10 AS_PATH .* Note: the characters “^” and “$” representing the beginning and the end of the expression respectively are optional and are implicitly defined if omitted. Step 2: Verify that the as-path access-list is referenced by the filter-list inbound for the appropriate BGP neighbors as shown in the example below: router bgp xx router-id 10.1.1.1 neighbor x.1.12.2 remote-as xx password 3 7b07d1b3023056a9 address-family ipv4 unicast filter-list AS_PATH in If the switch 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-22813r409817_fix

Configure the switch to deny updates received from eBGP peers that do not list their AS number as the first AS in the AS_PATH attribute. Step 1: Configure the as-path ACL as shown in the example below: SW1(config)# ip as-path access-list AS_PATH permit ^22$ SW1(config)# ip as-path access-list AS_PATH deny .* Step 2: Apply the as-path filter inbound as shown in the example below: SW1(config)# router bgp xx SW1(config-router)# neighbor x.1.12.2 SW1(config-router-neighbor)# address-family ipv4 unicast SW1(config-router-neighbor-af)# filter-list AS_PATH in SW1(config-router-neighbor-af)# end

b
The Cisco BGP switch must be configured to use the maximum prefixes feature to protect against route table flooding and prefix de-aggregation attacks.
SC-5 - Medium - CCI-002385 - V-221110 - SV-221110r999719_rule
RMF Control
SC-5
Severity
Medium
CCI
CCI-002385
Version
CISC-RT-000560
Vuln IDs
  • V-221110
  • V-101935
Rule IDs
  • SV-221110r999719_rule
  • SV-111039
The effects of prefix de-aggregation can degrade switch performance due to the size of routing tables and also result in black-holing legitimate traffic. Initiated by an attacker or a misconfigured switch, prefix de-aggregation occurs when the announcement of a large prefix is fragmented into a collection of smaller prefix announcements. In 1997, misconfigured switches in the Florida Internet Exchange network (AS7007) de-aggregated every prefix in their routing table and started advertising the first /24 block of each of these prefixes as their own. Faced with this additional burden, the internal switches became overloaded and crashed repeatedly. This caused prefixes advertised by these switches to disappear from routing tables and reappear when the switches came back online. As the switches came back after crashing, they were flooded with the routing table information by their neighbors. The flood of information would again overwhelm the switches and cause them to crash. This process of route flapping served to destabilize not only the surrounding network but also the entire Internet. Switches trying to reach those addresses would choose the smaller, more specific /24 blocks first. This caused backbone networks throughout North America and Europe to crash. Maximum prefix limits on peer connections combined with aggressive prefix-size filtering of customers' reachability advertisements will effectively mitigate the de-aggregation risk. BGP maximum prefix must be used on all eBGP switches to limit the number of prefixes that it should receive from a particular neighbor, whether customer or peering AS. Consider each neighbor and how many routes they should be advertising and set a threshold slightly higher than the number expected.
Checks: C-22825r409819_chk

Review the switch configuration to verify that the number of received prefixes from each eBGP neighbor is controlled. router bgp xx router-id 10.1.1.1 neighbor x.1.12.2 remote-as xx password 3 7b07d1b3023056a9 address-family ipv4 unicast maximum-prefix nnnnnnn neighbor x.2.44.4 remote-as xx password 3 f07a10cb41db8bb6f8f0a340049a9b02 address-family ipv4 unicast maximum-prefix nnnnnnn If the switch 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-22814r409820_fix

Configure the switch to use the maximum prefixes feature to protect against route table flooding and prefix de-aggregation attacks as shown in the example below: SW1(config)# router bgp xx SW1(config-router)# neighbor x.1.12.2 SW1(config-router-neighbor)# address-family ipv4 unicast SW1(config-router-neighbor-af)# maximum-prefix nnnnnnn SW1(config-router-neighbor-af)# exit SW1(config-router-neighbor)# exit SW1(config-router)# neighbor x.2.44.4 SW1(config-router-neighbor)# address-family ipv4 unicast SW1(config-router-neighbor-af)# maximum-prefix nnnnnnn SW1(config-router-neighbor-af)# end

a
The Cisco BGP switch must be configured to limit the prefix size on any inbound route advertisement to /24, or the least significant prefixes issued to the customer.
SC-5 - Low - CCI-002385 - V-221111 - SV-221111r999720_rule
RMF Control
SC-5
Severity
Low
CCI
CCI-002385
Version
CISC-RT-000570
Vuln IDs
  • V-221111
  • V-101937
Rule IDs
  • SV-221111r999720_rule
  • SV-111041
The effects of prefix de-aggregation can degrade switch performance due to the size of routing tables and also result in black-holing legitimate traffic. Initiated by an attacker or a misconfigured switch, prefix de-aggregation occurs when the announcement of a large prefix is fragmented into a collection of smaller prefix announcements.
Checks: C-22826r409822_chk

Review the switch configuration to determine if it is compliant with this requirement. Step 1: Verify that a route filter has been configured to reject prefixes longer than /24 or the least significant prefixes issued to the customers as shown in the example below: ip prefix-list FILTER_PREFIX_LENGTH seq 5 permit 0.0.0.0/0 ge 8 le 24 ip prefix-list FILTER_PREFIX_LENGTH seq 10 deny 0.0.0.0/0 le 32 Step 2: Verify that prefix filtering has been applied to each eBGP peer as shown in the example below: router bgp xx router-id 10.1.1.1 neighbor x.1.12.2 remote-as xx password 3 7b07d1b3023056a9 address-family ipv4 unicast prefix-list FILTER_PREFIX_LENGTH in neighbor x.2.44.4 remote-as xx password 3 f07a10cb41db8bb6f8f0a340049a9b02 address-family ipv4 unicast prefix-list FILTER_PREFIX_LENGTH in If the switch 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-22815r409823_fix

Configure the switch 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 list to reject any prefix that is longer than /24. SW1(config)# ip prefix-list FILTER_PREFIX_LENGTH permit 0.0.0.0/0 ge 8 le 24 SW1(config)# ip prefix-list FILTER_PREFIX_LENGTH deny 0.0.0.0/0 le 32 Step 2: Apply the prefix list to all eBGP peers as shown in the example below: SW1(config)# router bgp xx SW1(config-router)# neighbor x.1.12.2 SW1(config-router-neighbor)# address-family ipv4 unicast SW1(config-router-neighbor-af)# prefix-list FILTER_PREFIX_LENGTH in SW1(config-router-neighbor-af)# exit SW1(config-router-neighbor)# exit SW1(config-router)# neighbor x.2.44.4 SW1(config-router-neighbor)# address-family ipv4 unicast SW1(config-router-neighbor-af)# prefix-list FILTER_PREFIX_LENGTH in SW1(config-router-neighbor-af)# end

a
The Cisco BGP switch must be configured to use its loopback address as the source address for iBGP peering sessions.
- Low - CCI-004931 - V-221112 - SV-221112r999769_rule
RMF Control
Severity
Low
CCI
CCI-004931
Version
CISC-RT-000580
Vuln IDs
  • V-221112
  • V-101939
Rule IDs
  • SV-221112r999769_rule
  • SV-111043
Using a loopback address as the source address offers a multitude of uses for security, access, management, and scalability of the BGP switches. It is easier to construct appropriate ingress filters for switch management plane traffic destined to the network management subnet since the source addresses will be from the range used for loopback interfaces instead of a larger range of addresses used for physical interfaces. Log information recorded by authentication and syslog servers will record the switch’s loopback address instead of the numerous physical interface addresses. When the loopback address is used as the source for eBGP peering, the BGP session will be harder to hijack since the source address to be used is not known globally, making it more difficult for a hacker to spoof an eBGP neighbor. By using traceroute, a hacker can easily determine the addresses for an eBGP speaker when the IP address of an external interface is used as the source address. The switches within the iBGP domain should also use loopback addresses as the source address when establishing BGP sessions.
Checks: C-22827r409825_chk

Step 1: Review the switch configuration to verify that a loopback address has been configured. interface loopback0 ip address 10.1.1.1/32 Step 2: Verify that the loopback interface is used as the source address for all iBGP sessions. router bgp xx router-id 10.1.1.1 address-family ipv4 unicast neighbor 10.1.12.2 remote-as xx password 3 7b07d1b3023056a9 update-source loopback0 If the switch does not use its loopback address as the source address for all iBGP sessions, this is a finding.

Fix: F-22816r409826_fix

Configure the switch to use its loopback address as the source address for all iBGP peering. SW1(config)# router bgp xx SW1(config-router)# neighbor 10.1.12.2 SW1(config-router-neighbor)# update-source lo0 SW1(config-router-neighbor)# end

a
The Cisco MPLS switch must be configured to use its loopback address as the source address for LDP peering sessions.
- Low - CCI-004931 - V-221113 - SV-221113r999770_rule
RMF Control
Severity
Low
CCI
CCI-004931
Version
CISC-RT-000590
Vuln IDs
  • V-221113
  • V-101941
Rule IDs
  • SV-221113r999770_rule
  • SV-111045
Using a loopback address as the source address offers a multitude of uses for security, access, management, and scalability of backbone switches. It is easier to construct appropriate ingress filters for switch management plane traffic destined to the network management subnet since the source addresses will be from the range used for loopback interfaces instead of from a larger range of addresses used for physical interfaces. Log information recorded by authentication and syslog servers will record the switch's loopback address instead of the numerous physical interface addresses.
Checks: C-22828r409828_chk

Review the switch 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/32 By default, switches 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 a loopback interface as shown in the example below: mpls ldp configuration router-id lo0 If the switch is not configured do use its loopback address for LDP peering, this is a finding.

Fix: F-22817r409829_fix

Configure the switch 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. SW1(config)# mpls ldp configuration SW1(config-ldp)# router-id lo0

a
The Cisco MPLS switch must be configured to synchronize Interior Gateway Protocol (IGP) and LDP to minimize packet loss when an IGP adjacency is established prior to LDP peers completing label exchange.
CM-6 - Low - CCI-000366 - V-221114 - SV-221114r999723_rule
RMF Control
CM-6
Severity
Low
CCI
CCI-000366
Version
CISC-RT-000600
Vuln IDs
  • V-221114
  • V-101943
Rule IDs
  • SV-221114r999723_rule
  • SV-111047
Packet loss can occur when an IGP adjacency is established and the switch begins forwarding packets using the new adjacency before the LDP label exchange completes between the peers on that link. Packet loss can also occur if an LDP session closes and the switch continues to forward traffic using the link associated with the LDP peer rather than an alternate pathway with a fully synchronized LDP session. The MPLS LDP-IGP Synchronization feature provides a means to synchronize LDP with OSPF or IS-IS to minimize MPLS packet loss. When an IGP adjacency is established on a link but LDP-IGP synchronization is not yet achieved or is lost, the IGP will advertise the max-metric on that link.
Checks: C-22829r409831_chk

Review the switch OSPF or IS-IS configuration and verify that LDP will synchronize with the link-state routing protocol as shown in the example below: OSPF Example router ospf 1 mpls ldp sync IS-IS Example router isis mpls ldp sync If the switch is not configured to synchronize IGP and LDP, this is a finding.

Fix: F-22818r409832_fix

Configure the MPLS switch to synchronize IGP and LDP, minimizing packet loss when an IGP adjacency is established prior to LDP peers completing label exchange. OSPF Example SW1(config)# router ospf 1 SW1(config-switch)# mpls ldp sync IS-IS Example SW1(config)# router isis SW1(config-switch)# mpls ldp sync

a
The MPLS switch with RSVP-TE enabled must be configured with message pacing to adjust maximum burst and maximum number of RSVP messages to an output queue based on the link speed and input queue size of adjacent core switches.
SC-5 - Low - CCI-001095 - V-221115 - SV-221115r999724_rule
RMF Control
SC-5
Severity
Low
CCI
CCI-001095
Version
CISC-RT-000610
Vuln IDs
  • V-221115
  • V-101945
Rule IDs
  • SV-221115r999724_rule
  • SV-111049
RSVP-TE can be used to perform constraint-based routing when building LSP tunnels within the network core that will support QoS and traffic engineering requirements. RSVP-TE is also used to enable MPLS Fast Reroute, a network restoration mechanism that will reroute traffic onto a backup LSP in case of a node or link failure along the primary path. When there is a disruption in the MPLS core, such as a link flap or switch reboot, the result is a significant amount of RSVP signaling, such as "PathErr" and "ResvErr" messages that need to be sent for every LSP using that link. When RSVP messages are sent out, they are sent either hop by hop or with the switch alert bit set in the IP header. This means that every switch along the path must examine the packet to determine if additional processing is required for these RSVP messages. If there is enough signaling traffic in the network, it is possible for an interface to receive more packets for its input queue than it can hold, resulting in dropped RSVP messages and hence slower RSVP convergence. Increasing the size of the interface input queue can help prevent dropping packets; however, there is still the risk of having a burst of signaling traffic that can fill the queue. Solutions to mitigate this risk are RSVP message pacing or refresh reduction to control the rate at which RSVP messages are sent. RSVP refresh reduction includes the following features: RSVP message bundling, RSVP Message ID to reduce message processing overhead, reliable delivery of RSVP messages using Message ID, and summary refresh to reduce the amount of information transmitted every refresh interval.
Checks: C-22830r409834_chk

Review the switch configuration to determine if refresh reduction is enabled. Step 1: Determine if MPLS TE is enabled on any interface as shown in the example below: interface Ethernet4/47 mpls traffic-eng tunnels mpls ip Step 2: If MPLS TE is enabled, verify that message pacing is enabled. ip rsvp signaling refresh reduction bundle-max-size If the switch with RSVP-TE configured does not have refresh reduction features enabled, this is a finding.

Fix: F-22819r409835_fix

Configure the switch to rate limit RSVP messages per interface as shown in the example below. Configure the MPLS switch to synchronize IGP and LDP, minimizing packet loss when an IGP adjacency is established prior to LDP peers completing label exchange. OSPF Example SW1(config)# router ospf 1 SW1(config-switch)# mpls ldp sync IS-IS Example SW1(config)# router isis SW1(config-switch)# mpls ldp sync. SW1(config)# ip rsvp SW1(config-ip-rsvp)# signaling refresh reduction SW1(config-ip-rsvp)# end

b
The Cisco MPLS switch must be configured to have TTL Propagation disabled.
CM-6 - Medium - CCI-000366 - V-221116 - SV-221116r999725_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
CISC-RT-000620
Vuln IDs
  • V-221116
  • V-101947
Rule IDs
  • SV-221116r999725_rule
  • SV-111051
The head end of the label-switched path (LSP), the label edge switch (LER) will decrement the IP packet's time-to-live (TTL) value by one and then copy the value to the MPLS TTL field. At each label-switched switch (LSR) hop, the MPLS TTL value is decremented by one. The MPLS switch that pops the label (either the penultimate LSR or the egress LER) will copy the packet's MPLS TTL value to the IP TTL field and decrement it by one. This TTL propagation is the default behavior. Because the MPLS TTL is propagated from the IP TTL, a traceroute will list every hop in the path, be it routed or label switched, thereby exposing core nodes. With TTL propagation disabled, LER decrements the IP packet's TTL value by one and then places a value of 255 in the packet's MPLS TTL field, which is then decremented by one as the packet passes through each LSR in the MPLS core. Because the MPLS TTL never drops to zero, none of the LSP hops triggers an ICMP TTL exceeded message, and consequently, these hops are not recorded in a traceroute. Hence, nodes within the MPLS core cannot be discovered by an attacker.
Checks: C-22831r409837_chk

Review the switch configuration to verify that TTL propagation is disabled as shown in the example below: no mpls ip propagate-ttl If the MPLS switch is not configured to disable TTL propagation, this is a finding.

Fix: F-22820r409838_fix

Configure the MPLS switch to disable TTL propagation as shown in the example below: SW1(config)# no mpls ip propagate-ttl

c
The Cisco PE switch must be configured to have each Virtual Routing and Forwarding (VRF) instance bound to the appropriate physical or logical interfaces to maintain traffic separation between all MPLS L3VPNs.
- High - CCI-004931 - V-221117 - SV-221117r999771_rule
RMF Control
Severity
High
CCI
CCI-004931
Version
CISC-RT-000630
Vuln IDs
  • V-221117
  • V-101949
Rule IDs
  • SV-221117r999771_rule
  • SV-111053
The primary security model for an MPLS L3VPN infrastructure is traffic separation. The service provider must guarantee the customer that traffic from one VPN does not leak into another VPN or into the core, and that core traffic must not leak into any VPN. Hence, it is imperative that each CE-facing interface can only be associated to one VRF—that alone is the fundamental framework for traffic separation.
Checks: C-22832r409840_chk

Step 1: Review the design plan for deploying MPLS/L3VPN. Step 2: Review all CE-facing interfaces and verify that the proper VRF is defined via the ip vrf forwarding command. In the example below, customer 1 is bound to interface Ethernet2/1, while customer 2 is bound to Ethernet2/2. interface Ethernet2/1 no switchport vrf member CUST1 ip address x.2.22.3/24 interface Ethernet2/2 no switchport vrf member CUST2 ip address x.2.8.4/24 If any VRFs are not bound to the appropriate physical or logical interface, this is a finding.

Fix: F-22821r409841_fix

Configure the PE switch to have each VRF bound to the appropriate physical or logical interfaces to maintain traffic separation between all MPLS L3VPNs.

c
The Cisco PE switch must be configured to have each Virtual Routing and Forwarding (VRF) instance with the appropriate Route Target (RT).
- High - CCI-004931 - V-221118 - SV-221118r999772_rule
RMF Control
Severity
High
CCI
CCI-004931
Version
CISC-RT-000640
Vuln IDs
  • V-221118
  • V-101951
Rule IDs
  • SV-221118r999772_rule
  • SV-111055
The primary security model for an MPLS L3VPN as well as a VRF-lite infrastructure is traffic separation. Each interface can only be associated to one VRF, which is the fundamental framework for traffic separation. Forwarding decisions are made based on the routing table belonging to the VRF. Control of what routes are imported into or exported from a VRF is based on the RT. It is critical that traffic does not leak from one COI tenant or L3VPN to another; hence, it is imperative that the correct RT is configured for each VRF.
Checks: C-22833r409843_chk

Review the design plan for MPLS/L3VPN to determine what RTs have been assigned for each VRF. Review the switch configuration and verify that the correct RT is configured for each VRF. In the example below, route target 13:13 has been configured for customer 1. vrf context CUST1 address-family ipv4 unicast route-target export 13:13 route-target import 13:13 If there are VRFs configured with the wrong RT, this is a finding.

Fix: F-22822r409844_fix

Configure the switch to have each VRF instance defined with the correct RT. SW1(config)# vrf context CUST1 SW1(config-vrf)# address-family ipv4 unicast SW1(config-vrf-af-ipv4)# route-target import 13:13 SW1(config-vrf-af-ipv4)# route-target export 13:13 SW1(config-vrf-af-ipv4)# end

b
The Cisco PE switch must be configured to have each VRF with the appropriate Route Distinguisher (RD).
- Medium - CCI-004931 - V-221119 - SV-221119r999773_rule
RMF Control
Severity
Medium
CCI
CCI-004931
Version
CISC-RT-000650
Vuln IDs
  • V-221119
  • V-101953
Rule IDs
  • SV-221119r999773_rule
  • SV-111057
An RD provides uniqueness to the customer address spaces within the MPLS L3VPN infrastructure. The concept of the VPN-IPv4 and VPN-IPv6 address families consists of the RD prepended before the IP address. Hence, if the same IP prefix is used in several different L3VPNs, it is possible for BGP to carry several completely different routes for that prefix, one for each VPN. Since VPN-IPv4 addresses and IPv4 addresses are different address families, BGP never treats them as comparable addresses. The purpose of the RD is to create distinct routes for common IPv4 address prefixes. On any given PE switch, a single RD can define a VRF in which the entire address space may be used independently, regardless of the makeup of other VPN address spaces. Hence, it is imperative that a unique RD is assigned to each L3VPN and that the proper RD is configured for each VRF.
Checks: C-22834r409846_chk

Review the design plan for MPLS/L3VPN to determine what RD has been assigned for each VRF. Review the switch configuration and verify that the correct RD is configured for each VRF. In the example below, route distinguisher 13:13 has been configured for customer 1. vrf context CUST1 rd 13:13 address-family ipv4 unicast route-target export 13:13 route-target import 13:13 Note: This requirement is only applicable for MPLS L3VPN implementations. If the wrong RD has been configured for any VRF, this is a finding.

Fix: F-22823r409847_fix

Configure the correct RD for each VRF. SW1(config)# vrf context CUST1 SW1(config-vrf)# rd 13:13 SW1(config-vrf)# end

b
The Cisco PE switch providing MPLS Layer 2 Virtual Private Network (L2VPN) services must be configured to authenticate targeted Label Distribution Protocol (LDP) sessions used to exchange virtual circuit (VC) information using a FIPS-approved message authentication code algorithm.
IA-3 - Medium - CCI-001958 - V-221120 - SV-221120r999729_rule
RMF Control
IA-3
Severity
Medium
CCI
CCI-001958
Version
CISC-RT-000660
Vuln IDs
  • V-221120
  • V-101955
Rule IDs
  • SV-221120r999729_rule
  • SV-111059
LDP provides the signaling required for setting up and tearing down pseudowires (virtual circuits used to transport Layer 2 frames) across an MPLS IP core network. Using a targeted LDP session, each PE switch advertises a virtual circuit label mapping that is used as part of the label stack imposed on the frames by the ingress PE switch during packet forwarding. Authentication provides protection against spoofed TCP segments that can be introduced into the LDP sessions.
Checks: C-22835r409849_chk

The Cisco switch is not compliant with this requirement; hence, it is a finding. However, the severity level can be downgraded to a category 3 if the switch is configured to authenticate targeted LDP sessions using MD5 as shown in the configuration example below: Step 1: Verify that LDP neighbors are authenticating session, advertisement, and notification messages as shown in the example below: mpls ldp configurations password required for LDP_NBR1 password option 1 for LDP_NBR1 key-chain LDP_KEY password required for LDP_NBR2 password option 1 for LDP_NBR2 key-chain LDP_KEY Step 2: Verify that the neighbors identified in step 1 have the correct prefix. ip prefix-list LDP_NBR1 permit 10.1.22.2/32 ip prefix-list LDP_NBR2 permit 10.1.12.4/32 If the switch is not configured to authenticate targeted LDP sessions using MD5, this is a finding. The finding will remain as a CAT II.

Fix: F-22824r409850_fix

The severity level can be downgraded to a category 3 if the switch is configured to authenticate targeted LDP sessions using MD5 as shown in the example below: Step 1: Configure a key chain for LDP sessions. SW1(config)# key chain LDP_KEY SW1(config-keychain)# key 1 SW1(config-keychain-key)# key-string xxxxxxxxxxxx SW1(config-keychain-key)# send-lifetime 00:00:00 Oct 1 2019 23:59:59 Dec 31 2019 SW1(config-keychain-key)# accept-lifetime 00:00:00 Oct 1 2019 01:05:00 Jan 1 2020 SW1(config-keychain-key)# exit SW1(config-keychain)# exit Step 2: Configure a prefix lists to identify LDP neighbors. SW1(config)# ip prefix-list LDP_NBR1 permit 10.1.22.2/32 SW1(config)# ip prefix-list LDP_NBR2 permit 10.1.12.4/32 Step 3: Apply the key chain to the LDP neighbors. SW1 (config)# mpls ldp configurations SW1 (config-ldp)# password required for LDP_NBR1 SW1 (config-ldp)# password option 1 for LDP_NBR1 key-chain LDP_KEY SW1 (config-ldp)# password required for LDP_NBR2 SW1 (config-ldp)# password option 1 for LDP_NBR2 key-chain LDP_KEY SW1 (config-ldp)# end

c
The Cisco PE switch providing MPLS Virtual Private Wire Service (VPWS) must be configured to have the appropriate virtual circuit identification (VC ID) for each attachment circuit.
- High - CCI-004931 - V-221121 - SV-221121r999774_rule
RMF Control
Severity
High
CCI
CCI-004931
Version
CISC-RT-000670
Vuln IDs
  • V-221121
  • V-101957
Rule IDs
  • SV-221121r999774_rule
  • SV-111061
VPWS is an L2VPN technology that provides a virtual circuit between two PE switches to forward Layer 2 frames between two customer-edge switches or switches through an MPLS-enabled IP core. The ingress PE switch (virtual circuit head-end) encapsulates Ethernet frames inside MPLS packets using label stacking and forwards them across the MPLS network to the egress PE switch (virtual circuit tail-end). During a virtual circuit setup, the PE switches exchange VC label bindings for the specified VC ID. The VC ID specifies a pseudowire associated with an ingress and egress PE switch and the customer-facing attachment circuits. To guarantee that all frames are forwarded onto the correct pseudowire and to the correct customer and attachment circuits, it is imperative that the correct VC ID is configured for each attachment circuit.
Checks: C-22836r409852_chk

Verify that the correct and unique VCID has been configured for the appropriate attachment circuit. In the example below Ethernet2/1 is the CE-facing interface that is configured for VPWS with the VCID of 55. Step 1: Review the L2VPN virtual circuits and determine the member attachment circuit and pseudowire. l2vpn xconnect context VC55 member Ethernet2/1 member Pseudowire55 Step 2: Determine the VCID as configured for neighbor and verify the same VCID is defined on the remote PE device. port-profile type pseudowire MPLS_PROFILE encapsulation mpls interface Pseudowire55 neighbor 10.10.22.1 55 inherit port-profile MPLS_PROFILE Note: VPWS is also known as Ethernet over MPLS (EoMPLS) and Ethernet Virtual Circuit (EVC). If the correct VC ID has not been configured on both switches, this is a finding.

Fix: F-22825r409853_fix

Assign globally unique VC IDs for each virtual circuit and configure the attachment circuits with the appropriate VC ID.

c
The Cisco PE switch providing Virtual Private LAN Services (VPLS) must be configured to have all attachment circuits defined to the virtual forwarding instance (VFI) with the globally unique VPN ID assigned for each customer VLAN.
- High - CCI-004931 - V-221122 - SV-221122r999775_rule
RMF Control
Severity
High
CCI
CCI-004931
Version
CISC-RT-000680
Vuln IDs
  • V-221122
  • V-101959
Rule IDs
  • SV-221122r999775_rule
  • SV-111063
VPLS defines an architecture that delivers Ethernet multipoint services over an MPLS network. Customer Layer 2 frames are forwarded across the MPLS core via pseudowires using IEEE 802.1q Ethernet bridging principles. A pseudowire is a virtual bidirectional connection between two attachment circuits (virtual connections between PE and CE switches). A pseudowire contains two unidirectional label-switched paths (LSP) between two PE switches. Each MAC virtual forwarding table instance (VFI) is interconnected using pseudowires provisioned for the bridge domain, thereby maintaining privacy and logical separation between each VPLS bridge domain. The VFI specifies the pseudowires associated with connecting PE switches and the customer-facing attachment circuits belonging to a given VLAN. Resembling a Layer 2 switch, the VFI is responsible for learning MAC addresses and providing loop-free forwarding of customer traffic to the appropriate end nodes. Each VPLS domain is identified by a globally unique VPN ID; hence, VFIs of the same VPLS domain must be configured with the same VPN ID on all participating PE switches. To guarantee traffic separation for all customer VLANs and that all packets are forwarded to the correct destination, it is imperative that the correct attachment circuits are associated with the appropriate VFI and that each VFI is associated to the unique VPN ID assigned to the customer VLAN.
Checks: C-22837r409855_chk

Step 1: Review the implementation plan and the VPN IDs assigned to customer VLANs for the VPLS deployment. Step 2: Review the PE switch configuration to verify that customer attachment circuits are associated to the appropriate VFI. In the example below, the attached circuit at interface GigabitEthernet3 is associated to VPN ID 110. bridge-domain 100 member vfi CUST1_VPLS member Ethernet2/2 service instance 1 l2vpn vfi context CUST1_VPLS vpn id 100 member Pseudowire12 member Pseudowire13 … … … interface Ethernet2/2 service instance 1 ethernet encapsulation dot1q 100 … … … interface Pseudowire12 encapsulation mpls neighbor 10.2.2.2 100 interface Pseudowire13 encapsulation mpls neighbor 10.3.3.3 100 If the attachment circuits have not been bound to the VFI configured with the assigned VPN ID for each VLAN, this is a finding.

Fix: F-22826r409856_fix

Assign globally unique VPN IDs for each customer bridge domain using VPLS for carrier Ethernet services between multiple sites, and configure the attachment circuits to the appropriate VFI. Step 1: Configure the pseudowire interfaces with the assigned VC-ID. SW1(config)# interface Pseudowire12 SW1(config-if-pseudowire)# neighbor 10.2.2.2 100 SW1(config-if-pseudowire)# encapsulation mpls SW1(config-pseudowire-mpls)# exit SW1(config-if-pseudowire)# exit SW1(config)# interface Pseudowire13 SW1(config-if-pseudowire)# neighbor 10.3.3.3 100 SW1(config-if-pseudowire)# encapsulation mpls SW1(config-pseudowire-mpls)# exit SW1(config-if-pseudowire)# exit Step 2: Configure the virtual forwarding instance for the pseudowires as shown in the example with the assigned VPN ID. SW1(config)# l2vpn vfi context CUST1_VPLS SW1(config-l2vpn-vfi)# vpn 100 SW1(config-l2vpn-vfi)# member Pseudowire12 SW1(config-l2vpn-vfi)# member Pseudowire13 SW1(config-l2vpn-vfi)# exit Step 3: Configure the service instance on the attachment circuit as shown in the example below: SW1(config)# interface ethernet 2/2 SW1(config-if)# service instance 1 ethernet SW1(config-if-srv)# encapsulation dot1q 100 SW1(config-if-srv)# exit SW1(config-if)# exit Step 4: Configure the bridge domain. SW1(config)# bridge-domain 100 SW1(config-bdomain)# member ethernet 2/2 service-instance 1 SW1(config-bdomain)# member vfi CUST1_VPLS SW1(config-bdomain)# end Note: The service instance configured on the attachment circuit must map to the service instance configured on the bridge domain in order to be bound to the correct bridge domain with the VFI that defines the appropriate VPN ID.

b
The Cisco PE switch providing Virtual Private LAN Services (VPLS) must be configured to have traffic storm control thresholds on CE-facing interfaces.
SC-5 - Medium - CCI-001095 - V-221123 - SV-221123r999732_rule
RMF Control
SC-5
Severity
Medium
CCI
CCI-001095
Version
CISC-RT-000700
Vuln IDs
  • V-221123
  • V-101961
Rule IDs
  • SV-221123r999732_rule
  • SV-111065
A traffic storm occurs when packets flood a VPLS bridge, creating excessive traffic and degrading network performance. Traffic storm control prevents VPLS bridge disruption by suppressing traffic when the number of packets reaches configured threshold levels. Traffic storm control monitors incoming traffic levels on a port and drops traffic when the number of packets reaches the configured threshold level during any one-second interval.
Checks: C-22838r409858_chk

Review the switch configuration to verify that storm control is enabled on CE-facing interfaces deploying VPLS as shown in the example below: interface Ethernet2/4 no shutdown no switchport storm-control broadcast level 40.00 service instance 1 ethernet encapsulation dot1q 100 If storm control is not enabled at a minimum for broadcast traffic, this is a finding.

Fix: F-22827r409859_fix

Configure storm control for each CE-facing interface as shown in the example below: SW1(config)# int e2/4 SW1(config-if)# storm-control broadcast level 40 SW1(config-if)# end

a
The Cisco PE switch must be configured to implement Internet Group Management Protocol (IGMP) or Multicast Listener Discovery (MLD) snooping for each Virtual Private LAN Services (VPLS) bridge domain.
SC-5 - Low - CCI-002385 - V-221124 - SV-221124r999733_rule
RMF Control
SC-5
Severity
Low
CCI
CCI-002385
Version
CISC-RT-000710
Vuln IDs
  • V-221124
  • V-101963
Rule IDs
  • SV-221124r999733_rule
  • SV-111067
IGMP snooping provides a way to constrain multicast traffic at Layer 2. By monitoring the IGMP membership reports sent by hosts within the bridge domain, the snooping application can set up Layer 2 multicast forwarding tables to deliver traffic only to ports with at least one interested member within the VPLS bridge, thereby significantly reducing the volume of multicast traffic that would otherwise flood an entire VPLS bridge domain. The IGMP snooping operation applies to both access circuits and pseudowires within a VPLS bridge domain.
Checks: C-22839r409861_chk

Review the switch configuration to verify that IGMP or MLD snooping has been configured for IPv4 and IPv6 multicast traffic respectively for each VPLS bridge domain. The example below are the steps to verify that IGMP snooping is enabled for a VPLS bridge domain. Step 1: Verify that IGMP snooping is enabled globally. By default, IGMP snooping is enabled globally; hence, the following command should not be in the switch configuration: no ip igmp snooping Step 2: If IGMP snooping is enabled globally, it will also be enabled by default for each VPLS bridge domain. Hence, the command “no ip igmp snooping” should not be configured for any VPLS bridge domain as shown in the example below: bridge-domain 100 no ip igmp snooping If the switch is not configured to implement IGMP or MLD snooping for each VPLS bridge domain, this is a finding.

Fix: F-22828r409862_fix

Configure IGMP or MLD snooping for IPv4 and IPv6 multicast traffic respectively for each VPLS bridge domain. SW1(config)# bridge-domain 100 SW1(config-bdomain)# ip igmp snooping SW1(config-bdomain)# end

b
The Cisco PE switch must be configured to limit the number of MAC addresses it can learn for each Virtual Private LAN Services (VPLS) bridge domain.
SC-5 - Medium - CCI-001094 - V-221125 - SV-221125r999734_rule
RMF Control
SC-5
Severity
Medium
CCI
CCI-001094
Version
CISC-RT-000720
Vuln IDs
  • V-221125
  • V-101965
Rule IDs
  • SV-221125r999734_rule
  • SV-111069
VPLS defines an architecture that delivers Ethernet multipoint services over an MPLS network. Customer Layer 2 frames are forwarded across the MPLS core via pseudowires using IEEE 802.1q Ethernet bridging principles. A pseudowire is a virtual bidirectional connection between two attachment circuits (virtual connections between PE and CE switches). A pseudowire contains two unidirectional label-switched paths (LSP). Each MAC forwarding table instance is interconnected using domain-specific LSPs, thereby maintaining privacy and logical separation between each VPLS domain. When a frame arrives on a bridge port (pseudowire or attachment circuit) and the source MAC address is unknown to the receiving PE switch, the source MAC address is associated with the pseudowire or attachment circuit and the forwarding table is updated accordingly. Frames are forwarded to the appropriate pseudowire or attachment circuit according to the forwarding table entry for the destination MAC address. Ethernet frames sent to broadcast and unknown destination addresses must be flooded out to all interfaces for the bridge domain; hence, a PE switch must replicate packets across both attachment circuits and pseudowires. A malicious attacker residing in a customer network could launch a source MAC address spoofing attack by flooding packets to a valid unicast destination, each with a different MAC source address. The PE switch receiving this traffic would try to learn every new MAC address and would quickly run out of space for the VFI forwarding table. Older, valid MAC addresses would be removed from the table, and traffic sent to them would have to be flooded until the storm threshold limit is reached. Hence, it is essential that a limit is established to control the number of MAC addresses that will be learned and recorded into the forwarding table for each bridge domain.
Checks: C-22840r409864_chk

Review the PE switch configuration to determine if a MAC address limit has been set for each VPLS bridge domain. bridge-domain 100 mac limit maximum addresses nnnnn If a limit has not been configured, this is a finding.

Fix: F-22829r409865_fix

Configure a MAC address learning limit for each VPLS bridge domain. SW1(config)# bridge-domain 100 SW1(config-bdomain)# mac limit maximum addresses nnnn SW1(config-bdomain)# end

c
The Cisco PE switch must be configured to block any traffic that is destined to the IP core infrastructure.
SC-7 - High - CCI-001097 - V-221126 - SV-221126r999735_rule
RMF Control
SC-7
Severity
High
CCI
CCI-001097
Version
CISC-RT-000730
Vuln IDs
  • V-221126
  • V-101967
Rule IDs
  • SV-221126r999735_rule
  • SV-111071
IP/MPLS networks providing VPN and transit services must provide, at the least, the same level of protection against denial-of-service (DoS) attacks and intrusions as Layer 2 networks. Although the IP core network elements are hidden, security should never rely entirely on obscurity. IP addresses can be guessed. Core network elements must not be accessible from any external host. Protecting the core from any attack is vital for the integrity and privacy of customer traffic as well as the availability of transit services. A compromise of the IP core can result in an outage or, at a minimum, non-optimized forwarding of customer traffic. Protecting the core from an outside attack also prevents attackers from using the core to attack any customer. Hence, it is imperative that all switches at the edge deny traffic destined to any address belonging to the IP core infrastructure.
Checks: C-22841r409867_chk

Step 1: Review the switch configuration to verify that an ingress ACL is applied to all external or CE-facing interfaces. interface Ethernet1/2 ip address x.1.12.2/30 ip access-group BLOCK_TO_CORE in Step 2: Verify that the ingress ACL discards and logs packets destined to the IP core address space. ip access-list BLOCK_TO_CORE deny ip any 10.1.x.0 0.0.255.255 log permit ip any any Note: Internet Control Message Protocol (ICMP) echo requests and traceroutes will be allowed to the edge from external adjacent neighbors. If the PE switch is not configured to block any traffic with a destination address assigned to the IP core infrastructure, this is a finding.

Fix: F-22830r409868_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. SW1(config)# ip access-list BLOCK_TO_CORE SW1(config-acl)# deny ip any 10.1.x.0 0.0.255.255 log SW1(config-acl)# exit Step 2: Apply the ACL inbound to all external or CE-facing interfaces. SW1(config)#int e1/2 SW1(config-if)# ip access-group BLOCK_TO_CORE in SW1(config-if)# end

b
The Cisco PE switch must be configured with Unicast Reverse Path Forwarding (uRPF) loose mode enabled on all CE-facing interfaces.
SC-7 - Medium - CCI-001097 - V-221127 - SV-221127r999736_rule
RMF Control
SC-7
Severity
Medium
CCI
CCI-001097
Version
CISC-RT-000740
Vuln IDs
  • V-221127
  • V-101969
Rule IDs
  • SV-221127r999736_rule
  • SV-111073
The uRPF feature is a defense against spoofing and denial-of-service (DoS) attacks by verifying if the source address of any ingress packet is reachable. To mitigate attacks that rely on forged source addresses, all provider edge switches must enable uRPF loose mode to guarantee that all packets received from a CE switch contain source addresses that are in the route table.
Checks: C-22842r409870_chk

Review the switch configuration to determine if uRPF loose mode is enabled on all CE-facing interfaces. interface Ethernet1/2 ip address x.1.12.2/30 ip access-group BLOCK_TO_CORE in ip verify unicast source reachable-via any If uRPF loose mode is not enabled on all CE-facing interfaces, this is a finding.

Fix: F-22831r409871_fix

Configure uRPF loose mode on all CE-facing interfaces as shown in the example below: SW1(config)# int e1/2 SW1(config-if)# ip verify unicast source reachable-via any SW1(config-if)# end

b
The Cisco PE switch must be configured to ignore or drop all packets with any IP options.
SC-7 - Medium - CCI-002403 - V-221128 - SV-221128r999737_rule
RMF Control
SC-7
Severity
Medium
CCI
CCI-002403
Version
CISC-RT-000750
Vuln IDs
  • V-221128
  • V-101971
Rule IDs
  • SV-221128r999737_rule
  • SV-111075
Packets with IP options are not fast-switched and therefore must be punted to the switch processor. Hackers who initiate denial-of-service (DoS) attacks on switches commonly send large streams of packets with IP options. Dropping the packets with IP options reduces the load of IP options packets on the switch. The end result is a reduction in the effects of the DoS attack on the switch and on downstream switches.
Checks: C-22843r409873_chk

In Cisco NX-OS, all packets with any header option other than the “source-route” header option are dropped. By default, ipv4 source routing is enabled. Verify that source routing is disabled via the following command: no ip source-route If the switch is not configured to drop all packets with IP option source routing, this is a finding.

Fix: F-22832r409874_fix

Configure the switch to drop all packets with IP option source routing. SW1(config)# no ip source-route SW1(config)# end

a
The Cisco PE switch must be configured to enforce a Quality-of-Service (QoS) policy to provide preferred treatment for mission-critical applications.
SC-5 - Low - CCI-001095 - V-221129 - SV-221129r999738_rule
RMF Control
SC-5
Severity
Low
CCI
CCI-001095
Version
CISC-RT-000760
Vuln IDs
  • V-221129
  • V-101973
Rule IDs
  • SV-221129r999738_rule
  • SV-111077
Different applications have unique requirements and toleration levels for delay, jitter, bandwidth, packet loss, and availability. To manage the multitude of applications and services, a network requires a QoS framework to differentiate traffic and provide a method to manage network congestion. The Differentiated Services Model (DiffServ) is based on per-hop behavior by categorizing traffic into different classes and enabling each node to enforce a forwarding treatment to each packet as dictated by a policy. Packet markings such as IP Precedence and its successor, Differentiated Services Code Points (DSCP), were defined along with specific per-hop behaviors for key traffic types to enable a scalable QoS solution. DiffServ QoS categorizes network traffic, prioritizes it according to its relative importance, and provides priority treatment based on the classification. It is imperative that end-to-end QoS is implemented within the IP core network to provide preferred treatment for mission-critical applications.
Checks: C-22844r917449_chk

Review the switch configuration and verify that a QoS policy has been configured to provide preferred treatment for mission-critical applications. 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 C2_VOICE match ip dscp af47 class-map match-all VOICE match ip dscp ef class-map match-all VIDEO match ip dscp af41 class-map match-all CONTROL_PLANE match ip dscp cs6 class-map match-all PREFERRED_DATA match ip dscp af33 Step 2: Verify that the policy map reserves the bandwidth for each traffic type as shown in the example below: policy-map QOS_POLICY class C2_VOICE priority percent 10 class VOICE priority percent 15 class VIDEO bandwidth percent 25 class CONTROL_PLANE priority percent 10 class PREFERRED_DATA bandwidth percent 25 class class-default bandwidth percent 15 Step 3: Verify that an output service policy is bound to all interface as shown in the configuration example below: interface Ethernet1/1 ip address 10.1.15.1/30 service-policy output QOS_POLICY ! interface Ethernet1/2 ip address 10.1.15.4/30 service-policy output QOS_POLICY 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 switch is not configured to enforce a QoS policy in accordance with the QoS GIG Technical Profile, this is a finding.

Fix: F-22833r917450_fix

Configure to enforce a QoS policy to provide preferred treatment for mission-critical applications. Step 1: Configure class-maps to match on DSCP values as shown in the configuration example below: SW1(config-cmap)# class-map match-all C2_VOICE SW1(config-cmap)# match ip dscp 47 SW1(config-cmap)# class-map match-all VOICE SW1(config-cmap)# match ip dscp ef SW1(config-cmap)# class-map match-all VIDEO SW1(config-cmap)# match ip dscp af41 SW1(config-cmap)# class-map match-all CONTROL_PLANE SW1(config-cmap)# match ip dscp cs6 SW1(config-cmap)# class-map match-all PREFERRED_DATA SW1(config-cmap)# match ip dscp af33 SW1(config-cmap)# exit Step 2: Configure a policy map to be applied to the interfaces that reserves the bandwidth for each traffic type as shown in the example below: SW1(config)# policy-map QOS_POLICY SW1(config-pmap-c)# class C2_VOICE SW1(config-pmap-c)# priority percent 10 SW1(config-pmap-c)# class VOICE SW1(config-pmap-c)# priority percent 15 SW1(config-pmap-c)# class VIDEO SW1(config-pmap-c)# bandwidth percent 25 SW1(config-pmap)# class CONTROL_PLANE SW1(config-pmap-c)# priority percent 10 SW1(config-pmap-c)# class PREFERRED_DATA SW1(config-pmap-c)# bandwidth percent 25 SW1(config-pmap-c)# class class-default SW1(config-pmap-c)# bandwidth percent 15 SW1(config-pmap-c)# exit SW1(config-pmap)# exit Step 3: Apply the output service policy to all interfaces as shown in the configuration example below: SW1(config)# int e1/1 SW1(config-if)# service-policy output QOS_POLICY SW1(config-if)# exit SW1(config)# int e1/2 SW1(config-if)# service-policy output QOS_POLICY SW1(config-if)# end

a
The Cisco P switch must be configured to enforce a Quality-of-Service (QoS) policy to provide preferred treatment for mission-critical applications.
SC-5 - Low - CCI-001095 - V-221130 - SV-221130r999739_rule
RMF Control
SC-5
Severity
Low
CCI
CCI-001095
Version
CISC-RT-000770
Vuln IDs
  • V-221130
  • V-101975
Rule IDs
  • SV-221130r999739_rule
  • SV-111079
Different applications have unique requirements and toleration levels for delay, jitter, bandwidth, packet loss, and availability. To manage the multitude of applications and services, a network requires a QoS framework to differentiate traffic and provide a method to manage network congestion. The Differentiated Services Model (DiffServ) is based on per-hop behavior by categorizing traffic into different classes and enabling each node to enforce a forwarding treatment to each packet as dictated by a policy. Packet markings such as IP Precedence and its successor, Differentiated Services Code Points (DSCP), were defined along with specific per-hop behaviors for key traffic types to enable a scalable QoS solution. DiffServ QoS categorizes network traffic, prioritizes it according to its relative importance, and provides priority treatment based on the classification. It is imperative that end-to-end QoS is implemented within the IP core network to provide preferred treatment for mission-critical applications.
Checks: C-22845r917452_chk

Review the switch configuration and verify that a QoS policy has been configured to provide preferred treatment for mission-critical applications. 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 C2_VOICE match ip dscp af47 class-map match-all VOICE match ip dscp ef class-map match-all VIDEO match ip dscp af41 class-map match-all CONTROL_PLANE match ip dscp cs6 class-map match-all PREFERRED_DATA match ip dscp af33 Step 2: Verify that the policy map reserves the bandwidth for each traffic type as shown in the example below: policy-map QOS_POLICY class C2_VOICE priority percent 10 class VOICE priority percent 15 class VIDEO bandwidth percent 25 class CONTROL_PLANE priority percent 10 class PREFERRED_DATA bandwidth percent 25 class class-default bandwidth percent 15 Step 3: Verify that an output service policy is bound to all interface as shown in the configuration example below: interface Ethernet1/1 ip address 10.1.15.1/30 service-policy output QOS_POLICY ! interface Ethernet1/2 ip address 10.1.15.4/30 service-policy output QOS_POLICY 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 switch is not configured to enforce a QoS policy in accordance with the QoS GIG Technical Profile, this is a finding.

Fix: F-22834r917453_fix

Configure to enforce a QoS policy to provide preferred treatment for mission-critical applications. Step 1: Configure class-maps to match on DSCP values as shown in the configuration example below: SW1(config-cmap)# class-map match-all C2_VOICE SW1(config-cmap)# match ip dscp 47 SW1(config-cmap)# class-map match-all VOICE SW1(config-cmap)# match ip dscp ef SW1(config-cmap)# class-map match-all VIDEO SW1(config-cmap)# match ip dscp af41 SW1(config-cmap)# class-map match-all CONTROL_PLANE SW1(config-cmap)# match ip dscp cs6 SW1(config-cmap)# class-map match-all PREFERRED_DATA SW1(config-cmap)# match ip dscp af33 SW1(config-cmap)# exit Step 2: Configure a policy map to be applied to the interfaces that reserves the bandwidth for each traffic type as shown in the example below: SW1(config)# policy-map QOS_POLICY SW1(config-pmap-c)# class C2_VOICE SW1(config-pmap-c)# priority percent 10 SW1(config-pmap-c)# class VOICE SW1(config-pmap-c)# priority percent 15 SW1(config-pmap-c)# class VIDEO SW1(config-pmap-c)# bandwidth percent 25 SW1(config-pmap)# class CONTROL_PLANE SW1(config-pmap-c)# priority percent 10 SW1(config-pmap-c)# class PREFERRED_DATA SW1(config-pmap-c)# bandwidth percent 25 SW1(config-pmap-c)# class class-default SW1(config-pmap-c)# bandwidth percent 15 SW1(config-pmap-c)# exit SW1(config-pmap)# exit Step 3: Apply the output service policy to all interfaces as shown in the configuration example below: SW1(config)# int e1/1 SW1(config-if)# service-policy output QOS_POLICY SW1(config-if)# exit SW1(config)# int e1/2 SW1(config-if)# service-policy output QOS_POLICY SW1(config-if)# end

b
The Cisco switch must be configured to enforce a Quality-of-Service (QoS) policy to limit the effects of packet flooding denial-of-service (DoS) attacks.
SC-5 - Medium - CCI-001095 - V-221131 - SV-221131r999740_rule
RMF Control
SC-5
Severity
Medium
CCI
CCI-001095
Version
CISC-RT-000780
Vuln IDs
  • V-221131
  • V-101977
Rule IDs
  • SV-221131r999740_rule
  • SV-111081
DoS is a condition when a resource is not available for legitimate users. Packet flooding distributed denial-of-service (DDoS) attacks are referred to as volumetric attacks and have the objective of overloading a network or circuit to deny or seriously degrade performance, which denies access to the services that normally traverse the network or circuit. Volumetric attacks have become relatively easy to launch using readily available tools such as Low Orbit Ion Cannon or botnets. Measures to mitigate the effects of a successful volumetric attack must be taken to ensure that sufficient capacity is available for mission-critical traffic. Managing capacity may include, for example, establishing selected network usage priorities or quotas and enforcing them using rate limiting, Quality of Service (QoS), or other resource reservation control methods. These measures may also mitigate the effects of sudden decreases in network capacity that are the result of accidental or intentional physical damage to telecommunications facilities (such as cable cuts or weather-related outages).
Checks: C-22846r409882_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 ip dscp cs1 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 CONTROL_PLANE priority percent 10 class C2_VOICE priority percent 10 class VOICE priority percent 15 class VIDEO bandwidth percent 25 class PREFERRED_DATA bandwidth percent 25 class SCAVENGER bandwidth percent 5 class class-default bandwidth percent 10 Note: Traffic out of profile must be marked at the customer access layer or CE egress edge. If the switch is not configured to enforce a QoS policy to limit the effects of packet flooding DoS attacks, this is a finding.

Fix: F-22835r409883_fix

Step 1: Configure a class map for the SCAVENGER class. SW1(config)# class-map match-all SCAVENGER SW1(config-cmap)# match ip dscp cs1 Step 2: Add the SCAVENGER class to the policy map as shown in the example below: SW1(config)# policy-map QOS_POLICY SW1(config-pmap-c)# no class class-default SW1(config-pmap)# class SCAVENGER SW1(config-pmap-c)# bandwidth percent 5 SW1(config-pmap-c)# class class-default SW1(config-pmap-c)# bandwidth percent 10 SW1(config-pmap-c)# end

b
The Cisco multicast switch must be configured to disable Protocol Independent Multicast (PIM) on all interfaces that are not required to support multicast routing.
AC-4 - Medium - CCI-001414 - V-221132 - SV-221132r999741_rule
RMF Control
AC-4
Severity
Medium
CCI
CCI-001414
Version
CISC-RT-000790
Vuln IDs
  • V-221132
  • V-101979
Rule IDs
  • SV-221132r999741_rule
  • SV-111083
If multicast traffic is forwarded beyond the intended boundary, it is possible that it can be intercepted by unauthorized or unintended personnel. Limiting where, within the network, a given multicast group's data is permitted to flow is an important first step in improving multicast security. A scope zone is an instance of a connected region of a given scope. Zones of the same scope cannot overlap while zones of a smaller scope will fit completely within a zone of a larger scope. For example, Admin-local scope is smaller than Site-local scope, so the administratively configured boundary fits within the bounds of a site. According to RFC 4007 IPv6 Scoped Address Architecture (section 5), scope zones are also required to be "convex from a routing perspective"; that is, packets routed within a zone must not pass through any links that are outside of the zone. This requirement forces each zone to be one contiguous island rather than a series of separate islands. As stated in the DoD IPv6 IA Guidance for MO3, "One should be able to identify all interfaces of a zone by drawing a closed loop on their network diagram, engulfing some switches and passing through some switches to include only some of their interfaces." Therefore, it is imperative that the network engineers have documented their multicast topology and thereby knows which interfaces are enabled for multicast. Once this is done, the zones can be scoped as required.
Checks: C-22847r409885_chk

Step 1: Review the network's multicast topology diagram. Step 2: Review the switch configuration to verify that only the PIM interfaces as shown in the multicast topology diagram are enabled for PIM as shown in the example below: interface Ethernet2/1 no switchport ip address 10.1.12.1/24 ip pim sparse-mode If an interface is not required to support multicast routing and it is enabled, this is a finding.

Fix: F-22836r409886_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. SW1(config)# int e2/1 SW1(config-if)# no ip pim sparse-mode SW1(config-if)# end

b
The Cisco multicast switch must be configured to bind a Protocol Independent Multicast (PIM) neighbor filter to interfaces that have PIM enabled.
AC-4 - Medium - CCI-001414 - V-221133 - SV-221133r999742_rule
RMF Control
AC-4
Severity
Medium
CCI
CCI-001414
Version
CISC-RT-000800
Vuln IDs
  • V-221133
  • V-101981
Rule IDs
  • SV-221133r999742_rule
  • SV-111085
PIM is a routing protocol used to build multicast distribution trees for forwarding multicast traffic across the network infrastructure. PIM traffic must be limited to only known PIM neighbors by configuring and binding a PIM neighbor filter to those interfaces that have PIM enabled. If a PIM neighbor filter is not applied to those interfaces that have PIM enabled, unauthorized switches can join the PIM domain, discover and use the rendezvous points, and also advertise their rendezvous points into the domain. This can result in a denial of service by traffic flooding or result in the unauthorized transfer of data.
Checks: C-22848r409888_chk

Step 1: Verify all interfaces enabled for PIM have a neighbor policy bound to the interface as shown in the example below: interface Ethernet2/1 no switchport ip address 10.1.12.1/24 ip pim sparse-mode ip pim neighbor-policy prefix-list PIM_NEIGHBOR no shutdown Step 2: Review the configured prefix list for filtering PIM neighbors as shown in the example below: ip prefix-list PIM_NEIGHBOR seq 5 permit 10.1.12.2/32 ip prefix-list PIM_NEIGHBOR seq 10 deny 0.0.0.0/0 le 32 If PIM neighbor ACLs are not bound to all interfaces that have PIM enabled, this is a finding.

Fix: F-22837r409889_fix

Configure neighbor prefix lists to only accept PIM control plane traffic from documented PIM neighbors. Step 1: Configure prefix list for each PIM neighbor. SW1(config)# ip prefix-list PIM_NEIGHBOR seq 5 permit 10.1.12.2/32 SW1(config)# ip prefix-list PIM_NEIGHBOR deny 0.0.0.0/0 le 32 Step 2: Apply a prefix to all interfaces enabled for PIM. SW1(config)# int e2/1 SW1(config-if)# ip pim neighbor-policy prefix-list PIM_NEIGHBOR SW1(config-if)# end

a
The Cisco multicast edge switch must be configured to establish boundaries for administratively scoped multicast traffic.
AC-4 - Low - CCI-001414 - V-221134 - SV-221134r999743_rule
RMF Control
AC-4
Severity
Low
CCI
CCI-001414
Version
CISC-RT-000810
Vuln IDs
  • V-221134
  • V-101983
Rule IDs
  • SV-221134r999743_rule
  • SV-111087
If multicast traffic is forwarded beyond the intended boundary, it is possible that it can be intercepted by unauthorized or unintended personnel. Administrative scoped multicast addresses are locally assigned and are to be used exclusively by the enterprise network or enclave. Administrative scoped multicast traffic must not cross the enclave perimeter in either direction. Restricting multicast traffic makes it more difficult for a malicious user to access sensitive traffic. Admin-Local scope is encouraged for any multicast traffic within a network intended for network management, as well as for control plane traffic that must reach beyond link-local destinations.
Checks: C-22849r409891_chk

Multicast boundary for NX-OS can be established via combination of the border command along with an ACL to filter admin-scoped multicast traffic. Step 1: Verify that the interface at the multicast domain edge has been configured with both an ingress and egress ACL. interface Ethernet2/1 no switchport ip access-group FILTER_TRAFFIC_IN in ip access-group FILTER_TRAFFIC_OUT out ip address 10.1.12.1/24 ip pim sparse-mode ip pim border Note: The command ip pim border enables the interface to be on the border of PIM domain so that no bootstrap, candidate-RP, or Auto-RP messages are sent or received on the interface. Step 2: Verify that the ingress and egress ACLs block the address range for administratively scoped multicast traffic. ip access-list FILTER_TRAFFIC_IN 10 deny ip any 239.0.0.0/8 20 permit tcp any any established … … … 90 deny ip any any log ip access-list FILTER_TRAFFIC_OUT 10 deny ip any 239.0.0.0/8 20 deny ip … … 80 permit ip any any If the switch is not configured to establish boundaries for administratively scoped multicast traffic, this is a finding.

Fix: F-22838r409892_fix

Step 1: Configure an ingress and egress ACL to block administratively scoped multicast traffic. SW1(config)# ip access-list FILTER_TRAFFIC_IN SW1(config-acl)# deny 239.0.0.0/8 SW1(config-acl)# permit tcp any any established SW1(config-acl)# … SW1(config-acl)# deny ip any any log SW1(config-acl)# exit SW1(config)# ip access-list FILTER_TRAFFIC_OUT SW1(config-acl)# deny 239.0.0.0/8 SW1(config-acl)# … SW1(config-acl)# permit ip any any SW1(config-acl)# exit Step 2: Apply the ingress and egress ACL to the applicable interfaces. SW1(config)# int e2/1 SW1(config-if)# ip access-group FILTER_TRAFFIC_IN in SW1(config-if)# ip access-group FILTER_TRAFFIC_OUT out SW1(config-if)# end

a
The Cisco multicast Rendezvous Point (RP) switch must be configured to limit the multicast forwarding cache so that its resources are not saturated by managing an overwhelming number of Protocol Independent Multicast (PIM) and Multicast Source Discovery Protocol (MSDP) source-active entries.
SC-5 - Low - CCI-002385 - V-221135 - SV-221135r999744_rule
RMF Control
SC-5
Severity
Low
CCI
CCI-002385
Version
CISC-RT-000820
Vuln IDs
  • V-221135
  • V-101985
Rule IDs
  • SV-221135r999744_rule
  • SV-111089
MSDP peering between networks enables sharing of multicast source information. Enclaves with an existing multicast topology using PIM-SM can configure their RP switches to peer with MSDP switches. As a first step of defense against a denial-of-service (DoS) attack, all RP switches must limit the multicast forwarding cache to ensure that switch resources are not saturated managing an overwhelming number of PIM and MSDP source-active entries.
Checks: C-22850r409894_chk

The Cisco switch 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 switch to filter PIM register messages and accept MSDP packets only from known MSDP peers. Step 1: Verify that the RP 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 x.1.2.6 and x.1.2.7. ip pim register-policy PIM_REGISTER_FILTER … … … route-map PIM_REGISTER_FILTER deny 10 match ip multicast group 239.5.0.0/16 route-map PIM_REGISTER_FILTER permit 20 match ip multicast source x.1.2.6/32 route-map PIM_REGISTER_FILTER permit 30 match ip multicast source x.1.2.7/32 route-map PIM_REGISTER_FILTER permit 40 match ip multicast group-range 232.0.0.0 to 233.255.255.255 route-map PIM_REGISTER_FILTER deny 50 match ip multicast source 0.0.0.0/0 Step 2: Review the switch 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 2a: Verify that interfaces used for MSDP peering have an inbound ACL as shown in the example. interface Ethernet2/3 no switchport ip access-group EXTERNAL_ACL_INBOUND in ip address x.1.28.8/24 ip pim sparse-mode Step 2b: Verify that the ACL restricts MSDP peering to only known sources. ip access-list EXTERNAL_ACL_INBOUND 10 permit tcp any any established 20 permit tcp x.1.28.2/32 x.1.28.8/32 eq 639 30 deny tcp any x.1.28.8/32 eq 639 log 40 permit tcp x.1.28.2/32 10.x.28.8/32 eq bgp 50 permit tcp x.1.28.2/32 eq bgp x.1.28.8/32 60 permit pim x.1.28.2/32 x.1.28.8/32 … … … 120 deny ip any any log Note: MSDP connections is via TCP port 639. If the RP switch is not configured to filter PIM register messages and accept MSDP packets only from known MSDP peers, this is a finding.

Fix: F-22839r409895_fix

The risk associated with this requirement can be fully mitigated by configuring the switch 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 switch 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 x.1.2.6 and x.1.2.7. Step 1a: Configure a route map to filter multicast groups and sources as shown in the example below: SW1(config)# route-map PIM_REGISTER_FILTER deny 10 SW1(config-route-map)# match ip multicast group 239.5.0.0/16 SW1(config-route-map)# route-map PIM_REGISTER_FILTER permit 20 SW1(config-route-map)# match ip multicast source x.1.2.6/32 SW1(config-route-map)# route-map PIM_REGISTER_FILTER permit 30 SW1(config-route-map)# match ip multicast source x.1.2.7/32 SW1(config-route-map)# route-map PIM_REGISTER_FILTER permit 40 SW1(config-route-map)# match ip multicast group-range 232.0.0.0 to 233.255.255.255 SW1(config-route-map)# route-map PIM_REGISTER_FILTER deny 50 SW1(config-route-map)# match ip multicast source 0.0.0.0/0 SW1(config-route-map)# exit Step 1b: Configure a multicast register policy referencing the configured route map. SW1(config)# ip pim register-policy PIM_REGISTER_FILTER SW1(config)# end Step 2: Configure the receive path or interface ACLs to only accept MSDP packets from known MSDP peers. SW1(config)# ip access-list EXTERNAL_ACL_INBOUND SW1(config-acl) # permit tcp any any established SW1(config-acl) # permit tcp host x.1.28.2 host x.1.28.8 eq 639 SW1(config-acl) # deny tcp any host x1.28.8 eq 639 SW1(config-acl) # permit tcp host x.1.28.2 host x.1.28.8 eq bgp SW1(config-acl) # permit tcp host x.1.28.2 eq bgp host x.1.28.8 SW1(config-acl) # permit pim host x.1.28.2 host x.1.28.8 … … … SW1(config-acl)# deny ip any any

a
The Cisco multicast Rendezvous Point (RP) switch must be configured to filter Protocol Independent Multicast (PIM) Register messages received from the Designated switch (DR) for any undesirable multicast groups and sources.
AC-4 - Low - CCI-001414 - V-221136 - SV-221136r999745_rule
RMF Control
AC-4
Severity
Low
CCI
CCI-001414
Version
CISC-RT-000830
Vuln IDs
  • V-221136
  • V-101987
Rule IDs
  • SV-221136r999745_rule
  • SV-111091
Real-time multicast traffic can entail multiple large flows of data. An attacker can flood a network segment with multicast packets, over-using the available bandwidth and thereby creating a denial-of-service (DoS) condition. Hence, it is imperative that register messages are accepted only for authorized multicast groups and sources.
Checks: C-22851r409897_chk

Verify that the RP switch 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 x.1.2.6 and x.1.2.7. ip pim register-policy PIM_REGISTER_FILTER … … … route-map PIM_REGISTER_FILTER deny 10 match ip multicast group 239.5.0.0/16 route-map PIM_REGISTER_FILTER permit 20 match ip multicast source x.1.2.6/32 route-map PIM_REGISTER_FILTER permit 30 match ip multicast source x.1.2.7/32 route-map PIM_REGISTER_FILTER permit 40 match ip multicast group-range 232.0.0.0 to 233.255.255.255 route-map PIM_REGISTER_FILTER deny 50 match ip multicast source 0.0.0.0/0 If the RP switch peering with PIM-SM switches is not configured with a policy to block registration messages for any undesirable multicast groups and sources, this is a finding.

Fix: F-22840r409898_fix

Configure the switch 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 x.1.2.6 and x.1.2.7. Step 1: Configure a route map to filter multicast groups and sources as shown in the example below: SW1(config)# route-map PIM_REGISTER_FILTER deny 10 SW1(config-route-map)# match ip multicast group 239.5.0.0/16 SW1(config-route-map)# route-map PIM_REGISTER_FILTER permit 20 SW1(config-route-map)# match ip multicast source x.1.2.6/32 SW1(config-route-map)# route-map PIM_REGISTER_FILTER permit 30 SW1(config-route-map)# match ip multicast source x.1.2.7/32 SW1(config-route-map)# route-map PIM_REGISTER_FILTER permit 40 SW1(config-route-map)# match ip multicast group-range 232.0.0.0 to 233.255.255.255 SW1(config-route-map)# route-map PIM_REGISTER_FILTER deny 50 SW1(config-route-map)# match ip multicast source 0.0.0.0/0 SW1(config-route-map)# exit Step 2: Configure a multicast register policy referencing the configured route map. SW1(config)# ip pim register-policy PIM_REGISTER_FILTER SW1(config)# end

a
The Cisco multicast Rendezvous Point (RP) switch must be configured to filter Protocol Independent Multicast (PIM) Join messages received from the Designated Cisco switch (DR) for any undesirable multicast groups.
AC-4 - Low - CCI-001414 - V-221137 - SV-221137r999746_rule
RMF Control
AC-4
Severity
Low
CCI
CCI-001414
Version
CISC-RT-000840
Vuln IDs
  • V-221137
  • V-102211
Rule IDs
  • SV-221137r999746_rule
  • SV-111167
Real-time multicast traffic can entail multiple large flows of data. An attacker can flood a network segment with multicast packets, over-using the available bandwidth and thereby creating a denial-of-service (DoS) condition. Hence, it is imperative that join messages are only accepted for authorized multicast groups.
Checks: C-22852r409900_chk

Verify that the RP switch is configured to filter PIM join messages for any undesirable multicast groups. In the example below, groups from 239.8.0.0/16 are not allowed. route-map PIM_JOIN_FILTER deny 10 match ip multicast group 239.0.0.0/8 route-map PIM_JOIN_FILTER permit 20 match ip multicast group 224.0.0.0/4 … … … interface Ethernet2/1 no switchport ip address 10.1.12.1/24 ip pim sparse-mode ip pim jp-policy PIM_JOIN_FILTER in 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-22841r409901_fix

Configure the RP to filter PIM join messages for any undesirable multicast groups as shown in the example below: Step 1: Configure a PIM Join filter as shown in the example below: SW1(config)# route-map PIM_JOIN_FILTER deny SW1(config-route-map)# match ip multicast group 239.8.0.0/8 SW1(config-route-map)# route-map PIM_JOIN_FILTER permit 20 SW1(config-route-map)# match ip multicast group 224.0.0.0/4 SW1(config-route-map)# exit Step 2: Apply the PIM Join filter to the appropriate interfaces. SW1(config)# int e2/1 SW1(config-if)# ip pim jp-policy PIM_JOIN_FILTER in SW1(config-if)# end

a
The Cisco multicast Designated switch (DR) must be configured to filter the Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Report messages to allow hosts to join only multicast groups that have been approved by the organization.
SC-7 - Low - CCI-002403 - V-221138 - SV-221138r999747_rule
RMF Control
SC-7
Severity
Low
CCI
CCI-002403
Version
CISC-RT-000860
Vuln IDs
  • V-221138
  • V-102213
Rule IDs
  • SV-221138r999747_rule
  • SV-111169
Real-time multicast traffic can entail multiple large flows of data. Large unicast flows tend to be fairly isolated (i.e., someone doing a file download here or there), whereas multicast can have broader impact on bandwidth consumption, resulting in extreme network congestion. Hence, it is imperative that there is multicast admission control to restrict which multicast groups hosts are allowed to join via IGMP or MLD.
Checks: C-22853r409903_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: interface Ethernet2/4 no switchport ip address 10.2.22.3/24 ip pim sparse-mode ip igmp version 3 ip igmp report-policy ALLOWED_GROUPS Step 2: Verify that the report policy denies unauthorized groups or permits only authorized groups. route-map ALLOWED_GROUPS permit 10 match ip multicast group 233.1.1.0/24 route-map ALLOWED_GROUPS permit 20 match ip multicast group 233.1.1.0/32 route-map ALLOWED_GROUPS permit 30 match ip multicast group 233.1.1.1/32 route-map ALLOWED_GROUPS deny 40 match ip multicast group 224.0.0.0/4 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. If the DR is not filtering IGMP or MLD Membership Report messages, this is a finding.

Fix: F-22842r409904_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 report policy to filter IGMP Membership Report messages as shown in the example below: SW1(config)# route-map ALLOWED_GROUPS permit SW1(config-route-map)# match ip multicast group 233.1.1.0/24 SW1(config-route-map)# route-map ALLOWED_GROUPS permit 20 SW1(config-route-map)# match ip multicast group 233.1.1.0/32 SW1(config-route-map)# route-map ALLOWED_GROUPS permit 30 SW1(config-route-map)# match ip multicast group 233.1.1.1/32 SW1(config-route-map)# route-map ALLOWED_GROUPS deny 40 SW1(config-route-map)# match ip multicast group 224.0.0.0/4 SW1(config-route-map)# exit Step 2: Apply the report policy to all applicable interfaces. SW1(config)# int e2/4 SW1(config-if)# ip igmp report-policy ALLOWED_GROUPS SW1(config-if)# end

b
The Cisco multicast Designated switch (DR) must be configured to filter the Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Report messages to allow hosts to join a multicast group only from sources that have been approved by the organization.
SC-7 - Medium - CCI-002403 - V-221139 - SV-221139r999748_rule
RMF Control
SC-7
Severity
Medium
CCI
CCI-002403
Version
CISC-RT-000870
Vuln IDs
  • V-221139
  • V-102215
Rule IDs
  • SV-221139r999748_rule
  • SV-111171
Real-time multicast traffic can entail multiple large flows of data. Large unicast flows tend to be fairly isolated (i.e., someone doing a file download here or there), whereas multicast can have broader impact on bandwidth consumption, resulting in extreme network congestion. Hence, it is imperative that there is multicast admission control to restrict which multicast groups hosts are allowed to join via IGMP or MLD.
Checks: C-22854r409906_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: interface Ethernet2/4 no switchport ip address 10.2.22.3/24 ip pim sparse-mode ip igmp version 3 ip igmp report-policy ALLOWED_SOURCES Step 2: Verify that the report policy permits only sources that have been approved by the organization. route-map ALLOWED_SOURCES permit 10 match ip multicast source x.1.2.6/32 route-map ALLOWED_SOURCES permit 20 match ip multicast source x.1.2.7/32 route-map ALLOWED_SOURCES deny 30 match ip multicast source 0.0.0.0/0 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-22843r409907_fix

Step 1: Configure the report policy to filter IGMP Membership Report messages as shown in the example below: SW1(config-route-map)# route-map ALLOWED_SOURCES permit 10 SW1(config-route-map)# match ip multicast source x.1.2.6/32 SW1(config-route-map)# route-map ALLOWED_SOURCES permit 20 SW1(config-route-map)# match ip multicast source x.1.2.7/32 SW1(config-route-map)# route-map ALLOWED_SOURCES deny 30 SW1(config-route-map)# match ip multicast source 0.0.0.0/0 SW1(config-route-map)# exit Step 2: Apply the report policy to all applicable interfaces. SW1(config)# int e2/4 SW1(config-if)# ip igmp report-policy ALLOWED_SOURCES SW1(config-if)# end

b
The Cisco multicast Designated switch (DR) must be configured to limit the number of mroute states resulting from Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Host Membership Reports.
SC-5 - Medium - CCI-002385 - V-221140 - SV-221140r999749_rule
RMF Control
SC-5
Severity
Medium
CCI
CCI-002385
Version
CISC-RT-000880
Vuln IDs
  • V-221140
  • V-102217
Rule IDs
  • SV-221140r999749_rule
  • SV-111173
The current multicast paradigm can let any host join any multicast group at any time by sending an IGMP or MLD membership report to the DR. In a Protocol Independent Multicast (PIM) Sparse Mode network, the DR will send a PIM Join message for the group to the RP. Without any form of admission control, this can pose a security risk to the entire multicast domain, specifically the multicast switches along the shared tree from the DR to the RP that must maintain the mroute state information for each group join request. Hence, it is imperative that the DR is configured to limit the number of mroute state information that must be maintained to mitigate the risk of IGMP or MLD flooding.
Checks: C-22855r409909_chk

Review the DR configuration to verify that it is limiting the number of mroute states via IGMP or MLD. Verify IGMP state limits have been configured on all applicable interfaces as shown in the example below: interface Ethernet2/4 no switchport ip address 10.2.22.3/24 ip pim sparse-mode ip igmp version 3 ip igmp state-limit nnn If the DR is not limiting multicast join requests via IGMP or MLD on all applicable interfaces, this is a finding.

Fix: F-22844r409910_fix

Configure the DR on a global or interface basis to limit the number of mroute states resulting from IGMP or MLD membership reports. SW1(config)# int e2/4 SW1(config-if)# ip igmp state-limit 44 SW1(config-if)# end

b
The Cisco multicast Designated switch (DR) must be configured to set the shortest-path tree (SPT) threshold to infinity to minimalize source-group (S, G) state within the multicast topology where Any Source Multicast (ASM) is deployed.
CM-6 - Medium - CCI-000366 - V-221141 - SV-221141r999750_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
CISC-RT-000890
Vuln IDs
  • V-221141
  • V-102219
Rule IDs
  • SV-221141r999750_rule
  • SV-111175
ASM can have many sources for the same groups (many-to-many). For many receivers, the path via the RP may not be ideal compared with the shortest path from the source to the receiver. By default, the last-hop switch will initiate a switch from the shared tree to a source-specific SPT to obtain lower latencies. This is accomplished by the last-hop switch sending an (S, G) Protocol Independent Multicast (PIM) Join toward S (the source). When the last-hop switch begins to receive traffic for the group from the source via the SPT, it will send a PIM Prune message to the RP for the (S, G). The RP will then send a Prune message toward the source. The SPT switchover becomes a scaling issue for large multicast topologies that have many receivers and many sources for many groups because (S, G) entries require more memory than (*, G). Hence, it is imperative to minimize the amount of (S, G) state to be maintained by increasing the threshold that determines when the SPT switchover occurs.
Checks: C-22856r409912_chk

Review the DR configuration to verify that the SPT switchover threshold is set to infinity (never switch over). ip pim spt-threshold infinity group-list prefix-list SPT_GROUPS Note: The default behavior is to join the SPT immediately upon the first data packet it receives. If the DR is not configured set SPT threshold to infinity to minimalize (S, G) state, this is a finding.

Fix: F-22845r409913_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. Step 1: Configure a prefix list or route map to specify the ASM groups. The example below includes all global ASM groups. SW1(config)# ip prefix-list SPT_GROUPS permit 233.0.0.0/8 Step 2. Configure the SPT threshold to infinity. SW1(config)# ip pim spt-threshold infinity group prefix-list SPT_GROUPS SW1(config)# end

b
The Cisco Multicast Source Discovery Protocol (MSDP) switch must be configured to only accept MSDP packets from known MSDP peers.
SC-7 - Medium - CCI-002403 - V-221142 - SV-221142r999751_rule
RMF Control
SC-7
Severity
Medium
CCI
CCI-002403
Version
CISC-RT-000900
Vuln IDs
  • V-221142
  • V-102221
Rule IDs
  • SV-221142r999751_rule
  • SV-111177
MSDP peering with customer network switches presents additional risks to the DISN Core, whether from a rogue or misconfigured MSDP-enabled switch. To guard against an attack from malicious MSDP traffic, the receive path or interface filter for all MSDP-enabled RP switches must be configured to only accept MSDP packets from known MSDP peers.
Checks: C-22857r409915_chk

Review the switch configuration to determine if there is a receive path or interface filter to only accept MSDP packets from known MSDP peers. Step 1: Verify that interfaces used for MSDP peering have an inbound ACL as shown in the example below: interface Ethernet2/3 no switchport ip access-group EXTERNAL_ACL_INBOUND in ip address x.1.28.8/24 ip pim sparse-mode Step 2: Verify that the ACL restricts MSDP peering to only known sources. ip access-list EXTERNAL_ACL_INBOUND 10 permit tcp any any established 20 permit tcp x.1.28.2/32 x.1.28.8/32 eq 639 30 deny tcp any x.1.28.8/32 eq 639 log 40 permit tcp x.1.28.2/32 10.x.28.8/32 eq bgp 50 permit tcp x.1.28.2/32 eq bgp x.1.28.8/32 60 permit pim x.1.28.2/32 x.1.28.8/32 … … … 120 deny ip any any log Note: MSDP connections are via TCP port 639. If the switch is not configured to only accept MSDP packets from known MSDP peers, this is a finding.

Fix: F-22846r409916_fix

Configure the receive path or interface ACLs to only accept MSDP packets from known MSDP peers. SW1(config)# ip access-list EXTERNAL_ACL_INBOUND SW1(config-acl) # permit tcp any any established SW1(config-acl) # permit tcp host x.1.28.2 host x.1.28.8 eq 639 SW1(config-acl) # deny tcp any host x1.28.8 eq 639 SW1(config-acl) # permit tcp host x.1.28.2 host x.1.28.8 eq bgp SW1(config-acl) # permit tcp host x.1.28.2 eq bgp host x.1.28.8 SW1(config-acl) # permit pim host x.1.28.2 host x.1.28.8 … … … SW1(config-acl)# deny ip any any

b
The Cisco Multicast Source Discovery Protocol (MSDP) switch must be configured to authenticate all received MSDP packets.
IA-3 - Medium - CCI-001958 - V-221143 - SV-221143r999752_rule
RMF Control
IA-3
Severity
Medium
CCI
CCI-001958
Version
CISC-RT-000910
Vuln IDs
  • V-221143
  • V-102297
Rule IDs
  • SV-221143r999752_rule
  • SV-111253
MSDP peering with customer network switches presents additional risks to the core, whether from a rogue or misconfigured MSDP-enabled switch. MSDP password authentication is used to validate each segment sent on the TCP connection between MSDP peers, protecting the MSDP session against the threat of spoofed packets being injected into the TCP connection stream.
Checks: C-22858r409918_chk

Review the switch configuration to determine if received MSDP packets are authenticated. ip msdp peer x.1.28.2 remote-as nn ip msdp password peer x.1.28.2 xxxxxxxxxxxx ip msdp peer x.1.28.2 connect-source Ethernet2/3 remote-as 8 ip msdp password x.1.28.2 3 3ec66c90c104ad13 If the switch does not require MSDP authentication, this is a finding.

Fix: F-22847r409919_fix

Configure the switch to authenticate MSDP messages as shown in the following example: SW1(config)# ip msdp password x.1.28.2 xxxxxxxxxxxx

a
The Cisco Multicast Source Discovery Protocol (MSDP) switch must be configured to filter received source-active multicast advertisements for any undesirable multicast groups and sources.
AC-4 - Low - CCI-001368 - V-221144 - SV-221144r999753_rule
RMF Control
AC-4
Severity
Low
CCI
CCI-001368
Version
CISC-RT-000920
Vuln IDs
  • V-221144
  • V-102299
Rule IDs
  • SV-221144r999753_rule
  • SV-111255
The interoperability of BGP extensions for interdomain multicast routing and MSDP enables seamless connectivity of multicast domains between autonomous systems. MP-BGP advertises the unicast prefixes of the multicast sources used by Protocol Independent Multicast (PIM) switches to perform RPF checks and build multicast distribution trees. MSDP is a mechanism used to connect multiple PIM sparse-mode domains, allowing RPs from different domains to share information about active sources. When RPs in peering multicast domains hear about active sources, they can pass on that information to their local receivers, thereby allowing multicast data to be forwarded between the domains. Configuring an import policy to block multicast advertisements for reserved, Martian, single-source multicast, and any other undesirable multicast groups, as well as any source-group (S, G) states with Bogon source addresses, would assist in avoiding unwanted multicast traffic from traversing the core.
Checks: C-22859r409921_chk

Review the switch 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. ip msdp peer x.1.28.2 connect-source Ethernet2/1 remote-as nn ip msdp sa-policy x.1.28.2 prefix-list INBOUND_MSDP_SA_FILTER in Step 2: Review the prefix-list or route-map 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. ip prefix-list INBOUND_MSDP_SA_FILTER seq 10 deny 224.0.1.3/32 ip prefix-list INBOUND_MSDP_SA_FILTER seq 15 deny 224.0.1.24/32 ip prefix-list INBOUND_MSDP_SA_FILTER seq 20 deny 224.0.1.22/32 ip prefix-list INBOUND_MSDP_SA_FILTER seq 25 deny 224.0.1.2/32 ip prefix-list INBOUND_MSDP_SA_FILTER seq 30 deny 224.0.1.35/32 ip prefix-list INBOUND_MSDP_SA_FILTER seq 35 deny 224.0.1.60/32 ip prefix-list INBOUND_MSDP_SA_FILTER seq 40 deny 224.0.1.39/32 ip prefix-list INBOUND_MSDP_SA_FILTER seq 45 deny 224.0.1.40/32 ip prefix-list INBOUND_MSDP_SA_FILTER seq 50 deny 232.0.0.0/8 le 32 ip prefix-list INBOUND_MSDP_SA_FILTER seq 55 deny 239.0.0.0/8 le 32 ip prefix-list INBOUND_MSDP_SA_FILTER seq 60 deny 10.0.0.0/8 le 32 ip prefix-list INBOUND_MSDP_SA_FILTER seq 70 deny 172.16.0.0/12 le 32 ip prefix-list INBOUND_MSDP_SA_FILTER seq 75 permit 0.0.0.0/0 ge 8 If the switch is not configured with an import policy to filter undesirable SA multicast advertisements, this is a finding.

Fix: F-22848r409922_fix

Configure the MSDP switch to filter received source-active multicast advertisements for any undesirable multicast groups and sources as shown in the example below: SW1(config)# ip prefix-list INBOUND_MSDP_SA_FILTER seq 10 deny 224.0.1.3/32 SW1(config)# ip prefix-list INBOUND_MSDP_SA_FILTER seq 15 deny 224.0.1.24/32 SW1(config)# ip prefix-list INBOUND_MSDP_SA_FILTER seq 20 deny 224.0.1.22/32 SW1(config)# ip prefix-list INBOUND_MSDP_SA_FILTER seq 25 deny 224.0.1.2/32 SW1(config)# ip prefix-list INBOUND_MSDP_SA_FILTER seq 30 deny 224.0.1.35/32 SW1(config)# ip prefix-list INBOUND_MSDP_SA_FILTER seq 35 deny 224.0.1.60/32 SW1(config)# ip prefix-list INBOUND_MSDP_SA_FILTER seq 40 deny 224.0.1.39/32 SW1(config)# ip prefix-list INBOUND_MSDP_SA_FILTER seq 45 deny 224.0.1.40/32 SW1(config)# ip prefix-list INBOUND_MSDP_SA_FILTER seq 50 deny 232.0.0.0/8 le 32 SW1(config)# ip prefix-list INBOUND_MSDP_SA_FILTER seq 55 deny 239.0.0.0/8 le 32 SW1(config)# ip prefix-list INBOUND_MSDP_SA_FILTER seq 60 deny 10.0.0.0/8 le 32 SW1(config)# ip prefix-list INBOUND_MSDP_SA_FILTER seq 165 deny 127.0.0.0/8 le 32 SW1(config)# ip prefix-list INBOUND_MSDP_SA_FILTER seq 70 deny 172.16.0.0/12 le 32 SW1(config)# ip prefix-list INBOUND_MSDP_SA_FILTER seq 75 permit 0.0.0.0/0 ge 8 SW1(config)# exit SW1(config)# ip msdp sa-policy x.1.28.2 prefix-list INBOUND_MSDP_SA_FILTER in SW1(config)# end

a
The Cisco Multicast Source Discovery Protocol (MSDP) switch must be configured to filter source-active multicast advertisements to external MSDP peers to avoid global visibility of local-only multicast sources and groups.
AC-4 - Low - CCI-001368 - V-221145 - SV-221145r999754_rule
RMF Control
AC-4
Severity
Low
CCI
CCI-001368
Version
CISC-RT-000930
Vuln IDs
  • V-221145
  • V-102301
Rule IDs
  • SV-221145r999754_rule
  • SV-111257
To avoid global visibility of local information, there are a number of source-group (S, G) states in a PIM-SM domain that must not be leaked to another domain, such as multicast sources with private address, administratively scoped multicast addresses, and the auto-RP groups (224.0.1.39 and 224.0.1.40). Allowing a multicast distribution tree, local to the core, to extend beyond its boundary could enable local multicast traffic to leak into other autonomous systems and customer networks.
Checks: C-22860r409924_chk

Review the switch 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: ip msdp peer x.1.28.2 connect-source Ethernet2/1 remote-as nn ip msdp sa-policy x.1.28.2 prefix-list OUTBOUND_MSDP_SA_FILTER out 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. ip prefix-list OUTBOUND_MSDP_SA_FILTER seq 10 deny 10.0.0.0/8 le 32 ip prefix-list OUTBOUND_MSDP_SA_FILTER seq 20 permit 0.0.0.0/0 ge 8 If the switch is not configured with an export policy to filter local source-active multicast advertisements, this is a finding.

Fix: F-22849r409925_fix

Configure the switch 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. SW1(config)# ip prefix-list OUTBOUND_MSDP_SA_FILTER seq 10 deny 10.0.0.0/8 le 32 SW1(config)# ip prefix-list OUTBOUND_MSDP_SA_FILTER seq 20 permit 0.0.0.0/0 ge 8 SW1(config)# exit SW1(config)# ip msdp sa-policy x.1.28.2 prefix-list OUTBOUND_MSDP_SA_FILTER out SW1(config)# end

a
The Cisco Multicast Source Discovery Protocol (MSDP) switch must be configured to limit the amount of source-active messages it accepts on a per-peer basis.
AC-4 - Low - CCI-001368 - V-221146 - SV-221146r999755_rule
RMF Control
AC-4
Severity
Low
CCI
CCI-001368
Version
CISC-RT-000940
Vuln IDs
  • V-221146
  • V-102303
Rule IDs
  • SV-221146r999755_rule
  • SV-111259
To reduce any risk of a denial-of-service (DoS) attack from a rogue or misconfigured MSDP switch, the switch must be configured to limit the number of source-active messages it accepts from each peer.
Checks: C-22861r409927_chk

Review the switch configuration to determine if it is configured to limit the amount of source-active messages it accepts on a per-peer basis. ip msdp peer x.1.28.2 connect-source Ethernet2/1 remote-as nn … … … ip msdp sa-limit x.1.28.2 nnn If the switch is not configured to limit the source-active messages it accepts, this is a finding.

Fix: F-22850r409928_fix

Configure the switch to limit the amount of source-active messages it accepts from each peer. SW1(config)# ip msdp sa-limit x.1.28.2 nnn SW1(config)# end

a
The Cisco Multicast Source Discovery Protocol (MSDP) switch must be configured to use a loopback address as the source address when originating MSDP traffic.
- Low - CCI-004931 - V-221147 - SV-221147r999776_rule
RMF Control
Severity
Low
CCI
CCI-004931
Version
CISC-RT-000950
Vuln IDs
  • V-221147
  • V-102311
Rule IDs
  • SV-221147r999776_rule
  • SV-111267
Using a loopback address as the source address offers a multitude of uses for security, access, management, and scalability of MSDP switches. It is easier to construct appropriate ingress filters for switch management plane traffic destined to the network management subnet since the source addresses will be from the range used for loopback interfaces instead of a larger range of addresses used for physical interfaces. Log information recorded by authentication and syslog servers will record the switch’s loopback address instead of the numerous physical interface addresses.
Checks: C-22862r409930_chk

Step 1: Review the switch configuration to verify that a loopback address has been configured. interface Loopback12 ip address x.12.2.2/32 Step 2: Verify that the loopback interface is used as the source address for all MSDP packets generated by the switch. ip msdp peer x.44.2.34 connect-source Loopback12 remote-as nn If the switch does not use its loopback address as the source address when originating MSDP traffic, this is a finding.

Fix: F-22851r409931_fix

Configure the switch to use its loopback address is used as the source address when sending MSDP packets. SW1(config)# ip msdp peer x.44.2.34 connect-source lo12 remote-as nn

a
The Cisco switch must be configured to advertise a hop limit of at least 32 in Switch Advertisement messages for IPv6 stateless auto-configuration deployments.
CM-6 - Low - CCI-000366 - V-237754 - SV-237754r999759_rule
RMF Control
CM-6
Severity
Low
CCI
CCI-000366
Version
CISC-RT-000236
Vuln IDs
  • V-237754
Rule IDs
  • SV-237754r999759_rule
The Neighbor Discovery protocol allows a hop limit value to be advertised by routers in a Router Advertisement message being used by hosts instead of the standardized default value. If a very small value was configured and advertised to hosts on the LAN segment, communications would fail due to the hop limit reaching zero before the packets sent by a host reached its destination.
Checks: C-40972r999757_chk

Review the switch configuration to determine if the hop limit has been configured for Router Advertisement messages for all internal interfaces as shown in the example. interface Ethernet2/1 no switchport ipv6 address 2001::1:0:1/64 ipv6 nd hop-limit 32 no shutdown interface Ethernet2/2 no switchport ipv6 address 2001::1:1:1/64 ipv6 nd hop-limit 32 no shutdown If hop-limit has been configured and has not been set to at least 32, it is a finding.

Fix: F-40934r999758_fix

Configure the switch to advertise a hop limit of at least 32 in Router Advertisement messages as shown in the example. SW1(config)# interface e2/1 – 2 SW1(config-if-range)# ipv6 nd hop-limit 32 SW1(config-if-range)# end

b
The Cisco switch must not be configured to use IPv6 Site Local Unicast addresses.
CM-6 - Medium - CCI-000366 - V-237757 - SV-237757r999761_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
CISC-RT-000237
Vuln IDs
  • V-237757
Rule IDs
  • SV-237757r999761_rule
As currently defined, site local addresses are ambiguous and can be present in multiple sites. The address itself does not contain any indication of the site to which it belongs. The use of site-local addresses has the potential to adversely affect network security through leaks, ambiguity, and potential misrouting as documented in section 2 of RFC3879. RFC3879 formally deprecates the IPv6 site-local unicast prefix FEC0::/10 as defined in RFC3513.
Checks: C-40973r999760_chk

Review the switch configuration to ensure FEC0::/10 IPv6 addresses are not defined. If IPv6 Site Local Unicast addresses are defined, this is a finding.

Fix: F-40935r648785_fix

Configure the switch using only authorized IPv6 addresses.

b
The Cisco perimeter switch must be configured to suppress Router Advertisements on all external IPv6-enabled interfaces.
CM-6 - Medium - CCI-000366 - V-237760 - SV-237760r999764_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
CISC-RT-000391
Vuln IDs
  • V-237760
Rule IDs
  • SV-237760r999764_rule
Many of the known attacks in stateless autoconfiguration are defined in RFC 3756 were present in IPv4 ARP attacks. To mitigate these vulnerabilities, links that have no hosts connected such as the interface connecting to external gateways must be configured to suppress router advertisements.
Checks: C-40975r999762_chk

Review the switch configuration to verify that Router Advertisements are suppressed on all external IPv6-enabled interfaces as shown in the example below. interface Ethernet1/1 no switchport ipv6 address 2001::1:24:3/64 ipv6 nd suppress-ra no shutdown If the switch is not configured to suppress Router Advertisements on all external IPv6-enabled interfaces, this is a finding.

Fix: F-40937r999763_fix

Configure the switch to suppress Router Advertisements on all external IPv6-enabled interfaces as shown in the example below. SW1(config)# interface e1/1 SW1(config-if-range)# ipv6 nd suppress-ra SW1(config-if-range)# end