{
"stig": {
"date": "2021-03-19",
"description": "This Security Technical Implementation Guide is published as a tool to improve the security of Department of Defense (DoD) information systems. The requirements are derived from the National Institute of Standards and Technology (NIST) 800-53 and related documents. Comments or proposed revisions to this document should be sent via email to the following address: disa.stig_spt@mail.mil.",
"findings": {
"V-220419": {
"checkid": "C-22134r508351_chk",
"checktext": "Review the switch configuration to verify that ACLs are configured to allow or deny traffic for specific source and destination addresses as well as ports and protocols. For example, the configuration below will allow only printer traffic into subnet 10.1.12.0/24 and SQL traffic into subnet 10.1.13.0/24. ICMP is allowed for troubleshooting and OSPF is the routing protocol used within the network. \n\ninterface GigabitEthernet0/1 \n no switchport \n ip address 10.2.1.1 255.255.255.252 \n ip access-group FILTER_SERVER_TRAFFIC in \n\u2026 \n\u2026 \n\u2026 \nip access-list extended FILTER_SERVER_TRAFFIC \n permit tcp any 10.1.12.0 0.0.0.255 eq lpd 631 9100 \n permit tcp any 10.1.13.0 0.0.0.255 eq 1433 1434 4022 \n permit icmp any any \n permit ospf any any \n deny ip any any \n\nAlternate: Inter-VLAN routing \n\ninterface Vlan12 \n ip address 10.1.12.1 255.255.255.0 \n ip access-group FILTER_PRINTER_VLAN out \n! \ninterface Vlan13 \n ip address 10.1.13.1 255.255.255.0 \n ip access-group FILTER_SQL_VLAN out \n\u2026 \n\u2026 \n\u2026 \nip access-list extended FILTER_PRINTER_VLAN \n permit tcp any any eq lpd 631 9100 \n permit icmp any any \n deny ip any any \nip access-list extended FILTER_SQL_VLAN \n permit tcp any any eq 1433 1434 4022 \n permit icmp any any \n deny ip any any \n\nIf the switch is not configured to enforce approved authorizations for controlling the flow of information within the network based on organization-defined information flow control policies, this is a finding.",
"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, switches, guards, encrypted tunnels, and firewalls) that employ rule sets or establish configuration settings that restrict information system services, provide a packet-filtering capability based on header information, or provide a message-filtering capability based on message content (e.g., implementing key word searches or using document characteristics).",
"fixid": "F-22123r508352_fix",
"fixtext": "Configure ACLs to allow or deny traffic for specific source and destination addresses as well as ports and protocols between various subnets as required. The commands below were used to create the configuration as shown in the check content: \n\nSW1(config)#ip access-list extended FILTER_SERVER_TRAFFIC \nSW1(config-ext-nacl)#permit tcp any 10.1.12.0 0.0.0.255 eq 515 631 9100 \nSW1(config-ext-nacl)#permit tcp any 10.1.13.0 0.0.0.255 eq 1433 1434 4022 \nSW1(config-ext-nacl)#permit icmp any any \nSW1(config-ext-nacl)#permit ospf any any \nSW1(config-ext-nacl)#deny ip any any \nSW1(config-ext-nacl)#exit \nSW1(config)#interface g0/1 \nSW1(config-if)#ip access-group FILTER_SERVER_TRAFFIC in \nSW1(config-if)#end \n\nAlternate: Inter-VLAN routing \n\nSW1(config)#ip access-list extended FILTER_PRINTER_VLAN \nSW1(config-ext-nacl)#permit tcp any any eq lpd 631 9100 \nSW1(config-ext-nacl)#permit icmp any any \nSW1(config-ext-nacl)#deny ip any any \nSW1(config-ext-nacl)#exit \nSW1(config)#ip access-list extended FILTER_SQL_VLAN \nSW1(config-ext-nacl)#permit tcp any any eq 1433 1434 4022 \nSW1(config-ext-nacl)#permit icmp any any \nSW1(config-ext-nacl)#deny ip any any \nSW1(config-ext-nacl)#exit \nSW1(config)#interface vlan 12 \nSW1(config-if)#ip access-group FILTER_PRINTER_VLAN out \nSW1(config-if)#exit \nSW1(config)#interface vlan 13 \nSW1(config-if)#ip access-group FILTER_SQL_VLAN out \nSW1(config-if)#end",
"iacontrols": null,
"id": "V-220419",
"ruleID": "SV-220419r622190_rule",
"severity": "medium",
"title": "The Cisco switch must be configured to enforce approved authorizations for controlling the flow of information within the network based on organization-defined information flow control policies.",
"version": "CISC-RT-000010"
},
"V-220422": {
"checkid": "C-22137r508354_chk",
"checktext": "Review the switch configuration. For every routing protocol that affects the routing or forwarding tables, verify that the switch is encrypting the authentication key as shown in the examples below: \n\nEIGRP example: \n\ninterface GigabitEthernet1/0 \n no switchport \n ip address x.x.x.x 255.255.255.0 \n ip authentication mode eigrp 1 md5 \n ip authentication key-chain eigrp 1 EIGRP_KEY_CHAIN \n\nOSPF example: \n\ninterface GigabitEthernet1/0 \n no switchport \n ip address x.x.x.x 255.255.255.0 \n ip ospf authentication message-digest \n ip ospf message-digest-key 1 md5 xxxxxx \n\nRIP example: \n\ninterface GigabitEthernet1/0 \n no switchport \n ip rip authentication mode md5 \n ip rip authentication key-chain RIP_KEY_CHAIN \n\nIf the routing protocol is not encrypting the authentication key, this is a finding.",
"description": "A rogue switch could send a fictitious routing update to convince a site's perimeter switch to send traffic to an incorrect or even a rogue destination. This diverted traffic could be analyzed to learn confidential information about the site's network or used to disrupt the network's ability to communicate with other networks. \n\nThis is known as a \"traffic attraction attack\" and is prevented by configuring neighbor switch authentication for routing updates. However, using clear-text authentication provides little benefit since an attacker can intercept traffic and view the authentication key. This would allow the attacker to use the authentication key in an attack. \n\nThis requirement applies to all IPv4 and IPv6 protocols that are used to exchange routing or packet forwarding information; this includes all Interior Gateway Protocols (such as OSPF, EIGRP, and IS-IS) and Exterior Gateway Protocols (such as BGP), MPLS-related protocols (such as LDP), and multicast-related protocols.",
"fixid": "F-22126r508355_fix",
"fixtext": "Configure all routing protocol authentications to encrypt the authentication key. \n\nEIGRP example: \n\nSW2(config)#int g0/1 \nSW2(config-if)#ip authentication mode eigrp 1 md5 \nSW2(config-if)#ip authentication key-chain eigrp 1 EIGRP_KEY_CHAIN \n\nOSPF example: \n\nSW1(config)#int g1/0 \nSW1(config-if)#ip ospf authentication message-digest \nSW1(config-if)#ip ospf message-digest-key 1 md5 xxxxxx \n\nRIP example: \n\nSW2(config)#int g1/0 \nSW2(config-if)#ip rip authentication mode md5 \nSW2(config-if)#ip rip authentication key-chain RIP_KEY_CHAIN",
"iacontrols": null,
"id": "V-220422",
"ruleID": "SV-220422r622190_rule",
"severity": "medium",
"title": "The Cisco switch must be configured to use encryption for routing protocol authentication.",
"version": "CISC-RT-000040"
},
"V-220423": {
"checkid": "C-22138r508357_chk",
"checktext": "Review the switch configuration to verify it is using a NIST-validated FIPS 198-1 message authentication code algorithm to authenticate routing protocol messages. \n\nOSPF example: \n\nkey chain OSPF_KEY_CHAIN \n key 1 \n key-string xxxxxxx \n send-lifetime 00:00:00 Jan 1 2018 23:59:59 Mar 31 2018 \n accept-lifetime 00:00:00 Jan 1 2018 01:05:00 Apr 1 2018 \n cryptographic-algorithm hmac-sha-256 \n key 2 \n key-string yyyyyyy \n send-lifetime 00:00:00 Apr 1 2018 23:59:59 Jun 30 2018 \n accept-lifetime 23:55:00 Mar 31 2018 01:05:00 Jul 1 2018 \n cryptographic-algorithm hmac-sha-256 \n\u2026 \n\u2026 \n\u2026 \ninterface GigabitEthernet0/1 \n no switchport \n ip address x.x.x.x 255.255.255.0 \n ip ospf authentication key-chain OSPF_KEY_CHAIN \n\nIf a NIST-validated FIPS 198-1 message authentication code algorithm is not being used to authenticate routing protocol messages, this is a finding.",
"description": "A rogue switch could send a fictitious routing update to convince a site's perimeter switch to send traffic to an incorrect or even a rogue destination. This diverted traffic could be analyzed to learn confidential information about the site's network or used to disrupt the network's ability to communicate with other networks. \n\nThis is known as a \"traffic attraction attack\" and is prevented by configuring neighbor switch authentication for routing updates. However, using clear-text authentication provides little benefit since an attacker can intercept traffic and view the authentication key. This would allow the attacker to use the authentication key in an attack. \n\nSince MD5 is vulnerable to \"birthday\" attacks and may be compromised, routing protocol authentication must use FIPS 140-2 validated algorithms and modules to encrypt the authentication key. This requirement applies to all IPv4 and IPv6 protocols that are used to exchange routing or packet forwarding information; this includes all Interior Gateway Protocols (such as OSPF, EIGRP, and IS-IS) and Exterior Gateway Protocols (such as BGP), MPLS-related protocols (such as LDP), and multicast-related protocols.",
"fixid": "F-22127r508358_fix",
"fixtext": "Configure routing protocol authentication to use a NIST-validated FIPS 198-1 message authentication code algorithm as shown in the example below: \n\nSW1(config)#key chain OSPF_KEY_CHAIN \nSW1(config-keychain)#key 1 \nSW1(config-keychain-key)#key-string xxxxxx \nSW1(config-keychain-key)#send-lifetime 00:00:00 Jan 1 2018 23:59:59 Mar 31 2018 \nSW1(config-keychain-key)#accept-lifetime 00:00:00 Jan 1 2018 01:05:00 Apr 1 2018 \nSW1(config-keychain-key)#cryptographic-algorithm hmac-sha-256 \nSW1(config-keychain-key)#exit \nSW1(config-keychain)#key 2 \nSW1(config-keychain-key)#key-string yyyyyyy \nSW1(config-keychain-key)#send-lifetime 00:00:00 Apr 1 2018 23:59:59 Jun 30 2018 \nSW1(config-keychain-key)#accept-lifetime 23:55:00 Mar 31 2018 01:05:00 Jul 1 2018 \nSW1(config-keychain-key)#cryptographic-algorithm hmac-sha-256 \nSW1(config-keychain-key)#end \nSW1(config)#interface GigabitEthernet0/2 \nSW1(config-if)#ip ospf authentication key-chain OSPF_KEY_CHAIN",
"iacontrols": null,
"id": "V-220423",
"ruleID": "SV-220423r622190_rule",
"severity": "medium",
"title": "The Cisco switch must be configured to authenticate all routing protocol messages using NIST-validated FIPS 198-1 message authentication code algorithm.",
"version": "CISC-RT-000050"
},
"V-220424": {
"checkid": "C-22139r508360_chk",
"checktext": "Review the switch configuration and verify that inactive interfaces have been disabled as shown below: \n\ninterface GigabitEthernet3 \n no switchport \n shutdown \n! \ninterface GigabitEthernet4 \n no switchport \n shutdown \n\nIf an interface is not being used but is configured or enabled, this is a finding.",
"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 switch 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 inactive. If the sub-interface is no longer necessary for authorized communications, it must be deleted.",
"fixid": "F-22128r508361_fix",
"fixtext": "Disable all inactive interfaces as shown below: \n\nSW1(config)#interface GigabitEthernet3 \nSW1(config-if)#shutdown \nSW1(config)#interface GigabitEthernet4 \nSW1(config-if)#shutdown",
"iacontrols": null,
"id": "V-220424",
"ruleID": "SV-220424r622190_rule",
"severity": "low",
"title": "The Cisco switch must be configured to have all inactive Layer 3 interfaces disabled.",
"version": "CISC-RT-000060"
},
"V-220425": {
"checkid": "C-22140r508363_chk",
"checktext": "Review the switch configuration to verify that the switch does not have any unnecessary or non-secure services enabled. For example, the following commands should not be in the configuration: \n\nboot network \nip boot server \nip bootp server \nip dns server \nip identd \nip finger \nip http server \nip rcmd rcp-enable \nip rcmd rsh-enable \nservice config \nservice finger \nservice tcp-small-servers \nservice udp-small-servers \nservice pad \n\nIf any unnecessary services are enabled, this is a finding.",
"description": "A compromised switch 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. \n\nPreventing 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 switch is to enable only the capabilities required for operation.",
"fixid": "F-22129r508364_fix",
"fixtext": "Disable the following services if enabled as shown in the example below: \n\nSW2(config)#no boot network \nSW2(config)#no ip boot server \nSW2(config)#no ip bootp server \nSW2(config)#no ip dns server \nSW2(config)#no ip identd \nSW2(config)#no ip finger \nSW2(config)#no ip http server \nSW2(config)#no ip rcmd rcp-enable \nSW2(config)#no ip rcmd rsh-enable \nSW2(config)#no service config \nSW2(config)#no service finger \nSW2(config)#no service tcp-small-servers \nSW2(config)#no service udp-small-servers \nSW2(config)#no service pad",
"iacontrols": null,
"id": "V-220425",
"ruleID": "SV-220425r622190_rule",
"severity": "low",
"title": "The Cisco switch must be configured to have all non-essential capabilities disabled.",
"version": "CISC-RT-000070"
},
"V-220427": {
"checkid": "C-22142r508366_chk",
"checktext": "Review the device configuration to determine if auto-configuration or zero-touch deployment via Cisco Networking Services (CNS) is enabled. \n\nAuto-configuration example: \n\nversion 15.0 \nservice config \n\u2026 \n\u2026 \n\u2026 \nboot-start-marker \nboot network tftp://x.x.x.x/R5-config \nboot-end-marker \n\nCNS Zero-Touch example: \n\ncns trusted-server config x.x.x.x \ncns trusted-server image x.x.x.x \ncns config initial x.x.x.x 80 \ncns exec 80 \ncns image \n\nIf a configuration auto-loading feature or zero-touch deployment feature is enabled, this is a finding. \n\nNote: Auto-configuration or zero-touch deployment features can be enabled when the switch is offline for the purpose of image loading or building out the configuration. In addition, this would not be applicable to the provisioning of virtual switches via a software-defined network (SDN) orchestration system.",
"description": "Network devices that are configured via a zero-touch deployment or auto-loading feature can have their startup configuration or image pushed to the device for installation via TFTP or Remote Copy (rcp). Loading an image or configuration file from the network is taking a security risk because the file could be intercepted by an attacker who could corrupt the file, resulting in a denial of service.",
"fixid": "F-22131r508367_fix",
"fixtext": "Disable configuration auto-loading if enabled using the following commands: \n\nSW1(config)#no boot network \nSW1(config)#no service config \n\nDisable CNS zero-touch deployment if enabled as shown in the example below: \n\nSW2(config)#no cns config initial \nSW2(config)#no cns exec \nSW2(config)#no cns image \nSW2(config)#no cns trusted-server config x.x.x.x \nSW2(config)#no cns trusted-server image x.x.x.x",
"iacontrols": null,
"id": "V-220427",
"ruleID": "SV-220427r622190_rule",
"severity": "medium",
"title": "The Cisco switch must not be configured to have any zero-touch deployment feature enabled when connected to an operational network.",
"version": "CISC-RT-000090"
},
"V-220428": {
"checkid": "C-22143r508369_chk",
"checktext": "Review the Cisco switch configuration to verify that is protects against known types of DoS attacks by employing organization-defined security safeguards. \n\nStep 1: Verify traffic types have been classified based on importance levels. The following is an example configuration: \n\nclass-map match-all CoPP_CRITICAL \nmatch access-group name CoPP_CRITICAL \nclass-map match-any CoPP_IMPORTANT \nmatch access-group name CoPP_IMPORTANT \nmatch protocol arp \nclass-map match-all CoPP_NORMAL \nmatch access-group name CoPP_NORMAL \nclass-map match-any CoPP_UNDESIRABLE \nmatch access-group name CoPP_UNDESIRABLE \nclass-map match-all CoPP_DEFAULT \nmatch access-group name CoPP_DEFAULT \n\nStep 2: Review the access control lists (ACLs) referenced by the class maps to determine if the traffic is being classified appropriately. The following is an example configuration: \n\nip access-list extended CoPP_CRITICAL \nremark our control plane adjacencies are critical \npermit ospf host [OSPF neighbor A] any \npermit ospf host [OSPF neighbor B] any \npermit pim host [PIM neighbor A] any \npermit pim host [PIM neighbor B] any \npermit pim host [RP addr] any \npermit igmp any 224.0.0.0 15.255.255.255 \ndeny ip any any \n\nip access-list extended CoPP_IMPORTANT \npermit tcp host [TACACS server] eq tacacs any \npermit tcp [management subnet] 0.0.0.255 any eq 22 \npermit udp host [SNMP manager] any eq snmp \npermit udp host [NTP server] eq ntp any \ndeny ip any any \n\nip access-list extended CoPP_NORMAL \nremark we will want to rate limit ICMP traffic \npermit icmp any any echo \npermit icmp any any echo-reply \npermit icmp any any time-exceeded \npermit icmp any any unreachable \ndeny ip any any \n\nip access-list extended CoPP_UNDESIRABLE \nremark other management plane traffic that should not be received \npermit udp any any eq ntp \npermit udp any any eq snmp \npermit tcp any any eq 22 \npermit tcp any any eq 23 \nremark other control plane traffic not configured on switch \npermit eigrp any any \npermit udp any any eq rip \ndeny ip any any \n\nip access-list extended CoPP_DEFAULT \npermit ip any any \n\nNote: Explicitly defining undesirable traffic with ACL entries enables the network operator to collect statistics. Excessive ARP packets can potentially monopolize Route Processor resources, starving other important processes. Currently, ARP is the only Layer 2 protocol that can be specifically classified using the match protocol command. \n\nStep 3: Review the policy-map to determine if the traffic is being policed appropriately for each classification. The following is an example configuration: \n\npolicy-map CONTROL_PLANE_POLICY \nclass CoPP_CRITICAL \npolice 512000 8000 conform-action transmit exceed-action transmit \nclass CoPP_IMPORTANT \npolice 256000 4000 conform-action transmit exceed-action drop \nclass CoPP_NORMAL \npolice 128000 2000 conform-action transmit exceed-action drop \nclass CoPP_UNDESIRABLE \npolice 8000 1000 conform-action drop exceed-action drop \nclass CoPP_DEFAULT \npolice 64000 1000 conform-action transmit exceed-action drop \n\nStep 4: Verify that the Control Plane Policing (CoPP) policy is enabled. The following is an example configuration: \n\ncontrol-plane \nservice-policy input CONTROL_PLANE_POLICY \n\nNote: Control Plane Protection (CPPr) can be used to filter as well as police control plane traffic destined to the RP. CPPr is very similar to CoPP and has the ability to filter and police traffic using finer granularity by dividing the aggregate control plane into three separate categories: 1) host, 2) transit, and 3) CEF-exception. Hence, a separate policy-map could be configured for each traffic category. \n\nIf the Cisco switch is not configured to protect against known types of DoS attacks by employing organization-defined security safeguards, this is a finding.",
"description": "The Route Processor (RP) is critical to all network operations because it is the component used to build all forwarding paths for the data plane via control plane processes. It is also instrumental with ongoing network management functions that keep the switches and links available for providing network services. Any disruption to the RP or the control and management planes can result in mission-critical network outages. \n\nA DoS attack targeting the RP can result in excessive CPU and memory utilization. To maintain network stability and RP security, the switch must be able to handle specific control plane and management plane traffic that is destined to the RP. In the past, one method of filtering was to use ingress filters on forwarding interfaces to filter both forwarding path and receiving path traffic. However, this method does not scale well as the number of interfaces and the size of the ingress filters grow. \n\nControl plane policing increases the security of switches and multilayer switches by protecting the RP from unnecessary or malicious traffic. Filtering and rate limiting the traffic flow of control plane packets can be implemented to protect switches against reconnaissance and DoS attacks, allowing the control plane to maintain packet forwarding and protocol states despite an attack or heavy load on the switch or multilayer switch.",
"fixid": "F-22132r508370_fix",
"fixtext": "Configure the Cisco switch to protect against known types of DoS attacks on the route processor. Implementing a CoPP policy as shown in the example below is a best practice method: \n\nStep 1: Configure ACL specific traffic types. \n\nSW1(config)#ip access-list extended CoPP_CRITICAL \nSW1(config-ext-nacl)#remark our control plane adjacencies are critical \nSW1(config-ext-nacl)#permit ospf host x.x.x.x any \nSW1(config-ext-nacl)#permit ospf host x.x.x.x any \nSW1(config-ext-nacl)#permit pim host x.x.x.x any \nSW1(config-ext-nacl)#permit pim host x.x.x.x any \nSW1(config-ext-nacl)#permit igmp any 224.0.0.0 15.255.255.255 \nSW1(config-ext-nacl)#deny ip any any \nSW1(config-ext-nacl)#exit \n\nSW1(config)#ip access-list extended CoPP_IMPORTANT \nSW1(config-ext-nacl)#permit tcp host x.x.x.x eq tacacs any \nSW1(config-ext-nacl)#permit tcp x.x.x.x 0.0.0.255 any eq 22 \nSW1(config-ext-nacl)#permit udp host x.x.x.x any eq snmp \nSW1(config-ext-nacl)#permit udp host x.x.x.x eq ntp any \nSW1(config-ext-nacl)#deny ip any any \nSW1(config-ext-nacl)#exit \n\nSW1(config)#ip access-list extended CoPP_NORMAL \nSW1(config-ext-nacl)#remark we will want to rate limit ICMP traffic \nSW1(config-ext-nacl)#permit icmp any any echo \nSW1(config-ext-nacl)#permit icmp any any echo-reply \nSW1(config-ext-nacl)#permit icmp any any time-exceeded \nSW1(config-ext-nacl)#permit icmp any any unreachable \nSW1(config-ext-nacl)#deny ip any any \nSW1(config-ext-nacl)#exit \n\nSW1(config)#ip access-list extended CoPP_UNDESIRABLE \nSW1(config-ext-nacl)#remark management plane traffic that should not be received \nSW1(config-ext-nacl)#permit udp any any eq ntp \nSW1(config-ext-nacl)#permit udp any any eq snmp \nSW1(config-ext-nacl)#permit tcp any any eq 22 \nSW1(config-ext-nacl)#permit tcp any any eq 23 \nSW1(config-ext-nacl)#remark control plane traffic not configured on switch \nSW1(config-ext-nacl)#permit eigrp any any \nSW1(config-ext-nacl)#permit udp any any eq rip \nSW1(config-ext-nacl)#deny ip any any \nSW1(config-ext-nacl)#exit \nSW1(config)#ip access-list extended CoPP_DEFAULT \nSW1(config-ext-nacl)#permit ip any any \nSW1(config-ext-nacl)#exit \n\nStep 2: Configure class-maps referencing each of the ACLs. \n\nSW1(config)#class-map match-all CoPP_CRITICAL \nSW1(config-cmap)#match access-group name CoPP_CRITICAL \nSW1(config-cmap)#class-map match-any CoPP_IMPORTANT \nSW1(config-cmap)#match access-group name CoPP_IMPORTANT \nSW1(config-cmap)#match protocol arp \nSW1(config-cmap)#class-map match-all CoPP_NORMAL \nSW1(config-cmap)#match access-group name CoPP_NORMAL \nSW1(config-cmap)#class-map match-any CoPP_UNDESIRABLE \nSW1(config-cmap)#match access-group name CoPP_UNDESIRABLE \nSW1(config-cmap)#class-map match-all CoPP_DEFAULT \nSW1(config-cmap)#match access-group name CoPP_DEFAULT \nSW1(config-cmap)#exit \n\nStep 3: Configure a policy-map referencing the configured class-maps and apply appropriate bandwidth allowance and policing attributes. \n\nSW1(config)#policy-map CONTROL_PLANE_POLICY \nSW1(config-pmap)#class CoPP_CRITICAL \nSW1(config-pmap-c)#police 512000 8000 conform-action transmit exceed-action transmit \nSW1(config-pmap-c-police)#class CoPP_IMPORTANT \nSW1(config-pmap-c)#police 256000 4000 conform-action transmit exceed-action drop \nSW1(config-pmap-c-police)#class CoPP_NORMAL \nSW1(config-pmap-c)#police 128000 2000 conform-action transmit exceed-action drop \nSW1(config-pmap-c-police)#class CoPP_UNDESIRABLE \nSW1(config-pmap-c)#police 8000 1000 conform-action drop exceed-action drop \nSW1(config-pmap-c-police)#class CoPP_DEFAULT \nSW1(config-pmap-c)#police 64000 1000 conform-action transmit exceed-action drop \nSW1(config-pmap-c-police)#exit \nSW1(config-pmap-c)#exit \nSW1(config-pmap)#exit \n\nStep 4: Apply the policy-map to the control plane. \n\nSW1(config)#control-plane \nSW1(config-cp)#service-policy input CONTROL_PLANE_POLICY \nSW1(config-cp)#end",
"iacontrols": null,
"id": "V-220428",
"ruleID": "SV-220428r622190_rule",
"severity": "medium",
"title": "The Cisco switch must be configured to protect against or limit the effects of denial-of-service (DoS) attacks by employing control plane protection.",
"version": "CISC-RT-000120"
},
"V-220429": {
"checkid": "C-22144r508372_chk",
"checktext": "Review the external and internal access control lists (ACLs) to verify that the switch is configured to only allow specific management and control plane traffic from specific sources destined to itself. \n\nStep 1: Verify that ACLs have been configured as shown in the example below that matches expected control plane and management plane traffic. With the exception of Internet Control Message Protocol (ICMP), all other traffic destined to the switch should be dropped. \n\nip access-list extended EXTERNAL_ACL \n permit icmp host x.11.1.1 host x.11.1.2 echo \n permit icmp host x.11.1.1 host x.11.1.2 echo-reply \n deny ip any host x.11.1.1 log-input \n permit \u2026 \n \u2026 \n \u2026 \n \u2026 \ndeny ip any any log-input \n\nip access-list extended INTERNAL_ACL \n permit icmp any any \n permit ospf host 10.1.12.1 host 10.1.12.2 \n permit tcp 10.2.1.0 0.0.0.255 host 10.1.12.2 eq 22 \n permit tcp 10.2.1.0 0.0.0.255 host 10.1.12.2 eq tacacs \n permit udp 10.2.1.0 0.0.0.255 host 10.1.12.2 eq snmp \n permit udp 10.2.1.0 0.0.0.255 host 10.1.12.2 eq ntp \n deny ip any host 10.1.12.2 log-input \n permit \u2026 \n \u2026 \n \u2026 \n \u2026 \ndeny ip any any log-input \n\nNote: For the internal ACL example, all switches within the hypothetical network (10.1.0.0/16) have been configured to use the loopback address to source all management traffic (not shown); hence, the loopbacks are the only allowable destination address for management traffic. In addition, all management traffic destined to the switch must originate from the management network (10.2.1.0/24). With the exception of link-local control plane traffic and ICMP, all other traffic destined to any physical interface address will be dropped. \n\nStep 2: Verify that the ACL has been applied to the appropriate interface as shown in the example below: \n\ninterface GigabitEthernet0/2 \n no switchport \n ip address x.11.1.2 255.255.255.254 \n ip access-group EXTERNAL_ACL in \ninterface GigabitEthernet0/3 \n no switchport \n ip address 10.1.12.2 255.255.255.0 \n ip access-group INTERNAL_ACL in \n\nIf the switch is not configured to restrict traffic destined to itself, this is a finding.",
"description": "The route processor handles traffic destined to the switch. This is the key component used to build forwarding paths and is instrumental with all network management functions. Hence, any disruption or denial-of-service (DoS) attack to the route processor can result in mission-critical network outages.",
"fixid": "F-22133r508373_fix",
"fixtext": "Step 1: Configure the ACL for any external interfaces as shown in the example below: \n\nSW1(config)#ip access-list extended EXTERNAL_ACL \nSW1(config-ext-nacl)#permit icmp host x.11.1.1 host x.11.1.2 echo \nSW1(config-ext-nacl)#permit icmp host x.11.1.1 host x.11.1.2 echo-reply \nSW1(config-ext-nacl)#deny ip any host x.11.1.1 log-input \nSW1(config-ext-nacl)#permit \u2026 \n\u2026 \n\u2026 \n\u2026 \nSW1(config-ext-nacl)#deny ip any any log-input \n\nStep 2: Configure the ACL for any external interfaces as shown in the example below: \n\nSW1(config)#ip access-list extended INTERNAL_ACL \nSW1(config-ext-nacl)#permit ospf host 10.1.12.1 host 10.1.12.2 \nSW1(config-ext-nacl)#permit tcp 10.2.1.0 0.0.0.255 host 10.1.12.2 eq 22 \nSW1(config-ext-nacl)#permit tcp 10.2.1.0 0.0.0.255 host 10.1.12.2 eq tacacs \nSW1(config-ext-nacl)#permit udp 10.2.1.0 0.0.0.255 host 10.1.12.2 eq snmp \nSW1(config-ext-nacl)#permit udp 10.2.1.0 0.0.0.255 host 10.1.12.2 eq ntp \nSW1(config-ext-nacl)#deny ip any host 10.1.12.2 log-input \nSW1(config-ext-nacl)#permit \u2026 \n\u2026 \n\u2026 \n\u2026 \nSW1(config-ext-nacl)#permit ip any any log-input \nSW1(config-ext-nacl)#exit \n\nNote: Best practice is to configure the ACL statements relative to traffic destined to the switch first followed by ACL statements for transit traffic. \n\nStep 3: Apply the ACLs to the appropriate interface as shown in the example below: \n\nSW1(config)#int g0/2 \nSW1(config-if)#ip access-group EXTERNAL_ACL in \nSW1(config)#int g0/3 \nSW1(config-if)#ip access-group INTERNAL_ACL in",
"iacontrols": null,
"id": "V-220429",
"ruleID": "SV-220429r622190_rule",
"severity": "high",
"title": "The Cisco switch must be configured to restrict traffic destined to itself.",
"version": "CISC-RT-000130"
},
"V-220430": {
"checkid": "C-22145r508375_chk",
"checktext": "Review the external and internal access control lists (ACLs) to verify that the switch is configured drop all fragmented ICMP packets destined to itself. \n\nip access-list extended EXTERNAL_ACL \n deny icmp any host x.11.1.2 fragments \n permit icmp host x.11.1.1 host x.11.1.2 echo \n\u2026 \n \u2026 \ndeny ip any any \n! \nip access-list extended INTERNAL_ACL \ndeny icmp any host 10.1.12.2 fragments \npermit icmp any any \n\nNote: Ensure the statement to deny ICMP fragments is before any permit statements for ICMP. \n\nIf the switch is not configured to drop all fragmented ICMP packets destined to itself, this is a finding.",
"description": "Fragmented ICMP packets can be generated by hackers for denial-of-service (DoS) attacks such as Ping O' Death and Teardrop. It is imperative that all fragmented ICMP packets are dropped.",
"fixid": "F-22134r508376_fix",
"fixtext": "Configure the external and internal ACLs to drop all fragmented ICMP packets destined to itself as shown in the example below: \n\nSW1(config)#ip access-list extended EXTERNAL_ACL \nSW1(config-ext-nacl)#deny icmp any host x.11.1.2 fragments \n\nSW1(config)#ip access-list extended INTERNAL_ACL \nSW1(config-ext-nacl)#deny icmp any host 10.1.12.2 fragments \n\nNote: Ensure the above statement is before any permit statements for ICMP.",
"iacontrols": null,
"id": "V-220430",
"ruleID": "SV-220430r622190_rule",
"severity": "medium",
"title": "The Cisco switch must be configured to drop all fragmented Internet Control Message Protocol (ICMP) packets destined to itself.",
"version": "CISC-RT-000140"
},
"V-220431": {
"checkid": "C-22146r508378_chk",
"checktext": "Review the configuration to determine if gratuitous ARP is disabled. The following command should not be found in the switch configuration: \n\nip gratuitous-arps \n\nNote: With Cisco IOS, gratuitous ARP is enabled and disabled globally. \n\nIf gratuitous ARP is enabled on any external interface, this is a finding.",
"description": "A gratuitous ARP is an ARP broadcast in which the source and destination MAC addresses are the same. It is used to inform the network about a host IP address. A spoofed gratuitous ARP message can cause network mapping information to be stored incorrectly, causing network malfunction.",
"fixid": "F-22135r508379_fix",
"fixtext": "Disable gratuitous ARP as shown in the example below: \n\nSW1(config)#no ip gratuitous-arps",
"iacontrols": null,
"id": "V-220431",
"ruleID": "SV-220431r622190_rule",
"severity": "medium",
"title": "The Cisco switch must be configured to have gratuitous ARP disabled on all external interfaces.",
"version": "CISC-RT-000150"
},
"V-220432": {
"checkid": "C-22147r508381_chk",
"checktext": "Review the switch configuration to determine if IP directed broadcast is disabled. The IP directed broadcast command must not be found on any interface as shown in the example below: \n\ninterface GigabitEthernet0/1 \n no switchport \n ip address x.x.x.x 255.255.255.0 \n ip directed-broadcast \n\u2026 \n\u2026 \n\u2026 \nInterface Vlan11 \nno switchport \n ip address x.x.x.x 255.255.255.0 \n ip directed-broadcast \n\nIf IP directed broadcast is not disabled on all interfaces, this is a finding.",
"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 switch 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 switches and last-hop switches before entering and leaving the multicast transit area respectively. The last-hop switch must convert the multicast to broadcast. Hence, this interface must be configured to forward a broadcast packet (i.e., a directed broadcast address is converted to the all nodes broadcast address).",
"fixid": "F-22136r508382_fix",
"fixtext": "Disable IP directed broadcast on all interfaces as shown in the example below: \n\nSW1(config)#int g0/1 \nSW1(config-if)#no ip directed-broadcast \nSW1(config)#int vlan11 \nSW1(config-if)#no ip directed-broadcast",
"iacontrols": null,
"id": "V-220432",
"ruleID": "SV-220432r622190_rule",
"severity": "low",
"title": "The Cisco switch must be configured to have IP directed broadcast disabled on all interfaces.",
"version": "CISC-RT-000160"
},
"V-220433": {
"checkid": "C-22148r508384_chk",
"checktext": "Review the configuration to verify the no ip unreachables command has been configured on all external interfaces as shown in the configuration example below: \n\ninterface GigabitEthernet0/1 \n ip address x.x.x.x 255.255.255.0 \n no ip unreachables \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 switch is configured to rate limit ICMP unreachable messages as shown in the example below: \n\nip icmp rate-limit unreachable 60000 \nip icmp 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 DoS attack. \n\nIf the PE switch is not configured to rate limit ICMP unreachable messages, this is a finding.",
"description": "The ICMP supports IP traffic by relaying information about paths, routes, and network conditions. Switches automatically send ICMP messages under a wide variety of conditions. Host unreachable ICMP messages are commonly used by attackers for network mapping and diagnosis.",
"fixid": "F-22137r508385_fix",
"fixtext": "Step 1: Disable ip unreachables on all external interfaces. \n\nSW1(config)#int g0/1 \nSW1(config-if)#no ip unreachables \n\nStep 2: Disable ip unreachables on the Null0 interface if it is used to backhole packets. \n\nSW1(config-if)#int null 0 \nSW1(config-if)#no ip unreachables \n\nAlternative - DODIN Backbone: \n\nConfigure the PE switch to rate limit ICMP unreachable messages as shown in the example below: \n\nSW1(config)#ip icmp rate-limit unreachable df 100 \nSW1(config)#ip icmp rate-limit unreachable 100000 \nSW1(config)#end \n\nAlternative - Non-DODIN Backbone: \n\nAn alternative for non-backbone networks (e.g., enclave, base, camp, etc.) is to filter messages generated by the switch and silently drop ICMP Administratively Prohibited and Host Unreachable messages using the following configuration steps: \n\nStep 1: Configure ACL to include ICMP Type 3 Code 1 (Host Unreachable) and Code 13 (Administratively Prohibited) as shown in the example below: \n\nSW1(config)#ip access-list ext ICMP_T3C1C13 \nSW1(config-ext-nacl)#permit icmp any any host-unreachable \nSW1(config-ext-nacl)#permit icmp any any administratively-prohibited \nSW1(config-ext-nacl)#exit \n\nStep 2: Create a route-map to forward these ICMP messages to the Null0 interface. \n\nSW1(config)#route-map LOCAL_POLICY \nSW1(config-route-map)#match ip address ICMP_T3C1C13 \nSW1(config-route-map)#set interface Null0 \nSW1(config-route-map)#exit \n\nStep 3: Configure no ip unreachables on the Null0 interface. \n\nSW1(config)#int null 0 \nSW1(config-if)#no ip unreachables \nSW1(config-if)#exit \n\nStep 4: Apply the policy to filter messages generated by the switch. \n\nSW1(config)#ip local policy route-map LOCAL_POLICY \nSW1(config)#end",
"iacontrols": null,
"id": "V-220433",
"ruleID": "SV-220433r622190_rule",
"severity": "medium",
"title": "The Cisco switch must be configured to have Internet Control Message Protocol (ICMP) unreachable messages disabled on all external interfaces.",
"version": "CISC-RT-000170"
},
"V-220434": {
"checkid": "C-22149r508387_chk",
"checktext": "Review the switch configuration and verify that ip mask-reply command is not enabled on any external interfaces as shown in the example below: \n\ninterface GigabitEthernet0/1 \n ip address x.x.x.x 255.255.255.0 \n ip mask-reply \n\nIf the ip mask-reply command is configured on any external interface, this is a finding.",
"description": "The ICMP supports IP traffic by relaying information about paths, routes, and network conditions. Switches automatically send ICMP messages under a wide variety of conditions. Mask Reply ICMP messages are commonly used by attackers for network mapping and diagnosis.",
"fixid": "F-22138r508388_fix",
"fixtext": "Disable ip mask-reply on all external interfaces as shown below: \n\nSW1(config)#int g0/1 \nSW1(config-if)#no ip mask-reply",
"iacontrols": null,
"id": "V-220434",
"ruleID": "SV-220434r622190_rule",
"severity": "medium",
"title": "The Cisco switch must be configured to have Internet Control Message Protocol (ICMP) mask reply messages disabled on all external interfaces.",
"version": "CISC-RT-000180"
},
"V-220435": {
"checkid": "C-22150r508390_chk",
"checktext": "Review the switch configuration to verify that the no ip redirects command has been configured on all external interfaces as shown in the example below: \n\ninterface GigabitEthernet0/1 \n ip address x.x.x.x 255.255.255.0 \n no ip redirects \n\nIf ICMP Redirect messages are enabled on any external interfaces, this is a finding.",
"description": "The ICMP supports IP traffic by relaying information about paths, routes, and network conditions. Switches automatically send ICMP messages under a wide variety of conditions. Redirect ICMP messages are commonly used by attackers for network mapping and diagnosis.",
"fixid": "F-22139r508391_fix",
"fixtext": "Disable ICMP redirects on all external interfaces as shown in the example below: \n\nSW1(config)#int g0/1 \nSW1(config-if)#no ip redirects",
"iacontrols": null,
"id": "V-220435",
"ruleID": "SV-220435r622190_rule",
"severity": "medium",
"title": "The Cisco switch must be configured to have Internet Control Message Protocol (ICMP) redirect messages disabled on all external interfaces.",
"version": "CISC-RT-000190"
},
"V-220436": {
"checkid": "C-22151r508393_chk",
"checktext": "Review all ACLs used to filter traffic and verify that packets being dropped at interfaces via an ACL are logged as shown in the configuration below: \n\nip access-list extended INGRESS_FILTER \n permit tcp any any established \n permit tcp any host x.11.1.5 eq www \n permit icmp host x.11.1.1 host x.11.1.2 echo \n permit icmp any any echo-reply \n\u2026 \n \u2026 \n \u2026 \ndeny ip any any log \n\nIf packets being dropped are not logged, this is a finding.",
"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.",
"fixid": "F-22140r508394_fix",
"fixtext": "Configure ACLs to log packets that are dropped as shown in the example below: \n\nSW1(config)#ip access-list extended INGRESS_FILTER \n\u2026 \n\u2026 \n\u2026 \nSW1(config-ext-nacl)#deny ip any any log",
"iacontrols": null,
"id": "V-220436",
"ruleID": "SV-220436r622190_rule",
"severity": "low",
"title": "The Cisco switch must be configured to log all packets that have been dropped at interfaces via an access control list (ACL).",
"version": "CISC-RT-000200"
},
"V-220437": {
"checkid": "C-22152r508396_chk",
"checktext": "Review the switch configuration to verify that events are logged containing information to establish where the events occurred as shown in the example below: \n\nip access-list extended INGRESS_FILTER \n permit tcp any any established \n permit tcp any host x.11.1.5 eq www \n permit icmp host x.11.1.1 host x.11.1.2 echo \n permit icmp any any echo-reply \n\u2026 \n \u2026 \n \u2026 \ndeny ip any any log-input \n\nNote: When the log-input parameter is configured on deny statements, the log record will contain the interface where the ingress packet has been dropped. \n\nIf the switch is not configured to produce audit records containing information to establish to establish where the events occurred, this is a finding.",
"description": "Without establishing where events occurred, it is impossible to establish, correlate, and investigate the events leading up to an outage or attack. \n\nTo compile an accurate risk assessment and provide forensic analysis, it is essential for security personnel to know where events occurred, such as switch 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 switch.",
"fixid": "F-22141r508397_fix",
"fixtext": "Configure the switch to log events containing information to establish where the events occurred as shown in the example below: \n\nSW1(config)#ip access-list extended INGRESS_FILTER \n\u2026 \n\u2026 \n\u2026 \nSW1(config-ext-nacl)#deny ip any any log-input",
"iacontrols": null,
"id": "V-220437",
"ruleID": "SV-220437r622190_rule",
"severity": "medium",
"title": "The Cisco switch must be configured to produce audit records containing information to establish where the events occurred.",
"version": "CISC-RT-000210"
},
"V-220438": {
"checkid": "C-22153r508399_chk",
"checktext": "Review the switch configuration to verify that events are logged containing information to establish the source of the events as shown in the example below: \n\nip access-list extended INGRESS_FILTER \n permit tcp any any established \n permit tcp any host x.11.1.5 eq www \n permit icmp host x.11.1.1 host x.11.1.2 echo \n permit icmp any any echo-reply \n\u2026 \n \u2026 \n \u2026 \ndeny ip 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 switch is not configured to produce audit records containing information to establish the source of the events, this is a finding.",
"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\nTo 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.",
"fixid": "F-22142r508400_fix",
"fixtext": "Configure the switch to log events containing information to establish where the events occurred as shown in the example below: \n\nSW1(config)#ip access-list extended INGRESS_FILTER \n\u2026 \n\u2026 \n\u2026 \nSW1(config-ext-nacl)#deny ip any any log-input",
"iacontrols": null,
"id": "V-220438",
"ruleID": "SV-220438r622190_rule",
"severity": "medium",
"title": "The Cisco switch must be configured to produce audit records containing information to establish the source of the events.",
"version": "CISC-RT-000220"
},
"V-220439": {
"checkid": "C-22154r508402_chk",
"checktext": "Review the configuration and verify that the auxiliary port is disabled unless a secured modem providing encryption and authentication is connected to it. \n\nline aux 0 \n no exec \n\nNote: transport input none is the default; hence, it will not be shown in the configuration. \n\nIf the auxiliary port is not disabled or is not connected to a secured modem when it is enabled, this is a finding.",
"description": "The use of POTS lines to modems connecting to network devices provides clear text of authentication traffic over commercial circuits that could be captured and used to compromise the network. Additional war dial attacks on the device could degrade the device and the production network. \n\nSecured modem devices must be able to authenticate users and must negotiate a key exchange before full encryption takes place. The modem will provide full encryption capability (Triple DES) or stronger. The technician who manages these devices will be authenticated using a key fob and granted access to the appropriate maintenance port; thus, the technician will gain access to the managed device. The token provides a method of strong (two-factor) user authentication. The token works in conjunction with a server to generate one-time user passwords that will change values at second intervals. The user must know a personal identification number (PIN) and possess the token to be allowed access to the device.",
"fixid": "F-22143r508403_fix",
"fixtext": "Disable the auxiliary port. \n\nSW2(config)#line aux 0 \nSW2(config-line)#no exec \nSW2(config-line)#transport input none",
"iacontrols": null,
"id": "V-220439",
"ruleID": "SV-220439r622190_rule",
"severity": "low",
"title": "The Cisco switch must be configured to disable the auxiliary port unless it is connected to a secured modem providing encryption and authentication.",
"version": "CISC-RT-000230"
},
"V-220440": {
"checkid": "C-22155r508405_chk",
"checktext": "Review the switch configuration to verify that the inbound access control list (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/2 \n ip address x.11.1.2 255.255.255.254 \n ip access-group EXTERNAL_ACL in \n\nStep 2: Review the inbound ACL to verify that it is configured to deny all other traffic that is not explicitly allowed. \n\nip access-list extended EXTERNAL_ACL \n permit tcp any any established \n permit icmp host x.11.1.1 host x.11.1.2 echo \n permit icmp host x.11.1.1 host x.11.1.2 echo-reply \n\u2026 \n \u2026 \n \u2026 \ndeny ip 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. \n\nIf the ACL is not configured inbound on all external interfaces, this is a finding.",
"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 switches should only allow traffic through that is explicitly permitted. The initial defense for the internal network is to block any traffic at the perimeter that is attempting to make a connection to a host residing on the internal network. In addition, allowing unknown or undesirable outbound traffic by the firewall or switch will establish a state that will permit the return of this undesirable traffic inbound.",
"fixid": "F-22144r508406_fix",
"fixtext": "Step 1: Configure an inbound ACL to deny all other traffic by default as shown in the example below: \n\nSW1(config)#ip access-list extended EXTERNAL_ACL \nSW1(config-ext-nacl)#permit tcp any any established \nSW1(config-ext-nacl)#permit icmp host x.11.1.1 host x.11.1.2 echo \nSW1(config-ext-nacl)#permit icmp host x.11.1.1 host x.11.1.2 echo-reply \n\u2026 \n\u2026 \n\u2026 \nSW1(config-ext-nacl)#deny ip any any log-input \n\nStep 2: Apply the ingress filter to all external interfaces. \n\nSW1(config)#int g0/2 \nSW1(config-if)#ip access-group EXTERNAL_ACL in",
"iacontrols": null,
"id": "V-220440",
"ruleID": "SV-220440r622190_rule",
"severity": "high",
"title": "The Cisco perimeter switch must be configured to deny network traffic by default and allow network traffic by exception.",
"version": "CISC-RT-000240"
},
"V-220441": {
"checkid": "C-22156r508408_chk",
"checktext": "Review the switch configuration to verify that access control lists (ACLs) are configured to allow or deny traffic for specific source and destination addresses as well as ports and protocols. In the example below, 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\ninterface GigabitEthernet0/1 \n description Link to DISN \n ip address x.12.1.10 255.255.255.0 \n ip access-group FILTER_PERIMETER in \n\u2026 \n\u2026 \n\u2026 \nip access-list extended FILTER_PERIMETER \n permit tcp any any established \n permit icmp host x.12.1.9 host x.12.1.10 echo \n permit icmp host x.12.1.9 host x.12.1.10 echo-reply \n permit tcp any host x.12.1.22 eq www \n deny ip any any log-input \n\nIf the switch is not configured to enforce approved authorizations for controlling the flow of information between interconnected networks, this is a finding.",
"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. \n\nAn example of a flow control restriction is blocking outside traffic claiming to be from within the organization. For most switches, internal information flow control is a product of system design.",
"fixid": "F-22145r508409_fix",
"fixtext": "Step 1: Configure an ACL to allow or deny traffic as shown in the example below: \n\nR1(config)#ip access-list extended FILTER_PERIMETER \nR1(config-ext-nacl)#permit tcp any any established \nR1(config-ext-nacl)#permit tcp host x.12.1.9 host x.12.1.10 eq bgp \nR1(config-ext-nacl)#permit tcp host x.12.1.9 eq bgp host x.12.1.10 \nR1(config-ext-nacl)#permit icmp host x.12.1.9 host x.12.1.10 echo \nR1(config-ext-nacl)#permit icmp host x.12.1.9 host x.12.1.10 echo-reply \nR1(config-ext-nacl)#permit tcp any host x.12.1.22 eq www \nR1(config-ext-nacl)#deny ip any any log-input \nR1(config-ext-nacl)#exit \n\nStep 2: Apply the ACL inbound on all external interfaces. \n\nR2(config)#int g0/0 \nR1(config-if)#ip access-group FILTER_PERIMETER in \nR1(config-if)#end",
"iacontrols": null,
"id": "V-220441",
"ruleID": "SV-220441r622190_rule",
"severity": "medium",
"title": "The Cisco perimeter switch must be configured to enforce approved authorizations for controlling the flow of information between interconnected networks in accordance with applicable policy.",
"version": "CISC-RT-000250"
},
"V-220442": {
"checkid": "C-22157r508411_chk",
"checktext": "Review the switch configuration to determine if the switch allows only incoming communications from authorized sources to be routed to authorized destinations. The hypothetical example below allows inbound NTP from server x.1.12.9 only to host x.12.1.21. \n\nip access-list extended FILTER_PERIMETER \n permit tcp any any established \n\u2026 \n \u2026 \n \u2026 \npermit udp host x.12.1.9 host x.12.1.21 eq ntp \n deny ip any any log-input \n\nIf the switch does not restrict incoming communications to allow only authorized sources and destinations, this is a finding.",
"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 switch's normal routing procedures used to control the specific paths of network traffic. It is normally used for traffic engineering but can also be used to meet security requirements; for example, traffic that is not allowed can be routed to the Null0 or discard interface. Policy Routing can also be used to control which prefixes appear in the routing table. \n\nThis requirement is intended to allow network administrators the flexibility to use whatever technique is most effective.",
"fixid": "F-22146r508412_fix",
"fixtext": "Configure the switch to allow only incoming communications from authorized sources to be routed to authorized destinations. \n\nSW1(config)#ip access-list extended FILTER_PERIMETER \nSW1(config-ext-nacl)#permit udp host x.12.1.9 host x.12.1.21 eq ntp \nSW1(config-ext-nacl)#end",
"iacontrols": null,
"id": "V-220442",
"ruleID": "SV-220442r622190_rule",
"severity": "medium",
"title": "The Cisco perimeter switch must be configured to only allow incoming communications from authorized sources to be routed to authorized destinations.",
"version": "CISC-RT-000260"
},
"V-220443": {
"checkid": "C-22158r508414_chk",
"checktext": "Review the switch configuration to verify that an ingress access control list (ACL) applied to all external interfaces is blocking packets with Bogon source addresses. \n\nStep 1: Verify that an ACL has been configured containing the current Bogon prefixes as shown in the example below: \n\nip access-list extended FILTER_PERIMETER \n deny ip 0.0.0.0 0.255.255.255 any log-input \n deny ip 10.0.0.0 0.255.255.255 any log-input \n deny ip 100.64.0.0 0.63.255.255 any log-input \n deny ip 127.0.0.0 0.255.255.255 any log-input \n deny ip 169.254.0.0 0.0.255.255 any log-input \n deny ip 172.16.0.0 0.15.255.255 any log-input \n deny ip 192.0.0.0 0.0.0.255 any log-input \n deny ip 192.0.2.0 0.0.0.255 any log-input \n deny ip 192.168.0.0 0.0.255.255 any log-input \n deny ip 198.18.0.0 0.1.255.255 any log-input \n deny ip 198.51.100.0 0.0.0.255 any log-input \n deny ip 203.0.113.0 0.0.0.255 any log-input \n deny ip 224.0.0.0 31.255.255.255 any log-input \n permit tcp any any established \n permit icmp host x.12.1.9 host x.12.1.10 echo \n permit icmp host x.12.1.9 host x.12.1.10 echo-reply \n\u2026 \n \u2026 \n \u2026 \ndeny ip any any log-input \n\nStep 2: Verify that the inbound ACL applied to all external interfaces will block all traffic from Bogon source addresses. \n\ninterface GigabitEthernet0/1 \n description Link to DISN \n ip address x.12.1.10 255.255.255.254 \n ip access-group FILTER_PERIMETER in \n\nIf the switch is not configured to block inbound packets with source Bogon IP address prefixes, this is a finding.",
"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.",
"fixid": "F-22147r508415_fix",
"fixtext": "Configure 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\nSW1(config)#ip access-list extended FILTER_PERIMETER \nSW1(config-ext-nacl)#deny ip 0.0.0.0 0.255.255.255 any log-input \nSW1(config-ext-nacl)#deny ip 10.0.0.0 0.255.255.255 any log-input \nSW1(config-ext-nacl)#deny ip 100.64.0.0 0.63.255.255 any log-input \nSW1(config-ext-nacl)#deny ip 127.0.0.0 0.255.255.255 any log-input \nSW1(config-ext-nacl)#deny ip 169.254.0.0 0.0.255.255 any log-input \nSW1(config-ext-nacl)#deny ip 172.16.0.0 0.15.255.255 any log-input \nSW1(config-ext-nacl)#deny ip 192.0.0.0 0.0.0.255 any log-input \nSW1(config-ext-nacl)#deny ip 192.0.2.0 0.0.0.255 any log-input \nSW1(config-ext-nacl)#deny ip 192.168.0.0 0.0.255.255 any log-input \nSW1(config-ext-nacl)#deny ip 198.18.0.0 0.1.255.255 any log-input \nSW1(config-ext-nacl)#deny ip 198.51.100.0 0.0.0.255 any log-input \nSW1(config-ext-nacl)#deny ip 203.0.113.0 0.0.0.255 any log-input \nSW1(config-ext-nacl)#deny ip 224.0.0.0 31.255.255.255 any log-input \nSW1(config-ext-nacl)#deny ip 240.0.0.0 31.255.255.255 any log-input \nSW1(config-ext-nacl)#permit tcp any any established \nSW1(config-ext-nacl)#permit icmp host x.12.1.9 host x.12.1.10 echo \nSW1(config-ext-nacl)#permit icmp host x.12.1.9 host x.12.1.10 echo-reply \n\u2026 \n\u2026 \n\u2026 \nSW1(config-ext-nacl)#deny ip any any log-input \nSW1(config-ext-nacl)#end \n\nStep 2: Apply the ACL inbound on all external interfaces. \n\nSW1(config)#int g0/0 \nSW1(config-if)#ip access-group FILTER_PERIMETER in \nSW1(config-if)#end",
"iacontrols": null,
"id": "V-220443",
"ruleID": "SV-220443r622190_rule",
"severity": "medium",
"title": "The Cisco perimeter switch must be configured to block inbound packets with source Bogon IP address prefixes.",
"version": "CISC-RT-000270"
},
"V-220445": {
"checkid": "C-22160r508417_chk",
"checktext": "Review the switch 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/2 \n ip address x.11.1.2 255.255.255.254 \n ip access-group EXTERNAL_ACL_INBOUND in \n\nStep 2. Review the inbound ACL to verify that it is filtering traffic in accordance with DoD 8551.1. \n\nip access-list extended EXTERNAL_ACL_INBOUND \n permit tcp any any established \n permit icmp host x.11.1.1 host x.11.1.2 echo \n permit icmp host x.11.1.1 host x.11.1.2 echo-reply \n\u2026 \n \u2026 < must be in accordance with DoD Instruction 8551.1> \n\u2026 \ndeny ip any any log-input \n\nIf the switch does not filter traffic in accordance with the guidelines contained in DoD 8551.1, this is a finding.",
"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 that are stopped by an ACL will allow network administrators to broaden their protective ring and more tightly define the scope of operation. \n\nIf the perimeter is in a Deny-by-Default posture and what is allowed through the filter is in accordance with DoD Instruction 8551.1, and if the permit rule is explicitly defined with explicit ports and protocols allowed, then all requirements related to PPS being blocked would be satisfied.",
"fixid": "F-22149r508418_fix",
"fixtext": "Configure the switch to use an inbound ACL on all external interfaces as shown in the example below to restrict traffic in accordance with the guidelines contained in DoD Instruction 8551.1. \n\nSW1(config)#ip access-list extended EXTERNAL_ACL_INBOUND \nSW1(config-ext-nacl)#permit tcp any any established \nSW1(config-ext-nacl)#permit icmp host x.11.1.1 host x.11.1.2 echo \nSW1(config-ext-nacl)#permit icmp host x.11.1.1 host x.11.1.2 echo-reply \n\u2026 \n\u2026 < must be in accordance with DoD Instruction 8551.1> \n\u2026 \nSW1(config-ext-nacl)#deny ip any any log-input \nSW1(config-ext-nacl)#exit \nSW1(config)#int g0/2 \nSW1(config-if)#ip access-group EXTERNAL_ACL_INBOUND in",
"iacontrols": null,
"id": "V-220445",
"ruleID": "SV-220445r622190_rule",
"severity": "medium",
"title": "The Cisco perimeter switch must be configured to filter traffic destined to the enclave in accordance with the guidelines contained in DoD Instruction 8551.1.",
"version": "CISC-RT-000320"
},
"V-220446": {
"checkid": "C-22161r508420_chk",
"checktext": "Review the switch configuration to verify that an inbound ACL is configured on all external interfaces as shown in the example below: \n\ninterface GigabitEthernet0/2 \n ip address x.11.1.2 255.255.255.254 \n ip access-group EXTERNAL_ACL_INBOUND in \n\nIf the switch is not configured to filter traffic entering the network at all external interfaces in an inbound direction, this is a finding.",
"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 switches makes use of access lists to restrict access to services on the switch itself as well as filter traffic passing through the switch. \n\nInbound versus Outbound: 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 switch can protect itself before damage is inflicted. \n- The input port is still known and can be filtered on. \n- It is more efficient to filter packets before routing them.",
"fixid": "F-22150r508421_fix",
"fixtext": "Configure the switch to use an inbound ACL on all external interfaces as shown in the example below: \n\nSW1(config)#int g0/2 \nSW1(config-if)#ip access-group EXTERNAL_ACL_INBOUND in",
"iacontrols": null,
"id": "V-220446",
"ruleID": "SV-220446r622190_rule",
"severity": "medium",
"title": "The Cisco perimeter switch must be configured to filter ingress traffic at the external interface on an inbound direction.",
"version": "CISC-RT-000330"
},
"V-220447": {
"checkid": "C-22162r508423_chk",
"checktext": "Review the switch configuration to verify that the egress access control list (ACL) is bound to the internal interface in an inbound direction. \n\ninterface interface GigabitEthernet0/2 \n description downstream link to LAN \n ip address 10.1.25.5 255.255.255.0 \n ip access-group EGRESS_FILTER in \n\nIf the switch is not configured to filter traffic leaving the network at the internal interface in an inbound direction, this is a finding.",
"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 switches makes use of access lists to restrict access to services on the switch itself as well as filter traffic passing through the switch. \n\nInbound versus Outbound: 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 switch can protect itself before damage is inflicted. \n- The input port is still known and can be filtered on. \n- It is more efficient to filter packets before routing them.",
"fixid": "F-22151r508424_fix",
"fixtext": "Configure the switch to use an inbound ACL on all internal interfaces as shown in the example below: \n\nSW1(config)#int g0/2 \nSW1(config-if)#ip access-group EGRESS_FILTER in",
"iacontrols": null,
"id": "V-220447",
"ruleID": "SV-220447r622190_rule",
"severity": "medium",
"title": "The Cisco perimeter switch must be configured to filter egress traffic at the internal interface on an inbound direction.",
"version": "CISC-RT-000340"
},
"V-220449": {
"checkid": "C-22164r508426_chk",
"checktext": "Step 1: Verify LLDP is not enabled globally via the command. \n\nlldp run \n\nBy default, LLDP is not enabled globally. If LLDP is enabled, proceed to Step 2. \n\nStep 2: Verify LLDP is not enabled on any external interface as shown in the example below: \n\ninterface GigabitEthernet0/1 \n ip address x.1.12.1 255.255.255.252 \n no lldp transmit \n\nNote: LLDP is enabled by default on all interfaces once it is enabled globally; hence the command \"lldp transmit\" will not be visible on the interface configuration. \n\nIf LLDP transmit is enabled on any external interface, this is a finding.",
"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. \n\nAllowing 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.",
"fixid": "F-22153r508427_fix",
"fixtext": "Disable LLDP transmit on all external interfaces as shown in the example below: \n\nSW1(config)#int g0/1 \nSW1(config-if)#no lldp transmit",
"iacontrols": null,
"id": "V-220449",
"ruleID": "SV-220449r622190_rule",
"severity": "low",
"title": "The Cisco perimeter switch must be configured to have Link Layer Discovery Protocol (LLDP) disabled on all external interfaces.",
"version": "CISC-RT-000360"
},
"V-220450": {
"checkid": "C-22165r508429_chk",
"checktext": "Step 1: Verify if CDP is enabled globally as shown below: \n\ncdp run \n\nBy default, CDP is not enabled globally or on any interface. If CDP is enabled globally, proceed to Step 2. \n\nStep 2: Verify CDP is not enabled on any external interface as shown in the example below: \n\ninterface GigabitEthernet2 \n ip address z.1.24.4 255.255.255.252 \n\u2026 \n \u2026 \n \u2026 \ncdp enable \n\nIf CDP is enabled on any external interface, this is a finding.",
"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.",
"fixid": "F-22154r508430_fix",
"fixtext": "Disable CDP on all external interfaces via no cdp enable command or disable CDP globally via no cdp run command.",
"iacontrols": null,
"id": "V-220450",
"ruleID": "SV-220450r622190_rule",
"severity": "low",
"title": "The Cisco perimeter switch must be configured to have Cisco Discovery Protocol (CDP) disabled on all external interfaces.",
"version": "CISC-RT-000370"
},
"V-220451": {
"checkid": "C-22166r508432_chk",
"checktext": "Review the switch configuration to determine if IP Proxy ARP is disabled on all external interfaces as shown in the example below: \n\ninterface GigabitEthernet0/1 \n description link to DISN \n ip address x.1.12.2 255.255.255.252 \n no ip proxy-arp \n\nNote: By default, Proxy ARP is enabled on all interfaces; hence, if enabled, it will not be shown in the configuration. \n\nIf IP Proxy ARP is enabled on any external interface, this is a finding.",
"description": "When Proxy ARP is enabled on a switch, it allows that switch to extend the network (at Layer 2) across multiple interfaces (LAN segments). Because proxy ARP allows hosts from different LAN segments to look like they are on the same segment, proxy ARP is only safe when used between trusted LAN segments. \n\nAttackers can leverage the trusting nature of proxy ARP by spoofing a trusted host and then intercepting packets. Proxy ARP should always be disabled on switch interfaces that do not require it unless the switch is being used as a LAN bridge.",
"fixid": "F-22155r508433_fix",
"fixtext": "Disable Proxy ARP on all external interfaces as shown in the example below: \n\nSW1(config)#int g0/1 \nSW1(config-if)#no ip proxy-arp",
"iacontrols": null,
"id": "V-220451",
"ruleID": "SV-220451r622190_rule",
"severity": "medium",
"title": "The Cisco perimeter switch must be configured to have Proxy ARP disabled on all external interfaces.",
"version": "CISC-RT-000380"
},
"V-220452": {
"checkid": "C-22167r508435_chk",
"checktext": "Verify that the perimeter switch of the managed network is 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/2 \n description link to DISN \n ip address x.11.1.2 255.255.255.254 \n ip access-group EXTERNAL_ACL_OUTBOUND out \n\nStep 2: Verify that the outbound ACL discards management traffic as shown in the example below: \n\nip access-list extended EXTERNAL_ACL_OUTBOUND \n deny tcp any any eq tacacs log-input \n deny tcp any any eq 22 log-input \n deny udp any any eq snmp log-input \n deny udp any any eq snmptrap log-input \n deny udp any any eq syslog log-input \n permit tcp any any eq www log-input \n deny ip any any log-input \n\nIf management traffic is not blocked at the perimeter, this is a finding.",
"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 switches and firewalls. Management traffic between the managed network elements and the management network is routed via the same links and nodes as that used for production or operational traffic. Safeguards must be implemented to ensure that the management traffic does not leak past the perimeter of the managed network.",
"fixid": "F-22156r508436_fix",
"fixtext": "Configure the perimeter switch 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\nSW1(config)#ip access-list extended EXTERNAL_ACL_OUTBOUND \nSW1(config-ext-nacl)#deny tcp any any eq tacacs log-input \nSW1(config-ext-nacl)#deny tcp any any eq 22 log-input \nSW1(config-ext-nacl)#deny udp any any eq snmp log-input \nSW1(config-ext-nacl)#deny udp any any eq snmptrap log-input \nSW1(config-ext-nacl)#deny udp any any eq syslog log-input \nSW1(config-ext-nacl)#permit tcp any any eq www \nSW1(config-ext-nacl)#deny ip any any log-input \nSW1(config-ext-nacl)#exit \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\nSW1(config)#int g0/2 \nSW1(config-if)#ip access-group EXTERNAL_ACL_OUTBOUND out",
"iacontrols": null,
"id": "V-220452",
"ruleID": "SV-220452r622190_rule",
"severity": "medium",
"title": "The Cisco perimeter switch must be configured to block all outbound management traffic.",
"version": "CISC-RT-000390"
},
"V-220453": {
"checkid": "C-22168r508438_chk",
"checktext": "This requirement is only applicable where management access to the switch 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 access control list (ACL) configured. \n\ninterface GigabitEthernet0/7 \n no switchport \n description link to OOBM access switch \n ip address 10.11.1.22 255.255.255.0 \n ip access-group INGRESS_MANAGEMENT_ACL in \n ip access-group EGRESS_MANAGEMENT_ACL in \n\nStep 2: Verify that the ingress ACL only allows management and ICMP traffic. \n\nip access-list extended INGRESS_MANAGEMENT_ACL \n permit tcp any host 10.11.1.22 eq tacacs \n permit tcp any host 10.11.1.22 eq 22 \n permit udp any host 10.11.1.22 eq snmp \n permit udp any host 10.11.1.22 eq snmptrap \n permit udp any host 10.11.1.22 eq ntp \n permit icmp any host 10.11.1.22 \n deny ip any any log-input \n\nStep 3: Verify that the egress ACL blocks any transit traffic. \n\nip access-list extended EGRESS_MANAGEMENT_ACL \n deny ip any any log-input \n\nNote: On Cisco switches, local generated packets are not inspected by outgoing interface access lists. Hence, the above configuration would drop any packets not generated by the switch, blocking any transit traffic. \n\nIf the switch does not restrict traffic that ingresses and egresses the management interface, this is a finding.",
"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. \n\nIf 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 production traffic does not leak into the management network.",
"fixid": "F-22157r508439_fix",
"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 as shown in the example below: \n\nSW1(config)#ip access-list extended INGRESS_MANAGEMENT_ACL \nSW1(config-ext-nacl)#permit tcp any host 10.11.1.22 eq tacacs \nSW1(config-ext-nacl)#permit tcp any host 10.11.1.22 eq 22 \nSW1(config-ext-nacl)#permit udp any host 10.11.1.22 eq snmp \nSW1(config-ext-nacl)#permit udp any host 10.11.1.22 eq snmptrap \nSW1(config-ext-nacl)#permit udp any host 10.11.1.22 eq ntp \nSW1(config-ext-nacl)#permit icmp any host 10.11.1.22 \nSW1(config-ext-nacl)#deny ip any any log-input \nSW1(config-ext-nacl)#exit \n\nStep 2: Configure an egress ACL as shown in the example below: \n\nSW1(config)#ip access-list extended EGRESS_MANAGEMENT_ACL \nSW1(config-ext-nacl)#deny ip any any log-input \nSW1(config-ext-nacl)#exit \n\nStep 3: Apply the ACLs to the OOBM interfaces. \n\nSW1(config)#int g0/7 \nSW1(config-if)#ip access-group INGRESS_MANAGEMENT_ACL in \nSW1(config-if)#ip access-group EGRESS_MANAGEMENT_ACL out",
"iacontrols": null,
"id": "V-220453",
"ruleID": "SV-220453r622190_rule",
"severity": "medium",
"title": "The Cisco switch must be configured to only permit management traffic that ingresses and egresses the out-of-band management (OOBM) interface.",
"version": "CISC-RT-000450"
},
"V-220454": {
"checkid": "C-22169r508441_chk",
"checktext": "The Cisco switch is not compliant with this requirement; hence, it is a finding. However, the severity level can be downgraded to a CAT III if the switch is configured to authenticate targeted LDP sessions using MD5 as shown in the configuration example below:\n\nmpls ldp neighbor 10.1.1.2 password xxxxxxx \nmpls label protocol ldp \n\nIf the switch is not configured to authenticate targeted LDP sessions using MD5, the finding will remain as a CAT II.",
"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 switch advertises a virtual circuit label mapping that is used as part of the label stack imposed on the frames by the ingress PE switch during packet forwarding. Authentication provides protection against spoofed TCP segments that can be introduced into the LDP sessions.",
"fixid": "F-22158r508442_fix",
"fixtext": "The severity level can be downgraded to a CAT III if the switch is configured to authenticate targeted LDP sessions using MD5 as shown in the example below: \n\nSW1(config)#mpls ldp neighbor 10.1.1.2 password xxxxxxxx",
"iacontrols": null,
"id": "V-220454",
"ruleID": "SV-220454r622190_rule",
"severity": "medium",
"title": "The Cisco PE switch providing MPLS Layer 2 Virtual Private Network (L2VPN) services must be configured to authenticate targeted Label Distribution Protocol (LDP) sessions used to exchange virtual circuit (VC) information using a FIPS-approved message authentication code algorithm.",
"version": "CISC-RT-000660"
},
"V-220455": {
"checkid": "C-22170r508443_chk",
"checktext": "Step 1: Review the switch configuration to verify that an ingress ACL is applied to all external or CE-facing interfaces. \n\ninterface GigabitEthernet0/2\n no switchport\n ip address x.1.12.2 255.255.255.252\n ip access-group BLOCK_TO_CORE in\n\nStep 2: Verify that the ingress ACL discards and logs packets destined to the IP core address space. \n\nip access-list extended BLOCK_TO_CORE\n deny ip any 10.1.x.0 0.0.255.255 log-input\n permit ip any any\n!\n\nIf the PE switch 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.",
"description": "IP addresses can be guessed. Core network elements must not be accessible from any external host. Protecting the core from any attack is vital for the integrity and privacy of customer traffic as well as the availability of transit services. A compromise of the IP core can result in an outage or, at a minimum, non-optimized forwarding of customer traffic. Protecting the core from an outside attack also prevents attackers from using the core to attack any customer. Hence, it is imperative that all switches at the edge deny traffic destined to any address belonging to the IP core infrastructure.",
"fixid": "F-22159r508444_fix",
"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\nSW2(config)#ip access-list extended BLOCK_TO_CORE\nSW2(config-ext-nacl)#deny ip any 10.1.x.0 0.0.255.255 log-input\nSW2(config-ext-nacl)#exit\n\nStep 2: Apply the ACL inbound to all external or CE-facing interfaces.\n\nSW2(config)#int SW1(config)#int g0/2\nSW2(config-if)#ip access-group BLOCK_TO_CORE in\nSW2(config-if)#end",
"iacontrols": null,
"id": "V-220455",
"ruleID": "SV-220455r622190_rule",
"severity": "high",
"title": "The Cisco PE switch must be configured to block any traffic that is destined to the IP core infrastructure.",
"version": "CISC-RT-000730"
},
"V-220456": {
"checkid": "C-22171r508446_chk",
"checktext": "Review the switch configuration to determine if uRPF loose mode is enabled on all CE-facing interfaces.\n\ninterface GigabitEthernet0/2\n no switchport\n ip address x.1.12.2 255.255.255.252\n ip access-group BLOCK_TO_CORE in\n ip verify unicast source reachable-via any\n\nIf uRPF loose mode is not enabled on all CE-facing interfaces, this is a finding.",
"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 switches must enable uRPF loose mode to guarantee that all packets received from a CE switch contain source addresses that are in the route table.",
"fixid": "F-22160r508447_fix",
"fixtext": "Configure uRPF loose mode on all CE-facing interfaces as shown in the example below:\n\nSW2(config)#int SW1(config)#int g0/2\nSW2(config-if)#ip verify unicast source reachable-via any\nSW2(config-if)#end",
"iacontrols": null,
"id": "V-220456",
"ruleID": "SV-220456r622190_rule",
"severity": "medium",
"title": "The Cisco PE switch must be configured with Unicast Reverse Path Forwarding (uRPF) loose mode enabled on all CE-facing interfaces.",
"version": "CISC-RT-000740"
},
"V-220458": {
"checkid": "C-22173r508449_chk",
"checktext": "Review the switch configuration and verify that a QoS policy has been configured to provide preferred treatment for mission-critical applications in accordance with the QoS GIG Technical Profile.\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 C2_VOICE\n match ip dscp af47\nclass-map match-all VOICE\n match ip dscp ef\nclass-map match-all VIDEO\n match ip dscp af41\nclass-map match-all CONTROL_PLANE\n match ip dscp cs6\nclass-map match-all PREFERRED_DATA\n match ip dscp af33\n\nStep 2: Verify that the policy map reserves the bandwidth for each traffic type as shown in the example below:\n\npolicy-map QOS_POLICY\nclass C2_VOICE\n priority percent 10\n class VOICE\n priority percent 15\n class VIDEO\n bandwidth percent 25\nclass CONTROL_PLANE\n priority percent 10\n class PREFERRED_DATA\n bandwidth percent 25\n class class-default\n bandwidth percent 15\n\nStep 3: Verify that an output service policy is bound to all interfaces as shown in the configuration example below:\n\ninterface GigabitEthernet1/1\n no switchport\n ip address 10.1.15.1 255.255.255.252\n service-policy output QOS_POLICY\n!\ninterface GigabitEthernet1/2\n no switchport\n ip address 10.1.15.4 255.255.255.252\n service-policy output QOS_POLICY\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\nNote: The GTP QOS document (GTP-0009) can be downloaded via the following link: \nhttps://intellipedia.intelink.gov/wiki/Portal:GIG_Technical_Guidance/GTG_GTPs/GTP_Development_List\n\nIf the switch is not configured to enforce a QoS policy in accordance with the QoS GIG Technical Profile, this is a finding.",
"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.",
"fixid": "F-22162r508450_fix",
"fixtext": "Configure a QoS policy in accordance with the QoS GIG Technical Profile.\n\nStep 1: Configure class-maps to match on DSCP values as shown in the configuration example below:\n\nSW1(config)#class-map match-all PREFERRED_DATA\nSW1(config-cmap)#match ip dscp af33\nSW1(config-cmap)#class-map match-all CONTROL_PLANE\nSW1(config-cmap)#match ip dscp cs6\nSW1(config-cmap)#class-map match-all VIDEO\nSW1(config-cmap)#match ip dscp af41\nSW1(config-cmap)#class-map match-all VOICE\nSW1(config-cmap)#match ip dscp ef\nSW1(config-cmap)#class-map match-all C2_VOICE\nSW1(config-cmap)#match ip dscp 47\nSW1(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\nSW1(config)#policy-map QOS_POLICY\nSW1(config-pmap)#class CONTROL_PLANE\nSW1(config-pmap-c)#priority percent 10\nSW1(config-pmap-c)#class C2_VOICE\nSW1(config-pmap-c)#priority percent 10\nSW1(config-pmap-c)#class VOICE\nSW1(config-pmap-c)#priority percent 15\nSW1(config-pmap-c)#class VIDEO\nSW1(config-pmap-c)#bandwidth percent 25\nSW1(config-pmap-c)#class PREFERRED_DATA\nSW1(config-pmap-c)#bandwidth percent 25\nSW1(config-pmap-c)#class class-default\nSW1(config-pmap-c)#bandwidth percent 15\nSW1(config-pmap-c)#exit\nSW1(config-pmap)#exit\n\nStep 3: Apply the output service policy to all interfaces as shown in the configuration example below:\n\nSW1(config)#int g1/1\nSW1(config-if)#service-policy output QOS_POLICY\nSW1(config-if)#exit\nSW1(config)#int g1/2\nSW1(config-if)#service-policy output QOS_POLICY\nSW1(config-if)#end",
"iacontrols": null,
"id": "V-220458",
"ruleID": "SV-220458r622190_rule",
"severity": "low",
"title": "The Cisco PE switch must be configured to enforce a Quality-of-Service (QoS) policy in accordance with the QoS GIG Technical Profile.",
"version": "CISC-RT-000760"
},
"V-220459": {
"checkid": "C-22174r508452_chk",
"checktext": "Review the switch configuration and verify that a QoS policy has been configured to provide preferred treatment for mission-critical applications in accordance with the QoS GIG Technical Profile.\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 PREFERRED_DATA\n match ip dscp af33\nclass-map match-all CONTROL_PLANE\n match ip dscp cs6\nclass-map match-all VIDEO\n match ip dscp af41\nclass-map match-all VOICE\n match ip dscp ef\nclass-map match-all C2_VOICE\n match ip dscp 47\n\nStep 2: Verify that the policy map reserves the bandwidth for each traffic type as shown in the example below:\n\npolicy-map QOS_POLICY\n class CONTROL_PLANE\n priority percent 10\n class C2_VOICE\n priority percent 10\n class VOICE\n priority percent 15\n class VIDEO\n bandwidth percent 25\n class PREFERRED_DATA\n bandwidth percent 25\n class class-default\n bandwidth percent 15\n\nStep 3: Verify that an output service policy is bound to all interfaces as shown in the configuration example below:\n\ninterface GigabitEthernet1/1\n no switchport\n ip address 10.1.15.5 255.255.255.252\n service-policy output QOS_POLICY\n!\ninterface GigabitEthernet1/2\n no switchport\n ip address 10.1.15.8 255.255.255.252\n service-policy output QOS_POLICY\n\nNote: The GTP QOS document (GTP-0009) can be downloaded via the following link: \nhttps://intellipedia.intelink.gov/wiki/Portal:GIG_Technical_Guidance/GTG_GTPs/GTP_Development_List\n\nIf the switch is not configured to enforce a QoS policy in accordance with the QoS GIG Technical Profile, this is a finding.",
"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.",
"fixid": "F-22163r508453_fix",
"fixtext": "Configure a QoS policy in accordance with the QoS GIG Technical Profile.\n\nStep 1: Configure class-maps to match on DSCP values as shown in the configuration example below:\n\nSW1(config)#class-map match-all PREFERRED_DATA\nSW1(config-cmap)#match ip dscp af33\nSW1(config-cmap)#class-map match-all CONTROL_PLANE\nSW1(config-cmap)#match ip dscp cs6\nSW1(config-cmap)#class-map match-all VIDEO\nSW1(config-cmap)#match ip dscp af41\nSW1(config-cmap)#class-map match-all VOICE\nSW1(config-cmap)#match ip dscp ef\nSW1(config-cmap)#class-map match-all C2_VOICE\nSW1(config-cmap)#match ip dscp 47\nSW1(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\nSW1(config)#policy-map QOS_POLICY\nSW1(config-pmap)#class CONTROL_PLANE\nSW1(config-pmap-c)#priority percent 10\nSW1(config-pmap-c)#class C2_VOICE\nSW1(config-pmap-c)#priority percent 10\nSW1(config-pmap-c)#class VOICE\nSW1(config-pmap-c)#priority percent 15\nSW1(config-pmap-c)#class VIDEO\nSW1(config-pmap-c)#bandwidth percent 25\nSW1(config-pmap-c)#class PREFERRED_DATA\nSW1(config-pmap-c)#bandwidth percent 25\nSW1(config-pmap-c)#class class-default\nSW1(config-pmap-c)#bandwidth percent 15\nSW1(config-pmap-c)#exit\nSW1(config-pmap)#exit\n\nStep 3: Apply the output service policy to all interfaces as shown in the configuration example below:\n\nSW1(config)#int g1/1\nSW1(config-if)#service-policy output QOS_POLICY\nSW1(config-if)#exit\nSW1(config)#int g1/2\nSW1(config-if)#service-policy output QOS_POLICY\nSW1(config-if)#end",
"iacontrols": null,
"id": "V-220459",
"ruleID": "SV-220459r622190_rule",
"severity": "low",
"title": "The Cisco P switch must be configured to implement a Quality-of-Service (QoS) policy in accordance with the QoS GIG Technical Profile.",
"version": "CISC-RT-000770"
},
"V-220460": {
"checkid": "C-22175r508455_chk",
"checktext": "Review the switch configuration to determine if it is configured to enforce a QoS policy to limit the effects of packet flooding DoS attacks. \n\nStep 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 ip dscp cs1 \n\nStep 2: Verify that the policy-map includes the SCAVENGER class with low priority as shown in the example below: \n\npolicy-map QOS_POLICY \n class CONTROL_PLANE \n priority percent 10 \n class C2_VOICE \n priority percent 10 \n class VOICE \n priority percent 15 \n class VIDEO \n bandwidth percent 25 \n class PREFERRED_DATA \n bandwidth percent 25 \nclass SCAVENGER \n bandwidth percent 5 \n class class-default \n bandwidth percent 10 \n\nNote: Traffic out of profile must be marked at the customer access layer or CE egress edge. \n\nIf the switch is not configured to enforce a QoS policy to limit the effects of packet flooding DoS attacks, this is a finding.",
"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).",
"fixid": "F-22164r508456_fix",
"fixtext": "Step 1: Configure a class-map for the SCAVENGER class. \n\nSW1(config)#class-map match-all SCAVENGER \nSW1(config-cmap)#match ip dscp cs1 \n\nStep 2: Add the SCAVENGER class to the policy-map as shown in the example below: \n\nSW1(config)#policy-map QOS_POLICY \nSW1(config-pmap-c)#no class class-default \nSW1(config-pmap)#class SCAVENGER \nSW1(config-pmap-c)#bandwidth percent 5 \nSW1(config-pmap-c)#class class-default \nSW1(config-pmap-c)#bandwidth percent 10 \nSW1(config-pmap-c)#end",
"iacontrols": null,
"id": "V-220460",
"ruleID": "SV-220460r622190_rule",
"severity": "medium",
"title": "The Cisco switch must be configured to enforce a Quality-of-Service (QoS) policy to limit the effects of packet flooding denial-of-service (DoS) attacks.",
"version": "CISC-RT-000780"
},
"V-220461": {
"checkid": "C-22176r508458_chk",
"checktext": "Step 1: Review the network's multicast topology diagram. \n\nStep 2: Review the switch configuration to verify that only the PIM interfaces as shown in the multicast topology diagram are enabled for PIM as shown in the example below: \n\ninterface GigabitEthernet1/1 \n no switchport \n ip address 10.1.3.3 255.255.255.0 \n ip pim sparse-mode \n\nIf an interface is not required to support multicast routing and it is enabled, this is a finding.",
"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 switches and passing through some switches to include only some of their interfaces.\" Therefore, it is imperative that the network engineers have documented their multicast topology and know which interfaces are enabled for multicast. Once this is done, the zones can be scoped as required.",
"fixid": "F-22165r508459_fix",
"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\nSW1(config)#int g1/1 \nSW1(config-if)#no ip pim sparse-mode",
"iacontrols": null,
"id": "V-220461",
"ruleID": "SV-220461r622190_rule",
"severity": "medium",
"title": "The Cisco multicast switch must be configured to disable Protocol Independent Multicast (PIM) on all interfaces that are not required to support multicast routing.",
"version": "CISC-RT-000790"
},
"V-220462": {
"checkid": "C-22177r508461_chk",
"checktext": "Step 1: Verify that all interfaces enabled for PIM have a neighbor access control list (ACL) bound to the interface as shown in the example below: \n\ninterface GigabitEthernet1/1 \n no switchport \n ip address 10.1.2.2 255.255.255.0 \n ip pim neighbor-filter PIM_NEIGHBORS \n ip pim sparse-mode \n\nStep 2: Review the configured ACL for filtering PIM neighbors as shown in the example below: \n\nip access-list standard PIM_NEIGHBORS \n permit 10.1.2.6 \n\nIf PIM neighbor ACLs are not bound to all interfaces that have PIM enabled, this is a finding.",
"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 interfaces that have PIM enabled. \n\nIf a PIM neighbor filter is not applied to interfaces that have PIM enabled, unauthorized switches can join the PIM domain, discover and use the rendezvous points, and advertise their rendezvous points into the domain. This can result in a denial of service by traffic flooding or in the unauthorized transfer of data.",
"fixid": "F-22166r508462_fix",
"fixtext": "Configure 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\nSW2(config)#ip access-list standard PIM_NEIGHBORS \nSW2(config-std-nacl)#permit 10.1.2.6 \nSW2(config-std-nacl)#exit \n\nStep 2: Apply the ACL to all interfaces enabled for PIM. \n\nSW2(config)#int g1/1 \nSW2(config-if)#ip pim neighbor-filter PIM_NEIGHBORS",
"iacontrols": null,
"id": "V-220462",
"ruleID": "SV-220462r622190_rule",
"severity": "medium",
"title": "The Cisco multicast switch must be configured to bind a Protocol Independent Multicast (PIM) neighbor filter to interfaces that have PIM enabled.",
"version": "CISC-RT-000800"
},
"V-220463": {
"checkid": "C-22178r508464_chk",
"checktext": "Review the switch configuration and verify that admin-scope multicast traffic is blocked at the external edge as shown in the example below: \n\ninterface GigabitEthernet1/2 \n no switchport \n ip address x.1.12.2 255.255.255.252 \n ip pim sparse-mode \n ip multicast boundary MULTICAST_SCOPE \n\u2026 \n\u2026 \n\u2026 \nip access-list standard MULTICAST_SCOPE \n deny 239.0.0.0 0.255.255.255 \n permit any \n\nIf the switch is not configured to establish boundaries for administratively scoped multicast traffic, this is a finding.",
"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.",
"fixid": "F-22167r508465_fix",
"fixtext": "Step 1: Configure the ACL to deny packets with multicast administratively scoped destination addresses as shown in the example below: \n\nSW2(config)#ip access-list standard MULTICAST_SCOPE \nSW2(config-std-nacl)#deny 239.0.0.0 0.255.255.255 \nSW2(config-std-nacl)#permit any \nSW2(config-std-nacl)#exit \n\nStep 2: Apply the multicast boundary at the appropriate interfaces as shown in the example below: \n\nSW2(config)#int g1/2 \nSW2(config-if)#ip multicast boundary MULTICAST_SCOPE \nSW2(config-if)#end",
"iacontrols": null,
"id": "V-220463",
"ruleID": "SV-220463r622190_rule",
"severity": "low",
"title": "The Cisco multicast edge switch must be configured to establish boundaries for administratively scoped multicast traffic.",
"version": "CISC-RT-000810"
},
"V-220464": {
"checkid": "C-22179r508467_chk",
"checktext": "Review the configuration of the DR to verify that it is filtering IGMP or MLD Membership Report messages, allowing hosts to join only groups that have been approved. \n\nStep 1: Verify that all host-facing Layer 3 and VLAN interfaces are configured to filter IGMP Membership Report messages (IGMP joins) as shown in the example below: \n\ninterface Vlan3 \n ip address 10.3.3.3 255.255.255.0 \n ip pim sparse-mode \n ip igmp access-group IGMP_JOIN_FILTER \n ip igmp version 3 \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\nip access-list standard IGMP_JOIN_FILTER \n deny 239.8.0.0 0.0.255.255 \n permit any \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 switch. \n\nIf the DR is not filtering IGMP or MLD Membership Report messages, this is a finding.",
"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 group's hosts are allowed to join via IGMP or MLD.",
"fixid": "F-22168r508468_fix",
"fixtext": "Configure the DR to filter the IGMP or MLD Membership Report messages to allow hosts to join only multicast groups that have been approved. \n\nStep 1: Configure the ACL to filter IGMP Membership Report messages as shown in the example below: \n\nSW2(config)#ip access-list standard IGMP_JOIN_FILTER \nSW2(config-std-nacl)#deny 239.8.0.0 0.0.255.255 \nSW2(config-std-nacl)#permit any \nSW2(config-std-nacl)#exit \n\nStep 2: Apply the filter to all host-facing Layer 3 and VLAN interfaces. \n\nSW2(config)#int vlan3 \nSW2(config-if)#ip igmp access-group IGMP_JOIN_FILTER",
"iacontrols": null,
"id": "V-220464",
"ruleID": "SV-220464r622190_rule",
"severity": "low",
"title": "The Cisco multicast Designated switch (DR) must be configured to filter the Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Report messages to allow hosts to join only multicast groups that have been approved by the organization.",
"version": "CISC-RT-000860"
},
"V-220465": {
"checkid": "C-22180r508469_chk",
"checktext": "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 Layer 3 and VLAN interfaces are configured to filter IGMP Membership Report messages (IGMP joins) as shown in the example below: \n\ninterface Vlan3 \n ip address 10.3.3.3 255.255.255.0 \n ip pim sparse-mode \n ip igmp access-group IGMP_JOIN_FILTER \n ip igmp version 3 \n\nStep 2: Verify that the ACL denies unauthorized sources or allows only authorized sources. The example below denies all groups from the 232.8.0.0/16 range and permits sources only from the x.0.0.0/8 network. \n\nip access-list extended IGMP_JOIN_FILTER \n deny ip any 232.8.0.0 0.0.255.255 \n permit ip x.0.0.0 0.255.255.255 any \n deny ip any any \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.",
"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.",
"fixid": "F-22169r508470_fix",
"fixtext": "Configure the DR to filter the IGMP and MLD report messages to allow hosts to join only multicast groups from sources that have been approved as shown in the example below: \n\nSW2(config)#ip access-list extended IGMP_JOIN_FILTER \nSW2(config-ext-nacl)#deny ip any 232.8.0.0 0.0.255.255 \nSW2(config-ext-nacl)#permit ip x.0.0.0 0.255.255.255 any \nSW2(config-ext-nacl)#deny ip any any \nSW2(config-ext-nacl)#exit \n\nStep 2: Apply the filter to all host-facing Layer 3 and VLAN interfaces. \n\nSW2(config)#int vlan3 \nSW2(config-if)#ip igmp access-group IGMP_JOIN_FILTER",
"iacontrols": null,
"id": "V-220465",
"ruleID": "SV-220465r622190_rule",
"severity": "medium",
"title": "The Cisco multicast Designated switch (DR) must be configured to filter the Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Report messages to allow hosts to join a multicast group only from sources that have been approved by the organization.",
"version": "CISC-RT-000870"
},
"V-220466": {
"checkid": "C-22181r508471_chk",
"checktext": "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 Layer 3 and VLAN interface via the ip igmp limit command as shown in the example below: \n\ninterface Vlan3 \n ip address 10.3.3.3 255.255.255.0 \n\u2026 \n \u2026 \n \u2026 \nip igmp limit nn \n\nIf the DR is not limiting multicast join requests via IGMP or MLD on a global or interfaces basis, this is a finding.",
"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. \n\nWithout any form of admission control, this can pose a security risk to the entire multicast domain, specifically the multicast switches along the shared tree from the DR to the RP that must maintain the mroute state information for each group join request. Hence, it is imperative that the DR is configured to limit the number of mroute state information that must be maintained to mitigate the risk of IGMP or MLD flooding.",
"fixid": "F-22170r508472_fix",
"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\nSW2(config)#int vlan3 \nSW2(config-if)#ip igmp limit 2",
"iacontrols": null,
"id": "V-220466",
"ruleID": "SV-220466r622190_rule",
"severity": "medium",
"title": "The Cisco multicast Designated switch (DR) must be configured to limit the number of mroute states resulting from Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Host Membership Reports.",
"version": "CISC-RT-000880"
},
"V-220467": {
"checkid": "C-22182r508474_chk",
"checktext": "Review the DR configuration to verify that the SPT switchover threshold is increased (default is \"0\") or set to infinity (never switch over). \n\nip pim rp-address 10.2.2.2 \nip pim 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.",
"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 switch will initiate a switch from the shared tree to a source-specific SPT to obtain lower latencies. This is accomplished by the last-hop switch sending an (S, G) Protocol Independent Multicast (PIM) Join toward S (the source). \n\nWhen the last-hop switch begins to receive traffic for the group from the source via the SPT, it will send a PIM Prune message to the RP for the (S, G). The RP will then send a Prune message toward the source. The SPT switchover becomes a scaling issue for large multicast topologies that have many receivers and many sources for many groups because (S, G) entries require more memory than (*, G). Hence, it is imperative to minimize the amount of (S, G) state to be maintained by increasing the threshold that determines when the SPT switchover occurs.",
"fixid": "F-22171r508475_fix",
"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\nSW2(config)#ip pim spt-threshold infinity",
"iacontrols": null,
"id": "V-220467",
"ruleID": "SV-220467r622190_rule",
"severity": "medium",
"title": "The Cisco multicast Designated switch (DR) must be configured to set the shortest-path tree (SPT) threshold to infinity to minimalize source-group (S, G) state within the multicast topology where Any Source Multicast (ASM) is deployed.",
"version": "CISC-RT-000890"
},
"V-220468": {
"checkid": "C-22183r508477_chk",
"checktext": "Review the switch configuration. Verify that authentication is enabled for all routing protocols. The configuration examples below depict OSPF and EIGRP authentication. \n\nEIGRP example: \n\nkey chain EIGRP_KEY \n key 1 \n key-string xxxxxxx \n\u2026 \n\u2026 \n\u2026 \ninterface GigabitEthernet0/0 \n no switchport \n ip address x.x.x.x 255.255.255.0 \n ip authentication mode eigrp 1 md5 \n ip authentication key-chain eigrp 1 EIGRP_KEY \n\nOSPF example: \n\ninterface GigabitEthernet0/0 \n no switchport \n ip address x.x.x.x 255.255.255.0 \n ip ospf authentication-key xxxxx \n\nIf authentication is not enabled on all routing protocols, this is a finding.",
"description": "A rogue switch could send a fictitious routing update to convince a site's perimeter switch to send traffic to an incorrect or even a rogue destination. This diverted traffic could be analyzed to learn confidential information about the site's network or used to disrupt the network's ability to communicate with other networks. This is known as a \"traffic attraction attack\" and is prevented by configuring neighbor switch authentication for routing updates. \n\nThis requirement applies to all IPv4 and IPv6 protocols that are used to exchange routing or packet forwarding information; this includes all Interior Gateway Protocols (such as OSPF, EIGRP, and IS-IS) and Exterior Gateway Protocols (such as BGP), MPLS-related protocols (such as LDP), and multicast-related protocols.",
"fixid": "F-22172r508478_fix",
"fixtext": "Configure authentication to be enabled for every protocol that affects the routing or forwarding tables. The example configuration commands below enables OSPF and EIGRP authentication. \n\nEIGRP example: \n\nSW1(config)#key chain EIGRP_KEY \nSW1(config-keychain)#key 1 \nSW1(config-keychain-key)#key-string xxxxx \nSW1(config-keychain-key)#exit \nSW1(config-keychain)#exit \nSW1(config)#int g0/0 \nSW1(config-if)#ip authentication mode eigrp 1 md5 \nSW1(config-if)#ip authentication key-chain eigrp 1 EIGRP_KEY \nSW1(config-if)#end \n\nOSPF example: \n\nSW1(config)#int g0/0 \nSW1(config-if)#ip ospf authentication-key xxxxx \nSW1(config-if)#end",
"iacontrols": null,
"id": "V-220468",
"ruleID": "SV-220468r622190_rule",
"severity": "medium",
"title": "The Cisco switch must be configured to implement message authentication for all control plane protocols.",
"version": "CISC-RT-000020"
},
"V-220469": {
"checkid": "C-22184r508480_chk",
"checktext": "Review the start times for each key within the configured key chains used for routing protocol authentication as shown in the example below: \n\nkey chain OSPF_KEY_CHAIN \n key 1 \n key-string xxxxxxx \n send-lifetime 00:00:00 Jan 1 2018 23:59:59 Mar 31 2018 \n accept-lifetime 00:00:00 Jan 1 2018 01:05:00 Apr 1 2018 \n key 2 \n key-string yyyyyyy \n send-lifetime 00:00:00 Apr 1 2018 23:59:59 Jun 30 2018 \n accept-lifetime 23:55:00 Mar 31 2018 01:05:00 Jul 1 2018 \n\nNote: Key chains must be configured to authenticate routing protocol messages, as it is the only way to set an expiration. \n\nIf any key has a lifetime of more than 180 days, this is a finding.",
"description": "If the keys used for routing protocol authentication are guessed, the malicious user could create havoc within the network by advertising incorrect routes and redirecting traffic. Some routing protocols allow the use of key chains for authentication. A key chain is a set of keys that is used in succession, with each having a lifetime of no more than 180 days. Changing the keys frequently reduces the risk of them eventually being guessed. \n\nKeys cannot be used during time periods for which they are not activated. If a time period occurs during which no key is activated, neighbor authentication cannot occur, and therefore routing updates will fail. Therefore, ensure that for a given key chain, key activation times overlap to avoid any period of time during which no key is activated.",
"fixid": "F-22173r508481_fix",
"fixtext": "Configure each key used for routing protocol authentication to have a lifetime of no more than 180 days as shown in the example below: \n\nSW1(config)#key chain OSPF_KEY_CHAIN \nSW1(config-keychain)#key 1 \nSW1(config-keychain-key)#key-string xxxxxx \nSW1(config-keychain-key)#send-lifetime 00:00:00 Jan 1 2018 23:59:59 Mar 31 2018 \nSW1(config-keychain-key)#accept-lifetime 00:00:00 Jan 1 2018 01:05:00 Apr 1 2018 \nSW1(config-keychain-key)#exit \nSW1(config-keychain)#key 2 \nSW1(config-keychain-key)#key-string yyyyyyy \nSW1(config-keychain-key)#send-lifetime 00:00:00 Apr 1 2018 23:59:59 Jun 30 2018 \nSW1(config-keychain-key)#accept-lifetime 23:55:00 Mar 31 2018 01:05:00 Jul 1 2018 \nSW1(config-keychain-key)#end",
"iacontrols": null,
"id": "V-220469",
"ruleID": "SV-220469r622190_rule",
"severity": "medium",
"title": "The Cisco switch must be configured to use keys with a duration not exceeding 180 days for authenticating routing protocol messages.",
"version": "CISC-RT-000030"
},
"V-220470": {
"checkid": "C-22185r508483_chk",
"checktext": "Review the switch configuration to determine if the call home service is enabled as shown in the example below: \n\ncall-home \n contact-email-addr username@example.com \n phone-number \"+1-800-555-4567\" \n customer-id \"Customer1234\" \n contract-id \"Company1234\" \n\nIf the call home feature is configured to call home to the vendor, this is a finding.",
"description": "Call home services will routinely send data such as configuration and diagnostic information to the vendor for routine or emergency analysis and troubleshooting. There is a risk that transmission of sensitive data sent to unauthorized persons could result in data loss or downtime due to an attack.",
"fixid": "F-22174r508484_fix",
"fixtext": "Disable the call home feature as shown below: \n\nSW1(config)#no call-home",
"iacontrols": null,
"id": "V-220470",
"ruleID": "SV-220470r622190_rule",
"severity": "medium",
"title": "The Cisco switch must not be configured to have any feature enabled that calls home to the vendor.",
"version": "CISC-RT-000080"
},
"V-220471": {
"checkid": "C-22186r508486_chk",
"checktext": "Review the switch configuration to verify that uRPF or an egress ACL has been configured on all internal interfaces to restrict the switch from accepting outbound IP packets that contain an illegitimate address in the source address field. \n\nuRPF example: \n\ninterface GigabitEthernet0/1 \n description downstream link to LAN \n ip address 10.1.25.5 255.255.255.0 \n ip verify unicast source reachable-via rx \n\nEgress ACL example: \n\ninterface GigabitEthernet0/1 \n description downstream link to LAN \n ip address 10.1.25.5 255.255.255.0 \n ip access-group EGRESS_FILTER in \n\u2026 \n\u2026 \n\u2026 \nip access-list extended EGRESS_FILTER \n permit udp 10.1.15.0 0.0.0.255 any eq domain \n permit tcp 10.1.15.0 0.0.0.255 any eq ftp \n permit tcp 10.1.15.0 0.0.0.255 any eq ftp-data \n permit tcp 10.1.15.0 0.0.0.255 any eq www \n permit icmp 10.1.15.0 0.0.0.255 any \n permit icmp 10.1.15.0 0.0.0.255 any echo \n deny ip any any \n\nIf uRPF or an egress ACL to restrict the switch from accepting outbound IP packets that contain an illegitimate address in the source address field has not been configured on all internal interfaces in an enclave, this is a finding.",
"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. \n\nThis 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.",
"fixid": "F-22175r508487_fix",
"fixtext": "Configure the switch to ensure that an egress ACL or uRPF is configured on internal interfaces to restrict the switch from accepting any outbound IP packet that contains an illegitimate address in the source field. The example below enables uRPF. \n\nSW1(config)#int g0/1 \nSW1(config-if)#ip verify unicast source reachable-via rx",
"iacontrols": null,
"id": "V-220471",
"ruleID": "SV-220471r622190_rule",
"severity": "high",
"title": "The Cisco perimeter switch must be configured to restrict it from accepting outbound IP packets that contain an illegitimate address in the source address field via egress filter or by enabling Unicast Reverse Path Forwarding (uRPF).",
"version": "CISC-RT-000310"
},
"V-220472": {
"checkid": "C-22187r508489_chk",
"checktext": "Review the switch configuration to determine if it will block all packets with IP options. \n\nip access-list extended EXTERNAL_ACL \n permit tcp any any established \ndeny ip any any option any-options \npermit \u2026 \n \u2026 \n \u2026 \n \u2026 \ndeny ip any any log-input \n\nIf the switch is not configured to drop all packets with IP options, this is a finding.",
"description": "Packets with IP options are not fast switched and henceforth must be punted to the switch processor. Hackers who initiate denial-of-service (DoS) attacks on switches commonly send large streams of packets with IP options. Dropping the packets with IP options reduces the load of IP options packets on the switch. The end result is a reduction in the effects of the DoS attack on the switch and on downstream switches.",
"fixid": "F-22176r508490_fix",
"fixtext": "Configure the switch to drop all packets with IP options. \n\nSW1(config)#ip access-list extended EXTERNAL_ACL \nSW1(config-ext-nacl)#15 deny ip any any option any-options",
"iacontrols": null,
"id": "V-220472",
"ruleID": "SV-220472r622190_rule",
"severity": "medium",
"title": "The Cisco perimeter switch must be configured to block all packets with any IP options.",
"version": "CISC-RT-000350"
},
"V-220473": {
"checkid": "C-22188r508492_chk",
"checktext": "Review the switch configuration to determine if it will ignore or drop all packets with IP options as shown in the examples below:\n\nip options drop\nor\nip options ignore\n\nIf the switch is not configured to drop or block all packets with IP options, this is a finding.",
"description": "Packets with IP options are not fast-switched and therefore must be punted to the switch processor. Hackers who initiate denial-of-service (DoS) attacks on switches commonly send large streams of packets with IP options. Dropping the packets with IP options reduces the load of IP options packets on the switch. The end result is a reduction in the effects of the DoS attack on the switch and on downstream switches.",
"fixid": "F-22177r508493_fix",
"fixtext": "Configure the switch to ignore or drop all packets with IP options as shown in the examples below:\n\nSW1(config)#ip options ignore \n\nor\n\nSW1(config)#ip options drop",
"iacontrols": null,
"id": "V-220473",
"ruleID": "SV-220473r622190_rule",
"severity": "medium",
"title": "The Cisco PE switch must be configured to ignore or drop all packets with any IP options.",
"version": "CISC-RT-000750"
},
"V-237749": {
"checkid": "C-40969r648773_chk",
"checktext": "Review the switch to verify that CEF is enabled.\n\nIPv4 Example: ip cef \nIPv6 Example: ipv6 cef \n\nIf the switch is not configured to have CEF enabled, this is a finding.\n",
"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 switch will have to handle. Consequently, switches configured for CEF will perform better under SYN floods directed at hosts inside the network than switches using the traditional cache. ",
"fixid": "F-40931r648774_fix",
"fixtext": "Enable CEF\n\nIPv4 Example: ip cef \nIPv6 Example: ipv6 cef \n",
"iacontrols": null,
"id": "V-237749",
"ruleID": "SV-237749r648775_rule",
"severity": "medium",
"title": "The Cisco switch must be configured to have Cisco Express Forwarding enabled.",
"version": "CISC-RT-000235"
},
"V-237751": {
"checkid": "C-40970r648777_chk",
"checktext": "Review the switch 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 hop-limit has been configured and has not been set to at least 32, it is a finding. \n",
"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.",
"fixid": "F-40932r648778_fix",
"fixtext": "Configure the switch to advertise a hop limit of at least 32 in Router Advertisement messages as shown in the example.\n\nSW1(config)#ipv6 hop-limit 128\n",
"iacontrols": null,
"id": "V-237751",
"ruleID": "SV-237751r648779_rule",
"severity": "low",
"title": "The Cisco switch must be configured to advertise a hop limit of at least 32 in Switch Advertisement messages for IPv6 stateless auto-configuration deployments.",
"version": "CISC-RT-000236"
},
"V-237755": {
"checkid": "C-40973r648784_chk",
"checktext": "Review the switch configuration to ensure FEC0::/10 IPv6 addresses are not defined. \n\nIf IPv6 Site Local Unicast addresses are defined, this is a finding.\n",
"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.",
"fixid": "F-40935r648785_fix",
"fixtext": "Configure the switch using only authorized IPv6 addresses. ",
"iacontrols": null,
"id": "V-237755",
"ruleID": "SV-237755r648786_rule",
"severity": "medium",
"title": "The Cisco switch must not be configured to use IPv6 Site Local Unicast addresses.",
"version": "CISC-RT-000237"
},
"V-237758": {
"checkid": "C-40974r648789_chk",
"checktext": "This requirement is not applicable for the DODIN Backbone. \n\nReview the switch 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 switch is not configured to suppress Router Advertisements on all external IPv6-enabled interfaces, this is a finding.\n",
"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.",
"fixid": "F-40936r648790_fix",
"fixtext": "Configure the switch to suppress Router Advertisements on all external IPv6-enabled interfaces as shown in the example below.\n\nSW1(config)#int g1/0\nSW1(config-if)#ipv6 nd ra suppress\nSW1(config-if)#end\n",
"iacontrols": null,
"id": "V-237758",
"ruleID": "SV-237758r648791_rule",
"severity": "medium",
"title": "The Cisco perimeter switch must be configured to suppress Router Advertisements on all external IPv6-enabled interfaces.",
"version": "CISC-RT-000391"
},
"V-237761": {
"checkid": "C-40976r648796_chk",
"checktext": "This requirement is not applicable for the DODIN Backbone. \n\nReview the switch 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 gigabitethernet1/0\n ipv6 address 2001::1:0:22/64\n ipv6 traffic-filter FILTER_IPV6 in\n\n\nStep 2: Verify that the ACL drops undetermined transport packets as shown in the example below.\n\nipv6 access-list FILTER_IPV6\n deny ipv6 any any log undetermined-transport\n permit ipv6 \u2026\n \u2026\n \u2026\n \u2026\n deny ipv6 any any log\n\nIf the switch is not configured to drop IPv6 undetermined transport packets, this is a finding.\n",
"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.",
"fixid": "F-40938r648797_fix",
"fixtext": "Configure the switch to drop IPv6 undetermined transport packets as shown in the example below.\n\nSW1(config)#ipv6 access-list FILTER_IPV6\nSW1(config-ipv6-acl)#deny ipv6 any any undetermined-transport log\nSW1(config-ipv6-acl)#permit ipv6 \u2026\n\u2026\n\u2026\n\u2026\nSW1(config-ipv6-acl)#deny ipv6 any any log\nSW1(config-ipv6-acl)#exit\nSW1(config)#int g1/0\nSW1(config-if)#ipv6 traffic-filter FILTER_IPV6 in\n",
"iacontrols": null,
"id": "V-237761",
"ruleID": "SV-237761r648798_rule",
"severity": "medium",
"title": "The Cisco perimeter switch must be configured to drop IPv6 undetermined transport packets.",
"version": "CISC-RT-000392"
},
"V-237763": {
"checkid": "C-40977r648800_chk",
"checktext": "This requirement is not applicable for the DODIN Backbone. \n\nReview the switch 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 gigabitethernet1/0\n ipv6 address 2001::1:0:22/64\n ipv6 traffic-filter FILTER_IPV6 in\n\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 permit ipv6 any host 2001:DB8::1:1:1234 routing-type 2\n deny ipv6 any any log routing\n permit ipv6 \u2026\n \u2026\n \u2026\n \u2026\ndeny ipv6 any any log\n\nNote: The example above allows routing-type 2 in the event Mobility IPv6 is deployed.\n\nIf the switch is not configured to drop IPv6 packets containing a Routing Header of type 0, 1, or 3-255, this is a finding.\n",
"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\u2013255 Routing Header values in the routing type field are currently undefined and should be dropped inbound and outbound. \n",
"fixid": "F-40939r648801_fix",
"fixtext": "Configure the switch to drop IPv6 packets with Routing Header of type 0, 1, or 3-255 as shown in the example below.\nSW1(config)#ipv6 access-list FILTER_IPV6\nSW1(config-ipv6-acl)#permit ipv6 any host 2001:DB8::0:1:1:1234 routing-type 2\nSW1(config-ipv6-acl)#deny ipv6 any any routing log\nSW1(config-ipv6-acl)#permit \u2026\n\u2026\n\u2026\n\u2026\nSW1(config-ipv6-acl)#deny ipv6 any any log\nSW1(config-ipv6-acl)#exit\nSW1(config)#int g1/0\nSW1(config-if)#ipv6 traffic-filter FILTER_IPV6\n",
"iacontrols": null,
"id": "V-237763",
"ruleID": "SV-237763r648802_rule",
"severity": "medium",
"title": "The Cisco perimeter switch must be configured drop IPv6 packets with a Routing Header type 0, 1, or 3-255. ",
"version": "CISC-RT-000393"
},
"V-237765": {
"checkid": "C-40978r648804_chk",
"checktext": "This requirement is not applicable for the DODIN Backbone. \n\nReview the switch 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 gigabitethernet1/0\n ipv6 address 2001::1:0:22/64\n ipv6 traffic-filter FILTER_IPV6 in\n\n\nStep 2: Verify that the ACL drops IPv6 packets containing a Hop-by-Hop header with option type values of 0x04 (Tunnel Encapsulation Limit), 0xC9 (Home Address Destination), or 0xC3 (NSAP Address) as shown in the example below.\n\nipv6 access-list FILTER_IPV6\n deny hbh any any dest-option-type 4 log\n deny hbh any any dest-option-type 195 log\n deny hbh any any dest-option-type home-address log \n permit ipv6 \u2026\n \u2026\n \u2026\n \u2026\n deny ipv6 any any log\n\n\nIf the switch is not configured to drop IPv6 packets containing a Hop-by-Hop header with invalid option type values, this is a finding.\n",
"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. ",
"fixid": "F-40940r648805_fix",
"fixtext": "Configure the switch to drop IPv6 packets containing a Hop-by-Hop header with invalid option type values as shown in the example below.\n\nSW1(config)#ipv6 access-list FILTER_IPV6\nSW1(config-ipv6-acl)#deny hbh any any dest-option-type 4 log\nSW1(config-ipv6-acl)#deny hbh any any dest-option-type 195 log\nSW1(config-ipv6-acl)#deny hbh any any dest-option-type home-address log\nSW1(config-ipv6-acl)# permit ipv6 \u2026\n\u2026\n\u2026\n\u2026\nSW1(config-ipv6-acl)#deny ipv6 any any log\nSW1(config-ipv6-acl)#exit\nSW1(config)#int g1/0\nSW1(config-if)#ipv6 traffic-filter FILTER_IPV6\nSW1(config-if)#end\n",
"iacontrols": null,
"id": "V-237765",
"ruleID": "SV-237765r648806_rule",
"severity": "medium",
"title": "The Cisco perimeter switch must be configured to drop IPv6 packets containing a Hop-by-Hop header with invalid option type values.",
"version": "CISC-RT-000394"
},
"V-237771": {
"checkid": "C-40985r648808_chk",
"checktext": "This requirement is not applicable for the DODIN Backbone. \n\nReview the switch 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 gigabitethernet1/0\n ipv6 address 2001::1:0:22/64\n ipv6 traffic-filter FILTER_IPV6 in\n\n\nStep 2: Verify that the ACL drops IPv6 packets containing a Destination Option header with option type values of 0x05 (Switch Alert) or 0xC2 (Jumbo Payload) as shown in the example below.\n\nipv6 access-list FILTER_IPV6\n deny 60 any any dest-option-type 5 log\n deny 60 any any dest-option-type 194 log\n permit ipv6 \u2026\n \u2026\n \u2026\n \u2026\n deny ipv6 any any log\n\nIf the switch is not configured to drop IPv6 packets containing a Destination Option header with option type values of 0x05 (Switch Alert) or 0xC2 (Jumbo Payload), this is a finding.\n",
"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. ",
"fixid": "F-40944r648809_fix",
"fixtext": "Configure the switch to drop IPv6 packets containing a Destination Option header with option type values of 0x05 (Switch Alert) or 0xC2 (Jumbo Payload) as shown in the example below.\n\nSW1(config)#ipv6 access-list FILTER_IPV6\nSW1(config-ipv6-acl)#deny 60 any any dest-option-type 5 log\nSW1(config-ipv6-acl)#deny 60 any any dest-option-type 194 log\nSW1(config-ipv6-acl)#permit \u2026\n\u2026\n\u2026\n\u2026\nSW1(config-ipv6-acl)#deny ipv6 any any log\nSW1(config-ipv6-acl)#exit\nSW1(config)#int g1/0\nSW1(config-if)#ipv6 traffic-filter FILTER_IPV6\nSW1(config-if)#end\n",
"iacontrols": null,
"id": "V-237771",
"ruleID": "SV-237771r648810_rule",
"severity": "medium",
"title": "The Cisco perimeter switch must be configured to drop IPv6 packets containing a Destination Option header with invalid option type values.",
"version": "CISC-RT-000395"
},
"V-237773": {
"checkid": "C-40986r648812_chk",
"checktext": "This requirement is not applicable for the DODIN Backbone. \n\nReview the switch 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 gigabitethernet1/0\n ipv6 address 2001::1:0:22/64\n ipv6 traffic-filter FILTER_IPV6 in\n\n\nStep 2: Verify that the ACL drops IPv6 packets containing an extension header with the Endpoint Identification option as shown in the example below.\n\nipv6 access-list FILTER_IPV6\n deny any any dest-option-type 138 log\n permit ipv6 \u2026\n \u2026\n \u2026\n \u2026\n deny ipv6 any any log\n\n\nIf the switch is not configured to drop IPv6 packets containing an extension header with the Endpoint Identification option, this is a finding.\n",
"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.",
"fixid": "F-40945r648813_fix",
"fixtext": "Configure the switch to drop IPv6 packets containing an option type values 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\nSW1(config)#ipv6 access-list FILTER_IPV6\nSW1(config-ipv6-acl)#deny any any dest-option-type 138 log\nSW1(config-ipv6-acl)#permit ipv6 \u2026\n\u2026\n\u2026\n\u2026\nSW1(config-ipv6-acl)# deny ipv6 any any log\nSW1(config-ipv6-acl)#exit\nSW1(config)#int g1/0\nSW1(config-if)#ipv6 traffic-filter FILTER_IPV6\nSW1(config-if)#end\n",
"iacontrols": null,
"id": "V-237773",
"ruleID": "SV-237773r648814_rule",
"severity": "medium",
"title": "The Cisco perimeter switch must be configured to drop IPv6 packets containing an extension header with the Endpoint Identification option.",
"version": "CISC-RT-000396"
},
"V-237775": {
"checkid": "C-40987r648816_chk",
"checktext": "This requirement is not applicable for the DODIN Backbone. \n\nReview the switch configuration and determine if filters are bound to the applicable interfaces to drop IPv6 packets containing a Destination Option header with option type value of 0xC3 (NSAP address). \n\nStep 1: Verify that an inbound IPv6 ACL has been configured on the external interface.\n\ninterface gigabitethernet1/0\n ipv6 address 2001::1:0:22/64\n ipv6 traffic-filter FILTER_IPV6 in\n\n\nStep 2: Verify that the ACL drops IPv6 packets containing the NSAP address option within Destination Option header as shown in the example below.\n\nipv6 access-list FILTER_IPV6\n deny 60 any any dest-option-type 195 log\n permit ipv6 \u2026\n \u2026\n \u2026\n \u2026\n deny ipv6 any any log\n\nIf the switch is not configured to drop IPv6 packets containing the NSAP address option within Destination Option header, this is a finding.\n",
"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.",
"fixid": "F-40946r648817_fix",
"fixtext": "Configure the switch to to drop IPv6 packets containing the NSAP address option within Destination Option header as shown in the example below.\n\nSW1(config)#ipv6 access-list FILTER_IPV6\nSW1(config-ipv6-acl)#deny 60 any any dest-option-type 195 log\nSW1(config-ipv6-acl)#permit \u2026\n\u2026\n\u2026\n\u2026\nSW1(config-ipv6-acl)# deny ipv6 any any log\nSW1(config-ipv6-acl)#exit\nSW1(config)#int g1/0\nSW1(config-if)#ipv6 traffic-filter FILTER_IPV6\nSW1(config-if)#end\n",
"iacontrols": null,
"id": "V-237775",
"ruleID": "SV-237775r648818_rule",
"severity": "medium",
"title": "The Cisco perimeter switch must be configured to drop IPv6 packets containing the NSAP address option within Destination Option header.",
"version": "CISC-RT-000397"
},
"V-237777": {
"checkid": "C-40988r648820_chk",
"checktext": "This requirement is not applicable for the DODIN Backbone. \n\nReview the switch 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 \u2013 0xE, 0x10 \u2013 0x22, 0x24, 0x25, 0x27 \u2013 0x2F, and 0x31 \u2013 0xFF.\n\nStep 1: Verify that an inbound IPv6 ACL has been configured on the external interface.\n\ninterface gigabitethernet1/0\n ipv6 address 2001::1:0:22/64\n ipv6 traffic-filter FILTER_IPV6 in\n\n\nStep 2: Verify that the ACL drops IPv6 packets containing a Hop-by-Hop or Destination Option extension header with an undefined option type as shown in the example below.\n\nipv6 access-list FILTER_IPV6\n deny any any dest-option-type 2\n deny any any dest-option-type 3\n deny any any dest-option-type 6\n deny any any dest-option-type 9\n deny any any dest-option-type 10\n deny any any dest-option-type 11\n deny any any dest-option-type 12\n deny any any dest-option-type 13\n deny any any dest-option-type 14\n deny any any dest-option-type 16\n \u2026\n deny any any dest-option-type 34\n deny any any dest-option-type 36\n deny any any dest-option-type 37\n deny any any dest-option-type 39\n \u2026\n deny any any dest-option-type 47\n deny any any dest-option-type 49\n \u2026 \n deny any any dest-option-type 255\n permit \u2026\n \u2026\n \u2026\n \u2026\n deny ipv6 any any log\n\nNote: Because hop-by-hop and destination options have the same exact header format, they can be combined under the dest-option-type keyword. Since Hop-by-Hop and Destination Option headers have non-overlapping types, you can use dest-option-type to match either.\n\nIf the switch is not configured to drop IPv6 packets containing a Hop-by-Hop or Destination Option extension header with an undefined option type, this is a finding.\n",
"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. ",
"fixid": "F-40947r648821_fix",
"fixtext": "Configure the switch 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 as shown in the example below.\n\nSW1(config)#ipv6 access-list FILTER_IPV6\nSW1(config-ipv6-acl)#deny any any dest-option-type 2\nSW1(config-ipv6-acl)#deny any any dest-option-type 3\nSW1(config-ipv6-acl)#deny any any dest-option-type 6\nSW1(config-ipv6-acl)#deny any any dest-option-type 9\nSW1(config-ipv6-acl)#deny any any dest-option-type 10\nSW1(config-ipv6-acl)#deny any any dest-option-type 11\nSW1(config-ipv6-acl)#deny any any dest-option-type 12\nSW1(config-ipv6-acl)#deny any any dest-option-type 13\nSW1(config-ipv6-acl)#deny any any dest-option-type 14\nSW1(config-ipv6-acl)#deny any any dest-option-type 16\n \u2026\nSW1(config-ipv6-acl)#deny any any dest-option-type 34\nSW1(config-ipv6-acl)#deny any any dest-option-type 36\nSW1(config-ipv6-acl)#deny any any dest-option-type 37\nSW1(config-ipv6-acl)#deny any any dest-option-type 39\n\u2026\nSW1(config-ipv6-acl)#deny any any dest-option-type 47\nSW1(config-ipv6-acl)#deny any any dest-option-type 49\n\u2026 \nSW1(config-ipv6-acl)#deny any any dest-option-type 255\nSW1(config-ipv6-acl)#permit \u2026\n\u2026\n\u2026\n\u2026\nSW1(config-ipv6-acl)#deny ipv6 any any log\nSW1(config-ipv6-acl)#exit\nSW1(config)#int g1/0\nSW1(config-if)#ipv6 traffic-filter FILTER_IPV6\n",
"iacontrols": null,
"id": "V-237777",
"ruleID": "SV-237777r648822_rule",
"severity": "medium",
"title": "The Cisco perimeter switch must be configured to drop IPv6 packets containing a Hop-by-Hop or Destination Option extension header with an undefined option type.",
"version": "CISC-RT-000398"
}
},
"profiles": {
"MAC-1_Classified": {
"description": "",
"findings": {
"V-220419": "true",
"V-220422": "true",
"V-220423": "true",
"V-220424": "true",
"V-220425": "true",
"V-220427": "true",
"V-220428": "true",
"V-220429": "true",
"V-220430": "true",
"V-220431": "true",
"V-220432": "true",
"V-220433": "true",
"V-220434": "true",
"V-220435": "true",
"V-220436": "true",
"V-220437": "true",
"V-220438": "true",
"V-220439": "true",
"V-220440": "true",
"V-220441": "true",
"V-220442": "true",
"V-220443": "true",
"V-220445": "true",
"V-220446": "true",
"V-220447": "true",
"V-220449": "true",
"V-220450": "true",
"V-220451": "true",
"V-220452": "true",
"V-220453": "true",
"V-220454": "true",
"V-220455": "true",
"V-220456": "true",
"V-220458": "true",
"V-220459": "true",
"V-220460": "true",
"V-220461": "true",
"V-220462": "true",
"V-220463": "true",
"V-220464": "true",
"V-220465": "true",
"V-220466": "true",
"V-220467": "true",
"V-220468": "true",
"V-220469": "true",
"V-220470": "true",
"V-220471": "true",
"V-220472": "true",
"V-220473": "true",
"V-237749": "true",
"V-237751": "true",
"V-237755": "true",
"V-237758": "true",
"V-237761": "true",
"V-237763": "true",
"V-237765": "true",
"V-237771": "true",
"V-237773": "true",
"V-237775": "true",
"V-237777": "true"
},
"id": "MAC-1_Classified",
"title": "I - Mission Critical Classified"
},
"MAC-1_Public": {
"description": "",
"findings": {
"V-220419": "true",
"V-220422": "true",
"V-220423": "true",
"V-220424": "true",
"V-220425": "true",
"V-220427": "true",
"V-220428": "true",
"V-220429": "true",
"V-220430": "true",
"V-220431": "true",
"V-220432": "true",
"V-220433": "true",
"V-220434": "true",
"V-220435": "true",
"V-220436": "true",
"V-220437": "true",
"V-220438": "true",
"V-220439": "true",
"V-220440": "true",
"V-220441": "true",
"V-220442": "true",
"V-220443": "true",
"V-220445": "true",
"V-220446": "true",
"V-220447": "true",
"V-220449": "true",
"V-220450": "true",
"V-220451": "true",
"V-220452": "true",
"V-220453": "true",
"V-220454": "true",
"V-220455": "true",
"V-220456": "true",
"V-220458": "true",
"V-220459": "true",
"V-220460": "true",
"V-220461": "true",
"V-220462": "true",
"V-220463": "true",
"V-220464": "true",
"V-220465": "true",
"V-220466": "true",
"V-220467": "true",
"V-220468": "true",
"V-220469": "true",
"V-220470": "true",
"V-220471": "true",
"V-220472": "true",
"V-220473": "true",
"V-237749": "true",
"V-237751": "true",
"V-237755": "true",
"V-237758": "true",
"V-237761": "true",
"V-237763": "true",
"V-237765": "true",
"V-237771": "true",
"V-237773": "true",
"V-237775": "true",
"V-237777": "true"
},
"id": "MAC-1_Public",
"title": "I - Mission Critical Public"
},
"MAC-1_Sensitive": {
"description": "",
"findings": {
"V-220419": "true",
"V-220422": "true",
"V-220423": "true",
"V-220424": "true",
"V-220425": "true",
"V-220427": "true",
"V-220428": "true",
"V-220429": "true",
"V-220430": "true",
"V-220431": "true",
"V-220432": "true",
"V-220433": "true",
"V-220434": "true",
"V-220435": "true",
"V-220436": "true",
"V-220437": "true",
"V-220438": "true",
"V-220439": "true",
"V-220440": "true",
"V-220441": "true",
"V-220442": "true",
"V-220443": "true",
"V-220445": "true",
"V-220446": "true",
"V-220447": "true",
"V-220449": "true",
"V-220450": "true",
"V-220451": "true",
"V-220452": "true",
"V-220453": "true",
"V-220454": "true",
"V-220455": "true",
"V-220456": "true",
"V-220458": "true",
"V-220459": "true",
"V-220460": "true",
"V-220461": "true",
"V-220462": "true",
"V-220463": "true",
"V-220464": "true",
"V-220465": "true",
"V-220466": "true",
"V-220467": "true",
"V-220468": "true",
"V-220469": "true",
"V-220470": "true",
"V-220471": "true",
"V-220472": "true",
"V-220473": "true",
"V-237749": "true",
"V-237751": "true",
"V-237755": "true",
"V-237758": "true",
"V-237761": "true",
"V-237763": "true",
"V-237765": "true",
"V-237771": "true",
"V-237773": "true",
"V-237775": "true",
"V-237777": "true"
},
"id": "MAC-1_Sensitive",
"title": "I - Mission Critical Sensitive"
},
"MAC-2_Classified": {
"description": "",
"findings": {
"V-220419": "true",
"V-220422": "true",
"V-220423": "true",
"V-220424": "true",
"V-220425": "true",
"V-220427": "true",
"V-220428": "true",
"V-220429": "true",
"V-220430": "true",
"V-220431": "true",
"V-220432": "true",
"V-220433": "true",
"V-220434": "true",
"V-220435": "true",
"V-220436": "true",
"V-220437": "true",
"V-220438": "true",
"V-220439": "true",
"V-220440": "true",
"V-220441": "true",
"V-220442": "true",
"V-220443": "true",
"V-220445": "true",
"V-220446": "true",
"V-220447": "true",
"V-220449": "true",
"V-220450": "true",
"V-220451": "true",
"V-220452": "true",
"V-220453": "true",
"V-220454": "true",
"V-220455": "true",
"V-220456": "true",
"V-220458": "true",
"V-220459": "true",
"V-220460": "true",
"V-220461": "true",
"V-220462": "true",
"V-220463": "true",
"V-220464": "true",
"V-220465": "true",
"V-220466": "true",
"V-220467": "true",
"V-220468": "true",
"V-220469": "true",
"V-220470": "true",
"V-220471": "true",
"V-220472": "true",
"V-220473": "true",
"V-237749": "true",
"V-237751": "true",
"V-237755": "true",
"V-237758": "true",
"V-237761": "true",
"V-237763": "true",
"V-237765": "true",
"V-237771": "true",
"V-237773": "true",
"V-237775": "true",
"V-237777": "true"
},
"id": "MAC-2_Classified",
"title": "II - Mission Support Classified"
},
"MAC-2_Public": {
"description": "",
"findings": {
"V-220419": "true",
"V-220422": "true",
"V-220423": "true",
"V-220424": "true",
"V-220425": "true",
"V-220427": "true",
"V-220428": "true",
"V-220429": "true",
"V-220430": "true",
"V-220431": "true",
"V-220432": "true",
"V-220433": "true",
"V-220434": "true",
"V-220435": "true",
"V-220436": "true",
"V-220437": "true",
"V-220438": "true",
"V-220439": "true",
"V-220440": "true",
"V-220441": "true",
"V-220442": "true",
"V-220443": "true",
"V-220445": "true",
"V-220446": "true",
"V-220447": "true",
"V-220449": "true",
"V-220450": "true",
"V-220451": "true",
"V-220452": "true",
"V-220453": "true",
"V-220454": "true",
"V-220455": "true",
"V-220456": "true",
"V-220458": "true",
"V-220459": "true",
"V-220460": "true",
"V-220461": "true",
"V-220462": "true",
"V-220463": "true",
"V-220464": "true",
"V-220465": "true",
"V-220466": "true",
"V-220467": "true",
"V-220468": "true",
"V-220469": "true",
"V-220470": "true",
"V-220471": "true",
"V-220472": "true",
"V-220473": "true",
"V-237749": "true",
"V-237751": "true",
"V-237755": "true",
"V-237758": "true",
"V-237761": "true",
"V-237763": "true",
"V-237765": "true",
"V-237771": "true",
"V-237773": "true",
"V-237775": "true",
"V-237777": "true"
},
"id": "MAC-2_Public",
"title": "II - Mission Support Public"
},
"MAC-2_Sensitive": {
"description": "",
"findings": {
"V-220419": "true",
"V-220422": "true",
"V-220423": "true",
"V-220424": "true",
"V-220425": "true",
"V-220427": "true",
"V-220428": "true",
"V-220429": "true",
"V-220430": "true",
"V-220431": "true",
"V-220432": "true",
"V-220433": "true",
"V-220434": "true",
"V-220435": "true",
"V-220436": "true",
"V-220437": "true",
"V-220438": "true",
"V-220439": "true",
"V-220440": "true",
"V-220441": "true",
"V-220442": "true",
"V-220443": "true",
"V-220445": "true",
"V-220446": "true",
"V-220447": "true",
"V-220449": "true",
"V-220450": "true",
"V-220451": "true",
"V-220452": "true",
"V-220453": "true",
"V-220454": "true",
"V-220455": "true",
"V-220456": "true",
"V-220458": "true",
"V-220459": "true",
"V-220460": "true",
"V-220461": "true",
"V-220462": "true",
"V-220463": "true",
"V-220464": "true",
"V-220465": "true",
"V-220466": "true",
"V-220467": "true",
"V-220468": "true",
"V-220469": "true",
"V-220470": "true",
"V-220471": "true",
"V-220472": "true",
"V-220473": "true",
"V-237749": "true",
"V-237751": "true",
"V-237755": "true",
"V-237758": "true",
"V-237761": "true",
"V-237763": "true",
"V-237765": "true",
"V-237771": "true",
"V-237773": "true",
"V-237775": "true",
"V-237777": "true"
},
"id": "MAC-2_Sensitive",
"title": "II - Mission Support Sensitive"
},
"MAC-3_Classified": {
"description": "",
"findings": {
"V-220419": "true",
"V-220422": "true",
"V-220423": "true",
"V-220424": "true",
"V-220425": "true",
"V-220427": "true",
"V-220428": "true",
"V-220429": "true",
"V-220430": "true",
"V-220431": "true",
"V-220432": "true",
"V-220433": "true",
"V-220434": "true",
"V-220435": "true",
"V-220436": "true",
"V-220437": "true",
"V-220438": "true",
"V-220439": "true",
"V-220440": "true",
"V-220441": "true",
"V-220442": "true",
"V-220443": "true",
"V-220445": "true",
"V-220446": "true",
"V-220447": "true",
"V-220449": "true",
"V-220450": "true",
"V-220451": "true",
"V-220452": "true",
"V-220453": "true",
"V-220454": "true",
"V-220455": "true",
"V-220456": "true",
"V-220458": "true",
"V-220459": "true",
"V-220460": "true",
"V-220461": "true",
"V-220462": "true",
"V-220463": "true",
"V-220464": "true",
"V-220465": "true",
"V-220466": "true",
"V-220467": "true",
"V-220468": "true",
"V-220469": "true",
"V-220470": "true",
"V-220471": "true",
"V-220472": "true",
"V-220473": "true",
"V-237749": "true",
"V-237751": "true",
"V-237755": "true",
"V-237758": "true",
"V-237761": "true",
"V-237763": "true",
"V-237765": "true",
"V-237771": "true",
"V-237773": "true",
"V-237775": "true",
"V-237777": "true"
},
"id": "MAC-3_Classified",
"title": "III - Administrative Classified"
},
"MAC-3_Public": {
"description": "",
"findings": {
"V-220419": "true",
"V-220422": "true",
"V-220423": "true",
"V-220424": "true",
"V-220425": "true",
"V-220427": "true",
"V-220428": "true",
"V-220429": "true",
"V-220430": "true",
"V-220431": "true",
"V-220432": "true",
"V-220433": "true",
"V-220434": "true",
"V-220435": "true",
"V-220436": "true",
"V-220437": "true",
"V-220438": "true",
"V-220439": "true",
"V-220440": "true",
"V-220441": "true",
"V-220442": "true",
"V-220443": "true",
"V-220445": "true",
"V-220446": "true",
"V-220447": "true",
"V-220449": "true",
"V-220450": "true",
"V-220451": "true",
"V-220452": "true",
"V-220453": "true",
"V-220454": "true",
"V-220455": "true",
"V-220456": "true",
"V-220458": "true",
"V-220459": "true",
"V-220460": "true",
"V-220461": "true",
"V-220462": "true",
"V-220463": "true",
"V-220464": "true",
"V-220465": "true",
"V-220466": "true",
"V-220467": "true",
"V-220468": "true",
"V-220469": "true",
"V-220470": "true",
"V-220471": "true",
"V-220472": "true",
"V-220473": "true",
"V-237749": "true",
"V-237751": "true",
"V-237755": "true",
"V-237758": "true",
"V-237761": "true",
"V-237763": "true",
"V-237765": "true",
"V-237771": "true",
"V-237773": "true",
"V-237775": "true",
"V-237777": "true"
},
"id": "MAC-3_Public",
"title": "III - Administrative Public"
},
"MAC-3_Sensitive": {
"description": "",
"findings": {
"V-220419": "true",
"V-220422": "true",
"V-220423": "true",
"V-220424": "true",
"V-220425": "true",
"V-220427": "true",
"V-220428": "true",
"V-220429": "true",
"V-220430": "true",
"V-220431": "true",
"V-220432": "true",
"V-220433": "true",
"V-220434": "true",
"V-220435": "true",
"V-220436": "true",
"V-220437": "true",
"V-220438": "true",
"V-220439": "true",
"V-220440": "true",
"V-220441": "true",
"V-220442": "true",
"V-220443": "true",
"V-220445": "true",
"V-220446": "true",
"V-220447": "true",
"V-220449": "true",
"V-220450": "true",
"V-220451": "true",
"V-220452": "true",
"V-220453": "true",
"V-220454": "true",
"V-220455": "true",
"V-220456": "true",
"V-220458": "true",
"V-220459": "true",
"V-220460": "true",
"V-220461": "true",
"V-220462": "true",
"V-220463": "true",
"V-220464": "true",
"V-220465": "true",
"V-220466": "true",
"V-220467": "true",
"V-220468": "true",
"V-220469": "true",
"V-220470": "true",
"V-220471": "true",
"V-220472": "true",
"V-220473": "true",
"V-237749": "true",
"V-237751": "true",
"V-237755": "true",
"V-237758": "true",
"V-237761": "true",
"V-237763": "true",
"V-237765": "true",
"V-237771": "true",
"V-237773": "true",
"V-237775": "true",
"V-237777": "true"
},
"id": "MAC-3_Sensitive",
"title": "III - Administrative Sensitive"
}
},
"slug": "cisco_ios_switch_rtr",
"title": "Cisco IOS Switch RTR Security Technical Implementation Guide",
"version": "2"
}
}