{"stig":{"title":"Cisco IOS XR Router RTR Security Technical Implementation Guide","version":"3","release":"3"},"checks":[{"vulnId":"V-216735","ruleId":"SV-216735r1117236_rule","severity":"medium","ruleTitle":"The Cisco router must be configured to enforce approved authorizations for controlling the flow of information within the network based on organization-defined information flow control policies.","description":"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.\n\nEnforcement occurs, for example, in boundary protection devices (e.g., gateways, routers, 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).","checkContent":"This requirement is not applicable for the DODIN Backbone.\n\nIf Virtual Routing and Forwarding (VRF) is used to segment traffic and force traffic to traverse through next generation firewalls with ACLs, this requirement is not applicable.\n\nReview the router configuration to verify that ACLs are configured to allow or deny traffic for specific source and destination addresses as well as ports and protocols. For example, the configuration below will allow only printer traffic into subnet 10.1.23.0/24 and SQL traffic into subnet 10.1.24.0/24. ICMP is allowed for troubleshooting and OSPF is the routing protocol used within the network.\n\ninterface GigabitEthernet0/0/0/0\n description link to core\n ipv4 address 10.1.12.2 255.255.255.0\n ipv4 access-group FILTER_SERVER_TRAFFIC ingress\n…\n…\n…\nipv4 access-list FILTER_SERVER_TRAFFIC\n 10 permit tcp any 10.1.23.0 0.0.0.255 eq lpd\n 20 permit tcp any 10.1.23.0 0.0.0.255 eq 631\n 30 permit tcp any 10.1.23.0 0.0.0.255 eq 9100\n 40 permit tcp any 10.1.24.0 0.0.0.255 eq 1433\n 50 permit tcp any 10.1.24.0 0.0.0.255 eq 1434\n 60 permit tcp any 10.1.24.0 0.0.0.255 eq 4022\n 70 permit icmp any any\n 80 permit ospf any any\n 90 deny ipv4 any any\n\nIf the router is not configured to enforce approved authorizations for controlling the flow of information within the network based on organization-defined information flow control policies, this is a finding.","fixText":"This requirement is not applicable for the DODIN Backbone.\n\nConfigure 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.\n\nRP/0/0/CPU0:R2(config)#ipv4 access-list FILTER_SERVER_TRAFFIC\nRP/0/0/CPU0:R2(config-ipv4-acl)#permit tcp any 10.1.23.0 0.0.0.255 eq lpd \nRP/0/0/CPU0:R2(config-ipv4-acl)#permit tcp any 10.1.23.0 0.0.0.255 eq 631\nRP/0/0/CPU0:R2(config-ipv4-acl)#permit tcp any 10.1.23.0 0.0.0.255 eq 9100\nRP/0/0/CPU0:R2(config-ipv4-acl)#permit tcp any 10.1.24.0 0.0.0.255 eq 1433 \nRP/0/0/CPU0:R2(config-ipv4-acl)#permit tcp any 10.1.24.0 0.0.0.255 eq 1434 \nRP/0/0/CPU0:R2(config-ipv4-acl)#permit tcp any 10.1.24.0 0.0.0.255 eq 4022\nRP/0/0/CPU0:R2(config-ipv4-acl)#permit icmp any any\nRP/0/0/CPU0:R2(config-ipv4-acl)#permit ospf any any\nRP/0/0/CPU0:R2(config-ipv4-acl)#deny ip any any\nRP/0/0/CPU0:R2(config-ipv4-acl)#\nRP/0/0/CPU0:R2(config-ipv4-acl)#exit\nRP/0/0/CPU0:R2(config)#int g0/0/0/0\nRP/0/0/CPU0:R2(config-if)#ipv4 access-group FILTER_SERVER_TRAFFIC","ccis":["CCI-001368"]},{"vulnId":"V-216739","ruleId":"SV-216739r1007834_rule","severity":"medium","ruleTitle":"The Cisco router must be configured to enable routing protocol authentication using FIPS 198-1 algorithms with keys not exceeding 180 days of lifetime.","description":"A rogue router could send a fictitious routing update to convince a site's perimeter router to send traffic to an incorrect or even a rogue destination. This diverted traffic could be analyzed to learn confidential information about the site's network or used to disrupt the network's ability to communicate with other networks. This is known as a \"traffic attraction attack\" and is prevented by configuring neighbor router authentication using FIPS 198-1 algorithms for routing updates.\nIf the keys used for 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. If a time period occurs during which no key is activated, neighbor authentication cannot occur, and therefore routing updates will fail.","checkContent":"Review the router configuration using the configuration examples below for BGP and OSPF.\n\nCertain older protocols supporting only MD5 will incur a permanent finding for those protocols as MD5 is not FIPS compliant.\n\nNote: The 180-day key lifetime is Not Applicable for the DODIN Backbone. The remainder of the requirement still applies.\n\nVerify that neighbor router authentication is enabled for all routing protocols. If neighbor authentication is not enabled this is a finding.\n\nVerify that authentication is configured to use FIPS 198-1 message authentication algorithms. If the routing protocol authentication is not configured to use FIPS 198-1 algorithms this is a finding.\n\nVerify that the protocol key lifetime is configured to not exceed 180 days. If any protocol key lifetime is configured to exceed 180 days this is a finding.\n\nBGP Example:\n\nkey chain \n key \n send-id \n recv-id \n cryptographic-algorithm hmac-sha256\n key-string \n accept-lifetime 00:00:00 Jan 1 2022 duration 180\n send-lifetime 00:00:00 Jan 1 2022 duration 180 \n!\ntcp ao \n keychain BGP_KEY_CHAIN\n key SendID ReceiveID \n!\n!\nrouter bgp \n neighbor X.X.X.X\n remote-as \n ao BGP_KEY_CHAIN\naddress-family ipv4 unicast\n!\n\nNote: TCP-AO is used to replace MD5 in BGP authentication. \n\nOSPF Example:\n\nkey chain OSPF_KEY_CHAIN\nkey 1\nkey-string xxxxxxx\nsend-lifetime 00:00:00 Jan 1 2018 23:59:59 Mar 31 2018\naccept-lifetime 00:00:00 Jan 1 2018 01:05:00 Apr 1 2018\ncryptographic-algorithm hmac-sha-256\nkey 2\nkey-string yyyyyyy\nsend-lifetime 00:00:00 Apr 1 2018 23:59:59 Jun 30 2018\naccept-lifetime 23:55:00 Mar 31 2018 01:05:00 Jul 1 2018\ncryptographic-algorithm hmac-sha-256\n…\n…\n…\nrouter ospf 1\narea 0\nauthentication message-digest keychain OSPF_KEY_CHAIN","fixText":"Configure routing protocol authentication to use a NIST-validated FIPS 198-1 message authentication code algorithm with keys not exceeding 180 days of lifetime as shown in the examples.\n\nBGP Example:\n\nStep 1: Configure a keychain using a FIPS 198-1 algorithm with a key duration not exceeding 180 days.\n\nkey chain \n key \n send-id \n recv-id \n cryptographic-algorithm hmac-sha256\n key-string \n accept-lifetime 00:00:00 Jan 1 2022 duration 180\n send-lifetime 00:00:00 Jan 1 2022 duration 180 \n\nStep 2: Configure BGP autonomous system to use the keychain for authentication.\n\ntcp ao \n keychain BGP_KEY_CHAIN\n key SendID ReceiveID \n!\n!\nrouter bgp \n neighbor X.X.X.X\n remote-as \n ao BGP_KEY_CHAIN\naddress-family ipv4 unicast\n\nOSPF Example:\n\nStep 1: Configure a keychain using a FIPS 198-1 algorithm with a key duration not exceeding 180 days.\n\nkey chain OSPF_KEY_CHAIN\nkey 1\nkey-string xxxxxxx\nsend-lifetime 00:00:00 Jan 1 2018 23:59:59 Mar 31 2018\naccept-lifetime 00:00:00 Jan 1 2018 01:05:00 Apr 1 2018\ncryptographic-algorithm hmac-sha-256\nkey 2\nkey-string yyyyyyy\nsend-lifetime 00:00:00 Apr 1 2018 23:59:59 Jun 30 2018\naccept-lifetime 23:55:00 Mar 31 2018 01:05:00 Jul 1 2018\ncryptographic-algorithm hmac-sha-256\n\nStep 2: Configure OSPF to use the keychain for authentication.\n\nrouter ospf 1\narea 0\nauthentication message-digest keychain OSPF_KEY_CHAIN","ccis":["CCI-000803","CCI-002205"]},{"vulnId":"V-216740","ruleId":"SV-216740r1117237_rule","severity":"low","ruleTitle":"The Cisco router must be configured to have all inactive interfaces disabled.","description":"An inactive interface is rarely monitored or controlled and may expose a network to an undetected attack on that interface. Unauthorized personnel with access to the communication facility could gain access to a router by connecting to a configured interface that is not in use.\n\nIf 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.","checkContent":"Review the router configuration and verify that inactive interfaces have been disabled as shown below.\n\ninterface GigabitEthernet0/0/1/0\n shutdown \n!\ninterface GigabitEthernet0/0/1/1\n shutdown\n \nIf an interface is not being used but is configured or enabled, this is a finding.","fixText":"Disable all inactive interfaces as shown below.\n\nR4(config)#interface GigabitEthernet3\nR4(config-if)#shutdown\nR4(config)#interface GigabitEthernet4\nR4(config-if)#shutdown","ccis":["CCI-001414"]},{"vulnId":"V-216741","ruleId":"SV-216741r531087_rule","severity":"low","ruleTitle":"The Cisco router must be configured to have all non-essential capabilities disabled.","description":"A compromised router introduces risk to the entire network infrastructure, as well as data resources that are accessible via the network. The perimeter defense has no oversight or control of attacks by malicious users within the network. Preventing network breaches from within is dependent on implementing a comprehensive defense-in-depth strategy, including securing each device connected to the network. This is accomplished by following and implementing all security guidance applicable for each node type. A fundamental step in securing each router is to enable only the capabilities required for operation.","checkContent":"Review the router configuration to verify that the router does not have any unnecessary or non-secure services enabled. For example, the following commands should not be in the configuration:\n\nservice ipv4 tcp-small-servers max-servers 10\nservice ipv4 udp-small-servers max-servers 10\nhttp client vrf xxxxx\ntelnet vrf default ipv4 server max-servers 1\n\nIf any unnecessary services are enabled, this is a finding.","fixText":"Disable the following services if enabled as shown in the example below.\n\nRP/0/0/CPU0:R3(config)#no service ipv4 tcp-small-servers\nRP/0/0/CPU0:R3(config)#no service ipv4 udp-small-servers\nRP/0/0/CPU0:R3(config)#no http client vrf xxxxx\nRP/0/0/CPU0:R3(config)#no telnet ipv4 server","ccis":["CCI-000381"]},{"vulnId":"V-216743","ruleId":"SV-216743r531087_rule","severity":"high","ruleTitle":"The Cisco router must be configured to restrict traffic destined to itself.","description":"The route processor handles traffic destined to the router—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.","checkContent":"Review the external and internal ACLs to verify that the router is configured to only allow specific management and control plane traffic from specific sources destined to itself.\n\nStep 1: Verify ACLs has been configured as shown in the example below that matches expected control plane and management plane traffic. With the exception of ICMP, all other traffic destined to the router should be dropped.\n\nipv4 access-list EXTERNAL_ACL_INBOUND\n 10 permit tcp host x.11.1.1 eq bgp host x.11.1.2\n 20 permit tcp host x.11.1.1 host x.11.1.2 eq bgp\n 30 permit icmp host x.11.1.1 host x.11.1.2 echo\n 40 permit icmp host x.11.1.1 host x.11.1.2 echo-reply\n 50 deny ipv4 any host x.11.1.1 log \n 60 permit tcp any any established\n …\n …\n …\n 140 deny ipv4 any any log \n!\nipv4 access-list INTERNAL_ACL_INBOUND\n 10 permit icmp any any\n 20 permit ospf host 10.1.12.1 host 10.1.12.2\n 30 permit tcp 10.2.1.0 0.0.0.255 host 10.1.12.2 eq ssh\n 40 permit tcp 10.2.1.0 0.0.0.255 host 10.1.12.2 eq tacacs\n 50 permit udp 10.2.1.0 0.0.0.255 host 10.1.12.2 eq snmp\n 60 permit udp 10.2.1.0 0.0.0.255 host 10.1.12.2 eq ntp\n 70 deny ipv4 any host 10.1.12.2 log \n 80 permit ipv4 any any \n\nNote: For the internal ACL example, all routers within the hypothetical network (10.1.0.0/16) have been configured to use the loopback address to source all management traffic (not shown); hence, the loopbacks are the only allowable destination address for management traffic. In addition, all management traffic destined to the router must originate from the management network (10.2.1.0/24). With the exception of link-local control plane traffic and ICMP, all other traffic destined to any physical interface address will be dropped.\n\nStep 2: Verify that the ACL has been applied to the appropriate interface as shown in the example below.\n \ninterface GigabitEthernet0/0/0/1\n ipv4 address x.11.1.2 255.255.255.252\n ipv4 access-group EXTERNAL_ACL_INBOUND ingress\n!\ninterface GigabitEthernet0/0/0/2\n ipv4 address 10.1.12.2 255.255.255.0\n ipv4 access-group INTERNAL_ACL_INBOUND ingress\n \nIf the router is not configured to restrict traffic destined to itself, this is a finding.","fixText":"Configure the ACL for any external interfaces as shown in the example.\n\nRP/0/0/CPU0:R3(config)#ipv4 access-list EXTERNAL_ACL_INBOUND\nRP/0/0/CPU0:R3(config-ipv4-acl)#permit tcp host x.11.1.1 eq bgp host x.11.1.2\nRP/0/0/CPU0:R3(config-ipv4-acl)#permit tcp host x.11.1.1 host x.11.1.2 eq bgp\nRP/0/0/CPU0:R3(config-ipv4-acl)#permit icmp host x.11.1.1 host x.11.1.2 echo\nRP/0/0/CPU0:R3(config-ipv4-acl)#permit icmp host x.11.1.1 host x.11.1.2 echo-reply\nRP/0/0/CPU0:R3(config-ipv4-acl)#deny ip any host x.11.1.1 log \nRP/0/0/CPU0:R3(config-ipv4-acl)#permit tcp any any established\n…\n…\n…\nRP/0/0/CPU0:R3(config-ipv4-acl)#deny ip any any log \nRP/0/0/CPU0:R3(config-ipv4-acl)#exit\n\nConfigure the ACL for any external interfaces as shown in the example.\n\nRP/0/0/CPU0:R3(config)#ipv4 access-list INTERNAL_ACL_INBOUND\nRP/0/0/CPU0:R3(config-ipv4-acl)#permit icmp any any\nRP/0/0/CPU0:R3(config-ipv4-acl)#permit ospf host 10.1.12.1 host 10.1.12.2\nRP/0/0/CPU0:R3(config-ipv4-acl)#permit tcp 10.2.1.0 0.0.0.255 host 10.1.12.2eq 22\nRP/0/0/CPU0:R3(config-ipv4-acl)#permit tcp 10.2.1.0 0.0.0.255 host 10.1.12.2eq tacacs\nRP/0/0/CPU0:R3(config-ipv4-acl)#permit udp 10.2.1.0 0.0.0.255 host 10.1.12.2 eq snmp\nRP/0/0/CPU0:R3(config-ipv4-acl)#permit udp 10.2.1.0 0.0.0.255 host 10.1.12.2 eq ntp\nRP/0/0/CPU0:R3(config-ipv4-acl)#deny ip any host 10.1.12.2 log \nRP/0/0/CPU0:R3(config-ipv4-acl)#permit ip any any \nRP/0/0/CPU0:R3(config-ipv4-acl)#exit\n\nNote: best practice is to configure the ACL statements relative to traffic destined to the router first followed by ACL statements for transit traffic.\n\nStep 2: Apply the ACLs to the appropriate interface as shown in the example below.\n\nRP/0/0/CPU0:R3(config)#int g0/0/0/1 \nRP/0/0/CPU0:R3(config-if)#ipv4 access-group EXTERNAL_ACL_INBOUND in\nRP/0/0/CPU0:R3(config-if)#exit\nRP/0/0/CPU0:R3(config)#int g0/0/0/2 \nRP/0/0/CPU0:R3(config-if)#ipv4 access-group INTERNAL_ACL_INBOUND in","ccis":["CCI-001097"]},{"vulnId":"V-216744","ruleId":"SV-216744r531087_rule","severity":"medium","ruleTitle":"The Cisco router must be configured to drop all fragmented Internet Control Message Protocol (ICMP) packets destined to itself.","description":"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.","checkContent":"Review the external and internal ACLs to verify that the router is configured to drop all fragmented ICMP packets destined to itself.\n\nipv4 access-list EXTERNAL_ACL_INBOUND\n 10 permit tcp host x.11.1.1 eq bgp host x.11.1.2\n 20 permit tcp host x.11.1.1 host x.11.1.2 eq bgp\n 25 deny icmp any host x.11.1.2 fragments log \n 30 permit icmp host x.11.1.1 host x.11.1.2 echo\n 40 permit icmp host x.11.1.1 host x.11.1.2 echo-reply\n 50 deny ipv4 any host x.11.1.1 log \n 60 permit tcp any any established\n …\n …\n …\n 140 deny ipv4 any any log \n!\nipv4 access-list INTERNAL_ACL_INBOUND\n 5 deny icmp any any fragments\n 10 permit icmp any host 10.1.12.2 fragments\n 20 permit ospf host 10.1.12.1 host 10.1.12.2\n 30 permit tcp 10.2.1.0 0.0.0.255 host 10.1.12.2 eq ssh\n 40 permit tcp 10.2.1.0 0.0.0.255 host 10.1.12.2 eq tacacs\n 50 permit udp 10.2.1.0 0.0.0.255 host 10.1.12.2 eq snmp\n 60 permit udp 10.2.1.0 0.0.0.255 host 10.1.12.2 eq ntp\n 70 deny ipv4 any host 10.1.12.2 log \n …\n …\n …\n 110 permit ip any any \n\nNote: Ensure the statement to deny ICMP fragments is before any permit statements for ICMP.\n\nIf the router is not configured to drop all fragmented ICMP packets destined to itself, this is a finding.","fixText":"Configure the external and internal ACLs to drop all fragmented ICMP packets destined to itself as shown in the example below.\n\nRP/0/0/CPU0:R3(config)#ipv4 access-list EXTERNAL_ACL_INBOUND\nRP/0/0/CPU0:R2(config-ipv4-acl)#25 deny icmp any host x.11.1.2 fragments log \n\nRP/0/0/CPU0:R3(config)#ipv4 access-list INTERNAL_ACL_INBOUND\nRP/0/0/CPU0:R2(config-ipv4-acl)#5 deny icmp any host 10.1.12.2 fragments log \nNote: Ensure the above statement is before any permit statements for ICMP.","ccis":["CCI-001097"]},{"vulnId":"V-216745","ruleId":"SV-216745r856436_rule","severity":"low","ruleTitle":"The Cisco router must be configured to have IP directed broadcast disabled on all interfaces.","description":"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 router in the chain, which is connected directly to the target subnet, can conclusively identify a directed broadcast.\n\nIP 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.\n\nDirected 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 routers and last-hop routers before entering and leaving the multicast transit area respectively. The last-hop router 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).","checkContent":"Review the router configuration to determine if it is compliant with this requirement. IP directed broadcast command must not be found on any interface as shown in the example below.\n\ninterface GigabitEthernet0/0/0/1\n ipv4 address x.11.1.2 255.255.255.252\n ipv4 directed-broadcast\n\nIf IP directed broadcast is not disabled on all interfaces, this is a finding.","fixText":"Disable IP directed broadcast on all interfaces as shown in the example below.\n\nRP/0/0/CPU0:R3(config)#int g0/0/0/1\nRP/0/0/CPU0:R3(config-if)#no ipv4 directed-broadcast","ccis":["CCI-002385"]},{"vulnId":"V-216746","ruleId":"SV-216746r856437_rule","severity":"medium","ruleTitle":"The Cisco router must be configured to have Internet Control Message Protocol (ICMP) unreachable messages disabled on all external interfaces.","description":"The ICMP supports IP traffic by relaying information about paths, routes, and network conditions. Routers automatically send ICMP messages under a wide variety of conditions. Host unreachable ICMP messages are commonly used by attackers for network mapping and diagnosis.","checkContent":"Review the configuration to verify the ipv4 unreachables disable command has been configured on all external interfaces as shown in the configuration example below.\n\ninterface GigabitEthernet0/0/0/1\n ipv4 address x.11.1.2 255.255.255.252\n ipv4 unreachables disable \n\nNote: ICMP unreachables must also be configured. On the Null0 interface if it is used to black hole traffic.\n\nIf ICMP unreachable notifications are sent from any external or Null0 interface, this is a finding.\n\nAlternative – DODIN Backbone \n\nVerify that the PE router is configured to rate limit ICMP unreachable messages as shown in the example below.\n\nip icmp ipv4 rate-limit unreachable 60000\nip icmp ipv4 rate-limit unreachable DF 1000\n\nNote: In the example above, packet-too-big message (ICMP Type 3 Code 4) can be sent once every second, while all other destination unreachable messages can be sent once every minute. This will avoid disrupting Path MTU Discovery for traffic traversing the backbone while mitigating the risk of an ICMP unreachable denial of service attack.\n\nIF the PE router is not configured to rate limit ICMP unreachable messages, this is a finding.","fixText":"Disable ip unreachables on all external interfaces as shown below.\n\nRP/0/0/CPU0:R3(config)#int g0/0/0/1\nRP/0/0/CPU0:R3(config-if)#ipv4 unreachables disable \n\nAlternative – DODIN Backbone \n\nConfigure the PE router to rate limit ICMP unreachable messages as shown in the example below.\n\nRP/0/0/CPU0:R3(config)#icmp ipv4 rate-limit unreachable df 1000\nRP/0/0/CPU0:R3(config)#icmp ipv4 rate-limit unreachable 60000\nRP/0/0/CPU0:R3(config)#end","ccis":["CCI-002385"]},{"vulnId":"V-216747","ruleId":"SV-216747r856438_rule","severity":"medium","ruleTitle":"The Cisco router must be configured to have Internet Control Message Protocol (ICMP) mask reply messages disabled on all external interfaces.","description":"The ICMP supports IP traffic by relaying information about paths, routes, and network conditions. Routers automatically send ICMP messages under a wide variety of conditions. Mask Reply ICMP messages are commonly used by attackers for network mapping and diagnosis.","checkContent":"Review the router configuration and verify that ipv4 mask-reply command is not enabled on any external interfaces as shown in the example below. \n\ninterface GigabitEthernet0/0/0/1\n ipv4 address x.11.1.2 255.255.255.252\n ipv4 mask-reply \n\nIf the router configuration has the ipv4 mask-reply command is enabled on any external interfaces, this is a finding.","fixText":"Disable ipv4 mask-reply on all external interfaces as shown below.\n\nRP/0/0/CPU0:R3(config)#int g0/0/0/1\nRP/0/0/CPU0:R3(config-if)#no ipv4 mask-reply","ccis":["CCI-002385"]},{"vulnId":"V-216748","ruleId":"SV-216748r856439_rule","severity":"medium","ruleTitle":"The Cisco router must be configured to have Internet Control Message Protocol (ICMP) redirect messages disabled on all external interfaces.","description":"The ICMP supports IP traffic by relaying information about paths, routes, and network conditions. Routers automatically send ICMP messages under a wide variety of conditions. Redirect ICMP messages are commonly used by attackers for network mapping and diagnosis.","checkContent":"Review the router configuration to verify that ipv4 redirects command has not been configured on any external interface as shown in the example below.\n\ninterface GigabitEthernet0/0/0/1\n ipv4 address x.11.1.2 255.255.255.252\n ipv4 redirects\n\nIf ICMP Redirect messages are enabled on any external interfaces, this is a finding.","fixText":"Disable ICMP redirects on all external interfaces as shown in the example below.\n\nRP/0/0/CPU0:R3(config)#int g0/0/0/1\nRP/0/0/CPU0:R3(config-if)#no ipv4 redirects","ccis":["CCI-002385"]},{"vulnId":"V-216749","ruleId":"SV-216749r531087_rule","severity":"low","ruleTitle":"The Cisco router must be configured to log all packets that have been dropped at interfaces via ACL.","description":"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.","checkContent":"Review all ACLs used to filter traffic and verify that packets being dropped are logged as shown in the configuration below.\n\nipv4 access-list EXTERNAL_ACL_INBOUND\n 10 permit tcp host x.11.1.1 eq bgp host x.11.1.2\n 20 permit tcp host x.11.1.1 host x.11.1.2 eq bgp\n 25 deny icmp any host x.11.1.2 fragments log \n 30 permit icmp host x.11.1.1 host x.11.1.2 echo\n 40 permit icmp host x.11.1.1 host x.11.1.2 echo-reply\n 50 deny ipv4 any host x.11.1.1 log\n 60 permit tcp any any established\n …\n …\n …\n 140 deny ipv4 any any log \n\nIf packets being dropped at interfaces are not logged, this is a finding.","fixText":"Configure ACLs to log packets that are dropped as shown in the example below.\n\nRP/0/0/CPU0:R3(config)#ipv4 access-list EXTERNAL_ACL_INBOUND\n…\n…\n…\nRP/0/0/CPU0:R3(config-ipv4-acl)#deny ip any any log","ccis":["CCI-000134"]},{"vulnId":"V-216750","ruleId":"SV-216750r531087_rule","severity":"medium","ruleTitle":"The Cisco router must be configured to produce audit records containing information to establish where the events occurred.","description":"Without establishing where events occurred, it is impossible to establish, correlate, and investigate the events leading up to an outage or attack.\n\nIn order to compile an accurate risk assessment and provide forensic analysis, it is essential for security personnel to know where events occurred such as router components, modules, device identifiers, node names, and functionality.\n\nAssociating information about where the event occurred within the network provides a means of investigating an attack, recognizing resource utilization or capacity thresholds, or identifying an improperly configured router.","checkContent":"Review the router configuration to verify that events are logged containing information to establish where the events occurred as shown in the example below.\n\nipv4 access-list EXTERNAL_ACL_INBOUND\n 10 permit tcp host x.11.1.1 eq bgp host x.11.1.2\n 20 permit tcp host x.11.1.1 host x.11.1.2 eq bgp\n 25 deny icmp any host x.11.1.2 fragments log-input \n 30 permit icmp host x.11.1.1 host x.11.1.2 echo\n 40 permit icmp host x.11.1.1 host x.11.1.2 echo-reply\n 50 deny ipv4 any host x.11.1.1 log-input\n 60 permit tcp any any established\n …\n …\n …\n 140 deny ipv4 any any log-input\n\nNote: When the log-input parameter is configured on deny statements, the log record will contain the interface where ingress packet has been dropped.\n\nIf the router is not configured to produce audit records containing information to establish to establish where the events occurred, this is a finding.","fixText":"Configure the router to log events containing information to establish where the events occurred as shown in the example below.\n \nRP/0/0/CPU0:R3(config)#ipv4 access-list EXTERNAL_ACL_INBOUND\n…\n…\n…\nRP/0/0/CPU0:R3(config-ipv4-acl)#deny ip any any log-input","ccis":["CCI-000132"]},{"vulnId":"V-216751","ruleId":"SV-216751r531087_rule","severity":"medium","ruleTitle":"The Cisco router must be configured to produce audit records containing information to establish the source of the events.","description":"Without establishing the source of the event, it is impossible to establish, correlate, and investigate the events leading up to an outage or attack.\n\nIn order to compile an accurate risk assessment and provide forensic analysis, security personnel need to know the source of the event.\n\nIn addition to logging where events occur within the network, the audit records must also identify sources of events such as IP addresses, processes, and node or device names.","checkContent":"Review the router configuration to verify that events are logged containing information to establish the source of the events as shown in the example below.\n\nipv4 access-list EXTERNAL_ACL_INBOUND\n 10 permit tcp host x.11.1.1 eq bgp host x.11.1.2\n 20 permit tcp host x.11.1.1 host x.11.1.2 eq bgp\n 25 deny icmp any host x.11.1.2 fragments log \n 30 permit icmp host x.11.1.1 host x.11.1.2 echo\n 40 permit icmp host x.11.1.1 host x.11.1.2 echo-reply\n 50 deny ipv4 any host x.11.1.1 log-input\n 60 permit tcp any any established\n …\n …\n …\n 140 deny ipv4 any any log-input\n\nNote: When the log-input parameter is configured on deny statements, the log record will contain the layer 2 address of the forwarding device for any packet being dropped.\n\nIf the router is not configured to produce audit records containing information to establish the source of the events, this is a finding.","fixText":"Configure the router to log events containing information to establish where the events occurred as shown in the example below.\n \nRP/0/0/CPU0:R3(config)#ipv4 access-list EXTERNAL_ACL_INBOUND\n…\n…\n…\nRP/0/0/CPU0:R3(config-ipv4-acl)#deny ip any any log-input","ccis":["CCI-000133"]},{"vulnId":"V-216752","ruleId":"SV-216752r1117241_rule","severity":"high","ruleTitle":"The Cisco perimeter router must be configured to deny network traffic by default and allow network traffic by exception.","description":"A deny-all, permit-by-exception network communications traffic policy ensures that only connections that are essential and approved are allowed.\n\nThis requirement applies to both inbound and outbound network communications traffic. All inbound and outbound traffic must be denied by default. Firewalls and perimeter routers 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 router will establish a state that will permit the return of this undesirable traffic inbound.","checkContent":"This requirement is not applicable for the DODIN Backbone.\n\nReview the router configuration to verify that the inbound ACL applied to all external interfaces is configured to allow specific ports and protocols and deny all other traffic.\n\nStep 1: Verify that an inbound ACL is applied to all external interfaces as shown in the example below.\n\ninterface GigabitEthernet0/0/0/1\n ipv4 address x.11.1.2 255.255.255.252\n ipv4 access-group EXTERNAL_ACL_INBOUND ingress\n\nStep 2: Review inbound ACL to verify that it is configured to deny all other traffic that is not explicitly allowed.\n\nipv4 access-list EXTERNAL_ACL_INBOUND\n 10 permit tcp host x.11.1.1 eq bgp host x.11.1.2\n 20 permit tcp host x.11.1.1 host x.11.1.2 eq bgp\n 30 permit icmp host x.11.1.1 host x.11.1.2 echo\n 40 permit icmp host x.11.1.1 host x.11.1.2 echo-reply\n 50 deny ipv4 any host x.11.1.1 log-input \n 60 permit tcp any any established\n …\n …\n …\n 140 deny ipv4 any any log-input \n\nIf 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.","fixText":"This requirement is not applicable for the DODIN Backbone.\n\nStep 1: Configure an inbound ACL to deny all other traffic by default as shown in the example below.\n\nRP/0/0/CPU0:R3(config)#ipv4 access-list EXTERNAL_ACL_INBOUND\nRP/0/0/CPU0:R3(config-ipv4-acl)#permit tcp host x.11.1.1 eq bgp host x.11.1.2\nRP/0/0/CPU0:R3(config-ipv4-acl)#permit tcp host x.11.1.1 host x.11.1.2 eq bgp\nRP/0/0/CPU0:R3(config-ipv4-acl)#permit icmp host x.11.1.1 host x.11.1.2 echo\nRP/0/0/CPU0:R3(config-ipv4-acl)#permit icmp host x.11.1.1 host x.11.1.2 echo-reply\nRP/0/0/CPU0:R3(config-ipv4-acl)#deny ip any host x.11.1.1 log-input\nRP/0/0/CPU0:R3(config-ipv4-acl)#permit tcp any any established\n…\n…\n…\nRP/0/0/CPU0:R3(config-ipv4-acl)#deny ip any any log-input \nRP/0/0/CPU0:R3(config-ipv4-acl)#exit\n\nStep 2: Apply the ingress filter to all external interfaces\n\nRP/0/0/CPU0:R3(config)#int g0/0/0/1 \nRP/0/0/CPU0:R3(config-if)#ipv4 access-group EXTERNAL_ACL_INBOUND in\nRP/0/0/CPU0:R3(config-if)#end","ccis":["CCI-001109"]},{"vulnId":"V-216753","ruleId":"SV-216753r1117237_rule","severity":"medium","ruleTitle":"The Cisco perimeter router must be configured to enforce approved authorizations for controlling the flow of information between interconnected networks in accordance with applicable policy.","description":"Information flow control regulates authorized information to travel within a network and between interconnected networks. Controlling the flow of network traffic is critical so it does not introduce any unacceptable risk to the network infrastructure or data. An example of a flow control restriction is blocking outside traffic claiming to be from within the organization. For most routers, internal information flow control is a product of system design.","checkContent":"Review the router configuration to verify that ACLs are configured to allow or deny traffic for specific source and destination addresses as well as ports and protocols. In the example below, the router is peering BGP with DISN. ICMP echo and echo-reply packets are allowed for troubleshooting connectivity. WWW traffic is permitted inbound to the NIPRNet host-facing web server (x.12.1.22).\n\nipv4 access-list EXTERNAL_ACL_INBOUND\n 10 permit tcp host x.11.1.1 eq bgp host x.11.1.2\n 20 permit tcp host x.11.1.1 host x.11.1.2 eq bgp\n 30 permit icmp host x.11.1.1 host x.11.1.2 echo\n 40 permit icmp host x.11.1.1 host x.11.1.2 echo-reply\n 50 deny ipv4 any host x.11.1.1 log \n 60 permit tcp any host x.12.1.22 eq www\n 70 permit tcp any any established\n 80 deny ipv4 any any log-input \n…\n…\n…\ninterface GigabitEthernet0/0/0/1\n ipv4 address x.11.1.2 255.255.255.252\n ipv4 access-group EXTERNAL_ACL_INBOUND ingress\n\nIf the router is not configured to enforce approved authorizations for controlling the flow of information between interconnected networks, this is a finding.","fixText":"This requirement is not applicable for the DODIN Backbone.\n\nStep 1: Configure an ACL to allow or deny traffic as shown in the example below.\n\nRP/0/0/CPU0:R3(config)#ipv4 access-list EXTERNAL_ACL_INBOUND\nRP/0/0/CPU0:R3(config-ipv4-acl)#permit tcp host x.11.1.1 eq bgp host x.11.1.2\nRP/0/0/CPU0:R3(config-ipv4-acl)#permit tcp host x.11.1.1 host x.11.1.2 eq bgp\nRP/0/0/CPU0:R3(config-ipv4-acl)#permit icmp host x.11.1.1 host x.11.1.2 echo\nRP/0/0/CPU0:R3(config-ipv4-acl)#permit icmp host x.11.1.1 host x.11.1.2 echo-reply\nRP/0/0/CPU0:R3(config-ipv4-acl)#deny ip any host x.11.1.1 log-input \nRP/0/0/CPU0:R3(config-ipv4-acl)#permit tcp any host x.12.1.22 eq www\nRP/0/0/CPU0:R3(config-ipv4-acl)#permit tcp any any established\nRP/0/0/CPU0:R3(config-ipv4-acl)#deny ip any any log-input \nRP/0/0/CPU0:R3(config-ipv4-acl)#exit\n\nStep 2: Apply the ACL inbound on all external interfaces.\n\nRP/0/0/CPU0:R3(config)#int g0/0/0/1 \nRP/0/0/CPU0:R3(config-if)#ipv4 access-group EXTERNAL_ACL_INBOUND in\nRP/0/0/CPU0:R3(config-if)#end","ccis":["CCI-001414"]},{"vulnId":"V-216754","ruleId":"SV-216754r856440_rule","severity":"medium","ruleTitle":"The Cisco perimeter router must be configured to only allow incoming communications from authorized sources to be routed to authorized destinations.","description":"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.\n\nTraffic 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 router's normal routing procedures used to control the specific paths of network traffic. It is normally used for traffic engineering but can also be used to meet security requirements; for example, traffic that is not allowed can be routed to the Null0 or discard interface. Policy Routing can also be used to control which prefixes appear in the routing table.\n\nThis requirement is intended to allow network administrators the flexibility to use whatever technique is most effective.","checkContent":"This requirement is not applicable for the DODIN Backbone.\n\nReview the router configuration to determine if the router allows only incoming communications from authorized sources to be routed to authorized destinations. The hypothetical example below allows inbound NTP from server x.1.12.9 only to host x.12.1.21.\n\nipv4 access-list EXTERNAL_ACL_INBOUND\n …\n …\n …\n 60 permit udp host x.12.1.9 host x.12.1.21 eq ntp\n 70 permit tcp any any established\n 80 deny ipv4 any any log-input \n\nIf the router does not restrict incoming communications to allow only authorized sources and destinations, this is a finding.","fixText":"This requirement is not applicable for the DODIN Backbone.\n\nConfigure the router to allow only incoming communications from authorized sources to be routed to authorized destinations. \n\nRP/0/0/CPU0:R3(config)#ipv4 access-list EXTERNAL_ACL_INBOUND\n…\n…\n…\nRP/0/0/CPU0:R3(config-ipv4-acl)#permit udp host x.12.1.9 host x.12.1.21 eq ntp \nRP/0/0/CPU0:R3(config-ipv4-acl)#permit tcp any any established\nRP/0/0/CPU0:R3(config-ipv4-acl)#deny ip any any log-input \nRP/0/0/CPU0:R3(config-ipv4-acl)#exit","ccis":["CCI-002403"]},{"vulnId":"V-216755","ruleId":"SV-216755r856441_rule","severity":"medium","ruleTitle":"The Cisco perimeter router must be configured to block inbound packets with source Bogon IP address prefixes.","description":"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.","checkContent":"This requirement is not applicable for the DODIN Backbone.\n\nReview the router configuration to verify that an ingress ACL applied to all external interfaces is blocking packets with Bogon source addresses.\n\nStep 1: Verify an ACL has been configured containing the current Bogon prefixes as shown in the example below.\n\nipv4 access-list EXTERNAL_ACL_INBOUND\n 10 deny ipv4 0.0.0.0 0.255.255.255 any log-input\n 20 deny ipv4 10.0.0.0 0.255.255.255 any log-input\n 30 deny ipv4 100.64.0.0 0.63.255.255 any log-input\n 40 deny ipv4 127.0.0.0 0.255.255.255 any log-input\n 50 deny ipv4 169.254.0.0 0.0.255.255 any log-input\n 60 deny ipv4 172.16.0.0 0.15.255.255 any log-input\n 70 deny ipv4 192.0.0.0 0.0.0.255 any log-input\n 80 deny ipv4 192.0.2.0 0.0.0.255 any log-input\n 90 deny ipv4 192.168.0.0 0.0.255.255 any log-input\n 100 deny ipv4 198.18.0.0 0.1.255.255 any log-input\n 110 deny ipv4 198.51.100.0 0.0.0.255 any log-input\n 120 deny ipv4 203.0.113.0 0.0.0.255 any log-input\n 130 deny ipv4 224.0.0.0 31.255.255.255 any log-input\n 140 permit tcp any any established\n 150 permit tcp host x.12.1.9 host x.12.1.10 eq bgp\n 160 permit tcp host x.12.1.9 eq bgp host x.12.1.10\n 170 permit icmp host x.12.1.9 host x.12.1.10 echo\n 180 permit icmp host x.12.1.9 host x.12.1.10 echo-reply\n …\n …\n …\n 260 deny ipv4 any any log-input\n\nExternal Interfaces connected to the NIPRNet or SIPRNet\n\nReview the inbound ACLs on external facing interfaces attached to the NIPRNet or SIPRNet to validate access control lists are configured to block inbound packets with IP sources addresses as documented in RFC5735 and RFC6598. \n\nExternal Interfaces connected to a commercial ISP or other non-DoD network\n \nReview the inbound ACLs on external facing interfaces validate access control lists are configured to block inbound packets with IP sources addresses as documented in RFC5735 and RFC6598 as well as address space that has been allocated to the RIRs but not assigned by the RIR to an ISP or other enterprise network. The full list of bogons can be found at the following link: www.team-cymru.org/Services/Bogons/fullbogons-ipv4.txt\n\nStep 2: Verify that the inbound ACL applied to all external interfaces will block all traffic from Bogon source addresses.\n\ninterface GigabitEthernet0/0/0/1\n ipv4 address x.12.1.10 255.255.255.2\n ipv4 access-group EXTERNAL_ACL_INBOUND ingress\n\nIf the router is not configured to block inbound packets with source Bogon IP addresses, this is a finding.","fixText":"This requirement is not applicable for the DODIN Backbone.\n\nConfigure the perimeter to block inbound packets with Bogon source addresses.\n\nStep 1: Configure an ACL containing the current Bogon prefixes as shown below.\n\nRP/0/0/CPU0:R2(config)#ipv4 access-list EXTERNAL_ACL_INBOUND\nRP/0/0/CPU0:R2(config-ipv4-acl)#deny ip 0.0.0.0 0.255.255.255 any log-input\nRP/0/0/CPU0:R2(config-ipv4-acl)#deny ip 10.0.0.0 0.255.255.255 any log-input\nRP/0/0/CPU0:R2(config-ipv4-acl)#deny ip 100.64.0.0 0.63.255.255 any log-input\nRP/0/0/CPU0:R2(config-ipv4-acl)#deny ip 127.0.0.0 0.255.255.255 any log-input\nRP/0/0/CPU0:R2(config-ipv4-acl)#deny ip 169.254.0.0 0.0.255.255 any log-input\nRP/0/0/CPU0:R2(config-ipv4-acl)#deny ip 172.16.0.0 0.15.255.255 any log-input\nRP/0/0/CPU0:R2(config-ipv4-acl)#deny ip 192.0.0.0 0.0.0.255 any log-input\nRP/0/0/CPU0:R2(config-ipv4-acl)#deny ip 192.0.2.0 0.0.0.255 any log-input\nRP/0/0/CPU0:R2(config-ipv4-acl)#deny ip 192.168.0.0 0.0.255.255 any log-input\nRP/0/0/CPU0:R2(config-ipv4-acl)#deny ip 198.18.0.0 0.1.255.255 any log-input\nRP/0/0/CPU0:R2(config-ipv4-acl)#deny ip 198.51.100.0 0.0.0.255 any log-input\nRP/0/0/CPU0:R2(config-ipv4-acl)#deny ip 203.0.113.0 0.0.0.255 any log-input\nRP/0/0/CPU0:R2(config-ipv4-acl)#deny ip 224.0.0.0 31.255.255.255 any log-input\nRP/0/0/CPU0:R2(config-ipv4-acl)#permit tcp any any established\nRP/0/0/CPU0:R2(config-ipv4-acl)#permit tcp host x.12.1.9 host x.12.1.10 eq bgp\nRP/0/0/CPU0:R2(config-ipv4-acl)#permit tcp host x.12.1.9 eq bgp host x.12.1.10\nRP/0/0/CPU0:R2(config-ipv4-acl)#permit icmp host x.12.1.9 host x.12.1.10 echo\nRP/0/0/CPU0:R2(config-ipv4-acl)#permit icmp host x.12.1.9 host x.12.1.10 echo-reply\n…\n…\n…\nRP/0/0/CPU0:R2(config-ipv4-acl)#deny ip any any log-input\nRP/0/0/CPU0:R2(config-ipv4-acl)#end\n\nStep 2: Apply the ACL inbound on all external interfaces.\n\nRP/0/0/CPU0:R3(config)#int g0/0/0/1 \nRP/0/0/CPU0:R3(config-if)#ipv4 access-group EXTERNAL_ACL_INBOUND in\nRP/0/0/CPU0:R3(config-if)#end","ccis":["CCI-002403"]},{"vulnId":"V-216756","ruleId":"SV-216756r1117237_rule","severity":"high","ruleTitle":"The Cisco perimeter router must be configured to protect an enclave connected to an alternate gateway by using an inbound filter that only permits packets with destination addresses within the sites address space.","description":"Enclaves with alternate gateway connections must take additional steps to ensure there is no compromise on the enclave network or NIPRNet. Without verifying the destination address of traffic coming from the site's alternate gateway, the perimeter router could be routing transit data from the Internet into the NIPRNet. This could also make the perimeter router vulnerable to a denial-of-service (DoS) attack as well as provide a back door into the NIPRNet. The DoD enclave must ensure the ingress filter applied to external interfaces on a perimeter router connecting to an Approved Gateway is secure through filters permitting packets with a destination address belonging to the DoD enclave's address block.","checkContent":"This requirement is not applicable for the DODIN Backbone.\n\nStep 1: Verify the interface connecting to ISP has an inbound ACL as shown in the example below.\n\ninterface GigabitEthernet0/0/0/2\n description Link to ISP\n ipv4 address x.22.1.15 255.255.255.252\n ipv4 access-group ISP_ACL_INBOUND ingress\n\nStep 2: Verify that the ACL only allows traffic to specific destination addresses (i.e. enclave’s NIPRNet address space) as shown in the example below.\n\nipv4 access-list ISP_ACL_INBOUND\n 10 permit tcp any any established\n 20 permit icmp host x.12.1.16 host x.12.1.17 echo\n 30 permit icmp host x.12.1.16 host x.12.1.17 echo-reply\n 40 permit tcp any host x.12.1.22 eq www\n 50 permit tcp any host x.12.1.23 eq www\n 60 permit esp any host x.12.1.24\n 70 permit ahp any host x.12.1.24\n 80 deny ipv4 any any log-input\n\nNote: An Approved Gateway (AG) is any external connection from a DoD NIPRNet enclave to an Internet Service Provider, or network owned by a contractor, or non-DoD federal agency that has been approved by either the DoD CIO or the DoD Component CIO. This AG requirement does not apply to commercial cloud connections when the Cloud Service Provider (CSP) network is connected via the NIPRNet Boundary Cloud Access Point (BCAP).\n\nIf the ingress ACL bound to the interface connecting to an alternate gateway permits packets with addresses other than those specified, such as destination addresses of the site's NIPRNet address space or a destination address belonging to the address block assigned by the alternate gateway network service provider, this is a finding.","fixText":"This requirement is not applicable for the DODIN Backbone.\n\nStep 1: Configure the ingress ACL of the perimeter router connected to an alternate gateway to only permit packets with destination addresses of the site's NIPRNet address space or a destination address belonging to the address block assigned by the alternate gateway network service provider as shown in the example below.\n\nRP/0/0/CPU0:R2(config)#ip access-list ISP_ACL_INBOUND\nRP/0/0/CPU0:R2(config-ipv4-acl)#permit tcp any any established\nRP/0/0/CPU0:R2(config-ipv4-acl)#permit icmp host x.12.1.16 host x.12.1.17 echo\nRP/0/0/CPU0:R2(config-ipv4-acl)#permit icmp host x.12.1.16 host x.12.1.17 echo-reply\nRP/0/0/CPU0:R2(config-ipv4-acl)#permit tcp any host x.12.1.22 eq www\nRP/0/0/CPU0:R2(config-ipv4-acl)#permit tcp any host x.12.1.23 eq www\nRP/0/0/CPU0:R2(config-ipv4-acl)#permit 50 any host x.12.1.24\nRP/0/0/CPU0:R2(config-ipv4-acl)#permit 51 any host x.12.1.24\nRP/0/0/CPU0:R2(config-ipv4-acl)#deny ip any any log-input\nRP/0/0/CPU0:R2(config-ipv4-acl)#end\n\nStep 2: Apply the ACL inbound on the ISP-facing interface.\n\nRP/0/0/CPU0:R3(config)#int g0/0/0/2 \nRP/0/0/CPU0:R3(config-if)#ipv4 access-group ISP_ACL_INBOUND in\nRP/0/0/CPU0:R3(config-if)#end","ccis":["CCI-001414"]},{"vulnId":"V-216757","ruleId":"SV-216757r1117237_rule","severity":"high","ruleTitle":"The Cisco perimeter router must be configured to not be a Border Gateway Protocol (BGP) peer to an alternate gateway service provider.","description":"ISPs use BGP to share route information with other autonomous systems (i.e. other ISPs and corporate networks). If the perimeter router was configured to BGP peer with an ISP, NIPRnet routes could be advertised to the ISP, thereby creating a backdoor connection from the Internet to the NIPRnet.","checkContent":"This requirement is not applicable for the DODIN Backbone.\n\nStep 1: Configure the ingress ACL of the perimeter router connected to an alternate gateway to only permit packets with destination addresses of the site's NIPRNet address space or a destination address belonging to the address block assigned by the alternate gateway network service provider as shown in the example below.\n\nRP/0/0/CPU0:R2(config)#ip access-list ISP_ACL_INBOUND\nRP/0/0/CPU0:R2(config-ipv4-acl)# permit tcp any any established\nRP/0/0/CPU0:R2(config-ipv4-acl)# permit icmp host x.12.1.16 host x.12.1.17 echo\nRP/0/0/CPU0:R2(config-ipv4-acl)# permit icmp host x.12.1.16 host x.12.1.17 echo-reply\nRP/0/0/CPU0:R2(config-ipv4-acl)# permit tcp any host x.12.1.22 eq www\nRP/0/0/CPU0:R2(config-ipv4-acl)# permit tcp any host x.12.1.23 eq www\nRP/0/0/CPU0:R2(config-ipv4-acl)# permit 50 any host x.12.1.24\nRP/0/0/CPU0:R2(config-ipv4-acl)# permit 51 any host x.12.1.24\nRP/0/0/CPU0:R2(config-ipv4-acl)# deny ip any any log-input\nRP/0/0/CPU0:R2(config-ipv4-acl)#end\n\nStep 2: Apply the ACL inbound on the ISP-facing interface.\n\nRP/0/0/CPU0:R3(config)#int g0/0/0/2 \nRP/0/0/CPU0:R3(config-if)#ipv4 access-group ISP_ACL_INBOUND in\nRP/0/0/CPU0:R3(config-if)#end\n\nIf any BGP neighbors belonging to the alternate gateway service provider exist, this is a finding.","fixText":"This requirement is not applicable for the DODIN Backbone.\n\nRemove any BGP neighbors belonging to the alternate gateway service provider and configure a static route to forward Internet bound traffic to the alternate gateway as shown in the example below.\n\nR5(config)#ip route 0.0.0.0 0.0.0.0 x.22.1.14","ccis":["CCI-001414"]},{"vulnId":"V-216758","ruleId":"SV-216758r1117237_rule","severity":"low","ruleTitle":"The Cisco perimeter router must be configured to not redistribute static routes to an alternate gateway service provider into BGP or an IGP peering with the NIPRNet or to other autonomous systems.","description":"If the static routes to the alternate gateway are being redistributed into an Exterior Gateway Protocol or Interior Gateway Protocol to a NIPRNet gateway, this could make traffic on NIPRNet flow to that particular router and not to the Internet Access Point routers. This could not only wreak havoc with traffic flows on NIPRNet, but it could overwhelm the connection from the router to the NIPRNet gateway(s) and also cause traffic destined for outside of NIPRNet to bypass the defenses of the Internet Access Points.","checkContent":"This requirement is not applicable for the DODIN Backbone.\n\nStep 1: Review the IGP and BGP configurations. If there are redistribute static statements configured as shown in examples below proceed to step 2.\n\nOSPF Example\n\nrouter ospf 1\n redistribute static\n\nEIGRP example\n\nrouter eigrp 1\n address-family ipv4\n redistribute static\n\nRIP example\n\nrouter rip\n version 2\n redistribute static\n\nBGP example\n\nrouter bgp n\n address-family ipv4 unicast\n redistribute static\n\nStep 2: Review the static routes that have been configured to determine if any contain the next hop address of the alternate gateway.\n\nIf the static routes to the alternate gateway are being redistributed into BGP or any IGP peering to a NIPRNet gateway or any other autonomous system, this is a finding.","fixText":"This requirement is not applicable for the DODIN Backbone.\n\nConfigure the router so that static routes are not redistributed to an alternate gateway into either a BGP or any IGP peering with the NIPRNet or to any other autonomous systems. This can be done by excluding that route in the route policy as shown in the example below.\n\nStep 1: Configure a prefix list for any static routes with the alternate gateway as the next-hop address\n\nRP/0/0/CPU0:R3(config)#prefix-set ISP_PREFIX \nRP/0/0/CPU0:R3(config-pfx)#x.x.0.0/24 ge 8 le 32\nRP/0/0/CPU0:R3(config-pfx)#end-set\n\nStep 2: Configure a route policy\n\nRP/0/0/CPU0:R3(config)#route-policy FILTER_ISP_ROUTES \nRP/0/0/CPU0:R3(config-rpl)#if destination in ISP_PREFIX then\nRP/0/0/CPU0:R3(config-rpl-if)#drop\nRP/0/0/CPU0:R3(config-rpl-if)#else\nRP/0/0/CPU0:R3(config-rpl-else)#pass\nRP/0/0/CPU0:R3(config-rpl-else)#endif \nRP/0/0/CPU0:R3(config-rpl)#end-pol\n\nStep 3: Apply the route policy to the IGP and BGP redistribute static commands as shown in the OSPF example.\n\nRP/0/0/CPU0:R3(config-ospf)#redistribute static route-policy FILTER_ISP_ROUTES","ccis":["CCI-001414"]},{"vulnId":"V-216760","ruleId":"SV-216760r1007832_rule","severity":"medium","ruleTitle":"The Cisco perimeter router must be configured to filter traffic destined to the enclave in accordance with the guidelines contained in DoD Instruction 8551.1.","description":"Vulnerability assessments must be reviewed by the System Administrator, and protocols must be approved by the Information Assurance (IA) staff before entering the enclave.\n\nAccess control lists (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 but that are stopped by an ACL will allow network administrators to broaden their protective ring and more tightly define the scope of operation.","checkContent":"This requirement is not applicable for the DODIN Backbone.\n\nReview the router configuration to verify that the ingress ACL is in accordance with DoD 8551.1.\n\nStep 1: Verify that an inbound ACL is configured on all external interfaces.\n\ninterface GigabitEthernet0/0/0/1\n ipv4 address x.11.1.2 255.255.255.252\n ipv4 access-group EXTERNAL_ACL_INBOUND ingress\n\nStep 2. Review the inbound ACL to verify that it is filtering traffic in accordance with DoD 8551.1.\n\nipv4 access-list EXTERNAL_ACL_INBOUND\n 10 permit tcp host x.11.1.1 eq bgp host x.11.1.2\n 20 permit tcp host x.11.1.1 host x.11.1.2 eq bgp\n 30 permit icmp host x.11.1.1 host x.11.1.2 echo\n 40 permit icmp host x.11.1.1 host x.11.1.2 echo-reply\n 50 deny ipv4 any host x.11.1.1 log \n 60 permit tcp any host x.12.1.22 eq www\n 70 permit tcp any any established\n …\n … < must be in accordance with DoD Instruction 8551.1>\n …\n160 deny ipv4 any any log-input \n \nIf the router does not filter traffic in accordance with the guidelines contained in DoD 8551.1, this is a finding.","fixText":"This requirement is not applicable for the DODIN Backbone.\n\nConfigure the router to use an inbound ACL on all external interfaces as shown in the example below to restrict traffic in accordance with the guidelines contained in DOD Instruction 8551.1.\n\nRP/0/0/CPU0:R3(config)#ipv4 access-list EXTERNAL_ACL_INBOUND\nRP/0/0/CPU0:R3(config-ipv4-acl)#permit tcp host x.11.1.1 eq bgp host x.11.1.2\nRP/0/0/CPU0:R3(config-ipv4-acl)#permit tcp host x.11.1.1 host x.11.1.2 eq bgp\nRP/0/0/CPU0:R3(config-ipv4-acl)#permit icmp host x.11.1.1 host x.11.1.2 echo\nRP/0/0/CPU0:R3(config-ipv4-acl)#permit icmp host x.11.1.1 host x.11.1.2 echo-reply\nRP/0/0/CPU0:R3(config-ipv4-acl)#deny ip any host x.11.1.1 log-input \nRP/0/0/CPU0:R3(config-ipv4-acl)#permit tcp any host x.12.1.22 eq www\nRP/0/0/CPU0:R3(config-ipv4-acl)#permit tcp any any established\n…\n… < must be in accordance with DoD Instruction 8551.1>\n…\nRP/0/0/CPU0:R3(config-ipv4-acl)#deny ip any any log-input \nRP/0/0/CPU0:R3(config-ipv4-acl)#exit\n\nStep 2: Apply the ACL inbound on all applicable interfaces.\n\nRP/0/0/CPU0:R3(config)#int g0/0/0/1 \nRP/0/0/CPU0:R3(config-if)#ipv4 access-group EXTERNAL_ACL_INBOUND in\nRP/0/0/CPU0:R3(config-if)#end","ccis":["CCI-001097"]},{"vulnId":"V-216761","ruleId":"SV-216761r531087_rule","severity":"medium","ruleTitle":"The Cisco perimeter router must be configured to filter ingress traffic at the external interface on an inbound direction.","description":"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 routers makes use of access lists for restricting access to services on the router itself as well as for filtering traffic passing through the router. \n\nInbound 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:\n\n- The router can protect itself before damage is inflicted.\n- The input port is still known and can be filtered upon.\n- It is more efficient to filter packets before routing them.","checkContent":"This requirement is not applicable for the DODIN Backbone.\n\nReview the router configuration to verify that an inbound ACL is configured on all external interfaces as shown in the example below.\ninterface GigabitEthernet0/0/0/1\n ipv4 address x.11.1.2 255.255.255.252\n ipv4 access-group EXTERNAL_ACL_INBOUND ingress\n\nIf the router is not configured to filter traffic entering the network at all external interfaces in an inbound direction, this is a finding.","fixText":"This requirement is not applicable for the DODIN Backbone.\n\nConfigure the router to use an inbound ACL on all external interfaces as shown in the example below.\n\nRP/0/0/CPU0:R3(config)#int g0/0/0/1 \nRP/0/0/CPU0:R3(config-if)#ipv4 access-group EXTERNAL_ACL_INBOUND in\nRP/0/0/CPU0:R3(config-if)#end","ccis":["CCI-001097"]},{"vulnId":"V-216762","ruleId":"SV-216762r531087_rule","severity":"medium","ruleTitle":"The Cisco perimeter router must be configured to filter egress traffic at the internal interface on an inbound direction.","description":"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 routers makes use of access lists for restricting access to services on the router itself as well as for filtering traffic passing through the router. \n\nInbound 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:\n\n- The router can protect itself before damage is inflicted.\n- The input port is still known and can be filtered upon.\n- It is more efficient to filter packets before routing them.","checkContent":"This requirement is not applicable for the DODIN Backbone.\n\nReview the router configuration to verify that the egress ACL is bound to the internal interface in an inbound direction.\n\ninterface GigabitEthernet0/0/0/1\n description downstream link to LAN\n ipv4 address 10.1.34.3 255.255.255.0\n ipv4 access-group EGRESS_FILTER ingress\n\nIf the router is not configured to filter traffic leaving the network at the internal interface in an inbound direction, this is a finding.","fixText":"This requirement is not applicable for the DODIN Backbone.\n\nConfigure the router to use an inbound ACL on all internal interfaces as shown in the example below.\n\nRP/0/0/CPU0:R3(config)#int g0/0/0/1 \nRP/0/0/CPU0:R3(config-if)#ipv4 access-group EGRESS_FILTER in\nRP/0/0/CPU0:R3(config-if)#end","ccis":["CCI-001097"]},{"vulnId":"V-216764","ruleId":"SV-216764r856442_rule","severity":"low","ruleTitle":"The Cisco perimeter router must be configured to have Link Layer Discovery Protocol (LLDP) disabled on all external interfaces.","description":"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.","checkContent":"This requirement is not applicable for the DODIN Backbone.\n\nStep 1: Verify LLDP is not enabled globally via the command \n\nlldp\n\nBy default LLDP is not enabled globally. If LLDP is enabled, proceed to step 2.\n\nStep 2: Verify LLDP transmit is disabled on any external interface as shown in the example below.\n\ninterface GigabitEthernet0/0/0/1\n ipv4 address x.1.34.3 255.255.255.252\n lldp\n transmit disable\n\nNote: LLDP is enabled by default on all interfaces once it is enabled globally; hence the commands lldp transmit and lldp receive will not be visible on the interface configuration.\n\nIf LLDP transmit is enabled on any external interface, this is a finding.","fixText":"Disable LLDP transmit on all external interfaces as shown in the example below.\n\nRP/0/0/CPU0:R3(config)#interface g0/0/0/1\nRP/0/0/CPU0:R3(config-if)#lldp transmit disable","ccis":["CCI-002403"]},{"vulnId":"V-216765","ruleId":"SV-216765r856443_rule","severity":"low","ruleTitle":"The Cisco perimeter router must be configured to have Cisco Discovery Protocol (CDP) disabled on all external interfaces.","description":"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.","checkContent":"This requirement is not applicable for the DODIN Backbone.\n\nStep 1: Verify if CDP is enabled globally via the cdp command as shown below.\n\nhostname R3\ncdp\n\nBy default CDP is disabled globally; hence, the command cdp run will not be shown in the configuration. If CDP is enabled, proceed to step 2.\n\nStep 2: Verify CDP is not enabled on any external interface as shown in the example below.\n\ninterface GigabitEthernet0/0/0/1\n cdp\n ipv4 address x.1.34.3 255.255.255.252\n\nIf CDP is enabled on any external interface, this is a finding.","fixText":"This requirement is not applicable for the DODIN Backbone.\n\nDisable CDP on all external interfaces via no cdp command or disable CDP globally via no cdp command.","ccis":["CCI-002403"]},{"vulnId":"V-216766","ruleId":"SV-216766r856444_rule","severity":"medium","ruleTitle":"The Cisco perimeter router must be configured to have Proxy ARP disabled on all external interfaces.","description":"When Proxy ARP is enabled on a router, it allows that router 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 router interfaces that do not require it, unless the router is being used as a LAN bridge.","checkContent":"This requirement is not applicable for the DODIN Backbone.\n\nReview the router configuration to determine if IP Proxy ARP is enabled on any external interfaces as shown in the example below.\n\ninterface GigabitEthernet0/0/0/1\n description link to DISN\n ipv4 address x.1.12.2 255.255.255.252\n proxy-arp\n\nIf IP Proxy ARP is enabled on any external interface, this is a finding.","fixText":"This requirement is not applicable for the DODIN Backbone.\n\nDisable Proxy ARP on all external interfaces as shown in the example below.\n\nRP/0/0/CPU0:R3(config)#interface g0/0/0/1\nRP/0/0/CPU0:R3(config-if)#no proxy-arp","ccis":["CCI-002403"]},{"vulnId":"V-216767","ruleId":"SV-216767r945857_rule","severity":"medium","ruleTitle":"The Cisco perimeter router must be configured to block all outbound management traffic.","description":"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 routers 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.","checkContent":"This requirement is not applicable for the DODIN Backbone.\n\nThe perimeter router of the managed network must be configured with an outbound ACL on the egress interface to block all management traffic as shown in the example below.\n\nStep 1: Verify that all external interfaces has been configured with an outbound ACL as shown in the example below.\n\ninterface GigabitEthernet0/0/0/2\n ipv4 address 10.1.35.3 255.255.255.0\n ipv4 access-group EXTERNAL_ACL_OUTBOUND egress\n\nStep 2: Verify that the outbound ACL discards management traffic as shown in the example below.\n\nipv4 access-list EXTERNAL_ACL_OUTBOUND\n 10 deny tcp any any eq tacacs log-input\n 20 deny tcp any any eq ssh log-input\n 30 deny udp any any eq snmp log-input\n 40 deny udp any any eq snmptrap log-input\n 50 deny udp any any eq syslog log-input\n 60 permit tcp any any eq www log-input\n 70 deny ipv4 any any log-input\n\nIf management traffic is not blocked at the perimeter, this is a finding.","fixText":"This requirement is not applicable for the DODIN Backbone.\n\nConfigure the perimeter router of the managed network with an outbound ACL on the egress interface to block all management traffic.\n\nStep 1: Configure an ACL to block egress management traffic.\n\nRP/0/0/CPU0:R3(config)#Ipv4 access-list EXTERNAL_ACL_OUTBOUND\nRP/0/0/CPU0:R3(config-ipv4-acl)#deny tcp any any eq tacacs log-input\nRP/0/0/CPU0:R3(config-ipv4-acl)#deny tcp any any eq 22 log-input\nRP/0/0/CPU0:R3(config-ipv4-acl)#deny udp any any eq snmp log-input\nRP/0/0/CPU0:R3(config-ipv4-acl)#deny udp any any eq snmptrap log-input\nRP/0/0/CPU0:R3(config-ipv4-acl)#deny udp any any eq syslog log-input\nRP/0/0/CPU0:R3(config-ipv4-acl)#permit tcp any any eq www log-input\nRP/0/0/CPU0:R3(config-ipv4-acl)#deny ip any any log-input\nRP/0/0/CPU0:R3(config-ipv4-acl)#end\n\nNote: Permit commands would be configured to allow applicable outbound traffic. The example above is allowing web traffic.\n\nStep 2: Configure the external interfaces with the outbound ACL.\n\nRP/0/0/CPU0:R3(config)#int g0/0/0/2\nRP/0/0/CPU0:R3(config-if)#ipv4 access-group EXTERNAL_ACL_OUTBOUND egress","ccis":["CCI-001097"]},{"vulnId":"V-216768","ruleId":"SV-216768r991934_rule","severity":"medium","ruleTitle":"The Cisco out-of-band management (OOBM) gateway router must be configured to transport management traffic to the Network Operations Center (NOC) via dedicated circuit, MPLS/VPN service, or IPsec tunnel.","description":"Using dedicated paths, the OOBM backbone connects the OOBM gateway routers located at the edge of the managed network and at the NOC. Dedicated links can be deployed using provisioned circuits or MPLS Layer 2 and Layer 3 VPN services or implementing a secured path with gateway-to-gateway IPsec tunnels. The tunnel mode ensures that the management traffic will be logically separated from any other traffic traversing the same path.","checkContent":"This requirement is not applicable for the DODIN Backbone.\n\nReview the network topology diagram to determine connectivity between the managed network and the NOC. Review the OOBM gateway router configuration to validate the path and interface that the management traffic traverses. If an IPsec tunnel is used to transport the management traffic between the NOC and the managed network, review the configuration following the steps below.\n\nStep 1: Note the profile referenced for the IPsec tunnel to the NOC.\n\ninterface tunnel-ipsec 30\n profile IPSEC_NOC_PROFILE\n tunnel source GigabitEthernet0/0/0/2\n tunnel destination x.1.22.2\n\nStep 2: Note the crypto ACL that was specified in the IPsec profile.\n\n crypto isakmp keyring ISAKMP_KEYRING\n pre-shared-key address x.1.22.2 255.255.255.255 key encrypted 150A13141C32\n!\ncrypto isakmp policy 10\n hash sha256\n encryption aes 256\n authentication pre-share\n!\ncrypto ipsec transform-set IPSEC_TRANS esp-aes 256 esp-sha256-hmac\n mode tunnel\n!\ncrypto ipsec profile IPSEC_NOC_PROFILE\n set pfs group16\n match address MGMT_TRAFFIC_ACL\n\nStep 3: Review the ACL defined in the crypto map and verify that the destination is the management network.\n\n!\nipv4 access-list MGMT_TRAFFIC_ACL\n 10 permit ipv4 10.1.34.0 0.0.0.255 10.22.2.0 0.0.0.255\n!\n\nNote: The management network is this example is 10.22.2.0/24\n\nIf management traffic is not transported between the managed network and the NOC via dedicated circuit, MPLS/VPN service, or IPsec tunnel, this is a finding.","fixText":"This requirement is not applicable for the DODIN Backbone.\n\nEnsure that a dedicated circuit, MPLS/VPN service, or IPsec tunnel is deployed to transport management traffic between the managed network and the NOC. If an IPsec tunnel is to be used, the steps below can be used as a guideline.\n\nStep 1: Configure the ACL for the management network as the destination. This ACL will be defined in the crypto as the interesting traffic to be forwarded into the IPsec tunnel.\n\nRP/0/0/CPU0:R3(config)#Ipv4 access-list MGMT_TRAFFIC_ACL\nRP/0/0/CPU0:R3(config-ipv4-acl)#permit ip 10.1.34.0 0.0.0.255 10.22.2.0 0.0.0.255\n\nStep 2: Create an ISAKMP policy for Phase 1 negotiations.\n\nRP/0/0/CPU0:R3(config)#crypto isakmp policy 10\nRP/0/0/CPU0:R3(config-isakmp-policy)#authentication pre-share\nRP/0/0/CPU0:R3(config-isakmp-policy)#hash sha256\nRP/0/0/CPU0:R3(config-isakmp-policy)#encryption aes 256\nRP/0/0/CPU0:R3(config-isakmp-policy)#exit\n\nStep 3: Configure the keyring to be used for ISAKMP to authenticate the remote side during IKE negotiation.\n\nRP/0/0/CPU0:R3(config)#crypto isakmp keyring ISAKMP_KEYRING\nRP/0/0/CPU0:R3(config-crypto-keyring)#pre-shared-key address 255.255.255.255 key xxxxx\nRP/0/0/CPU0:R3(config-crypto-keyring)#exit\n\nStep 4: Configure the IPsec transform set.\n\nRP/0/0/CPU0:R3(config)#crypto ipsec transform-set IPSEC_TRANS esp-aes 256 esp-sha256-hmac\nRP/0/0/CPU0:R3(config-transform-set IPSEC_TRANS)#mode tunnel\n\nStep 5: Configure the IPsec profile.\n\nRP/0/0/CPU0:R3(config)#crypto ipsec profile IPSEC_NOC_PROFILE\nRP/0/0/CPU0:R3(config- IPSEC_NOC_PROFILE)#set pfs group 16\nRP/0/0/CPU0:R3(config- IPSEC_NOC_PROFILE)#match MGMT_TRAFFIC_ACL transform-set IPSEC_TRANS\nRP/0/0/CPU0:R3(config- IPSEC_NOC_PROFILE)#exit\n\nStep 6: Configure the IPsec virtual interface.\n \nRP/0/0/CPU0:R3(config)#interface tunnel-ipsec 22\nRP/0/0/CPU0:R3(config-if)#profile IPSEC_NOC_PROFILE\nRP/0/0/CPU0:R3(config-if)#tunnel source GigabitEthernet0/0/0/2\nRP/0/0/CPU0:R3(config-if)#tunnel destination x.1.22.2\nRP/0/0/CPU0:R3(config-if)#end","ccis":["CCI-001097","CCI-004891"]},{"vulnId":"V-216769","ruleId":"SV-216769r531087_rule","severity":"medium","ruleTitle":"The Cisco out-of-band management (OOBM) gateway router must be configured to forward only authorized management traffic to the Network Operations Center (NOC).","description":"The OOBM network is an IP network used exclusively for the transport of OAM&P data from the network being managed to the OSS components located at the NOC. Its design provides connectivity to each managed network device, enabling network management traffic to flow between the managed network elements and the NOC. This allows the use of paths separate from those used by the managed network.","checkContent":"This requirement is not applicable for the DODIN Backbone.\n\nReview the network topology diagram to determine connectivity between the managed network and the NOC. Review the OOBM gateway router configuration to validate the path that the management traffic traverses. Verify that only management traffic is forwarded through the OOBM interface or IPsec tunnel.\n\nIf an OOBM link is used, verify that the only authorized management traffic is transported to the NOC by reviewing the outbound ACL applied to the OOBM interface as shown in the example below.\n\nStep 1: Note the outbound ACL applied to the OOBM interface.\n\ninterface GigabitEthernet0/0/0/2\n description OOB link to NOC\n ipv4 address 10.11.1.8 255.255.255.0\n ipv4 access-group MGMT_TRAFFIC_ACL egress\n\nStep 2: Review the outbound ACL and verify only management traffic is forwarded to the NOC.\n\nipv4 access-list MGMT_TRAFFIC_ACL\n 10 permit tcp 10.1.34.0 0.0.0.255 10.22.2.0 0.0.0.255 eq tacacs\n 20 permit tcp 10.1.34.0 0.0.0.255 10.22.2.0 0.0.0.255 eq ssh\n 30 permit udp 10.1.34.0 0.0.0.255 10.22.2.0 0.0.0.255 eq snmp\n 40 permit udp 10.1.34.0 0.0.0.255 10.22.2.0 0.0.0.255 eq snmptrap\n 50 permit udp 10.1.34.0 0.0.0.255 10.22.2.0 0.0.0.255 eq syslog\n 60 permit icmp 10.1.34.0 0.0.0.255 10.22.22.0 0.0.0.255 echo\n 70 permit icmp 10.1.34.0 0.0.0.255 10.22.22.0 0.0.0.255 echo-reply\n 80 deny ipv4 any any log-input\n\nIf an IPSec tunnel is used, verify that the only authorized management traffic is transported to the NOC.\n\nStep 1: Note the profile referenced for the IPSec tunnel to the NOC.\n\ninterface tunnel-ipsec 30\n profile IPSEC_NOC_PROFILE\n tunnel source GigabitEthernet0/0/0/2\n tunnel destination x.1.22.2\n\nStep 2: Note the crypto ACL that was specified in the IPSec profile.\n\n crypto isakmp keyring ISAKMP_KEYRING\n pre-shared-key address x.1.22.2 255.255.255.255 key encrypted 150A13141C32\n!\ncrypto isakmp policy 10\n hash sha256\n encryption aes 256\n authentication pre-share\n!\ncrypto ipsec transform-set IPSEC_TRANS esp-aes 256 esp-sha256-hmac\n mode tunnel\n!\ncrypto ipsec profile IPSEC_NOC_PROFILE\n set pfs group16\n match address MGMT_TRAFFIC_ACL\n\nStep 3: Review the crypto ACL defined in the IPSec profile and verify only management traffic is forwarded to the NOC.\n\nipv4 access-list MGMT_TRAFFIC_ACL\n 10 permit tcp 10.1.34.0 0.0.0.255 10.22.2.0 0.0.0.255 eq tacacs\n 20 permit tcp 10.1.34.0 0.0.0.255 10.22.2.0 0.0.0.255 eq ssh\n 30 permit udp 10.1.34.0 0.0.0.255 10.22.2.0 0.0.0.255 eq snmp\n 40 permit udp 10.1.34.0 0.0.0.255 10.22.2.0 0.0.0.255 eq snmptrap\n 50 permit udp 10.1.34.0 0.0.0.255 10.22.2.0 0.0.0.255 eq syslog\n 60 permit icmp 10.1.34.0 0.0.0.255 10.22.22.0 0.0.0.255\n\nNote: ICMP is permitted for troubleshooting purposes. The IPSec SA can only identify interesting traffic via address, protocol, and port; hence, the ICMP traffic cannot be qualified via type attribute.\n\nIf traffic other than authorized management traffic is permitted through the OOBM interface or IPsec tunnel, this is a finding.","fixText":"This requirement is not applicable for the DODIN Backbone.\n\nConfigure ACLs to permit only authorized management traffic into IPsec tunnels or the OOBM interface used for forwarding management data as shown in the examples below.\n\nOOBM Link\n\nRP/0/0/CPU0:R3(config)#ipv4 access-list MGMT_TRAFFIC_ACL\nRP/0/0/CPU0:R3(config-ipv4-acl)#permit tcp 10.1.34.0 0.0.0.255 10.22.2.0 0.0.0.255 eq tacacs\nRP/0/0/CPU0:R3(config-ipv4-acl)#permit tcp 10.1.34.0 0.0.0.255 10.22.2.0 0.0.0.255 eq ssh\nRP/0/0/CPU0:R3(config-ipv4-acl)#permit udp 10.1.34.0 0.0.0.255 10.22.2.0 0.0.0.255 eq snmp\nRP/0/0/CPU0:R3(config-ipv4-acl)#permit udp 10.1.34.0 0.0.0.255 10.22.2.0 0.0.0.255 eq snmptrap\nRP/0/0/CPU0:R3(config-ipv4-acl)#permit udp 10.1.34.0 0.0.0.255 10.22.2.0 0.0.0.255 eq syslog\nRP/0/0/CPU0:R3(config-ipv4-acl)#permit icmp 10.1.34.0 0.0.0.255 10.22.22.0 0.0.0.255\nRP/0/0/CPU0:R3(config-ipv4-acl)#deny ipv4 any any log-input\nRP/0/0/CPU0:R3(config-ipv4-acl)#exit\n\nIPsec Tunnel\n\nRP/0/0/CPU0:R3(config)#ipv4 access-list MGMT_TRAFFIC_ACL\nRP/0/0/CPU0:R3(config-ipv4-acl)#permit tcp 10.1.34.0 0.0.0.255 10.22.2.0 0.0.0.255 eq tacacs\nRP/0/0/CPU0:R3(config-ipv4-acl)#permit tcp 10.1.34.0 0.0.0.255 10.22.2.0 0.0.0.255 eq ssh\nRP/0/0/CPU0:R3(config-ipv4-acl)#permit udp 10.1.34.0 0.0.0.255 10.22.2.0 0.0.0.255 eq snmp\nRP/0/0/CPU0:R3(config-ipv4-acl)#permit udp 10.1.34.0 0.0.0.255 10.22.2.0 0.0.0.255 eq snmptrap\nRP/0/0/CPU0:R3(config-ipv4-acl)#permit udp 10.1.34.0 0.0.0.255 10.22.2.0 0.0.0.255 eq syslog\nRP/0/0/CPU0:R3(config-ipv4-acl)#permit icmp 10.1.34.0 0.0.0.255 10.22.22.0 0.0.0.255\nRP/0/0/CPU0:R3(config-ipv4-acl)#exit","ccis":["CCI-001097"]},{"vulnId":"V-216770","ruleId":"SV-216770r1117237_rule","severity":"medium","ruleTitle":"The Cisco out-of-band management (OOBM) gateway router must be configured to have separate IGP instances for the managed network and management network.","description":"If the gateway router is not a dedicated device for the OOBM network, implementation of several safeguards for containment of management and production traffic boundaries must occur. Since the managed and management network are separate routing domains, configuration of separate Interior Gateway Protocol routing instances is critical on the router to segregate traffic from each network.","checkContent":"This requirement is not applicable for the DODIN Backbone.\n\nVerify that the OOBM interface is an adjacency in the IGP domain for the management network via separate VRF as shown in the example below.\n\nrouter ospf 2\n vrf MGMT\n area 0\n interface GigabitEthernet0/0/0/0.2\n !\n !\n !\n!\nrouter ospf 3\n vrf PROD\n area 0\n interface GigabitEthernet0/0/0/0.3\n !\n !\n !\n!\n\nIf the router is not configured to have separate IGP instances for the managed network and management network, this is a finding.","fixText":"This requirement is not applicable for the DODIN Backbone.\n\nConfigure the router to have a separate IGP instance for the management network as shown in the example below.\n\nRP/0/0/CPU0:R2(config)#router ospf 2 vrf MGMT\nRP/0/0/CPU0:R2(config-ospf-vrf)#area 0\nRP/0/0/CPU0:R2(config-ospf-vrf-ar)#interface GigabitEthernet0/0/0/0.2\nRP/0/0/CPU0:R2(config-ospf-vrf-ar-if)#exit\nRP/0/0/CPU0:R2(config-ospf-vrf-ar)#exit\nRP/0/0/CPU0:R2(config-ospf-vrf)#exit\nRP/0/0/CPU0:R2(config-ospf)#exit\nRP/0/0/CPU0:R2(config)#router ospf 3 vrf PROD\nRP/0/0/CPU0:R2(config-ospf-vrf)#area 0\nRP/0/0/CPU0:R2(config-ospf-vrf-ar)#interface GigabitEthernet0/0/0/0.3\nRP/0/0/CPU0:R2(config-ospf-vrf-ar-if)#end","ccis":["CCI-001414"]},{"vulnId":"V-216771","ruleId":"SV-216771r1117237_rule","severity":"medium","ruleTitle":"The Cisco out-of-band management (OOBM) gateway router must be configured to not redistribute routes between the management network routing domain and the managed network routing domain.","description":"If the gateway router is not a dedicated device for the OOBM network, several safeguards must be implemented for containment of management and production traffic boundaries; otherwise, it is possible that management traffic will not be separated from production traffic.\n\nSince the managed network and the management network are separate routing domains, separate Interior Gateway Protocol routing instances must be configured on the router, one for the managed network and one for the OOBM network. In addition, the routes from the two domains must not be redistributed to each other.","checkContent":"This requirement is not applicable for the DODIN Backbone.\n\nVerify the Interior Gateway Protocol (IGP) instance used for the managed network does not redistribute routes into the IGP instance used for the management network, and vice versa. The example below imports OSPF routes from the production route table (VRF PROD) into the management route table (VRF MGMT) using BGP.\n\nvrf MGMT\n address-family ipv4 unicast\n import route-target\n 4:4\n 8:8\n !\n export route-target\n 4:4\n !\n !\n!\nvrf PROD\n address-family ipv4 unicast\n import route-target\n 8:8\n !\n export route-target\n 8:8\n !\n !\n!\n…\n…\n…\nrouter ospf 2\n vrf MGMT\n redistribute bgp 64512\n area 0\n interface GigabitEthernet0/0/0/0.2\n !\n !\n !\n!\nrouter ospf 3\n vrf PROD\n area 0\n interface GigabitEthernet0/0/0/0.3\n !\n !\n !\n!\nrouter bgp 64512\n address-family ipv4 unicast\n !\n address-family vpnv4 unicast\n !\n vrf MGMT\n rd 4:4\n address-family ipv4 unicast\n redistribute ospf 2\n !\n !\n vrf PROD\n rd 8:8\n address-family ipv4 unicast\n redistribute ospf 3\n !\n !\n!\n\nIf the IGP instance used for the managed network redistributes routes into the IGP instance used for the management network, or vice versa, this is a finding.","fixText":"This requirement is not applicable for the DODIN Backbone.\n\nRemove the configuration that imports routes from the managed network into the management network or vice versa as shown in the example below.\n\nRP/0/0/CPU0:R2(config)#vrf MGMT\nRP/0/0/CPU0:R2(config-vrf)#address-family ipv4 unicast \nRP/0/0/CPU0:R2(config-vrf-af)#no import route-target 8:8\nRP/0/0/CPU0:R2(config-vrf-af)#end","ccis":["CCI-001414"]},{"vulnId":"V-216772","ruleId":"SV-216772r531087_rule","severity":"medium","ruleTitle":"The Cisco out-of-band management (OOBM) gateway router must be configured to block any traffic destined to itself that is not sourced from the OOBM network or the Network Operations Center (NOC).","description":"If the gateway router is not a dedicated device for the OOBM network, several safeguards must be implemented for containment of management and production traffic boundaries. It is imperative that hosts from the managed network are not able to access the OOBM gateway router.","checkContent":"This requirement is not applicable for the DODIN Backbone. It is only applicable if the OOBM gateway router is not a dedicated device to the OOBM backbone.\n\nVerify that traffic destined to itself is only sourced by the OOBM or the NOC. In the example below, the OOBM backbone network is 10.11.1.0/24, the NOC address spaces is 10.12.1.0/24, and the OOBM LAN address space at remote site connecting to the managed network is 10.13.1.0/24.\n\nStep 1: Note the inbound ACL applied to the OOBM interfaces.\n\ninterface GigabitEthernet0/0/0/2\n description OOB link to NOC\n ip address 10.11.1.8 255.255.255.0\n ipv4 access-group TRAFFIC_FROM_NOC ingress\n!\ninterface Giga GigabitEthernet0/0/0/3\n description link to OOBM LAN access switch\n ip address 10.13.1.1 255.255.255.0\n ipv4 access-group TRAFFIC_TO_NOC ingress\n\nStep 2: Review the inbound ACL bound to any OOB interface connecting to the OOBM backbone and verify traffic destined to itself is only from the OOBM or NOC address space.\n\nipv4 access-list TRAFFIC_FROM_NOC\n 10 permit ipv4 10.11.1.0 0.255.255.255 host 10.11.1.8\n 20 permit ipv4 10.12.1.0 0.255.255.255 host 10.11.1.8\n 30 permit ipv4 10.11.1.0 0.255.255.255 host 10.13.1.1\n 40 permit ipv4 10.12.1.0 0.255.255.255 host 10.13.1.1\n 50 deny ipv4 any host 10.11.1.8 log-input\n 60 deny ipv4 any host 10.13.1.1 log-input\n 70 permit ipv4 10.11.1.0 0.0.0.255 10.13.1.0 0.0.0.255\n 80 permit ipv4 10.12.1.0 0.0.0.255 10.13.1.0 0.0.0.255\n 90 deny ipv4 any any log-input\n\nStep 3: Review the inbound ACL bound to any OOBM LAN interfaces and verify traffic destined to itself is from the OOBM LAN address space.\n\nipv4 access-list TRAFFIC_TO_NOC\n 10 permit ipv4 10.13.1.0 0.255.255.255 host 10.13.1.1\n 20 permit ipv4 10.13.1.0 0.255.255.255 host 10.11.1.8\n 30 deny ipv4 any host 10.13.1.1 log-input\n 40 deny ipv4 any host 10.11.1.8 log-input\n 50 permit ipv4 10.13.1.0 0.255.255.255 10.11.1.0 0.0.0.255\n 60 permit ipv4 10.13.1.0 0.255.255.255 10.12.1.0 0.0.0.255\n 70 deny ipv4 any any log-input\n\nIf the router does not block any traffic destined to itself that is not sourced from the OOBM network or the NOC, this is a finding.","fixText":"This requirement is not applicable for the DODIN Backbone. It is only applicable if the OOBM gateway router is not a dedicated device to the OOBM backbone.\n\nStep 1: Configure the ACL to only allow traffic to the route processor from the OOBM backbone and the NOC.\n\nRP/0/0/CPU0:R2(config)#ipv4 access-list TRAFFIC_FROM_NOC\nRP/0/0/CPU0:R2(config-ipv4-acl)#permit ip 10.11.1.0 0.255.255.255 host 10.11.$\nRP/0/0/CPU0:R2(config-ipv4-acl)#permit ip 10.12.1.0 0.255.255.255 host 10.11.$\nRP/0/0/CPU0:R2(config-ipv4-acl)#permit ip 10.11.1.0 0.255.255.255 host 10.13.$\nRP/0/0/CPU0:R2(config-ipv4-acl)#permit ip 10.12.1.0 0.255.255.255 host 10.13.$\nRP/0/0/CPU0:R2(config-ipv4-acl)#deny ip any host 10.11.1.8 log-input\nRP/0/0/CPU0:R2(config-ipv4-acl)#deny ip any host 10.13.1.1 log-input\nRP/0/0/CPU0:R2(config-ipv4-acl)#permit ip 10.11.1.0 0.0.0.255 10.13.1.0 0.0.0$\nRP/0/0/CPU0:R2(config-ipv4-acl)#permit ip 10.12.1.0 0.0.0.255 10.13.1.0 0.0.0$\nRP/0/0/CPU0:R2(config-ipv4-acl)#deny ip any any log-input\nRP/0/0/CPU0:R2(config-ipv4-acl)#exit\n\nStep 2: Configure the ACL to only allow traffic to the route processor from the OOBM LAN.\n\nRP/0/0/CPU0:R2(config)#ipv4 access-list TRAFFIC_TO_NOC\nRP/0/0/CPU0:R2(config-ipv4-acl)#permit ip 10.13.1.0 0.255.255.255 host 10.13.$\nRP/0/0/CPU0:R2(config-ipv4-acl)#permit ip 10.13.1.0 0.255.255.255 host 10.11.$\nRP/0/0/CPU0:R2(config-ipv4-acl)#deny ip any host 10.13.1.1 log-input\nRP/0/0/CPU0:R2(config-ipv4-acl)#deny ip any host 10.11.1.8 log-input\nRP/0/0/CPU0:R2(config-ipv4-acl)#permit ip 10.13.1.0 0.255.255.255 10.11.1.0 0$\nRP/0/0/CPU0:R2(config-ipv4-acl)#permit ip 10.13.1.0 0.255.255.255 10.12.1.0 0$\nRP/0/0/CPU0:R2(config-ipv4-acl)#deny ip any any log-input\nRP/0/0/CPU0:R2(config-ipv4-acl)#exit\n\nStep 3: Apply the ACLs configured above to the appropriate OOBM interfaces as shown in the example below.\n\nRP/0/0/CPU0:R2(config)#int g0/0/0/2\nRP/0/0/CPU0:R2(config-if)#ipv4 access-group TRAFFIC_FROM_NOC in\nRP/0/0/CPU0:R2(config)#int g0/0/0/3\nRP/0/0/CPU0:R2(config-if)#access-group TRAFFIC_TO_NOC in\nRP/0/0/CPU0:R2(config-if)#end","ccis":["CCI-001097"]},{"vulnId":"V-216773","ruleId":"SV-216773r531087_rule","severity":"medium","ruleTitle":"The Cisco router must be configured to only permit management traffic that ingresses and egresses the out-of-band management (OOBM) interface.","description":"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.\n\nAn 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.","checkContent":"This requirement is only applicable where management access to the router is via an OOBM interface which is not a true OOBM interface.\n\nStep 1: Verify that the managed interface has an inbound and outbound ACL configured. \n\ninterface MgmtEth0/0/CPU0/0\n ipv4 address 10.1.13.4 255.255.255.0\n ipv4 access-group INGRESS_MANAGEMENT_ACL ingress\n ipv4 access-group EGRESS_MANAGEMENT_ACL egress\n\nStep 2: Verify that the ingress ACL only allows management and ICMP traffic. \n\nipv4 access-list INGRESS_MANAGEMENT_ACL\n 10 permit tcp any host 10.11.1.22 eq tacacs\n 20 permit tcp any host 10.11.1.22 eq ssh\n 30 permit udp any host 10.11.1.22 eq snmp\n 40 permit udp any host 10.11.1.22 eq snmptrap\n 50 permit udp any host 10.11.1.22 eq ntp\n 60 permit icmp any host 10.11.1.22\n 70 deny ipv4 any any log-input\n\nStep 3: Verify that the egress ACL blocks any transit traffic.\n\nipv4 access-list EGRESS_MANAGEMENT_ACL\n 10 deny ipv4 any any log-input\n\nNote: On Cisco routers, local generated packets are not inspected by outgoing interface access-lists. Hence, the above configuration would simply drop any packets not generated by the router; hence, blocking any transit traffic.\n\nIf the router does not restrict traffic that ingresses and egresses the management interface, this is a finding.","fixText":"If the management interface is not a dedicated OOBM interface, it must be configured with both an ingress and egress ACL.\n\nStep 1: Configure an ingress ACL a shown in the example below.\n\nRP/0/0/CPU0:R2(config)#Ipv4 access-list INGRESS_MANAGEMENT_ACL\nRP/0/0/CPU0:R2(config-ipv4-acl)#permit tcp any host 10.11.1.22 eq tacacs\nRP/0/0/CPU0:R2(config-ipv4-acl)#permit tcp any host 10.11.1.22 eq 22\nRP/0/0/CPU0:R2(config-ipv4-acl)#permit udp any host 10.11.1.22 eq snmp\nRP/0/0/CPU0:R2(config-ipv4-acl)#permit udp any host 10.11.1.22 eq snmptrap\nRP/0/0/CPU0:R2(config-ipv4-acl)#permit udp any host 10.11.1.22 eq ntp\nRP/0/0/CPU0:R2(config-ipv4-acl)#permit icmp any host 10.11.1.22\nRP/0/0/CPU0:R2(config-ipv4-acl)#deny ip any any log-input\nRP/0/0/CPU0:R2(config-ipv4-acl)#exit\n\nStep 2: Configure an egress ACL a shown in the example below.\n\nRP/0/0/CPU0:R2(config)#Ipv4 access-list EGRESS_MANAGEMENT_ACL\nRP/0/0/CPU0:R2(config-ipv4-acl)#deny ip any any log-input\nRP/0/0/CPU0:R2(config-ipv4-acl)#exit\n\nStep 3: Apply the ACLs to the OOBM interfaces.\n\nRP/0/0/CPU0:R2(config)#int MgmtEth0/0/CPU0/0 \nRP/0/0/CPU0:R2(config-if)#ipv4 access-group INGRESS_MANAGEMENT_ACL ingress\nRP/0/0/CPU0:R2(config-if)#ipv4 access-group EGRESS_MANAGEMENT_ACL egress","ccis":["CCI-001097"]},{"vulnId":"V-216774","ruleId":"SV-216774r531087_rule","severity":"medium","ruleTitle":"The Cisco router providing connectivity to the Network Operations Center (NOC) must be configured to forward all in-band management traffic via an IPsec tunnel.","description":"When the production network is managed in-band, the management network could be housed at a NOC that is located remotely at single or multiple interconnected sites. NOC interconnectivity, as well as connectivity between the NOC and the managed network, must be enabled using IPsec tunnels to provide the separation and integrity of the managed traffic.","checkContent":"This requirement is not applicable for the DODIN Backbone.\n\nVerify that all traffic from the managed network to the management network or NOC and vice-versa is secured via IPsec tunnel.\n\nStep 1: Note the profile referenced for the IPSec tunnel to the NOC.\n\ninterface tunnel-ipsec 30\n profile IPSEC_NOC_PROFILE\n tunnel source GigabitEthernet0/0/0/2\n tunnel destination x.1.22.2\n\nStep 2: Note the crypto ACL that was specified in the IPSec profile.\n\n crypto isakmp keyring ISAKMP_KEYRING\n pre-shared-key address x.1.22.2 255.255.255.255 key encrypted 150A13141C32\n!\ncrypto isakmp policy 10\n hash sha256\n encryption aes 256\n authentication pre-share\n!\ncrypto ipsec transform-set IPSEC_TRANS esp-aes 256 esp-sha256-hmac\n mode tunnel\n!\ncrypto ipsec profile IPSEC_NOC_PROFILE\n set pfs group16\n match address MGMT_TRAFFIC_ACL\n\nStep 3: Review the ACL defined in the crypto map and verify that the destination is the management network.\n\n!\nipv4 access-list MGMT_TRAFFIC_ACL\n 10 permit ipv4 10.1.34.0 0.0.0.255 10.22.2.0 0.0.0.255\n!\n\nNote: The management network is this example is 10.22.2.0/24.\n\nIf the management traffic is not secured via IPsec tunnel, this is a finding.","fixText":"This requirement is not applicable for the DODIN Backbone.\n\nEnsure that all traffic from the managed network to the management network is secured via IPsec tunnel as shown in the configuration examples below.\n\nStep 1: Configure the ACL for the management network as the destination. This ACL will be defined in the crypto as the interesting traffic to be forwarded into the IPsec tunnel.\n\nRP/0/0/CPU0:R3(config)#Ipv4 access-list MGMT_TRAFFIC_ACL\nRP/0/0/CPU0:R3(config-ipv4-acl)#permit ip 10.1.34.0 0.0.0.255 10.22.2.0 0.0.0.255\n\nStep 2: Create an ISAKMP policy for Phase 1 negotiations.\n\nRP/0/0/CPU0:R3(config)#crypto isakmp policy 10\nRP/0/0/CPU0:R3(config-isakmp-policy)#authentication pre-share\nRP/0/0/CPU0:R3(config-isakmp-policy)#hash sha256\nRP/0/0/CPU0:R3(config-isakmp-policy)#encryption aes 256\nRP/0/0/CPU0:R3(config-isakmp-policy)#exit\n\nStep 3: Configure the keyring to be used for ISAKMP to authenticate the remote side during IKE negotiation.\n\nRP/0/0/CPU0:R3(config)#crypto isakmp keyring ISAKMP_KEYRING\nRP/0/0/CPU0:R3(config-crypto-keyring)#pre-shared-key address 255.255.255.255 key xxxxx\nRP/0/0/CPU0:R3(config-crypto-keyring)#exit\n\nStep 4: Configure the IPSec transform set.\n\nRP/0/0/CPU0:R3(config)#crypto ipsec transform-set IPSEC_TRANS esp-aes 256 esp-sha256-hmac\nRP/0/0/CPU0:R3(config-transform-set IPSEC_TRANS)#mode tunnel\n\nStep 5: Configure the IPSec profile.\n\n RP/0/0/CPU0:R3(config)#crypto ipsec profile IPSEC_NOC_PROFILE\nRP/0/0/CPU0:R3(config- IPSEC_NOC_PROFILE)#set pfs group 16\nRP/0/0/CPU0:R3(config- IPSEC_NOC_PROFILE)#match MGMT_TRAFFIC_ACL transform-set IPSEC_TRANS\nRP/0/0/CPU0:R3(config- IPSEC_NOC_PROFILE)#exit\n\nStep 6: Configure the IPSec virtual interface.\n \nRP/0/0/CPU0:R3(config)#interface tunnel-ipsec 22\nRP/0/0/CPU0:R3(config-if)#profile IPSEC_NOC_PROFILE\nRP/0/0/CPU0:R3(config-if)#tunnel source GigabitEthernet0/0/0/2\nRP/0/0/CPU0:R3(config-if)#tunnel destination x.1.22.2\nRP/0/0/CPU0:R3(config-if)#end","ccis":["CCI-001097"]},{"vulnId":"V-216777","ruleId":"SV-216777r1117236_rule","severity":"medium","ruleTitle":"The Cisco BGP router must be configured to reject inbound route advertisements for any Bogon prefixes.","description":"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.","checkContent":"Review the router configuration to verify that it will reject BGP routes for any Bogon prefixes.\n\nStep 1: verify that an inbound route policy has been configured for each external neighbor as shown in the example below.\n\nrouter bgp n\n address-family ipv4 unicast\n !\n neighbor x.1.23.3\n remote-as y\n keychain YYY_KEY_CHAIN\n ttl-security\n address-family ipv4 unicast\n route-policy BGP_FILTER in\n !\n !\n neighbor x.1.24.4\n remote-as z\n keychain ZZZ_KEY_CHAIN\n ttl-security\n address-family ipv4 unicast\n route-policy BGP_FILTER in\n !\n!\n\nStep 2: Review the route policy to determine if it is filtering at a minimum BOGON prefixes as shown in the example below.\n\nroute-policy BGP_FILTER\n if destination in BOGON_PREFIXES then\n drop\n else\n pass\n endif\nend-policy \n\nStep 3: Review the prefix set referenced in the route policy above has been configured containing the current Bogon prefixes as shown in the example below.\n\nprefix-set BOGON_PREFIXES\n 0.0.0.0/8 le 32,\n 10.0.0.0/8 le 32,\n 100.64.0.0/10 le 32,\n 127.0.0.0/8 le 32,\n 169.254.0.0/16 le 32,\n 172.16.0.0/12 le 32,\n 192.0.2.0/24 le 32,\n 192.88.99.0/24 le 32,\n 192.168.0.0/16 le 32,\n 198.18.0.0/15 le 32,\n 198.51.100.0/24 le 32,\n 203.0.113.0/24 le 32,\n 240.0.0.0/4 le 32,\n 224.0.0.0/4 le 32\nend-set\n\nIf the router is not configured to reject inbound route advertisements for any Bogon prefixes, this is a finding.","fixText":"Configure the router to reject inbound route advertisements for any Bogon prefixes.\n\nStep 1: Configure a prefix set containing the current Bogon prefixes as shown below.\n\nRP/0/0/CPU0:R2(config)#prefix-set BOGON_PREFIXES \nRP/0/0/CPU0:R2(config-pfx)#0.0.0.0/8 le 32,\nRP/0/0/CPU0:R2(config-pfx)#10.0.0.0/8 le 32,\nRP/0/0/CPU0:R2(config-pfx)#100.64.0.0/10 le 32,\nRP/0/0/CPU0:R2(config-pfx)#127.0.0.0/8 le 32,\nRP/0/0/CPU0:R2(config-pfx)#169.254.0.0/16 le 32,\nRP/0/0/CPU0:R2(config-pfx)#172.16.0.0/12 le 32,\nRP/0/0/CPU0:R2(config-pfx)#192.0.2.0/24 le 32,\nRP/0/0/CPU0:R2(config-pfx)#192.88.99.0/24 le 32,\nRP/0/0/CPU0:R2(config-pfx)#192.168.0.0/16 le 32,\nRP/0/0/CPU0:R2(config-pfx)#198.18.0.0/15 le 32,\nRP/0/0/CPU0:R2(config-pfx)#198.51.100.0/24 le 32,\nRP/0/0/CPU0:R2(config-pfx)#203.0.113.0/24 le 32,\nRP/0/0/CPU0:R2(config-pfx)#240.0.0.0/4 le 32,\nRP/0/0/CPU0:R2(config-pfx)#224.0.0.0/4 le 32\nRP/0/0/CPU0:R2(config-pfx)#end-set\n\nStep 2: Configure the route policy to drop routes with BOGON prefixes as shown in the example below.\n\nRP/0/0/CPU0:R2(config)#route-policy BGP_FILTER \nRP/0/0/CPU0:R2(config-rpl)#if destination in BOGON_PREFIXES then \nRP/0/0/CPU0:R2(config-rpl-if)#drop\nRP/0/0/CPU0:R2(config-rpl-if)#else pass endif\nRRP/0/0/CPU0:R2(config-rpl)#end-policy \nRP/0/0/CPU0:R2(config)#exit\n\nStep 3: Apply the route policy to each external BGP neighbor as shown in the example.\n\nRP/0/0/CPU0:R2(config)#router bgp xx\nRP/0/0/CPU0:R2(config-bgp)#neighbor x.1.23.3\nRP/0/0/CPU0:R2(config-bgp-nbr)#address-family ipv4 unicast \nRP/0/0/CPU0:R2(config-bgp-nbr-af)#route-policy BGP_FILTER in\nRP/0/0/CPU0:R2(config-bgp)#neighbor x.1.24.4\nRP/0/0/CPU0:R2(config-bgp-nbr)#address-family ipv4 unicast \nRP/0/0/CPU0:R2(config-bgp-nbr-af)#route-policy BGP_FILTER in","ccis":["CCI-001368"]},{"vulnId":"V-216778","ruleId":"SV-216778r1117236_rule","severity":"medium","ruleTitle":"The Cisco BGP router must be configured to reject inbound route advertisements for any prefixes belonging to the local autonomous system (AS).","description":"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.","checkContent":"Review the router configuration to verify that it will reject routes belonging to the local AS.\n\nStep 1: verify that an inbound route policy has been configured for each external neighbor as shown in the example below.\n\nrouter bgp xx\n address-family ipv4 unicast\n !\n neighbor x.1.23.3\n remote-as yy\n keychain YYY_KEY_CHAIN\n ttl-security\n address-family ipv4 unicast\n route-policy BGP_FILTER_INBOUND in\n !\n !\n neighbor x.1.24.4\n remote-as zz\n keychain ZZZ_KEY_CHAIN\n ttl-security\n address-family ipv4 unicast\n route-policy BGP_FILTER_INBOUND in\n !\n!\n\nStep 2: Review the route policy to determine if it is filtering at a minimum local prefixes as shown in the example below.\n\nroute-policy BGP_FILTER_INBOUND\n if destination in LOCAL_PREFIX then\n drop\n else\n pass\n endif\nend-policy \n\nNote: If bogons are also filtered per previous requirement, the route policy would look similar to the following example:\n\nroute-policy BGP_FILTER_INBOUND\n if destination in BOGON_PREFIXES then\n drop\n elseif destination in LOCAL_PREFIX then\n drop\n else\n pass\n endif\nend-policy\n\nStep 3: Review the prefix set referenced in the route policy above to determine if it includes the local global prefix as shown in the example below.\n\nprefix-set LOCAL_PREFIX\n x.13.1.0/24 le 32\nend-set\n\nIf the router is not configured to reject inbound route advertisements belonging to the local AS, this is a finding.","fixText":"Step 1: Configure a prefix set containing the current Bogon prefixes as shown below.\n\nRP/0/0/CPU0:R2(config)#prefix-set Step 1: Configure a prefix set containing the current Bogon prefixes as shown below.\n\nRP/0/0/CPU0:R2(config)#prefix-set LOCAL_PREFIX\nRP/0/0/CPU0:R2(config-pfx)#x.13.1.0/24 le 32\nRP/0/0/CPU0:R2(config-pfx)#end-set\n\nStep 2: Configure the route policy to drop routes with BOGON prefixes as shown in the example below.\n\nRP/0/0/CPU0:R2(config)#route-policy BGP_FILTER_INBOUND\nRP/0/0/CPU0:R2(config-rpl)#if destination in LOCAL_PREFIX then \nRP/0/0/CPU0:R2(config-rpl-if)#drop\nRP/0/0/CPU0:R2(config-rpl-if)#else pass endif\nRRP/0/0/CPU0:R2(config-rpl)#end-policy \nRP/0/0/CPU0:R2(config)#exit\n\nStep 3: Apply the route policy to each external BGP neighbor as shown in the example.\n\nRP/0/0/CPU0:R2(config)#router bgp xx\nRP/0/0/CPU0:R2(config-bgp)#neighbor x.1.23.3\nRP/0/0/CPU0:R2(config-bgp-nbr)#address-family ipv4 unicast \nRP/0/0/CPU0:R2(config-bgp-nbr-af)#route-policy BGP_FILTER_INBOUND in\nRP/0/0/CPU0:R2(config-bgp)#neighbor x.1.24.4\nRP/0/0/CPU0:R2(config-bgp-nbr)#address-family ipv4 unicast \nRP/0/0/CPU0:R2(config-bgp-nbr-af)#route-policy BGP_FILTER_INBOUND in","ccis":["CCI-001368"]},{"vulnId":"V-216779","ruleId":"SV-216779r1117236_rule","severity":"medium","ruleTitle":"The Cisco BGP router must be configured to reject inbound route advertisements from a customer edge (CE) router for prefixes that are not allocated to that customer.","description":"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 routers 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.","checkContent":"Review the router configuration to verify that there are ACLs defined to only accept routes for prefixes that belong to specific customers. \n\nStep 1: Verify that an inbound route policy has been configured for each customer neighbor as shown in the example below.\n\nrouter bgp xx\n address-family ipv4 unicast\n !\n neighbor x.12.4.14\n remote-as 64514\n address-family ipv4 unicast\n route-policy CUST1_PREFIX_FILTER in\n !\n !\n neighbor x.12.4.16\n remote-as 64516\n address-family ipv4 unicast\n route-policy CUST2_PREFIX_FILTER in\n !\n!\n\nStep 2: Review the route policies to determine if it is accepting only prefixes belonging to each customer as shown in the example below.\n\nroute-policy CUST1_PREFIX_FILTER\n if destination in CUST1_PREFIX then\n pass\n else\n drop\n endif\nend-policy\n!\nroute-policy CUST2_PREFIX_FILTER\n if destination in CUST2_PREFIX then\n pass\n else\n drop\n endif\nend-policy\n\nStep 3: Review the prefix sets referenced in the route policies above to determine if they include only prefixes belonging to each customer.\n\nprefix-set CUST1_PREFIX\n x.1.1.0/24 le 32\nend-set\n!\nprefix-set CUST2_PREFIX\n x.2.1.0/24 le 32\nend-set\n\nNote: 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.\n\nIf the router is not configured to reject inbound route advertisements from each CE router for prefixes that are not allocated to that customer, this is a finding.","fixText":"Configure the router to reject inbound route advertisements from each CE router for prefixes that are not allocated to that customer.\n\nStep 1: Configure a prefix set for each customer containing prefixes belonging to each as shown in the example.\n\nRP/0/0/CPU0:R2(config)#prefix-set CUST1_PREFIX\nRP/0/0/CPU0:R2(config-pfx)#x.1.1.0/24 le 32\nRP/0/0/CPU0:R2(config-pfx)#end-set\nRP/0/0/CPU0:R2(config)#prefix-set CUST2_PREFIX\nRP/0/0/CPU0:R2(config-pfx)#x.2.1.0/24 le 32\nRP/0/0/CPU0:R2(config-pfx)#end-set \n\nStep 2: Configure a route policy filter for each customer as shown in the example.\n\nRP/0/0/CPU0:R2(config)#route-policy CUST1_PREFIX_FILTER \nRP/0/0/CPU0:R2(config-rpl)#if destination in CUST1_PREFIX then\nRP/0/0/CPU0:R2(config-rpl-if)#pass\nRP/0/0/CPU0:R2(config-rpl-if)#else\nRP/0/0/CPU0:R2(config-rpl-else)#drop\nRP/0/0/CPU0:R2(config-rpl-else)#endif\nRP/0/0/CPU0:R2(config-rpl)#end-policy\nRP/0/0/CPU0:R2(config)#route-policy CUST2_PREFIX_FILTER \nRP/0/0/CPU0:R2(config-rpl)#if destination in CUST2_PREFIX then\nRP/0/0/CPU0:R2(config-rpl-if)#pass\nRP/0/0/CPU0:R2(config-rpl-if)#else\nRP/0/0/CPU0:R2(config-rpl-else)#drop\nRP/0/0/CPU0:R2(config-rpl-else)#endif\nRP/0/0/CPU0:R2(config-rpl)#end-policy\n\nStep 3: Apply the route policy to each customer neighbor as shown in the example.\n\nRP/0/0/CPU0:R2(config)#router bgp xx\nRP/0/0/CPU0:R2(config-bgp)#neighbor x.12.4.14\nRP/0/0/CPU0:R2(config-bgp-nbr)#address-family ipv4 unicast \nRP/0/0/CPU0:R2(config-bgp-nbr-af)#route-policy CUST1_PREFIX_FILTER in\nRP/0/0/CPU0:R2(config-bgp)#neighbor x.12.4.16\nRP/0/0/CPU0:R2(config-bgp-nbr)#address-family ipv4 unicast \nRP/0/0/CPU0:R2(config-bgp-nbr-af)#route-policy CUST2_PREFIX_FILTER in","ccis":["CCI-001368"]},{"vulnId":"V-216780","ruleId":"SV-216780r1117236_rule","severity":"medium","ruleTitle":"The Cisco BGP router must be configured to reject outbound route advertisements for any prefixes that do not belong to any customers or the local autonomous system (AS).","description":"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 router within the GIG IP core could redistribute IGP routes into BGP, thereby leaking internal routes.","checkContent":"This requirement is not applicable for the DODIN Backbone.\n\nStep 1: verify that an outbound route policy has been configured for each customer neighbor as shown in the example below.\n\nrouter bgp xx\n address-family ipv4 unicast\n !\n neighbor x.12.4.14\n remote-as 64514\n address-family ipv4 unicast\n route-policy CE_ADVERTISEMENTS out\n !\n !\n neighbor x.12.4.16\n remote-as 64516\n address-family ipv4 unicast\n route-policy CE_ADVERTISEMENTS out\n !\n!\n\nStep 2: Review the route policy to determine if it is accepting only prefixes belonging to customers or the local autonomous system as shown in the example below.\n\nroute-policy CE_ADVERTISEMENTS\n if destination in CE_PREFIX_ADVERTISEMENTS then\n pass\n else\n drop\n endif\nend-policy\n\nStep 3: Review the prefix sets referenced in the route policy above to determine if they include only prefixes belonging to customers or the local autonomous system as shown in the example below.\n\nprefix-set CE_PREFIX_ADVERTISEMENTS\n x.13.1.0/24 le 32,\n x.13.2.0/24 le 32,\n x.13.3.0/24 le 32,\n x.13.4.0/24 le 32\nend-set\n\nIf the router is not configured to reject outbound route advertisements that do not belong to any customers or the local AS, this is a finding.","fixText":"This requirement is not applicable for the DODIN Backbone.\n\nStep 1: Configure a prefix set for customer and local autonomous system prefixes as shown in the example.\n\nRP/0/0/CPU0:R2(config)#prefix-set CE_PREFIX_ADVERTISEMENTS\nRP/0/0/CPU0:R2(config-pfx)#x.13.1.0/24 le 32,\nRP/0/0/CPU0:R2(config-pfx)#x.13.2.0/24 le 32,\nRP/0/0/CPU0:R2(config-pfx)#x.13.3.0/24 le 32,\nRP/0/0/CPU0:R2(config-pfx)#x.13.4.0/24 le 32\nRP/0/0/CPU0:R2(config-pfx)#end-set\n\nStep 2: Configure a route policy filter for allow customer and local autonomous system prefixes as shown in the example.\n\nRP/0/0/CPU0:R2(config)#route-policy CE_ADVERTISEMENTS\nRP/0/0/CPU0:R2(config-rpl)#if destination in CE_PREFIX_ADVERTISEMENTS then\nRP/0/0/CPU0:R2(config-rpl-if)#pass\nRP/0/0/CPU0:R2(config-rpl-if)#else\nRP/0/0/CPU0:R2(config-rpl-else)#drop\nRP/0/0/CPU0:R2(config-rpl-else)#endif\nRP/0/0/CPU0:R2(config-rpl)#end-policy\n\nStep 3: Apply the route policy to each customer neighbor as shown in the example.\n\nRP/0/0/CPU0:R2(config)#router bgp xx\nRP/0/0/CPU0:R2(config-bgp)#neighbor x.12.4.14\nRP/0/0/CPU0:R2(config-bgp-nbr)#address-family ipv4 unicast \nRP/0/0/CPU0:R2(config-bgp-nbr-af)#route-policy route-policy CE_ADVERTISEMENTS out \nRP/0/0/CPU0:R2(config-bgp)#neighbor x.12.4.16\nRP/0/0/CPU0:R2(config-bgp-nbr)#address-family ipv4 unicast \nRP/0/0/CPU0:R2(config-bgp-nbr-af)#route-policy CE_ADVERTISEMENTS out\nRP/0/0/CPU0:R2(config-bgp-nbr-af)#end","ccis":["CCI-001368"]},{"vulnId":"V-216781","ruleId":"SV-216781r531087_rule","severity":"medium","ruleTitle":"The Cisco BGP router must be configured to reject outbound route advertisements for any prefixes belonging to the IP core.","description":"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.","checkContent":"Step 1: verify that an outbound route policy has been configured for each external neighbor as shown in the example below.\n\nrouter bgp xx\n address-family ipv4 unicast\n !\n neighbor x.1.23.3\n remote-as yy\n address-family ipv4 unicast\n route-policy BGP_FILTER_OUTBOUND out\n !\n !\n neighbor x.1.24.4\n remote-as zz\n address-family ipv4 unicast\n route-policy BGP_FILTER_OUTBOUND out\n !\n!\n\nStep 2: Review the route policy to determine if it is filtering at a minimum IP core prefixes as shown in the example below.\n\nroute-policy BGP_FILTER_OUTBOUND\n if destination in CORE_PREFIX then\n drop\n else\n pass\n endif\nend-policy \n\nStep 3: Review the prefix set referenced in the route policy above to determine if it includes the IP core prefix as shown in the example below.\n\nprefix-set CORE_PREFIX\n 10.1.1.0/24 le 32\nend-set\n\nIf the router is not configured to reject outbound route advertisements for prefixes belonging to the IP core, this is a finding.","fixText":"Step 1: Configure a prefix set containing the IP core prefix as shown below.\n\nRP/0/0/CPU0:R2(config)#prefix-set \n\nStep 2: Configure a prefix set containing the current Bogon prefixes as shown below.\n\nRP/0/0/CPU0:R2(config)#prefix-set CORE_PREFIX\nRP/0/0/CPU0:R2(config-pfx)#10.1.1.0/24 le 32\nRP/0/0/CPU0:R2(config-pfx)#end-set\n\nStep 3: Configure the route policy to drop route advertisements for IP core prefixes as shown in the example below.\n\nRP/0/0/CPU0:R2(config)#route-policy BGP_FILTER_OUTBOUND\nRP/0/0/CPU0:R2(config-rpl)#if destination in CORE_PREFIX then\nRP/0/0/CPU0:R2(config-rpl-if)#drop\nRP/0/0/CPU0:R2(config-rpl-if)#else\nRP/0/0/CPU0:R2(config-rpl-else)#pass\nRP/0/0/CPU0:R2(config-rpl-else)#endif\nRP/0/0/CPU0:R2(config-rpl)#end-policy\n\nStep 4: Apply the route policy to each external BGP neighbor as shown in the example.\n\nRP/0/0/CPU0:R2(config)#router bgp xx\nRP/0/0/CPU0:R2(config-bgp)#neighbor x.1.23.3\nRP/0/0/CPU0:R2(config-bgp-nbr)#address-family ipv4 unicast \nRP/0/0/CPU0:R2(config-bgp-nbr-af)#route-policy BGP_FILTER_OUTBOUND out\nRP/0/0/CPU0:R2(config-bgp)#neighbor x.1.24.4\nRP/0/0/CPU0:R2(config-bgp-nbr)#address-family ipv4 unicast \nRP/0/0/CPU0:R2(config-bgp-nbr-af)#route-policy BGP_FILTER_ OUTBOUND out","ccis":["CCI-001097"]},{"vulnId":"V-216782","ruleId":"SV-216782r1117236_rule","severity":"low","ruleTitle":"The Cisco BGP router 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.","description":"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 routers (ASBRs) must ensure updates received from eBGP peers list their AS number as the first AS in the AS_PATH attribute.","checkContent":"Review the router configuration to verify the router is configured to deny updates received from eBGP peers that do not list their AS number as the first AS in the AS_PATH attribute.\n\nBy default Cisco IOS enforces the first AS in the AS_PATH attribute for all route advertisements. Review the router configuration to verify that the command bgp enforce-first-as disable is not configured as shown in the example below.\n\nrouter bgp nn\n bgp enforce-first-as disable\n\nIf the router is not configured to reject updates from peers that do not list their AS number as the first AS in the AS_PATH attribute, this is a finding.","fixText":"Configure the router to deny updates received from eBGP peers that do not list their AS number as the first AS in the AS_PATH attribute.\n\nRP/0/0/CPU0:R2(config)#router bgp 2\nRP/0/0/CPU0:R2(config-bgp)#no bgp enforce-first-as disable","ccis":["CCI-000032"]},{"vulnId":"V-216783","ruleId":"SV-216783r1117236_rule","severity":"low","ruleTitle":"The Cisco BGP router must be configured to reject route advertisements from CE routers with an originating AS in the AS_PATH attribute that does not belong to that customer.","description":"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 routers must be configured to reject routes with an originating AS other than that belonging to the customer.","checkContent":"This requirement is not applicable for the DODIN Backbone.\n\nReview the router configuration to verify the router is configured to deny updates received from CE routers with an originating AS in the AS_PATH attribute that does not belong to that customer.\n\nStep 1: verify that an inbound route policy has been configured for each customer neighbor as shown in the example below.\n\nrouter bgp xx\n address-family ipv4 unicast\n !\n neighbor x.12.4.14\n remote-as 64514\n address-family ipv4 unicast\n route-policy FILTER _64514_ROUTES in\n !\n !\n neighbor x.12.4.16\n remote-as 64516\n address-family ipv4 unicast\n route-policy FILTER_64516_ROUTES in\n !\n\nStep 2: Verify that the route policy permits only routes from each CE router with an originating AS that does not belong to that customer.\n\nroute-policy FILTER_64514_ROUTES\n if as-path originates-from 64514' then\n pass\n else\n drop\n endif\nend-policy\n!\nroute-policy FILTER_64516_ROUTES\n if as-path originates-from 64516' then\n pass\n else\n drop\n endif\nend-policy\n\nNote: The inbound route policy to filter customer prefixes can be nested with the above route policy as shown in the example below.\n\nroute-policy CUST1_INBOUND_FILTER\n apply CUST1_FILTER\n apply FILTER_64514_ROUTES\nend-policy\n\nIf the router is not configured to reject updates from CE routers with an originating AS in the AS_PATH attribute that does not belong to that customer, this is a finding.","fixText":"This requirement is not applicable for the DODIN Backbone.\n\nConfigure the router to reject updates from CE routers with an originating AS in the AS_PATH attribute that does not belong to that customer.\n\nStep 1: Configure an inbound route policy for each customer to only accept routes with an originating AS that belongs to that customer as shown in the example below.\n\nRP/0/0/CPU0:R2(config)#route-policy FILTER_64514_ROUTES\nRP/0/0/CPU0:R2(config-rpl)#if as-path originates-from '64514' then\nRP/0/0/CPU0:R2(config-rpl-if)#pass\nRP/0/0/CPU0:R2(config-rpl-if)#else\nRP/0/0/CPU0:R2(config-rpl-else)#drop\nRP/0/0/CPU0:R2(config-rpl-else)#endif \nRP/0/0/CPU0:R2(config-rpl)#end-policy \nRP/0/0/CPU0:R2(config)#route-policy FILTER_64516_ROUTES\nRP/0/0/CPU0:R2(config-rpl)#if as-path originates-from '64516' then\nRP/0/0/CPU0:R2(config-rpl-if)#pass\nRP/0/0/CPU0:R2(config-rpl-if)#else\nRP/0/0/CPU0:R2(config-rpl-else)#drop\nRP/0/0/CPU0:R2(config-rpl-else)#endif \nRP/0/0/CPU0:R2(config-rpl)#end-policy \n\nStep 2: Apply the appropriate inbound route policy with each peering CE router as shown in the example below.\n\nRP/0/0/CPU0:R2(config)#router bgp xx\nRP/0/0/CPU0:R2(config-bgp)#neighbor x.12.4.14\nRP/0/0/CPU0:R2(config-bgp-nbr)#address-family ipv4 unicast \nRP/0/0/CPU0:R2(config-bgp-nbr-af)#route-policy route-policy FILTER_64514_ROUTES in\nRP/0/0/CPU0:R2(config-bgp)#neighbor x.12.4.16\nRP/0/0/CPU0:R2(config-bgp-nbr)#address-family ipv4 unicast \nRP/0/0/CPU0:R2(config-bgp-nbr-af)#route-policy FILTER_64516_ROUTES in\nRP/0/0/CPU0:R2(config-bgp-nbr-af)#end","ccis":["CCI-000032"]},{"vulnId":"V-216784","ruleId":"SV-216784r856445_rule","severity":"medium","ruleTitle":"The Cisco BGP router must be configured to use the maximum prefixes feature to protect against route table flooding and prefix de-aggregation attacks.","description":"The effects of prefix de-aggregation can degrade router performance due to the size of routing tables and also result in black-holing legitimate traffic. Initiated by an attacker or a misconfigured router, prefix de-aggregation occurs when the announcement of a large prefix is fragmented into a collection of smaller prefix announcements.\n\nIn 1997, misconfigured routers 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 routers became overloaded and crashed repeatedly. This caused prefixes advertised by these routers to disappear from routing tables and reappear when the routers came back online. As the routers came back after crashing, they were flooded with the routing table information by their neighbors. The flood of information would again overwhelm the routers and cause them to crash. This process of route flapping served to destabilize not only the surrounding network but also the entire Internet. Routers 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.\n\nMaximum 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 routers 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.","checkContent":"Review the router configuration to verify that the number of received prefixes from each eBGP neighbor is controlled.\n\nrouter bgp xx\n address-family ipv4 unicast\n !\n neighbor x.1.23.3\n remote-as yy\n ttl-security\n address-family ipv4 unicast\n route-policy BGP_FILTER in\n maximum-prefix nnnn 75 discard-extra-paths\n !\n !\n neighbor x.1.24.4\n remote-as zz\n address-family ipv4 unicast\n route-policy BGP_FILTER in\n maximum-prefix nnnn 75 discard-extra-paths\n !\n !\n!\nIf the router is not configured to control the number of prefixes received from each peer to protect against route table flooding and prefix de-aggregation attacks, this is a finding.","fixText":"Configure the router to use the maximum prefixes feature to protect against route table flooding and prefix de-aggregation attacks as shown in the example below.\n\nRP/0/0/CPU0:R2(config)#router bgp xx\nRP/0/0/CPU0:R2(config-bgp)#neighbor x1.24.4\nRP/0/0/CPU0:R2(config-bgp-nbr)#address-family ipv4 unicast \nRP/0/0/CPU0:R2(config-bgp-nbr-af)#maximum-prefix 444 discard-extra-paths\nRP/0/0/CPU0:R2(config-bgp-nbr-af)#end","ccis":["CCI-002385"]},{"vulnId":"V-216785","ruleId":"SV-216785r856446_rule","severity":"low","ruleTitle":"The Cisco BGP router must be configured to limit the prefix size on any inbound route advertisement to /24 or the least significant prefixes issued to the customer.","description":"The effects of prefix de-aggregation can degrade router performance due to the size of routing tables and also result in black-holing legitimate traffic. Initiated by an attacker or a misconfigured router, prefix de-aggregation occurs when the announcement of a large prefix is fragmented into a collection of smaller prefix announcements.","checkContent":"This requirement is not applicable for the DODIN Backbone.\n\nReview the router configuration to determine if it is compliant with this requirement.\n\nStep 1: Verify that an inbound route policy has been configured for each CE router as shown in the example below.\n\nrouter bgp xx\n address-family ipv4 unicast\n !\n neighbor x.12.4.14\n remote-as 64514\n address-family ipv4 unicast\n route-policy FILTER_LONG_PREFIXES in\n !\n !\n neighbor x.12.4.16\n remote-as 64516\n address-family ipv4 unicast\n route-policy FILTER_LONG_PREFIXES in\n !\n\nStep 2: Verify that the route policy permits only routes from each CE router with a prefix length of 24 or shorter or the least significant prefixes issued to the customer as shown in the example below.\n\nroute-policy FILTER_LONG_PREFIXES\n if destination in PREFIX_LENGTH then\n pass\n else\n drop\n endif\nend-policy\n\nNote: The inbound route policy to filter customer prefixes can be nested with the above route policy as shown in the example below.\n\nroute-policy CUST1_INBOUND_FILTER\n apply CUST1_FILTER\n apply FILTER_64514_ROUTES\n apply FILTER_LONG_PREFIXES\nend-policy\n\nStep 3: Review the prefix set referenced in the route policy above to determine if it only allows a prefix length 24 or shorter.\n\nprefix-set PREFIX_LENGTH\n 0.0.0.0/0 ge 8 le 24\nend-set\n\nIf the router is not configured to limit the prefix size on any inbound route advertisement to /24 or the least significant prefixes issued to the customer, this is a finding.","fixText":"This requirement is not applicable for the DODIN Backbone.\n\nConfigure the router to limit the prefix size on any route advertisement to /24 or the least significant prefixes issued to the customer.\n\nStep 1: Configure a prefix set to not include prefixes are longer than /24.\n\nRP/0/0/CPU0:R2(config)#prefix-set PREFIX_LENGTH\nRP/0/0/CPU0:R2(config-pfx)#0.0.0.0/0 ge 8 le 24\nRP/0/0/CPU0:R2(config-pfx)#end-set\n\nStep 2: Configure a route policy to only accept prefixes that are /24 or shorter as shown in the example below.\n\nRP/0/0/CPU0:R2(config)#route-policy FILTER_LONG_PREFIXES\nRP/0/0/CPU0:R2(config-rpl)#if destination in PREFIX_LENGTH then\nRP/0/0/CPU0:R2(config-rpl-if)#pass\nRP/0/0/CPU0:R2(config-rpl-if)#else\nRP/0/0/CPU0:R2(config-rpl-else)#drop\nRP/0/0/CPU0:R2(config-rpl-else)#endif \nRP/0/0/CPU0:R2(config-rpl)#end-policy\n\nStep 3: Apply the route policy above inbound with each peering CE router as shown in the example below.\n\nRP/0/0/CPU0:R2(config)#router bgp xx\nRP/0/0/CPU0:R2(config-bgp)#neighbor x.12.4.14\nRP/0/0/CPU0:R2(config-bgp-nbr)#address-family ipv4 unicast \nRP/0/0/CPU0:R2(config-bgp-nbr-af)#route-policy route-policy FILTER_LONG_PREFIXES in\nRP/0/0/CPU0:R2(config-bgp)#neighbor x.12.4.16\nRP/0/0/CPU0:R2(config-bgp-nbr)#address-family ipv4 unicast \nRP/0/0/CPU0:R2(config-bgp-nbr-af)#route-policy FILTER_LONG_PREFIXES in\nRP/0/0/CPU0:R2(config-bgp-nbr-af)#end","ccis":["CCI-002385"]},{"vulnId":"V-216786","ruleId":"SV-216786r991935_rule","severity":"low","ruleTitle":"The Cisco BGP router must be configured to use its loopback address as the source address for iBGP peering sessions.","description":"Using a loopback address as the source address offers a multitude of uses for security, access, management, and scalability of the BGP routers. It is easier to construct appropriate ingress filters for router 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 router’s loopback address instead of the numerous physical interface addresses.\n\nWhen 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 routers within the iBGP domain should also use loopback addresses as the source address when establishing BGP sessions.","checkContent":"Step 1: Review the router configuration to verify that a loopback address has been configured.\n\ninterface Loopback0\n ip address 10.1.1.1 255.255.255.255\n\nStep 2: Verify that the loopback interface is used as the source address for all iBGP sessions.\n\nrouter bgp xx\n address-family ipv4 unicast\n !\n neighbor 10.1.23.3\n remote-as xx\n update-source Loopback0\n \nIf the router does not use its loopback address as the source address for all iBGP sessions, this is a finding.","fixText":"Configure the router to use its loopback address as the source address for all iBGP peering.\n\nRP/0/0/CPU0:R2(config)#router bgp 2\nRP/0/0/CPU0:R2(config-bgp)#neighbor 10.1.24.4\nRP/0/0/CPU0:R2(config-bgp-nbr)#update-source lo0\nRP/0/0/CPU0:R2(config-bgp-nbr)#end","ccis":["CCI-004931"]},{"vulnId":"V-216787","ruleId":"SV-216787r991936_rule","severity":"low","ruleTitle":"The Cisco MPLS router must be configured to use its loopback address as the source address for LDP peering sessions.","description":"Using a loopback address as the source address offers a multitude of uses for security, access, management, and scalability of backbone routers. It is easier to construct appropriate ingress filters for router 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 router's loopback address instead of the numerous physical interface addresses.","checkContent":"Review the router configuration to determine if it is compliant with this requirement.\n\nVerify that a loopback address has been configured as shown in the following example:\n\ninterface Loopback0\n ip address 10.1.1.1 255.255.255.255\n\nBy default, routers will use its loopback address for LDP peering. If an address has not be configured on the loopback interface, it will use its physical interface connecting to the LDP peer. If the router-id command is specified that overrides this default behavior, verify that it is the IP address of the designated loopback interface as shown in the example below.\n\nmpls ldp\n router-id 10.1.1.1\n\nIf the router is not configured do use its loopback address for LDP peering, this is a finding.","fixText":"Configure the router to use their loopback address as the source address for LDP peering sessions. As noted in the check content, the default behavior is to use its loopback address. \n\nRP/0/0/CPU0:R3(config)#mpls ldp router-id 10.1.1.1","ccis":["CCI-004931"]},{"vulnId":"V-216788","ruleId":"SV-216788r531087_rule","severity":"low","ruleTitle":"The Cisco MPLS router must be configured to synchronize IGP and LDP to minimize packet loss when an IGP adjacency is established prior to LDP peers completing label exchange.","description":"Packet loss can occur when an IGP adjacency is established and the router 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 router 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.","checkContent":"OSPF Example\n\nrouter ospf 1\n mpls ldp sync\n\nIS-IS Example\n\nrouter isis 1\n net 49.0001.1234.1600.5531.00\n interface GigabitEthernet0/0/0/1\n address-family ipv4 unicast\n mpls ldp sync\n\nIf the router is not configured to synchronize IGP and LDP, this is a finding.","fixText":"Configure the MPLS router to synchronize IGP and LDP, minimizing packet loss when an IGP adjacency is established prior to LDP peers completing label exchange.\n\nOSPF Example\n\nRP/0/0/CPU0:R3(config)#router ospf 1\nRP/0/0/CPU0:R3(config-ospf)#mpls ldp sync\nRP/0/0/CPU0:R3(config-ospf)#end\n\nIS-IS Example\n\nRP/0/0/CPU0:R3(config)#router isis 1\nRP/0/0/CPU0:R3(config-isis)#interface g0/0/0/1\nRP/0/0/CPU0:R3(config-isis-if)#address-family ipv4 unicast \nRP/0/0/CPU0:R3(config-isis-if-af)#mpls ldp sync \nRP/0/0/CPU0:R3(config-isis-if-af)#end","ccis":["CCI-000366"]},{"vulnId":"V-216789","ruleId":"SV-216789r531087_rule","severity":"low","ruleTitle":"The MPLS router 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 routers.","description":"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 router 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.\n\nWhen RSVP messages are sent out, they are sent either hop by hop or with the router alert bit set in the IP header. This means that every router 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.","checkContent":"Review the router configuration to determine RSVP messages are rate limited.\n\nStep 1: Determine if MPLS TE is enabled on any interface as shown in the example below.\n\nmpls traffic-eng\n interface GigabitEthernet0/0/0/1\n \nStep 2: If MPLS TE is enabled, verify that RSVP messages are rate limited on each interface. The example allows 50 messages per 500 milliseconds.\n\nrsvp\n interface GigabitEthernet0/0/0/1\n signaling rate-limit rate 50 interval 500\n\nNote: The command rsvp msg-pacing has been deprecated by the command ip rsvp signaling rate-limit command.\n\nIf the router with RSVP-TE enabled does not have message pacing configured based on the link speed and input queue size of adjacent core routers, this is a finding.","fixText":"Configure the router to rate limit RSVP messages as shown in the example.\n\nRP/0/0/CPU0:R3(config)#rsvp interface g0/0/0/1\nRP/0/0/CPU0:R3(config-rsvp-if)#signaling rate-limit rate 50 interval 500\nRP/0/0/CPU0:R3(config-rsvp-if)#end","ccis":["CCI-001095"]},{"vulnId":"V-216790","ruleId":"SV-216790r531087_rule","severity":"medium","ruleTitle":"The Cisco MPLS router must be configured to have TTL Propagation disabled.","description":"The head end of the label-switched path (LSP), the label edge router (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 router (LSR) hop, the MPLS TTL value is decremented by one. The MPLS router 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.\n\nThis 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.","checkContent":"Review the router configuration to verify that TTL propagation is disabled as shown in the example below.\n\nmpls ip-ttl-propagate disable\n\nIf the MPLS router is not configured to disable TTL propagation, this is a finding.","fixText":"Configure the MPLS router to disable TTL propagation as shown in the example below.\n\nRP/0/0/CPU0:R3(config)#mpls ip-ttl-propagate disable","ccis":["CCI-000366"]},{"vulnId":"V-216791","ruleId":"SV-216791r991937_rule","severity":"high","ruleTitle":"The Cisco PE router 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.","description":"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.","checkContent":"Step 1: Review the design plan for deploying L3VPN and VRF-lite. \n\nStep 2: Review the design plan for deploying L3VPN and VRF-lite. Review all CE-facing interfaces and verify that the proper VRF is defined via the ip vrf forwarding command. In the example below, COI1 is bound to interface GigabitEthernet0/0/0/1, while COI2 is bound to GigabitEthernet0/0/0/2.\n\ninterface GigabitEthernet0/0/0/1\ndescription link to COI1\n vrf COI1\n ipv4 address x.1.34.12 255.255.255.252\n!\ninterface GigabitEthernet0/0/0/2\n description link to COI2\n vrf COI2\n ipv4 address x.1.22.12 255.255.255.252\n\nIf any VRFs are not bound to the appropriate physical or logical interface, this is a finding.","fixText":"Configure the PE router to have each VRF bound to the appropriate physical or logical interfaces to maintain traffic separation between all MPLS L3VPNs.","ccis":["CCI-004931"]},{"vulnId":"V-216792","ruleId":"SV-216792r991939_rule","severity":"high","ruleTitle":"The Cisco PE router must be configured to have each Virtual Routing and Forwarding (VRF) instance with the appropriate Route Target (RT).","description":"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.","checkContent":"Review the design plan for MPLS/L3VPN and VRF-lite to determine what RTs have been assigned for each VRF. Review the router configuration and verify that the correct RT is configured for each VRF. In the example below, route target 13:13 has been configured for COI1.\n\nvrf COI1\n address-family ipv4 unicast\n import route-target\n 13:13\n !\n export route-target\n 13:13\n !\n !\n!\n\nIf there are VRFs configured with the wrong RT, this is a finding.","fixText":"Configure the router to have each VRF instance defined with the correct RT.\n\nRP/0/0/CPU0:R3(config)#vrf COI1\nRP/0/0/CPU0:R3(config-vrf)#address-family ipv4 unicast \nRP/0/0/CPU0:R3(config-vrf-af)#import route-target 13:13\nRP/0/0/CPU0:R3(config-vrf-af)#export route-target 13:13\nRP/0/0/CPU0:R3(config-vrf-af)#end","ccis":["CCI-004931"]},{"vulnId":"V-216793","ruleId":"SV-216793r991940_rule","severity":"medium","ruleTitle":"The Cisco PE router must be configured to have each VRF with the appropriate Route Distinguisher (RD).","description":"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.\n\nSince 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 router, 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.","checkContent":"Review the design plan for MPLS/L3VPN to determine what RD have been assigned for each VRF. Review the router configuration and verify that the correct RD is configured for each VRF. In the example below, route distinguisher 13:13 has been configured for COI1.\n\nrouter bgp nn\n address-family ipv4 unicast\n !\n address-family vpnv4 unicast\n !\n …\n …\n …\n !\n vrf COI1\n rd 13:13\n address-family ipv4 unicast\n redistribute ospf 1\n !\n !\n!\n\nNote: This requirement is only applicable for MPLS VPN implementations.\n\nIf the wrong RD has been configured for any VRF, this is a finding.","fixText":"Configure the correct RD for each VRF.\n\nRP/0/0/CPU0:R3(config)#router bgp nn\nRP/0/0/CPU0:R3(config-bgp)#vrf COI1\nRP/0/0/CPU0:R3(config-bgp-vrf)#rd 13:13","ccis":["CCI-004931"]},{"vulnId":"V-216794","ruleId":"SV-216794r878124_rule","severity":"medium","ruleTitle":"The Cisco PE router 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.","description":"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 router advertises a virtual circuit label mapping that is used as part of the label stack imposed on the frames by the ingress PE router during packet forwarding. Authentication provides protection against spoofed TCP segments that can be introduced into the LDP sessions.","checkContent":"The Cisco router is not compliant with this requirement; hence, it is a finding. However, the severity level can be downgraded to a category 3 if the router is configured to authenticate targeted LDP sessions using MD5 as shown in the configuration example below.\n\nmpls ldp\nrouter-id 10.1.1.2\nneighbor 10.1.1.1\n password encrypted xxxxxxxxxxxxxxx\nneighbor 10.1.2.1\n password encrypted xxxxxxxxxxxxxxx\n\nIf the router is not configured to authenticate targeted LDP sessions using MD5, the finding will remain as a CAT II.","fixText":"The severity level can be downgraded to a category 3 if the router is configured to authenticate targeted LDP sessions using MD5 as shown in the example below.\n\nRP/0/0/CPU0:R3(config)#mpls ldp\nRP/0/0/CPU0:R3(config-ldp)#neighbor 10.1.1.1\nRP/0/0/CPU0:R3(config-ldp)#neighbor password clear xxxxxxxx\nRP/0/0/CPU0:R3(config-ldp)#neighbor 10.1.2.1\nRP/0/0/CPU0:R3(config-ldp)#neighbor password clear xxxxxxxx\nRP/0/0/CPU0:R3(config-ldp)#commit","ccis":["CCI-001958"]},{"vulnId":"V-216795","ruleId":"SV-216795r991942_rule","severity":"high","ruleTitle":"The Cisco PE router providing MPLS Virtual Private Wire Service (VPWS) must be configured to have the appropriate pseudowire ID for each attachment circuit.","description":"VPWS is an L2VPN technology that provides a virtual circuit (aka pseudowire) between two PE routers to forward Layer 2 frames between two customer-edge routers or switches through an MPLS-enabled IP core. The ingress PE router (virtual circuit head-end) encapsulates Ethernet frames inside MPLS packets using label stacking and forwards them across the MPLS network to the egress PE router (virtual circuit tail-end). During a virtual circuit setup, the PE routers exchange label bindings for the specified pseudowire ID. The pseudowire ID specifies a pseudowire associated with an ingress and egress PE router and the customer-facing attachment circuits. \n\nTo guarantee that all frames are forwarded onto the correct pseudowire and to the correct customer and attachment circuits, it is imperative that the correct pseudowire ID is configured for each attachment circuit.","checkContent":"Verify that the correct pseudowire ID has been configured for the appropriate attachment circuit. In the example below GigabitEthernet0/0/0/1 is the CE-facing interface that is configured for VPWS.\n\nl2vpn\n pw-class ETHOM\n encapsulation mpls\n !\n !\n xconnect group COI1\n p2p COI1-S1-S2\n interface GigabitEthernet0/0/0/1\n neighbor ipv4 10.1.12.4 pw-id 55\n pw-class ETHOM\n !\n !\n !\n!\n\nIf the correct pseudowire ID has not been configured on both routers, this is a finding.","fixText":"Assign globally unique pseudowire IDs for each virtual circuit and configure the attachment circuits with the appropriate pseudowire ID.\n\nRP/0/0/CPU0:R3(config)#l2vpn\nRP/0/0/CPU0:R3(config-l2vpn)#xconnect group COI1 \nRP/0/0/CPU0:R3(config-l2vpn-xc)#p2p COI1-S1-S2\nRP/0/0/CPU0:R3(config-l2vpn-xc-p2p)#interface g0/0/0/1\nRP/0/0/CPU0:R3(config-l2vpn-xc-p2p)#neighbor 10.1.12.4 pw-id 55","ccis":["CCI-004931"]},{"vulnId":"V-216796","ruleId":"SV-216796r531087_rule","severity":"high","ruleTitle":"The Cisco PE router 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.","description":"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 routers). A pseudowire contains two unidirectional label-switched paths (LSP) between two PE routers. 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.\n\nThe VFI specifies the pseudowires associated with connecting PE routers 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 routers. 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.","checkContent":"Review the implementation plan and the VPN IDs assigned to customer VLANs for the VPLS deployment.\n\nReview the PE router configuration to verify that customer attachment circuits are associated to the appropriate VFI. In the example below, the attached circuit at interface GigabitEthernet0/0/0/2 is associated to VPN ID 110.\n\ninterface GigabitEthernet0/0/0/2\n l2transport\n…\n…\n…\nl2vpn\n pw-class ETH_O_MPLS\n encapsulation mpls\n transport-mode ethernet\n !\n !\n bridge group L2GROUP\n bridge-domain L2_BRIDGE_COI1\n interface GigabitEthernet0/0/0/2\n !\n vfi VFI_COI1\n vpn-id 101\n neighbor 10.1.1.1 pw-id 55\n pw-class ETH_O_MPLS\n !\n neighbor 10.2.2.2 pw-id 55\n pw-class ETH_O_MPLS\n !\n !\n !\n !\n\nIf the attachment circuits have not been bound to VFI configured with the assigned VPN ID for each VLAN, this is a finding.","fixText":"Assign globally unique VPN IDs for each customer using VPLS for carrier Ethernet services between multiple sites, and configure the attachment circuits to the appropriate VFI.\n\nRP/0/0/CPU0:R3(config)#l2vpn\nRP/0/0/CPU0:R3(config-l2vpn)#bridge group L2GROUP\nRP/0/0/CPU0:R3(config-l2vpn-bg)#bridge-domain L2_BRIDGE_COI1\nRP/0/0/CPU0:R3(config-l2vpn-bg-bd)#interface GigabitEthernet0/0/0/2\nRP/0/0/CPU0:R3(config-l2vpn-bg-bd-ac)#exit\nRP/0/0/CPU0:R3(config-l2vpn-bg-bd)#vfi VFI_COI1\nRP/0/0/CPU0:R3(config-l2vpn-bg-bd-vfi)#vpn-id 101","ccis":["CCI-000366"]},{"vulnId":"V-216797","ruleId":"SV-216797r531087_rule","severity":"low","ruleTitle":"The Cisco PE router must be configured to enforce the split-horizon rule for all pseudowires within a Virtual Private LAN Services (VPLS) bridge domain.","description":"A virtual forwarding instance (VFI) must be created on each participating PE router for each customer VLAN using VPLS for carrier Ethernet services. The VFI specifies the VPN ID of a VPLS domain, the addresses of other PE routers in the domain, and the type of tunnel signaling and encapsulation mechanism for each peer PE router. The set of VFIs formed by the interconnection of the emulated VCs is called a VPLS instance, which forms the logic bridge over the MPLS core network.\n\nThe PE routers use the VFI with a unique VPN ID to establish a full mesh of emulated virtual circuits or pseudowires to all the other PE routers in the VPLS instance. The full-mesh configuration allows the PE router to maintain a single broadcast domain. With a full-mesh configuration, signaling and packet replication requirements for each provisioned virtual circuit on a PE can be high. To avoid the problem of a packet looping in the provider core, thereby adding more overhead, the PE devices must enforce a split-horizon principle for the emulated virtual circuits; that is, if a packet is received on an emulated virtual circuit, it is not forwarded on any other virtual circuit.","checkContent":"Review the PE router configuration to verify that split horizon is enabled at each attachment circuit within each bridge domain as shown in the example below.\n\nbridge group L2GROUP\n bridge-domain L2_BRIDGE_COI1\n interface GigabitEthernet0/0/0/2\n split-horizon group\n !\n\nIf split horizon is not enabled, this is a finding.\n\nNote: This requirement is only applicable to a mesh VPLS topology. VPLS solves the loop problem by using a split-horizon rule which states that member PE routers of a VPLS must forward VPLS traffic only to the local attachment circuits when they receive the traffic from the other PE routers. In a ring VPLS, split horizon must be disabled so that a PE router can forward a packet received from one pseudowire to another pseudowire. To prevent the consequential loop, at least one span in the ring would not have a pseudowire for any given VPLS instance.","fixText":"Enable split horizon on all PE routers deploying VPLS in a full-mesh configuration.\n\nRP/0/0/CPU0:R3(config)#l2vpn\nRP/0/0/CPU0:R3(config-l2vpn)#bridge group L2GROUP\nRP/0/0/CPU0:R3(config-l2vpn-bg)#bridge-domain L2_BRIDGE_COI1\nRP/0/0/CPU0:R3(config-l2vpn-bg-bd)#interface GigabitEthernet0/0/0/2\nRP/0/0/CPU0:R3(config-l2vpn-bg-bd-ac)#split-horizon group \nRP/0/0/CPU0:R3(config-l2vpn-bg-bd-ac)#end","ccis":["CCI-000366"]},{"vulnId":"V-216798","ruleId":"SV-216798r531087_rule","severity":"medium","ruleTitle":"The Cisco PE router providing Virtual Private LAN Services (VPLS) must be configured to have traffic storm control thresholds on CE-facing interfaces.","description":"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.","checkContent":"Review the router configuration to verify that storm control is enabled on CE-facing interfaces deploying VPLS as shown in the example below.\n\nbridge group L2GROUP\n bridge-domain L2_BRIDGE_COI1\n interface GigabitEthernet0/0/0/2\n storm-control unknown-unicast kbps 1200\n storm-control multicast kbps 1200\n storm-control broadcast kbps 1200\n split-horizon group\n !\n\nIf storm control is not enabled at a minimum for broadcast traffic, this is a finding.","fixText":"Configure storm control for each CE-facing interface as shown in the example below.\n\nRP/0/0/CPU0:R3(config)#l2vpn\nRP/0/0/CPU0:R3(config-l2vpn)#bridge group L2GROUP\nRP/0/0/CPU0:R3(config-l2vpn-bg)# bridge-domain L2_BRIDGE_COI1\nRP/0/0/CPU0:R3(config-l2vpn-bg-bd)#interface GigabitEthernet0/0/0/2\nRP/0/0/CPU0:R3(config-l2vpn-bg-bd-ac)#storm-control broadcast kbps 1200\nRP/0/0/CPU0:R3(config-l2vpn-bg-bd-ac)#storm-control multicast kbps 1200\nRP/0/0/CPU0:R3(config-l2vpn-bg-bd-ac)#storm-control unknown-unicast kbps 1200\nRP/0/0/CPU0:R3(config-l2vpn-bg-bd-ac)#end\n\nNote: The acceptable range is 10000000 -1000000000 for a gigabit ethernet interface, and 100000000-10000000000 for a ten gigabit interface. Storm control is not supported on most FastEthernet interfaces.","ccis":["CCI-001095"]},{"vulnId":"V-216799","ruleId":"SV-216799r856448_rule","severity":"low","ruleTitle":"The Cisco PE router 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.","description":"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.","checkContent":"Review the router configuration to verify that IGMP or MLD snooping has been configured for IPv4 and IPv6 multicast traffic respectively for each VPLS bridge domain. \n\nl2vpn\n bridge group L2GROUP\n bridge-domain L2_BRIDGE_COI1\n interface GigabitEthernet0/0/0/2\n igmp snooping profile default\n\nIf the router is not configured to implement IGMP or MLD snooping for each VPLS bridge domain, this is a finding.","fixText":"Configure IGMP or MLD snooping for IPv4 and IPv6 multicast traffic respectively for each VPLS bridge domain.\n\nRP/0/0/CPU0:R3(config)#l2vpn\nRP/0/0/CPU0:R3(config-l2vpn)#bridge group L2GROUP\nRP/0/0/CPU0:R3(config-l2vpn-bg)# bridge-domain L2_BRIDGE_COI1\nRP/0/0/CPU0:R3(config-l2vpn-bg-bd)#interface GigabitEthernet0/0/0/2\nRP/0/0/CPU0:R3(config-l2vpn-bg-bd-ac)#igmp snooping profile default\nRP/0/0/CPU0:R3(config-l2vpn-bg-bd-ac)#end","ccis":["CCI-002385"]},{"vulnId":"V-216800","ruleId":"SV-216800r531087_rule","severity":"medium","ruleTitle":"The Cisco PE router must be configured to limit the number of MAC addresses it can learn for each Virtual Private LAN Services (VPLS) bridge domain.","description":"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 routers). 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.\n\nWhen a frame arrives on a bridge port (pseudowire or attachment circuit) and the source MAC address is unknown to the receiving PE router, 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 router must replicate packets across both attachment circuits and pseudowires.\n\nA 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 router 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.","checkContent":"Review the PE router configuration to determine if a MAC address limit has been set for each VPLS bridge domain.\n\nbridge group L2GROUP\n bridge-domain L2_BRIDGE_COI1\n interface GigabitEthernet0/0/0/2\n mac\n limit\n maximum nnnn\n !\n !\n\nIf a limit has not been configured, this is a finding.","fixText":"Configure a MAC address learning limit for each VPLS bridge domain.\n\nRP/0/0/CPU0:R3(config)#l2vpn\nRP/0/0/CPU0:R3(config-l2vpn)#bridge group L2GROUP\nRP/0/0/CPU0:R3(config-l2vpn-bg)#bridge-domain L2_BRIDGE_COI1\nRP/0/0/CPU0:R3(config-l2vpn-bg-bd)#interface GigabitEthernet0/0/0/2\nRP/0/0/CPU0:R3(config-l2vpn-bg-bd-ac)#mac limit maximum nnn\nRP/0/0/CPU0:R3(config-l2vpn-bg-bd-ac)#end","ccis":["CCI-001094"]},{"vulnId":"V-216801","ruleId":"SV-216801r531087_rule","severity":"high","ruleTitle":"The Cisco PE router must be configured to block any traffic that is destined to IP core infrastructure.","description":"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.\n\nIP 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 routers at the edge deny traffic destined to any address belonging to the IP core infrastructure.","checkContent":"Step 1: Review the router configuration to verify that an ingress ACL is applied to all external or CE-facing interfaces. \n\ninterface GigabitEthernet1/1/0/0\n ipv4 address x.1.12.2 255.255.255.252\n ipv4 access-group BLOCK_TO_CORE ingress\n\nStep 2: Verify that the ingress ACL discards and logs packets destined to the IP core address space. \n\nIpv4 access-list BLOCK_TO_CORE\n 10 deny ipv4 any 10.1.x.0 0.0.255.255 log-input\n 20 permit ipv4 any any\n!\n\nIf the PE router is not configured to block any traffic with a destination address assigned to the IP core infrastructure, this is a finding.\n\nNote: Internet Control Message Protocol (ICMP) echo requests and traceroutes will be allowed to the edge from external adjacent neighbors.","fixText":"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.\n\nStep 1: Configure an ingress ACL to discard and log packets destined to the IP core address space. \n\nRP/0/0/CPU0:R3(config)#Ipv4 access-list BLOCK_TO_CORE\nRP/0/0/CPU0:R3(config-ipv4-acl)#deny tcp any any eq tacacs log-input\nRP/0/0/CPU0:R3(config-ipv4-acl)#deny ipv4 any 10.1.x.0 0.0.255.255 log-input\nRP/0/0/CPU0:R3(config-ipv4-acl)#end\n\nStep 2: Apply the ACL inbound to all external or CE-facing interfaces.\n\nRP/0/0/CPU0:R3(config)#int g1/1/0/0\nRP/0/0/CPU0:R3(config-if)#ipv4 access-group BLOCK_TO_CORE in\nRP/0/0/CPU0:R3(config-if)#end","ccis":["CCI-001097"]},{"vulnId":"V-216802","ruleId":"SV-216802r531087_rule","severity":"medium","ruleTitle":"The Cisco PE router must be configured with Unicast Reverse Path Forwarding (uRPF) loose mode enabled on all CE-facing interfaces.","description":"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 routers must enable uRPF loose mode to guarantee that all packets received from a CE router contain source addresses that are in the route table.","checkContent":"Review the router configuration to determine if uRPF loose mode is enabled on all CE-facing interfaces.\n\ninterface GigabitEthernet1/1/0/0\n ip address x.1.12.2 255.255.255.252\n ipv4 verify unicast source reachable-via any\n\nIf uRPF loose mode is not enabled on all CE-facing interfaces, this is a finding.","fixText":"Configure uRPF loose mode on all CE-facing interfaces as shown in the example\n\nRP/0/0/CPU0:R3(config)#int g1/1/0/0\nRP/0/0/CPU0:R3(config-if)#ipv4 verify unicast source reachable-via any","ccis":["CCI-001097"]},{"vulnId":"V-216804","ruleId":"SV-216804r917439_rule","severity":"low","ruleTitle":"The Cisco PE router must be configured to enforce a Quality-of-Service (QoS) policy to provide preferred treatment for mission-critical applications.","description":"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.\n\nPacket 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.","checkContent":"Review the router configuration and verify that a QoS policy has been configured to provide preferred treatment for mission-critical applications.\n\nStep 1: Verify that the class-maps are configured to match on DSCP values as shown in the configuration example below.\n\nclass-map match-all VIDEO\n match dscp af41 \n end-class-map\n! \nclass-map match-all VOICE\n match dscp ef \n end-class-map\n! \nclass-map match-all C2_VOICE\n match dscp 47 \n end-class-map\n! \nclass-map match-all CONTROL_PLANE\n match dscp cs6 \n end-class-map\n! \nclass-map match-all PREFERRED_DATA\n match dscp af33 \n end-class-map\n!\n\nStep 2: Verify that the policy map reserves the bandwidth for each traffic type as shown in the following example:\n\npolicy-map QOS_POLICY\n class C2_VOICE\n bandwidth percent 10 \n ! \n class VOICE\n bandwidth percent 15 \n ! \n class VIDEO\n bandwidth percent 25 \n ! \n class CONTROL_PLANE\n bandwidth percent 10 \n ! \n class PREFERRED_DATA\n bandwidth percent 25 \n ! \n class class-default\n bandwidth percent 15 \n ! \n end-policy-map\n!\n\nStep 3: Verify that an output service policy is bound to all interface as shown in the configuration example below.\n\ninterface GigabitEthernet0/0/0/1\n service-policy output QOS_POLICY\n ipv4 address x.1.24.2 255.255.255.252\n!\ninterface GigabitEthernet0/0/0/2\n service-policy output QOS_POLICY\nipv4 address x.1.24.5 255.255.255.252\n\nNote: 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.\n\nIf the router is not configured to enforce a QoS policy in accordance with the QoS DODIN Technical Profile, this is a finding.","fixText":"Configure to enforce a QoS policy to provide preferred treatment for mission-critical applications.\n\nStep 1: Configure class-maps to match on DSCP values as shown in the configuration example below.\n\nRP/0/0/CPU0:R2(config-cmap)#class-map match-all C2_VOICE\nRP/0/0/CPU0:R2(config-cmap)#match dscp 47\nRP/0/0/CPU0:R2(config-cmap)#class-map match-all VOICE\nRP/0/0/CPU0:R2(config-cmap)#match dscp ef\nRP/0/0/CPU0:R2(config-cmap)#class-map match-all VIDEO\nRP/0/0/CPU0:R2(config-cmap)#match dscp af41\nRP/0/0/CPU0:R2(config-cmap)#class-map match-all CONTROL_PLANE\nRP/0/0/CPU0:R2(config-cmap)#match dscp cs6\nRP/0/0/CPU0:R2(config-cmap)#class-map match-all PREFERRED_DATA\nRP/0/0/CPU0:R2(config-cmap)#match dscp af33\nRP/0/0/CPU0:R2(config-cmap)#exit\n\nStep 2: Configure a policy map to be applied to the core-layer-facing interface that reserves the bandwidth for each traffic type as shown in the example below.\n\nRP/0/0/CPU0:R2(config-pmap)#policy-map QOS_POLICY\nRP/0/0/CPU0:R2(config-pmap)#class C2_VOICE\nRP/0/0/CPU0:R2(config-pmap-c)#bandwidth percent 10\nRP/0/0/CPU0:R2(config-pmap-c)#class VOICE\nRP/0/0/CPU0:R2(config-pmap-c)#bandwidth percent 15\nRP/0/0/CPU0:R2(config-pmap-c)#class VIDEO\nRP/0/0/CPU0:R2(config-pmap-c)#bandwidth percent 25\nRP/0/0/CPU0:R2(config-pmap-c)#class CONTROL_PLANE\nRP/0/0/CPU0:R2(config-pmap-c)#bandwidth percent 10\nRP/0/0/CPU0:R2(config-pmap-c)#class PREFERRED_DATA\nRP/0/0/CPU0:R2(config-pmap-c)#bandwidth percent 25\nRP/0/0/CPU0:R2(config-pmap-c)#class class-default\nRP/0/0/CPU0:R2(config-pmap-c)#bandwidth percent 15\nRP/0/0/CPU0:R2(config-pmap-c)#exit\n\nStep 3: Apply the output service policy to the core-layer-facing interface as shown in the configuration example below.\n\nRP/0/0/CPU0:R2(config)#int g0/0/0/1\nRP/0/0/CPU0:R2(config-if)#service-policy output QOS_POLICY \nRP/0/0/CPU0:R2(config-if)#exit\nRP/0/0/CPU0:R2(config)#int g0/0/0/2 \nRP/0/0/CPU0:R2(config-if)#service-policy output QOS_POLICY \nRP/0/0/CPU0:R2(config-if)#end","ccis":["CCI-001095"]},{"vulnId":"V-216805","ruleId":"SV-216805r917442_rule","severity":"low","ruleTitle":"The Cisco P router must be configured to enforce a Quality-of-Service (QoS) policy to provide preferred treatment for mission-critical applications.","description":"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.\n\nPacket 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.","checkContent":"Review the router configuration and verify that a QoS policy has been configured to provide preferred treatment for mission-critical applications.\n\nStep 1: Verify that the class-maps are configured to match on DSCP values as shown in the configuration example below.\n\nclass-map match-all VIDEO\n match dscp af41 \n end-class-map\n! \nclass-map match-all VOICE\n match dscp ef \n end-class-map\n! \nclass-map match-all C2_VOICE\n match dscp 47 \n end-class-map\n! \nclass-map match-all CONTROL_PLANE\n match dscp cs6 \n end-class-map\n! \nclass-map match-all PREFERRED_DATA\n match dscp af33 \n end-class-map\n!\n\nStep 2: Verify that the policy map reserves the bandwidth for each traffic type as shown in the following example:\n\npolicy-map QOS_POLICY\n class C2_VOICE\n bandwidth percent 10 \n ! \n class VOICE\n bandwidth percent 15 \n ! \n class VIDEO\n bandwidth percent 25 \n ! \n class CONTROL_PLANE\n bandwidth percent 10 \n ! \n class PREFERRED_DATA\n bandwidth percent 25 \n ! \n class class-default\n bandwidth percent 15 \n ! \n end-policy-map\n!\n\nStep 3: Verify that an output service policy is bound to all interfaces as shown in the configuration example below.\n\ninterface GigabitEthernet0/0/0/1\n service-policy output QOS_POLICY\n ipv4 address x.1.24.2 255.255.255.252\n!\ninterface GigabitEthernet0/0/0/2\n service-policy output QOS_POLICY\nipv4 address x.1.24.5 255.255.255.252\n\nNote: 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.\n\nIf the router is not configured to enforce a QoS policy in accordance with the QoS DODIN Technical Profile, this is a finding.","fixText":"Configure to enforce a QoS policy to provide preferred treatment for mission-critical applications.\n\nStep 1: Configure class-maps to match on DSCP values as shown in the configuration example below.\n\nRP/0/0/CPU0:R2(config-cmap)#class-map match-all C2_VOICE\nRP/0/0/CPU0:R2(config-cmap)#match dscp 47\nRP/0/0/CPU0:R2(config-cmap)#class-map match-all VOICE\nRP/0/0/CPU0:R2(config-cmap)#match dscp ef\nRP/0/0/CPU0:R2(config-cmap)#class-map match-all VIDEO\nRP/0/0/CPU0:R2(config-cmap)#match dscp af41\nRP/0/0/CPU0:R2(config-cmap)#class-map match-all CONTROL_PLANE\nRP/0/0/CPU0:R2(config-cmap)#match dscp cs6\nRP/0/0/CPU0:R2(config-cmap)#class-map match-all PREFERRED_DATA\nRP/0/0/CPU0:R2(config-cmap)#match dscp af33\nRP/0/0/CPU0:R2(config-cmap)#exit\n\nStep 2: Configure a policy map to be applied to the core-layer-facing interface that reserves the bandwidth for each traffic type as shown in the example below.\n\nRP/0/0/CPU0:R2(config-pmap)#policy-map QOS_POLICY\nRP/0/0/CPU0:R2(config-pmap)#class C2_VOICE\nRP/0/0/CPU0:R2(config-pmap-c)#bandwidth percent 10\nRP/0/0/CPU0:R2(config-pmap-c)#class VOICE\nRP/0/0/CPU0:R2(config-pmap-c)#bandwidth percent 15\nRP/0/0/CPU0:R2(config-pmap-c)#class VIDEO\nRP/0/0/CPU0:R2(config-pmap-c)#bandwidth percent 25\nRP/0/0/CPU0:R2(config-pmap-c)#class CONTROL_PLANE\nRP/0/0/CPU0:R2(config-pmap-c)#bandwidth percent 10\nRP/0/0/CPU0:R2(config-pmap-c)#class PREFERRED_DATA\nRP/0/0/CPU0:R2(config-pmap-c)#bandwidth percent 25\nRP/0/0/CPU0:R2(config-pmap-c)#class class-default\nRP/0/0/CPU0:R2(config-pmap-c)#bandwidth percent 15\nRP/0/0/CPU0:R2(config-pmap-c)#exit\n\nStep 3: Apply the output service policy to the core-layer-facing interface as shown in the configuration example below.\n\nRP/0/0/CPU0:R2(config)#int g0/0/0/1\nRP/0/0/CPU0:R2(config-if)#service-policy output QOS_POLICY \nRP/0/0/CPU0:R2(config-if)#exit\nRP/0/0/CPU0:R2(config)#int g0/0/0/2 \nRP/0/0/CPU0:R2(config-if)#service-policy output QOS_POLICY \nRP/0/0/CPU0:R2(config-if)#end","ccis":["CCI-001095"]},{"vulnId":"V-216806","ruleId":"SV-216806r531087_rule","severity":"medium","ruleTitle":"The Cisco PE router must be configured to enforce a Quality-of-Service (QoS) policy to limit the effects of packet flooding denial-of-service (DoS) attacks.","description":"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. \n\nMeasures 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).","checkContent":"Step 1: Verify that a class map has been configured for the Scavenger class as shown in the example below.\n\nclass-map match-all SCAVENGER\n match dscp cs1 \n end-class-map\n\nStep 2: Verify that the policy map includes the SCAVENGER class with low priority as shown in the following example below. \n\npolicy-map QOS_POLICY\n class C2_VOICE\n bandwidth percent 10 \n ! \n class VOICE\n bandwidth percent 15 \n ! \n class VIDEO\n bandwidth percent 25 \n ! \n class CONTROL_PLANE\n bandwidth percent 10 \n ! \n class PREFERRED_DATA\n bandwidth percent 25 \n ! \n class SCAVENGER\n bandwidth percent 5 \n ! \n class class-default\n bandwidth percent 10 \n ! \n end-policy-map\n\nNote: Traffic out of profile must be marked at the customer access layer or CE egress edge.\n\nIf the policy map does not include the SCAVENGER class with low priority, this is a finding.","fixText":"Step 1: Configure a class map for the SCAVENGER class.\n\nRP/0/0/CPU0:R2(config)#class-map match-all SCAVENGER\nRP/0/0/CPU0:R2(config-cmap)#match dscp cs1\nRP/0/0/CPU0:R2(config-cmap)#exit\n\nStep 2: Add the SCAVENGER class to the policy map as shown in the example below.\n\nRP/0/0/CPU0:R2(config)#policy-map QOS_POLICY\nRP/0/0/CPU0:R2(config-pmap)#no class class-default\nRP/0/0/CPU0:R2(config-pmap)#class SCAVENGER\nRP/0/0/CPU0:R2(config-pmap-c)#bandwidth percent 5\nRP/0/0/CPU0:R2(config-pmap-c)#class class-default\nRP/0/0/CPU0:R2(config-pmap-c)#bandwidth percent 10\nRP/0/0/CPU0:R2(config-pmap-c)#end","ccis":["CCI-001095"]},{"vulnId":"V-216807","ruleId":"SV-216807r1117237_rule","severity":"medium","ruleTitle":"The Cisco multicast router must be configured to disable Protocol Independent Multicast (PIM) on all interfaces that are not required to support multicast routing.","description":"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. \n\nA 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. \n\nAs stated in the DoD IPv6 IA Guidance for MO3, \"One should be able to identify all interfaces of a zone by drawing a closed loop on their network diagram, engulfing some routers and passing through some routers to include only some of their interfaces\". Therefore, it is imperative that the network 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.","checkContent":"Step 1: Review the network's multicast topology diagram.\n\nStep 2: Review the router configuration to verify that only the interfaces as shown in the multicast topology diagram are enabled as shown in the example below.\n\n!\nrouter pim\n address-family ipv4\n interface GigabitEthernet0/0/0/0\n enable\n !\n interface GigabitEthernet0/0/0/1\n enable\n !\n !\n\nIf an interface is not required to support multicast routing and it is enabled, this is a finding.","fixText":"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.\n\nRP/0/0/CPU0:R2(config)#router pim\nRP/0/0/CPU0:R2(config-pim)#address-family ipv4\nRP/0/0/CPU0:R2(config-pim-default-ipv4)#int g0/0/0/1\nRP/0/0/CPU0:R2(config-pim-ipv4-if)#disable \nRP/0/0/CPU0:R2(config-pim-ipv4-if)#end","ccis":["CCI-001414"]},{"vulnId":"V-216808","ruleId":"SV-216808r1117237_rule","severity":"medium","ruleTitle":"The Cisco multicast router must be configured to bind a Protocol Independent Multicast (PIM) neighbor filter to interfaces that have PIM enabled.","description":"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 routers 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.","checkContent":"This requirement is not applicable for the DODIN Backbone.\n\nStep 1: Verify all interfaces enabled for PIM have a neighbor ACL bound to the interface as shown in the example below.\n\nrouter pim\n address-family ipv4\n interface GigabitEthernet0/0/0/1\n enable\n neighbor-filter PIM_NEIGHBOR_1\n !\n interface GigabitEthernet0/0/0/2\n enable\n neighbor-filter PIM_NEIGHBOR_2\n !\n !\n!\n\nStep 2: Review the configured ACL for filtering PIM neighbors as shown in the example below.\n\nipv4 access-list PIM_NEIGHBOR_1\n 10 permit ipv4 host 10.1.1.2 any\n!\nipv4 access-list PIM_NEIGHBOR_2\n 10 permit ipv4 host 10.1.2.8 any\n!\n\nIf PIM neighbor ACLs are not bound to all interfaces that have PIM enabled, this is a finding.","fixText":"This requirement is not applicable for the DODIN Backbone.\n\nConfigure neighbor ACLs to only accept PIM control plane traffic from documented PIM neighbors. Bind neighbor ACLs to all PIM enabled interfaces.\n\nStep 1: Configure ACL for PIM neighbors.\n\nRP/0/0/CPU0:R2(config)#ipv4 access-list PIM_NEIGHBOR_1\nRP/0/0/CPU0:R2(config-ipv4-acl)#permit ipv4 host 10.1.1.2 any\nRP/0/0/CPU0:R2(config-ipv4-acl)#exit\n\nStep 2: Apply the ACL to all interfaces enabled for PIM.\n\nRP/0/0/CPU0:R2(config)#router pim\nRP/0/0/CPU0:R2(config-pim)#address-family ipv4\nRP/0/0/CPU0:R2(config-pim-default-ipv4)#int g0/0/0/1\nRP/0/0/CPU0:R2(config-pim-ipv4-if)#neighbor-filter PIM_NEIGHBOR_1\nRP/0/0/CPU0:R2(config-pim-ipv4-if)#exit\nRP/0/0/CPU0:R2(config-pim-default-ipv4)#int g0/0/0/2 \nRP/0/0/CPU0:R2(config-pim-ipv4-if)#neighbor-filter PIM_NEIGHBOR_2\nRP/0/0/CPU0:R2(config-pim-ipv4-if)#end","ccis":["CCI-001414"]},{"vulnId":"V-216809","ruleId":"SV-216809r1117237_rule","severity":"low","ruleTitle":"The Cisco multicast edge router must be configured to establish boundaries for administratively scoped multicast traffic.","description":"If multicast traffic is forwarded beyond the intended boundary, it is possible that it can be intercepted by unauthorized or unintended personnel.\n\nAdministrative 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.\n\nAdmin-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.","checkContent":"Review the router configuration and verify that admin-scope multicast traffic is blocked at the external edge as shown in the example below.\n\nipv4 access-list MULTICAST_SCOPE\n 10 deny ipv4 239.0.0.0 0.255.255.255 any\n 20 permit ipv4 any any\n…\n…\n…\n\nmulticast-routing\n address-family ipv4\n interface GigabitEthernet0/0/0/1\n enable\n boundary MULTICAST_SCOPE\n !\n interface GigabitEthernet0/0/0/2\n enable\n !\n !\n!\n\nIf the router is not configured to establish boundaries for administratively scoped multicast traffic, this is a finding.","fixText":"Step 1: Configure the ACL to deny packets with multicast administratively scoped destination addresses as shown in the example below.\n\nRP/0/0/CPU0:R2(config)#Ipv4 access-list MULTICAST_SCOPE\nRP/0/0/CPU0:R2(config-ipv4-acl)#deny 239.0.0.0 0.255.255.255\nRP/0/0/CPU0:R2(config-ipv4-acl)#permit any\n\nStep 2: Apply the multicast boundary at the appropriate interfaces as shown in the example below.\n\nRP/0/0/CPU0:R2(config)#multicast-routing \nRP/0/0/CPU0:R2(config-mcast)#address-family ipv4\nRP/0/0/CPU0:R2(config-mcast-default-ipv4)#int g0/0/0/1\nRP/0/0/CPU0:R2(config-mcast-default-ipv4-if)#boundary MULTICAST_SCOPE\nRP/0/0/CPU0:R2(config-mcast-default-ipv4-if)#end","ccis":["CCI-001414"]},{"vulnId":"V-216810","ruleId":"SV-216810r856449_rule","severity":"low","ruleTitle":"The Cisco multicast Rendezvous Point (RP) router must be configured to filter Protocol Independent Multicast (PIM) Join messages received from the Designated Router (DR) for any undesirable multicast groups.","description":"MSDP peering between networks enables sharing of multicast source information. Enclaves with an existing multicast topology using PIM-SM can configure their RP routers to peer with MSDP routers. As a first step of defense against a denial-of-service (DoS) attack, all RP routers must limit the multicast forwarding cache to ensure that router resources are not saturated managing an overwhelming number of PIM and MSDP source-active entries.","checkContent":"The Cisco router does not have a mechanism to limit the multicast forwarding cache. However, the risk associated with this requirement can be fully mitigated by configuring the router to:\n\n1. Filter PIM register messages.\n2. Rate limiting the number of PIM register messages.\n3. Accept MSDP packets only from known MSDP peers.\n\nStep 1: Verify that the RP router is configured to filter PIM register messages for any undesirable multicast groups and sources. The example below will deny any multicast streams for groups 239.5.0.0/16 and allow from only sources 10.1.2.6 and 10.1.2.7. \n\nipv4 access-list PIM_REGISTER_FILTER\n 10 deny ipv4 any 239.5.0.0 0.0.255.255\n 20 permit ipv4 host 10.1.2.6 any\n 30 permit ipv4 host 10.1.2.7 any\n 40 deny ipv4 any any \n…\n…\n…\nrouter pim\n address-family ipv4\n rp-address 2.2.2.2\n accept-register PIM_REGISTER_FILTER\n\nStep 2: Verify that the router is configured to rate limiting the number of PIM register messages as shown in the example below.\n\nrouter pim\n address-family ipv4\n allow-rp group-list FILTER_PIM_JOINS\n rp-address 10.2.2.2\n accept-register PIM_REGISTER_FILTER\n maximum register-states 250\n\nNote: The maximum register-states command is used to set an upper limit for PIM register states. When the limit is reached, PIM discontinues route creation from PIM register messages. If not configured, the default is 2000 which would be an overage for a small to average size multicast deployment.\n\nStep 3: Review the router configuration to determine if there is a receive path or interface filter to only accept MSDP packets from known MSDP peers as shown in the example below.\n\nStep 3a: Determine which interfaces would be peering MSDP with an external router by the configured peer addresses as shown in the example below.\n\nrouter msdp\n peer x.14.2.1\n remote-as nn\n !\n peer x.15.3.5\n remote-as nn\n !\n!\n\nStep 3b: Verify that interfaces used for MSDP peering have an inbound ACL as shown in the example.\n\ninterface GigabitEthernet0/0/0/1\n ipv4 address x.14.2.2 255.255.255.252\n ipv4 access-group EXTERNAL_ACL_INBOUND ingress\n\nStep 3c: Verify that the ACL restricts MSDP peering to only known sources.\n\nipv4 access-list EXTERNAL_ACL_INBOUND\n 10 permit tcp host x.1.28.2 host x.1.28.8 eq 639\n 20 deny tcp any host x.1.28.8 eq 639 log\n 30 permit tcp host x.1.28.2 host x.1.28.8 eq bgp\n 40 permit tcp host x.1.28.2 eq bgp host x.1.28.8\n 50 permit pim host x.1.28.2 host x.1.28.8\n 60 permit tcp any any established\n …\n …\n …\n 140 deny ipv4 any any log\n\nNote: MSDP connections is via TCP port 639\n\nIf the RP router is not configured to filter PIM register messages, rate limiting the number of PIM register messages, and accept MSDP packets only from known MSDP peers, this is a finding.","fixText":"The risk associated with this requirement can be fully mitigated by configuring the router to filter PIM register messages, rate limiting the number of PIM register messages, and accept MSDP packets only from known MSDP peers.\n\nStep 1: Configure the router to filter PIM register messages received from a multicast DR for any undesirable multicast groups and sources. The example below will deny any multicast streams for groups 239.5.0.0/16 and allow from only sources 10.1.2.6 and 10.1.2.7. \n\nRP/0/0/CPU0:R2(config)#ipv4 access-list PIM_REGISTER_FILTER\nRP/0/0/CPU0:R2(config-ipv4-acl)#deny ipv4 any 239.5.0.0 0.0.255.255\nRP/0/0/CPU0:R2(config-ipv4-acl)#permit ipv4 host 10.1.2.6 any\nRP/0/0/CPU0:R2(config-ipv4-acl)#permit ipv4 host 10.1.2.7 any\nRP/0/0/CPU0:R2(config-ipv4-acl)#deny ipv4 any any\nRP/0/0/CPU0:R2(config-ipv4-acl)#exit\nRP/0/0/CPU0:R2(config)#router pim\nRP/0/0/CPU0:R2(config-pim)#address-family ipv4\nRP/0/0/CPU0:R2(config-pim-default-ipv4)#accept-register PIM_REGISTER_FILTER\nRP/0/0/CPU0:R2(config-pim-default-ipv4)#end \n\nStep 2: Configure the RP to rate limit the number of multicast register messages.\n\nRP/0/0/CPU0:R2(config)#router pim\nRP/0/0/CPU0:R2(config-pim)#address-family ipv4\nRP/0/0/CPU0:R2(config-pim-default-ipv4)#maximum register-states 250\nRP/0/0/CPU0:R2(config-pim-default-ipv4)#end\n\nStep 3: Configure the receive path or interface ACLs to only accepts MSDP packets from known MSDP peers.\n\nRP/0/0/CPU0:R2(config)#ipv4 access-list EXTERNAL_ACL_INBOUND\nRP/0/0/CPU0:R2(config-ipv4-acl)#permit tcp host x.1.28.2 host x.1.28.8 eq 639\nRP/0/0/CPU0:R2(config-ipv4-acl)#deny tcp any host x.1.28.8 eq 639 log\nRP/0/0/CPU0:R2(config-ipv4-acl)#permit tcp host x.1.28.2 host x.1.28.8 eq bgp\nRP/0/0/CPU0:R2(config-ipv4-acl)#permit tcp host x.1.28.2 eq bgp host x.1.28.8\nRP/0/0/CPU0:R2(config-ipv4-acl)#permit pim host x.1.28.2 host x.1.28.8\nRP/0/0/CPU0:R2(config-ipv4-acl)#permit tcp any any established\n…\n…\n…\nRP/0/0/CPU0:R2(config-ipv4-acl)#deny ip any any log","ccis":["CCI-002385"]},{"vulnId":"V-216811","ruleId":"SV-216811r1117237_rule","severity":"low","ruleTitle":"The Cisco multicast Rendezvous Point (RP) router must be configured to filter Protocol Independent Multicast (PIM) Register messages received from the Designated Router (DR) for any undesirable multicast groups and sources.","description":"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.","checkContent":"Verify that the RP router is configured to filter PIM register messages. The example below will deny any multicast streams for groups 239.5.0.0/16 and allow from only sources 10.1.2.6 and 10.1.2.7. \n\nipv4 access-list PIM_REGISTER_FILTER\n 10 deny ipv4 any 239.5.0.0 0.0.255.255\n 20 permit ipv4 host 10.1.2.6 any\n 30 permit ipv4 host 10.1.2.7 any\n 40 deny ipv4 any any \n…\n…\n…\nrouter pim\n address-family ipv4\n rp-address 2.2.2.2\n accept-register PIM_REGISTER_FILTER\n\nIf the RP router peering with PIM-SM routers is not configured with a policy to block registration messages for any undesirable multicast groups and sources, this is a finding.","fixText":"Configure the router to filter PIM register messages received from a multicast DR for any undesirable multicast groups and sources. The example below will deny any multicast streams for groups 239.5.0.0/16 and allow from only sources 10.1.2.6 and 10.1.2.7. \n\nRP/0/0/CPU0:R2(config)#ipv4 access-list PIM_REGISTER_FILTER\nRP/0/0/CPU0:R2(config-ipv4-acl)#deny ipv4 any 239.5.0.0 0.0.255.255\nRP/0/0/CPU0:R2(config-ipv4-acl)#permit ipv4 host 10.1.2.6 any\nRP/0/0/CPU0:R2(config-ipv4-acl)#permit ipv4 host 10.1.2.7 any\nRP/0/0/CPU0:R2(config-ipv4-acl)#deny ipv4 any any\nRP/0/0/CPU0:R2(config-ipv4-acl)#exit\nRP/0/0/CPU0:R2(config)#router pim\nRP/0/0/CPU0:R2(config-pim)#address-family ipv4\nRP/0/0/CPU0:R2(config-pim-default-ipv4)#accept-register PIM_REGISTER_FILTER\nRP/0/0/CPU0:R2(config-pim-default-ipv4)#end","ccis":["CCI-001414"]},{"vulnId":"V-216812","ruleId":"SV-216812r1117237_rule","severity":"low","ruleTitle":"The Cisco multicast Rendezvous Point (RP) router must be configured to filter Protocol Independent Multicast (PIM) Join messages received from the Designated Router (DR) for any undesirable multicast groups.","description":"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.","checkContent":"Verify that the RP router is configured to filter PIM join messages for any undesirable multicast groups. In the example below, groups from 239.8.0.0/16 are no allowed.\n\nipv4 access-list FILTER_PIM_JOINS\n 10 deny ipv4 239.8.0.0 0.0.255.255 any\n 20 permit ipv4 any any\n…\n…\n…\nrouter pim\n address-family ipv4\n allow-rp group-list FILTER_PIM_JOINS\n\nIf the RP is not configured to filter join messages received from the DR for any undesirable multicast groups, this is a finding.","fixText":"Configure the RP to filter PIM join messages for any undesirable multicast groups as shown in the example below.\n\nRP/0/0/CPU0:R2(config)#ipv4 access-list FILTER_PIM_JOINS\nRP/0/0/CPU0:R2(config-ipv4-acl)#deny 239.8.0.0 0.0.255.255\nRP/0/0/CPU0:R2(config-ipv4-acl)#permit any\nRP/0/0/CPU0:R2(config-ipv4-acl)#exit\nRP/0/0/CPU0:R2(config)#router pim\nRP/0/0/CPU0:R2(config-pim)#address-family ipv4\nRP/0/0/CPU0:R2(config-pim-default-ipv4)#allow-rp group-list FILTER_PIM_JOINS \nRP/0/0/CPU0:R2(config-pim-default-ipv4)#end","ccis":["CCI-001414"]},{"vulnId":"V-216813","ruleId":"SV-216813r856450_rule","severity":"medium","ruleTitle":"The Cisco multicast Rendezvous Point (RP) must be configured to rate limit the number of Protocol Independent Multicast (PIM) Register messages.","description":"When a new source starts transmitting in a PIM Sparse Mode network, the Designated Router (DR) will encapsulate the multicast packets into register messages and forward them to the RP using unicast. \n\nThis process can be taxing on the CPU for both the DR and the RP if the source is running at a high data rate and there are many new sources starting at the same time. This scenario can potentially occur immediately after a network failover. \n\nThe rate limit for the number of register messages should be set to a relatively low value based on the known number of multicast sources within the multicast domain.","checkContent":"Review the configuration of the RP to verify that it is limiting the number of PIM register states as shown in the example. \n\nrouter pim\n address-family ipv4\n allow-rp group-list FILTER_PIM_JOINS\n rp-address 10.2.2.2\n accept-register PIM_REGISTER_FILTER\n maximum register-states 250\n\nNote: The maximum register-states command is used to set an upper limit for PIM register states. When the limit is reached, PIM discontinues route creation from PIM register messages. If not configured, the default is 2000 which would be an overage for a small to average size multicast deployment. \n\nIf the RP is not limiting PIM register states, this is a finding.","fixText":"Configure the RP to rate limit the number of multicast register states.\n\nRP/0/0/CPU0:R2(config)#router pim\nRP/0/0/CPU0:R2(config-pim)#address-family ipv4\nRP/0/0/CPU0:R2(config-pim-default-ipv4)#maximum register-states 250\nRP/0/0/CPU0:R2(config-pim-default-ipv4)#end","ccis":["CCI-002385"]},{"vulnId":"V-216814","ruleId":"SV-216814r878125_rule","severity":"low","ruleTitle":"The Cisco multicast Designated Router (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.","description":"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.","checkContent":"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.\n\nStep 1: Verify that all host facing interfaces are configured to filter IGMP Membership Report messages (IGMP joins) as shown in the example below.\n\nrouter igmp\n interface GigabitEthernet0/0/1/0\n access-group IGMP_JOIN_FILTER\n !\n interface GigabitEthernet0/0/1/1\n access-group IGMP_JOIN_FILTER\n !\n\nStep 2: Verify that the ACL denies unauthorized groups or permits only authorized groups. The example below denies all groups from 239.8.0.0/16 range.\n\nipv4 access-list IGMP_JOIN_FILTER\n 10 deny ipv4 239.8.0.0 0.0.255.255 any\n 20 permit ipv4 any any\n!\n\nNote: This requirement is only applicable to Source Specific Multicast (SSM) implementation. This requirement is not applicable to Any Source Multicast (ASM) since the filtering is being performed by the Rendezvous Point router.\n\nIf the DR is not filtering IGMP or MLD Membership Report messages, this is a finding.","fixText":"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.\n\nStep 1: Configure the ACL to filter IGMP Membership Report messages as shown in the example.\n\nRP/0/0/CPU0:R5(config)#ipv4 access-list IGMP_JOIN_FILTER\nRP/0/0/CPU0:R5(config-ipv4-acl)#deny 239.8.0.0 0.0.255.255\nRP/0/0/CPU0:R5(config-ipv4-acl)#exit\n\nStep 2: Apply the filter to all host facing interfaces.\n\nRP/0/0/CPU0:R5(config)#router igmp \nRP/0/0/CPU0:R5(config-igmp)#interface g0/0/1/0 \nRP/0/0/CPU0:R5(config-igmp-default-if)#access-group IGMP_JOIN_FILTER\nRP/0/0/CPU0:R5(config-igmp-default-if)#exit\nRP/0/0/CPU0:R5(config-igmp)#interface g0/0/1/1\nRP/0/0/CPU0:R5(config-igmp-default-if)#end","ccis":["CCI-002403"]},{"vulnId":"V-216815","ruleId":"SV-216815r878126_rule","severity":"medium","ruleTitle":"The Cisco multicast Designated Router (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.","description":"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.","checkContent":"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.\n\nStep 1: Verify that all host facing interfaces are configured to filter IGMP Membership Report messages (IGMP joins) as shown in the example below.\n\nrouter igmp\n interface GigabitEthernet0/0/1/0\n access-group IGMP_JOIN_FILTER\n !\n interface GigabitEthernet0/0/1/1\n access-group IGMP_JOIN_FILTER\n !\n\nStep 2: Verify that the ACL denies unauthorized sources or allows only authorized sources. The example below denies all groups from 232.8.0.0/16 range and permits sources only from the x.0.0.0/8 network.\n\nipv4 access-list IGMP_JOIN_FILTER\n 10 deny ipv4 any 232.8.0.0 0.0.255.255\n 20 permit ipv4 x.0.0.0 0.255.255.255 any\n 30 deny ipv4 any any\n!\n\nNote: This requirement is only applicable to Source Specific Multicast (SSM) implementation.\n\nIf the DR is not filtering IGMP or MLD report messages, this is a finding.","fixText":"Configure the DR to filter the IGMP and MLD report messages to allow hosts to join only those multicast groups from sources that have been approved as shown in the example.\n\nStep 1: Configure the access list to filter multicast joins as shown in the example below.\n\nRP/0/0/CPU0:R2(config)#ipv4 access-list IGMP_JOIN_FILTER\nRP/0/0/CPU0:R2(config-ipv4-acl)#deny ip any 232.8.0.0 0.0.255.255\nRP/0/0/CPU0:R2(config-ipv4-acl)#permit ip x.0.0.0 0.255.255.255 any\nRP/0/0/CPU0:R2(config-ipv4-acl)#deny ip any any\n\nStep 2: Apply the filter to all host facing interfaces.\n\nRP/0/0/CPU0:R5(config)#router igmp \nRP/0/0/CPU0:R5(config-igmp)#interface g0/0/1/0 \nRP/0/0/CPU0:R5(config-igmp-default-if)#access-group IGMP_JOIN_FILTER\nRP/0/0/CPU0:R5(config-igmp-default-if)#exit\nRP/0/0/CPU0:R5(config-igmp)#interface g0/0/1/1\nRP/0/0/CPU0:R5(config-igmp-default-if)#end","ccis":["CCI-002403"]},{"vulnId":"V-216816","ruleId":"SV-216816r856453_rule","severity":"medium","ruleTitle":"The Cisco multicast Designated Router (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.","description":"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 routers 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.","checkContent":"Review the DR configuration to verify that it is limiting the number of mroute states via IGMP or MLD.\n\nVerify IGMP limits have been configured globally or on each host-facing interface via the ip igmp limit command as shown in the example.\n\nrouter igmp\n interface GigabitEthernet0/0/0/0\n access-group IGMP_JOIN_FILTER\n !\n interface GigabitEthernet0/0/0/1\n access-group IGMP_JOIN_FILTER\n !\n maximum groups 200\n\n!Note: After the maximum groups value is met, all additional memberships learned are ignored. If not configured, the default is 5000 which would be an overage for a small to average size multicast deployment. \n\nIf the DR is not limiting multicast join requests via IGMP or MLD on a global or interfaces basis, this is a finding.","fixText":"Configure the DR on a global or interface basis to limit the number of mroute states resulting from IGMP or MLD membership reports.\n\nRP/0/0/CPU0:R5(config)#router igmp \nRP/0/0/CPU0:R2(config-igmp)#maximum groups 200\nRP/0/0/CPU0:R5(config-igmp)#end","ccis":["CCI-002385"]},{"vulnId":"V-216817","ruleId":"SV-216817r945856_rule","severity":"medium","ruleTitle":"The Cisco multicast Designated Router (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.","description":"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 router will initiate a switch from the shared tree to a source-specific SPT to obtain lower latencies. This is accomplished by the last-hop router sending an (S, G) Protocol Independent Multicast (PIM) Join toward S (the source).\n\nWhen the last-hop router 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.","checkContent":"Review the DR configuration to verify that the SPT switchover threshold is increased (default is \"0\") or set to infinity (never switch over). \n\nrouter pim\n address-family ipv4\n …\n …\n …\n spt-threshold infinity\n\nIf the DR is not configured to increase the SPT threshold or set to infinity to minimalize (S, G) state, this is a finding.","fixText":"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.\n\nRP/0/0/CPU0:R2(config)#router pim\nRP/0/0/CPU0:R2(config-pim)#address-family ipv4\nRP/0/0/CPU0:R2(config-pim-default-ipv4)#spt-threshold infinity \nRP/0/0/CPU0:R2(config-pim-default-ipv4)#end","ccis":["CCI-002385"]},{"vulnId":"V-216818","ruleId":"SV-216818r856455_rule","severity":"medium","ruleTitle":"The Cisco Multicast Source Discovery Protocol (MSDP) router must be configured to only accept MSDP packets from known MSDP peers.","description":"MSDP peering with customer network routers presents additional risks to the DISN Core, whether from a rogue or misconfigured MSDP-enabled router. \n\nTo guard against an attack from malicious MSDP traffic, the receive path or interface filter for all MSDP-enabled RP routers must be configured to only accept MSDP packets from known MSDP peers.","checkContent":"Review the router configuration to determine if there is a receive path or interface filter to only accept MSDP packets from known MSDP peers.\n\nStep 1: Determine which interfaces would be peering MSDP with an external router by the configured peer addresses as shown in the example below.\n\nrouter msdp\n peer x.14.2.1\n remote-as nn\n !\n peer x.15.3.5\n remote-as nn\n !\n!\n\nStep 2: Verify that interfaces used for MSDP peering have an inbound ACL as shown in the example.\n\ninterface GigabitEthernet0/0/0/1\n ipv4 address x.14.2.2 255.255.255.252\n ipv4 access-group EXTERNAL_ACL_INBOUND ingress\n\nStep 3: Verify that the ACL restricts MSDP peering to only known sources.\n\nipv4 access-list EXTERNAL_ACL_INBOUND\n 10 permit tcp host x.1.28.2 host x.1.28.8 eq 639\n 20 deny tcp any host x.1.28.8 eq 639 log\n 30 permit tcp host x.1.28.2 host x.1.28.8 eq bgp\n 40 permit tcp host x.1.28.2 eq bgp host x.1.28.8\n 50 permit pim host x.1.28.2 host x.1.28.8\n 60 permit tcp any any established\n …\n …\n …\n 140 deny ipv4 any any log \n\nNote: MSDP connections is via TCP port 639\n\nIf the router is not configured to only accept MSDP packets from known MSDP peers, this is a finding.","fixText":"Configure the interface ACLs to only accept MSDP packets from known MSDP peers.\n\nRP/0/0/CPU0:R2(config)#ipv4 access-list EXTERNAL_ACL_INBOUND\nRP/0/0/CPU0:R2(config-ipv4-acl)#permit tcp host x.1.28.2 host x.1.28.8 eq 639\nRP/0/0/CPU0:R2(config-ipv4-acl)#deny tcp any host x.1.28.8 eq 639 log\nRP/0/0/CPU0:R2(config-ipv4-acl)#permit tcp host x.1.28.2 host x.1.28.8 eq bgp\nRP/0/0/CPU0:R2(config-ipv4-acl)#permit tcp host x.1.28.2 eq bgp host x.1.28.8\nRP/0/0/CPU0:R2(config-ipv4-acl)#permit pim host x.1.28.2 host x.1.28.8\nRP/0/0/CPU0:R2(config-ipv4-acl)#permit tcp any any established\n…\n…\n…\nRP/0/0/CPU0:R2(config-ipv4-acl)#deny ip any any log","ccis":["CCI-002403"]},{"vulnId":"V-216819","ruleId":"SV-216819r856456_rule","severity":"medium","ruleTitle":"The Cisco Multicast Source Discovery Protocol (MSDP) router must be configured to authenticate all received MSDP packets.","description":"MSDP peering with customer network routers presents additional risks to the core, whether from a rogue or misconfigured MSDP-enabled router. \n\nMSDP 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.","checkContent":"Review the router configuration to determine if received MSDP packets are authenticated.\n\nrouter msdp\n peer x.14.2.1\n password encrypted 094E410B1B1C\n remote-as nn\n !\n peer x.15.3.5\n password encrypted 04500A140A2F\n remote-as nn\n !\n!\n\nIf the router does not require MSDP authentication, this is a finding.","fixText":"Configure the router to authenticate MSDP messages as shown in the following example:\n\nRP/0/0/CPU0:R2(config)#router msdp\nRP/0/0/CPU0:R2(config-msdp)#peer x.14.2.1\nRP/0/0/CPU0:R2(config-msdp-peer)#password clear xxxxxxxxxxxx\nRP/0/0/CPU0:R2(config-msdp-peer)#exit\nRP/0/0/CPU0:R2(config-msdp)#peer x.15.3.5\nRP/0/0/CPU0:R2(config-msdp-peer)#password clear xxxxxxxxxxx \nRP/0/0/CPU0:R2(config-msdp-peer)#end","ccis":["CCI-001958"]},{"vulnId":"V-216820","ruleId":"SV-216820r1117236_rule","severity":"low","ruleTitle":"The Cisco Multicast Source Discovery Protocol (MSDP) router must be configured to filter received source-active multicast advertisements for any undesirable multicast groups and sources.","description":"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) routers to perform RPF checks and build multicast distribution trees. \n\nMSDP is a mechanism used to connect multiple PIM sparse-mode domains, allowing RPs from different domains to share information about active sources. \n\nWhen 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. \n\nConfiguring 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.","checkContent":"Review the router configuration to determine if there is import policy to block source-active multicast advertisements for any undesirable multicast groups, as well as any (S, G) states with undesirable source addresses. \n\nStep 1: Verify that an inbound source-active filter is bound to each MSDP peer.\n\nrouter msdp\n sa-filter in list INBOUND_MSDP_SA_FILTER\n\nStep 2: Review the access lists referenced by the source-active filter to verify that undesirable multicast groups, auto-RP, single source multicast (SSM) groups, and advertisements from undesirable sources are blocked.\n\nipv4 access-list INBOUND_MSDP_SA_FILTER\n 10 deny ipv4 any host 224.0.1.3\n 20 deny ipv4 any host 224.0.1.24\n 30 deny ipv4 any host 224.0.1.22\n 40 deny ipv4 any host 224.0.1.2\n 50 deny ipv4 any host 224.0.1.35\n 60 deny ipv4 any host 224.0.1.60\n 70 deny ipv4 any host 224.0.1.39\n 80 deny ipv4 any host 224.0.1.40\n 90 deny ipv4 any 232.0.0.0 0.255.255.255\n 100 deny ipv4 any 239.0.0.0 0.255.255.255\n 110 deny ipv4 10.0.0.0 0.255.255.255 any\n 120 deny ipv4 127.0.0.0 0.255.255.255 any\n 130 deny ipv4 172.16.0.0 0.15.255.255 any\n 140 deny ipv4 192.168.0.0 0.0.255.255 any\n 150 permit ipv4 any any\n\nIf the router is not configured with an import policy to filter undesirable SA multicast advertisements, this is a finding.","fixText":"Configure the MSDP router to filter received source-active multicast advertisements for any undesirable multicast groups and sources as shown in the example below.\n\nRP/0/0/CPU0:R2(config)#ipv4 access-list INBOUND_MSDP_SA_FILTER\nRP/0/0/CPU0:R2(config-ipv4-acl)#deny ip any host 224.0.1.3\nRP/0/0/CPU0:R2(config-ipv4-acl)#deny ipv4 any host 224.0.1.24\nRP/0/0/CPU0:R2(config-ipv4-acl)#deny ipv4 any host 224.0.1.22\nRP/0/0/CPU0:R2(config-ipv4-acl)#deny ipv4 any host 224.0.1.2\nRP/0/0/CPU0:R2(config-ipv4-acl)#deny ipv4 any host 224.0.1.35\nRP/0/0/CPU0:R2(config-ipv4-acl)#deny ipv4 any host 224.0.1.60\nRP/0/0/CPU0:R2(config-ipv4-acl)#deny ipv4 any host 224.0.1.39\nRP/0/0/CPU0:R2(config-ipv4-acl)#deny ipv4 any host 224.0.1.40\nRP/0/0/CPU0:R2(config-ipv4-acl)#deny ipv4 any 232.0.0.0 0.255.255.255\nRP/0/0/CPU0:R2(config-ipv4-acl)#deny ipv4 any 239.0.0.0 0.255.255.255\nRP/0/0/CPU0:R2(config-ipv4-acl)#deny ipv4 10.0.0.0 0.255.255.255 any\nRP/0/0/CPU0:R2(config-ipv4-acl)#deny ipv4 127.0.0.0 0.255.255.255 any\nRP/0/0/CPU0:R2(config-ipv4-acl)#deny ipv4 172.16.0.0 0.15.255.255 any\nRP/0/0/CPU0:R2(config-ipv4-acl)#deny ipv4 192.168.0.0 0.0.255.255 any\nRP/0/0/CPU0:R2(config-ipv4-acl)#permit ipv4 any any\nRP/0/0/CPU0:R2(config-ipv4-acl)#exit\nRP/0/0/CPU0:R2(config)#router msdp\nRP/0/0/CPU0:R2(config-msdp)#sa-filter in list INBOUND_MSDP_SA_FILTER\nRP/0/0/CPU0:R2(config-msdp)#end","ccis":["CCI-001368"]},{"vulnId":"V-216821","ruleId":"SV-216821r1117236_rule","severity":"low","ruleTitle":"The Cisco Multicast Source Discovery Protocol (MSDP) router must be configured to filter source-active multicast advertisements to external MSDP peers to avoid global visibility of local-only multicast sources and groups.","description":"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).\n\nAllowing 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.","checkContent":"Review the router configuration to determine if there is export policy to block local source-active multicast advertisements.\n\nStep 1: Verify that an outbound source-active filter is bound to each MSDP peer as shown in the example below.\n\nrouter msdp\n sa-filter in list INBOUND_MSDP_SA_FILTER\n sa-filter out list OUTBOUND_MSDP_SA_FILTER\n\nStep 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.\n\nipv4 access-list OUTBOUND_MSDP_SA_FILTER\n 10 deny ipv4 10.0.0.0 0.255.255.255 any\n 20 permit ipv4 any any\n\nIf the router is not configured with an export policy to filter local source-active multicast advertisements, this is a finding.","fixText":"Configure the router with an export policy to avoid global visibility of local multicast (S, G) states. The example below will prevent exporting multicast active sources belonging to the private network.\n\nRP/0/0/CPU0:R2(config)#ipv4 access-list OUTBOUND_MSDP_SA_FILTER\nRP/0/0/CPU0:R2(config-ipv4-acl)#deny ipv4 10.0.0.0 0.255.255.255 any\nRP/0/0/CPU0:R2(config-ipv4-acl)#permit ip any any\nRP/0/0/CPU0:R2(config-ipv4-acl)#exit\nRP/0/0/CPU0:R2(config)#router msdp\nRP/0/0/CPU0:R2(config-msdp)#sa-filter out list OUTBOUND_MSDP_SA_FILTER \nRP/0/0/CPU0:R2(config-msdp)#end","ccis":["CCI-001368"]},{"vulnId":"V-216822","ruleId":"SV-216822r1117236_rule","severity":"low","ruleTitle":"The Cisco Multicast Source Discovery Protocol (MSDP) router must be configured to limit the amount of source-active messages it accepts on a per-peer basis.","description":"To reduce any risk of a denial-of-service (DoS) attack from a rogue or misconfigured MSDP router, the router must be configured to limit the number of source-active messages it accepts from each peer.","checkContent":"Review the router configuration to determine if it is configured to limit the amount of source-active messages it accepts on a per-peer basis.\n\nrouter msdp\n …\n …\n …\n peer 4.4.4.4\n remote-as 33\n maximum external-sa 555\n !\n peer 5.5.5.5\n remote-as 44\n maximum external-sa 555\n !\n!\n\nIf the router is not configured to limit the source-active messages it accepts, this is a finding.","fixText":"Configure the router to limit the amount of source-active messages it accepts from each peer.\n\nRP/0/0/CPU0:R2(config)#router msdp\nRP/0/0/CPU0:R2(config-msdp)#peer x.14.2.1\nRP/0/0/CPU0:R2(config-msdp-peer)#maximum external-sa nnn\nRP/0/0/CPU0:R2(config-msdp-peer)#exit\nRP/0/0/CPU0:R2(config-msdp)#peer x.15.3.5\nRP/0/0/CPU0:R2(config-msdp-peer)#maximum external-sa nnn\nRP/0/0/CPU0:R2(config-msdp-peer)#end","ccis":["CCI-001368"]},{"vulnId":"V-216823","ruleId":"SV-216823r991943_rule","severity":"low","ruleTitle":"The Cisco Multicast Source Discovery Protocol (MSDP) router must be configured to use a loopback address as the source address when originating MSDP traffic.","description":"Using a loopback address as the source address offers a multitude of uses for security, access, management, and scalability of MSDP routers. \n\nIt is easier to construct appropriate ingress filters for router 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. \n\nLog information recorded by authentication and syslog servers will record the router’s loopback address instead of the numerous physical interface addresses.","checkContent":"Verify that the loopback interface is used as the source address for all MSDP packets generated by the router.\n\nrouter msdp\n connect-source Loopback0\n\nIf the router does not use its loopback address as the source address when originating MSDP traffic, this is a finding.","fixText":"Configure the router to use its loopback address is used as the source address when sending MSDP packets.\n\nRP/0/0/CPU0:R2(config)#router msdp\nRP/0/0/CPU0:R2(config-msdp)#connect-source lo0\nRP/0/0/CPU0:R2(config-msdp)#end","ccis":["CCI-004931"]},{"vulnId":"V-217005","ruleId":"SV-217005r945858_rule","severity":"high","ruleTitle":"The Cisco perimeter router must be configured to restrict it from accepting outbound IP packets that contain an illegitimate address in the source address field via egress filter or by enabling Unicast Reverse Path Forwarding (uRPF).","description":"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.","checkContent":"This requirement is not applicable for the DODIN Backbone.\n\nReview the router configuration to verify uRPF or an egress ACL has been configured on all internal interfaces to restrict the router from accepting outbound IP packets that contain an illegitimate address in the source address field.\n\nuRPF example\n\ninterface GigabitEthernet0/0/0/1\n description downstream link to LAN\n ipv4 address 10.1.34.3 255.255.255.0\n ipv4 verify unicast source reachable-via rx\n\nEgress ACL example\n\nipv4 access-list EGRESS_FILTER\n 10 permit udp 10.1.15.0 0.0.0.255 any eq domain\n 20 permit tcp 10.1.15.0 0.0.0.255 any eq ftp\n 30 permit tcp 10.1.15.0 0.0.0.255 any eq ftp-data\n 40 permit tcp 10.1.15.0 0.0.0.255 any eq www\n 50 permit icmp 10.1.15.0 0.0.0.255 any\n 60 permit icmp 10.1.15.0 0.0.0.255 any echo\n 70 deny ipv4 any any\n…\n…\n…\ninterface GigabitEthernet0/0/0/1\n description downstream link to LAN\n ipv4 address 10.1.34.3 255.255.255.0\n ipv4 access-group EGRESS_FILTER ingress\n\nIf uRPF or an egress ACL to restrict the router from accepting outbound IP packets that contain an illegitimate address in the source address field has not been configured on all internal interfaces in an enclave, this is a finding.","fixText":"This requirement is not applicable for the DODIN Backbone.\n\nConfigure the router to ensure that an egress ACL or uRPF is configured on internal interfaces to restrict the router from accepting any outbound IP packet that contains an illegitimate address in the source field. The example below enables uRPF.\n\nRP/0/0/CPU0:R3(config)#int g0/0/0/1\nRP/0/0/CPU0:R3(config-if)#ipv4 verify unicast source reachable-via rx","ccis":["CCI-001094"]},{"vulnId":"V-217006","ruleId":"SV-217006r945859_rule","severity":"medium","ruleTitle":"The Cisco perimeter router must be configured to block all packets with any IP options.","description":"Packets with IP options are not fast switched and henceforth must be punted to the router processor. Hackers who initiate denial-of-service (DoS) attacks on routers commonly send large streams of packets with IP options. Dropping the packets with IP options reduces the load of IP options packets on the router. The end result is a reduction in the effects of the DoS attack on the router and on downstream routers.","checkContent":"This requirement is not applicable for the DODIN Backbone.\n\nIn Cisco IOS XR, all IPv4 packets with any header option other than the \"source-route\" header options are dropped. By default, ipv4 source routing is disabled. Verify that the following command is not configured: ipv4 source-route\n\nIf the router is not configured to drop all packets with IP option source routing, this is a finding.","fixText":"This requirement is not applicable for the DODIN Backbone.\n\nConfigure the router to drop all packets with IP option source routing.\n\nRP/0/0/CPU0:R3(config)#no ipv4 source-route","ccis":["CCI-002403"]},{"vulnId":"V-217007","ruleId":"SV-217007r856462_rule","severity":"low","ruleTitle":"The Cisco BGP router must be configured to enable the Generalized TTL Security Mechanism (GTSM).","description":"As described in RFC 3682, GTSM is designed to protect a router's IP-based control plane from DoS attacks. Many attacks focused on CPU load and line-card overload can be prevented by implementing GTSM on all Exterior Border Gateway Protocol speaking routers. \n\nGTSM is based on the fact that the vast majority of control plane peering is established between adjacent routers; that is, the Exterior Border Gateway Protocol peers are either between connecting interfaces or between loopback interfaces. Since TTL spoofing is considered nearly impossible, a mechanism based on an expected TTL value provides a simple and reasonably robust defense from infrastructure attacks based on forged control plane traffic.","checkContent":"Review the BGP configuration to verify that TTL security has been configured for each external neighbor as shown in the example below.\n\nrouter bgp n\n address-family ipv4 unicast\n !\n neighbor x.1.23.3\n remote-as n\n ttl-security\n address-family ipv4 unicast\n !\n !\n!\n\nIf the router is not configured to use GTSM for all Exterior Border Gateway Protocol peering sessions, this is a finding.","fixText":"Configure TTL security on all external BGP neighbors as shown in the example below.\n\nRP/0/0/CPU0:R2(config)#router bgp n\nRP/0/0/CPU0:R2(config-bgp)#neighbor x.1.23.3 \nRP/0/0/CPU0:R2(config-bgp-nbr)#ttl-security","ccis":["CCI-002385"]},{"vulnId":"V-217008","ruleId":"SV-217008r945862_rule","severity":"medium","ruleTitle":"The Cisco BGP router must be configured to use a unique key for each autonomous system (AS) that it peers with.","description":"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.","checkContent":"Review the BGP configuration to determine if it is peering with multiple autonomous systems. Interview the ISSM and router administrator to determine if unique keys are being used. \n\nrouter bgp n\n address-family ipv4 unicast\n !\n neighbor x.1.23.3\n remote-as y\n keychain YYY_KEY_CHAIN\n ttl-security\n address-family ipv4 unicast\n !\n !\n neighbor x.1.24.4\n remote-as z\n keychain ZZZ_KEY_CHAIN\n ttl-security\n address-family ipv4 unicast\n !\n!\n\nIf unique keys are not being used, this is a finding.","fixText":"Configure the router to use unique keys for each AS that it peers with as shown in the example below.\n\nRP/0/0/CPU0:R2(config)#router bgp n\nRP/0/0/CPU0:R2(config-bgp)#neighbor x.1.23.3\nRP/0/0/CPU0:R2(config-bgp-nbr)#keychain YYY_KEY_CHAIN \nRP/0/0/CPU0:R2(config-bgp-nbr)#neighbor x.1.24.4\nRP/0/0/CPU0:R2(config-bgp-nbr)#keychain ZZZ_KEY_CHAIN \nRP/0/0/CPU0:R2(config-bgp-nbr)#end","ccis":["CCI-000366","CCI-002205"]},{"vulnId":"V-217009","ruleId":"SV-217009r945860_rule","severity":"medium","ruleTitle":"The Cisco PE router must be configured to ignore or block all packets with any IP options.","description":"Packets with IP options are not fast switched and therefore must be punted to the router processor. Hackers who initiate denial-of-service (DoS) attacks on routers commonly send large streams of packets with IP options. Dropping the packets with IP options reduces the load of IP options packets on the router. The end result is a reduction in the effects of the DoS attack on the router and on downstream routers.","checkContent":"In Cisco IOS XR, all IPv4 packets with any header option other than the \"source-route\" header options are dropped. By default, ipv4 source routing is disabled. \n\nVerify that the following command is not configured:\n\n ipv4 source-route\n\nIf the router is not configured to drop all packets with IP options, this is a finding.","fixText":"Configure the router to drop all packets with ipv4 source-route as shown below.\n\nRP/0/0/CPU0:R3(config)#no ipv4 source-route","ccis":["CCI-002403"]},{"vulnId":"V-230037","ruleId":"SV-230037r878128_rule","severity":"medium","ruleTitle":"The Cisco router must be configured to have Cisco Express Forwarding enabled.","description":"The Cisco Express Forwarding (CEF) switching mode replaces the traditional Cisco routing cache with a data structure that mirrors the entire system routing table. Because there is no need to build cache entries when traffic starts arriving for new destinations, CEF behaves more predictably when presented with large volumes of traffic addressed to many destinations—such as a SYN flood attacks that. Because many SYN flood attacks use randomized source addresses to which the hosts under attack will reply to, there can be a substantial amount of traffic for a large number of destinations that the router will have to handle. Consequently, routers configured for CEF will perform better under SYN floods directed at hosts inside the network than routers using the traditional cache.","checkContent":"Review the router to verify that CEF is enabled.\n\nIPv4 Example: ip cef \nIPv6 Example: ipv6 cef\n\nIf CEF is not enabled, this is a finding.","fixText":"Enable CEF\n\nIPv4 Example: ip cef \nIPv6 Example: ipv6 cef","ccis":["CCI-000366"]},{"vulnId":"V-230040","ruleId":"SV-230040r532994_rule","severity":"low","ruleTitle":"The Cisco router must be configured to advertise a hop limit of at least 32 in Router Advertisement messages for IPv6 stateless auto-configuration deployments.","description":"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.","checkContent":"Review the router configuration to determine if the hop limit has been configured for Router Advertisement messages as shown in the example.\n\nipv6 hop-limit 128\n\nIf it has been configured and has not been set to at least 32, it is a finding.","fixText":"Configure the router to advertise a hop limit of at least 32 in Router Advertisement messages.\n\nR1(config)#ipv6 hop-limit 128","ccis":["CCI-000366"]},{"vulnId":"V-230043","ruleId":"SV-230043r533001_rule","severity":"medium","ruleTitle":"The Cisco router must not be configured to use IPv6 Site Local Unicast addresses.","description":"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.","checkContent":"Review the router configuration to ensure FEC0::/10 IPv6 addresses are not defined. \n\nIf IPv6 Site Local Unicast addresses are defined, this is a finding.","fixText":"Configure the router using only authorized IPv6 addresses.","ccis":["CCI-000366"]},{"vulnId":"V-230046","ruleId":"SV-230046r533007_rule","severity":"medium","ruleTitle":"The Cisco perimeter router must be configured to suppress Router Advertisements on all external IPv6-enabled interfaces.","description":"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.","checkContent":"This requirement is not applicable for the DODIN Backbone. \n\nReview the router configuration to verify that Router Advertisements are suppressed on all external IPv6-enabled interfaces as shown in the example below.\n\ninterface gigabitethernet1/0\n ipv6 address 2001::1:0:22/64\n ipv6 nd ra suppress\n\nIf the router is not configured to suppress Router Advertisements on all external IPv6-enabled interfaces, this is a finding.","fixText":"Configure the router to suppress Router Advertisements on all external IPv6-enabled interfaces as shown in the example below.\nR1(config)#int g1/0\nR1(config-if)#ipv6 nd ra suppress\nR1(config-if)#end","ccis":["CCI-000366"]},{"vulnId":"V-230049","ruleId":"SV-230049r950991_rule","severity":"medium","ruleTitle":"The Cisco perimeter router must be configured to drop IPv6 undetermined transport packets.","description":"One of the fragmentation weaknesses known in IPv6 is the undetermined transport packet. This packet contains an undetermined protocol due to fragmentation. Depending on the length of the IPv6 extension header chain, the initial fragment may not contain the layer four port information of the packet.","checkContent":"This requirement is not applicable for the DODIN Backbone. \n\nReview the router configuration to determine if it is configured to drop IPv6 undetermined transport packets.\n\nStep 1: Verify that an inbound IPv6 ACL has been configured on the external interface.\n\ninterface interface gigabitethernet 0/2/0/2\n ipv6 address 2001::1:0:22/64\n ipv6 access-group FILTER_IPV6 ingress\n\nStep 2: Verify that the ACL drops undetermined transport packets as shown in the example below.\n\nipv6 access-list FILTER_IPV6\n 10 deny ipv6 any any log undetermined-transport\n 20 permit ipv6 …\n …\n …\n …\n 90 deny ipv6 any any log\n\nIf the router is not configured to drop IPv6 undetermined transport packets, this is a finding.","fixText":"Configure the router to drop IPv6 undetermined transport packets as shown in the example below.\nRP/0/0/CPU0:R3(config)# ipv6 access-list FILTER_IPV6\nRP/0/0/CPU0:R3(config-ipv6-acl)# deny ipv6 any any undetermined-transport log\nRP/0/0/CPU0:R3(config-ipv6-acl)# permit ipv6 …\n…\n…\n…\nRP/0/0/CPU0:R3(config-ipv6-acl)# deny ipv6 any any log\nRP/0/0/CPU0:R3(config-ipv6-acl)# exit\nRP/0/0/CPU0:R3(config)# interface gigabitethernet 0/2/0/2\nRP/0/0/CPU0:R3(config-if)# ipv6 access-group FILTER_IPV6 ingress","ccis":["CCI-002403"]},{"vulnId":"V-230052","ruleId":"SV-230052r856665_rule","severity":"medium","ruleTitle":"The Cisco perimeter router must be configured drop IPv6 packets with a Routing Header type 0, 1, or 3–255.","description":"The routing header can be used maliciously to send a packet through a path where less robust security is in place, rather than through the presumably preferred path of routing protocols. Use of the routing extension header has few legitimate uses other than as implemented by Mobile IPv6. \n\nThe Type 0 Routing Header (RFC 5095) is dangerous because it allows attackers to spoof source addresses and obtain traffic in response, rather than the real owner of the address. Secondly, a packet with an allowed destination address could be sent through a Firewall using the Routing Header functionality, only to bounce to a different node once inside. The Type 1 Routing Header is defined by a specification called \"Nimrod Routing\", a discontinued project funded by DARPA. Assuming that most implementations will not recognize the Type 1 Routing Header, it must be dropped. The Type 3–255 Routing Header values in the routing type field are currently undefined and should be dropped inbound and outbound.","checkContent":"This requirement is not applicable for the DODIN Backbone. \n\nReview the router configuration to determine if it is configured to drop IPv6 packets containing a Routing Header of type 0, 1, or 3-255.\n\nStep 1: Verify that an inbound IPv6 ACL has been configured on the external interface.\n\ninterface interface gigabitethernet 0/2/0/2\n ipv6 address 2001::1:0:22/64\n ipv6 access-group FILTER_IPV6 ingress\n\nStep 2: Verify that the ACL drops IPv6 packets with a Routing Header type 0, 1, or 3-255 \nas shown in the example below.\n\nipv6 access-list FILTER_IPV6\n 10 permit ipv6 any host 2001:DB8::1:1:1234 routing-type 2\n 20 deny ipv6 any any log routing\n 30 permit ipv6 …\n …\n …\n …\n90 deny ipv6 any any log\n\nNote: The example above allows routing-type 2 in the event Mobility IPv6 is deployed.\n\nIf the router is not configured to drop IPv6 packets containing a Routing Header of type 0, 1, or 3-255, this is a finding.","fixText":"Configure the router to drop IPv6 packets with Routing Header of type 0, 1, or 3-255 as shown in the example below.\n\nRP/0/0/CPU0:R3(config)# ipv6 access-list FILTER_IPV6\nRP/0/0/CPU0:R3(config-ipv6-acl)# permit ipv6 any host 2001:DB8::0:1:1:1234 routing-type 2\nRP/0/0/CPU0:R3(config-ipv6-acl)# deny ipv6 any any routing log\nRP/0/0/CPU0:R3(config-ipv6-acl)# permit …\n…\n…\n…\nRP/0/0/CPU0:R3(config-ipv6-acl)# deny ipv6 any any log\nRP/0/0/CPU0:R3(config-ipv6-acl)# exit\nRP/0/0/CPU0:R3(config)# interface gigabitethernet 0/2/0/2\nRP/0/0/CPU0:R3(config-if)# ipv6 access-group FILTER_IPV6 ingress","ccis":["CCI-002403"]},{"vulnId":"V-230147","ruleId":"SV-230147r1132531_rule","severity":"medium","ruleTitle":"The Cisco perimeter router must be configured to drop IPv6 packets containing a Hop-by-Hop header with invalid option type values.","description":"These options are intended to be for the Destination Options header only. The optional and extensible natures of the IPv6 extension headers require higher scrutiny since many implementations do not always drop packets with headers that it cannot recognize and hence could cause a Denial-of-Service on the target device. In addition, the type, length, value (TLV) formatting provides the ability for headers to be very large.","checkContent":"This requirement is not applicable for the DODIN Backbone. \n\nReview the router configuration to determine if it is compliant with this requirement. \n\nStep 1: Verify that an inbound IPv6 ACL has been configured on the external interface.\n\ninterface interface gigabitethernet 0/2/0/2\n ipv6 address 2001::1:0:22/64\n ipv6 access-group FILTER_IPV6 ingress\n\nStep 2: Verify that the ACL drops IPv6 packets containing a Hop-by-Hop header with destination options as shown in the example below.\n\nipv6 access-list FILTER_IPV6\n 10 deny hbh any any dest-option log\n 20 permit ipv6 …\n …\n …\n …\n 90 deny ipv6 any any log\n\nNote: Cisco has deprecated the dest-option-type command used to filter by option type within the Hop-by-Hop header. Therefore, all packets with the Hop-by-Hop header option types must be dropped.\n\nIf the router is not configured to drop IPv6 packets containing a Hop-by-Hop header with destination options, this is a finding.","fixText":"Drop IPv6 packets containing a Hop-by-Hop header as shown in the example below.\n\nRP/0/0/CPU0:R3(config)# ipv6 access-list FILTER_IPV6\nRP/0/0/CPU0:R3(config-ipv6-acl)# deny hbh any any dest-option log\nRP/0/0/CPU0:R3(config-ipv6-acl)# permit ipv6 …\n…\n…\n…\nRP/0/0/CPU0:R3(config-ipv6-acl)# deny ipv6 any any log\nRP/0/0/CPU0:R3(config-ipv6-acl)# exit\nRP/0/0/CPU0:R3(config)# interface gigabitethernet 0/2/0/2\nRP/0/0/CPU0:R3(config-if)# ipv6 access-group FILTER_IPV6 ingress\nRP/0/0/CPU0:R3(config-if)# end","ccis":["CCI-002403"]},{"vulnId":"V-230151","ruleId":"SV-230151r1132534_rule","severity":"medium","ruleTitle":"The Cisco perimeter router must be configured to drop IPv6 packets containing a Destination Option header with invalid option type values.","description":"These options are intended to be for the Hop-by-Hop header only. The optional and extensible natures of the IPv6 extension headers require higher scrutiny since many implementations do not always drop packets with headers that it cannot recognize. Hence, this could cause a Denial-of-Service on the target device. In addition, the type, length, value (TLV) formatting provides the ability for headers to be very large.","checkContent":"This requirement is not applicable for the DODIN Backbone. \n\nReview the router configuration to determine if it is compliant with this requirement. \n\nStep 1: Verify that an inbound IPv6 ACL has been configured on the external interface.\n\ninterface interface gigabitethernet 0/2/0/2\n ipv6 address 2001::1:0:22/64\n ipv6 access-group FILTER_IPV6 ingress\n\nStep 2: Verify that the ACL drops IPv6 packets containing a Destination Option header with option type values of 0x05 (Router Alert) or 0xC2 (Jumbo Payload) as shown in the example below.\n\nipv6 access-list FILTER_IPV6\n 10 deny 60 any any dest-option log\n 20 permit ipv6 …\n …\n …\n …\n 90 deny ipv6 any any log\n \nNote: Cisco has deprecated the dest-option-type command used to filter by option type within the Destination Option header. Therefore, all packets with the Destination Option header must be dropped.\n\nIf the router is not configured to drop IPv6 packets containing a Destination Option header, this is a finding.","fixText":"Configure the router to drop IPv6 packets containing a Destination Option header as shown in the example below.\n\nRP/0/0/CPU0:R3(config)# ipv6 access-list FILTER_IPV6\nRP/0/0/CPU0:R3(config-ipv6-acl)# deny 60 any any dest-option log\nRP/0/0/CPU0:R3(config-ipv6-acl)# permit ipv6 …\n…\n…\n…\nRP/0/0/CPU0:R3(config-ipv6-acl)# deny ipv6 any any log\nRP/0/0/CPU0:R3(config-ipv6-acl)# exit\nRP/0/0/CPU0:R3(config)# interface gigabitethernet 0/2/0/2\nRP/0/0/CPU0:R3(config-if)# ipv6 access-group FILTER_IPV6 ingress\nRP/0/0/CPU0:R3(config-if)# end","ccis":["CCI-002403"]},{"vulnId":"V-230154","ruleId":"SV-230154r1132537_rule","severity":"medium","ruleTitle":"The Cisco perimeter router must be configured to drop IPv6 packets containing an extension header with the Endpoint Identification option.","description":"The optional and extensible natures of the IPv6 extension headers require higher scrutiny since many implementations do not always drop packets with headers that it cannot recognize, and hence could cause a Denial-of-Service on the target device. In addition, the type, length, value (TLV) formatting provides the ability for headers to be very large. This option type is associated with the Nimrod Routing system and has no defining RFC document.","checkContent":"This requirement is not applicable for the DODIN Backbone. \n\nReview the router configuration to determine if it is compliant with this requirement. \n\nStep 1: Verify that an inbound IPv6 ACL has been configured on the external interface.\n\ninterface interface gigabitethernet 0/2/0/2\n ipv6 address 2001::1:0:22/64\n ipv6 access-group FILTER_IPV6 ingress\n\nStep 2: Verify that the ACL drops IPv6 packets containing a Destination Option header as shown in the example below.\n\nipv6 access-list FILTER_IPV6\n 10 deny 60 any any dest-option log\n 20 permit ipv6 …\n …\n …\n …\n90 deny ipv6 any any log\n\nNote: Cisco has deprecated the dest-option-type command used to filter by option type within the Destination Option header. Therefore, all packets with the Destination Option header must be dropped.\n\nIf the router is not configured to drop IPv6 packets containing a Destination Option header, this is a finding.","fixText":"Configure the router to drop IPv6 packets containing an option type value of 0x8A (Endpoint Identification) regardless of whether it appears in a Hop-by-Hop or Destination Option header as shown in the example below.\n\nRP/0/0/CPU0:R3(config)# ipv6 access-list FILTER_IPV6\nRP/0/0/CPU0:R3(config-ipv6-acl)# deny 60 any any dest-option log\nRP/0/0/CPU0:R3(config-ipv6-acl)# deny hbh any any dest-option log\nRP/0/0/CPU0:R3(config-ipv6-acl)# permit ipv6 …\n…\n…\n…\nRP/0/0/CPU0:R3(config-ipv6-acl)# deny ipv6 any any log\nRP/0/0/CPU0:R3(config-ipv6-acl)# exit\nRP/0/0/CPU0:R3(config)# interface gigabitethernet 0/2/0/2\nRP/0/0/CPU0:R3(config-if)# ipv6 access-group FILTER_IPV6 ingress\nRP/0/0/CPU0:R3(config-if)# end","ccis":["CCI-002403"]},{"vulnId":"V-230157","ruleId":"SV-230157r1132540_rule","severity":"medium","ruleTitle":"The Cisco perimeter router must be configured to drop IPv6 packets containing the NSAP address option within Destination Option header.","description":"The optional and extensible natures of the IPv6 extension headers require higher scrutiny since many implementations do not always drop packets with headers that it cannot recognize, and hence could cause a Denial-of-Service on the target device. In addition, the type, length, value (TLV) formatting provides the ability for headers to be very large. This option type from RFC 1888 (OSI NSAPs and IPv6) has been deprecated by RFC 4048.","checkContent":"This requirement is not applicable for the DODIN Backbone. \n\nReview the router configuration to determine if it is compliant with this requirement. \n\nStep 1: Verify that an inbound IPv6 ACL has been configured on the external interface.\n\ninterface interface gigabitethernet 0/2/0/2\n ipv6 address 2001::1:0:22/64\n ipv6 access-group FILTER_IPV6 ingress\n\nStep 2: Verify that the ACL drops IPv6 packets containing a Destination Option header as shown in the example below.\n\nipv6 access-list FILTER_IPV6\n 10 deny 60 any any dest-option log\n 20 permit ipv6 …\n …\n …\n …\n 90 deny ipv6 any any log\n\nNote: Cisco has deprecated the dest-option-type command used to filter by option type within the Destination Option header. Therefore, all packets with the Destination Option header must be dropped.\n\nIf the router is not configured to drop IPv6 packets containing a Destination Option header, this is a finding.","fixText":"Configure the router to drop IPv6 packets containing a Destination Option header as shown in the example below.\n\nRP/0/0/CPU0:R3(config)# ipv6 access-list FILTER_IPV6\nRP/0/0/CPU0:R3(config-ipv6-acl)# deny 60 any any dest-option log\nRP/0/0/CPU0:R3(config-ipv6-acl)# permit ipv6 …\n…\n…\n…\nRP/0/0/CPU0:R3(config-ipv6-acl)# deny ipv6 any any log\nRP/0/0/CPU0:R3(config-ipv6-acl)# exit\nRP/0/0/CPU0:R3(config)# interface gigabitethernet 0/2/0/2\nRP/0/0/CPU0:R3(config-if)# ipv6 access-group FILTER_IPV6 ingress\nRP/0/0/CPU0:R3(config-if)# end","ccis":["CCI-002403"]},{"vulnId":"V-230160","ruleId":"SV-230160r1132543_rule","severity":"medium","ruleTitle":"The Cisco perimeter router must be configured to drop IPv6 packets containing a Hop-by-Hop or Destination Option extension header with an undefined option type.","description":"The optional and extensible natures of the IPv6 extension headers require higher scrutiny since many implementations do not always drop packets with headers that it cannot recognize, and hence could cause a Denial-of-Service on the target device. In addition, the type, length, value (TLV) formatting provides the ability for headers to be very large.","checkContent":"This requirement is not applicable for the DODIN Backbone. \n\nReview the router configuration and determine if filters are bound to the applicable interfaces to drop all inbound IPv6 packets containing an undefined option type value regardless of whether they appear in a Hop-by-Hop or Destination Option header. Undefined values are 0x02, 0x03, 0x06, 0x9 – 0xE, 0x10 – 0x22, 0x24, 0x25, 0x27 – 0x2F, and 0x31 – 0xFF.\n\nStep 1: Verify that an inbound IPv6 ACL has been configured on the external interface.\n\ninterface interface gigabitethernet 0/2/0/2\n ipv6 address 2001::1:0:22/64\n ipv6 access-group FILTER_IPV6 ingress\n\nStep 2: Verify that the ACL drops IPv6 packets containing Hop-by-Hop or Destination Option extension headers as shown in the example below.\n\nipv6 access-list FILTER_IPV6\n 10 deny 60 any any dest-option log\n 20 deny hbh any any dest-option log\n 30 permit …\n …\n …\n …\n 90 deny ipv6 any any log\n\n\nNote: Cisco has deprecated the dest-option-type command used to filter by option type within the Destination Option and Hop-by-Hop header. Therefore, all packets with the Destination Option header and Hop-by-Hop options must be dropped.\n\nIf the router is not configured to drop IPv6 packets containing a Hop-by-Hop or Destination Option extension headers with destination options, this is a finding.","fixText":"Configure the router to drop all inbound IPv6 packets containing option type values regardless of whether they appear in a Hop-by-Hop or Destination Option header as shown in the example below.\n\n\nRP/0/0/CPU0:R3(config)# ipv6 access-list FILTER_IPV6\nRP/0/0/CPU0:R3(config-ipv6-acl)# deny 60 any any dest-option log\nRP/0/0/CPU0:R3(config-ipv6-acl)# deny hbh any any dest-option log\nRP/0/0/CPU0:R3(config-ipv6-acl)# permit ipv6 …\n…\n…\n…\nRP/0/0/CPU0:R3(config-ipv6-acl)# deny ipv6 any any log\nRP/0/0/CPU0:R3(config-ipv6-acl)# exit\nRP/0/0/CPU0:R3(config)# interface gigabitethernet 0/2/0/2\nRP/0/0/CPU0:R3(config-if)# ipv6 access-group FILTER_IPV6 ingress\nRP/0/0/CPU0:R3(config-if)# end","ccis":["CCI-002403"]}]}