None Computing title Cisco ACI Router Security Technical Implementation Guide version 1 releaseinfo Release: 2 Vuln_Num V-272061 Rule_ID SV-272061r1168386_rule Severity medium Rule_Title The Cisco ACI must be configured to enforce approved authorizations for controlling the flow of information within the network based on organization-defined information flow control policies. Vuln_Discuss 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. In Cisco ACI, the administrator uses "contracts" to define security policies that control traffic between different endpoint groups (EPGs), essentially acting as a more granular and flexible ACL mechanism by specifying source and destination addresses, ports, and protocols based on the desired network segmentation needs. Add multiple filter rules to create a comprehensive set of allowed traffic patterns. Satisfies: SRG-NET-000019-RTR-000005, SRG-NET-000715-RTR-000120 Check_Content Review the switch configuration to verify that contracts are configured. 1. To check contract configuration, navigate to Tenants >> {{Your_Tenant}} >> Contracts >> Standard (whitelist)/Taboos (blacklist) >> {{Your_Contract}} >> {{your_subject}}. 2. To check the configuration for the Provider and Consumer of the contract, navigate to Tenants >> {{Your_Tenant}} >> Application Profiles >> {{ your_Application_Profile}} >> Application EPGs >> {{Your_EPG}} >> Contracts. If the switch is not configured to use contract filters to enforce approved authorizations for controlling the flow of information within the network based on organization-defined information flow control policies, this is a finding. Fix_Text Configure "contracts" to define security policies that control traffic between different EPGs. Contract subjects must combine filters that will designate what traffic is allowed to pass through the contract, but for the contract to work it must be applied where the Provider contract is attached to the service side and the Consumer is attached to the user side. Traffic must be initiated from the Consumer EPG to the Provider EPG, including filters and security policies. 1. Configure the details of each contract. Navigate to Tenants >> {{Your_Tenant}} >> Contracts >> Standard (whitelist)/Taboos (blacklist) >> {{Your_Contract}} >> {{your_subject}}. 2. Configure the details of each Provider and Consumer of the contract. Navigate to Tenants >> {{Your_Tenant}} >> Application Profiles >> {{ your_Application_Profile}} >> Application EPGs >> {{Your_EPG}} >> Contracts. Not_Reviewed Vuln_Num V-272062 Rule_ID SV-272062r1168387_rule Severity medium Rule_Title The BGP Cisco ACI must be configured to reject inbound route advertisements for any prefixes belonging to the local autonomous system (AS). Vuln_Discuss Accepting route advertisements belonging to the local AS can result in traffic looping or being black holed, or at a minimum using a nonoptimized path. For Cisco APIC, the default setting is to prevent route loops from occurring. Sites are required to use different AS numbers when configuring. To prevent such a situation from occurring, sites must not enable the "BGP Autonomous System override" feature to override the default setting, and must not enable the "Disable Peer AS Check". An alternative to route maps is to use subnets under the External EPG with the correct route Controls assigned discussed in vendor documentation (Reference the L3 out white paper). Check_Content Review the switch configuration to verify it will reject routes belonging to the local AS. 1. Verify a prefix list has been configured containing prefixes belonging to the local AS. Navigate to Tenants >> {{your_Tenant}} >> Networking >> L3Outs >> {{your_L3Outs}} >> Route Map for import and export route control. 2. Review the route-map to the inbound BGP policy. Navigate to Tenants >> {{your_Tenant}} >> Networking >> L3Outs >> {{your_L3Outs}} >> External EPGs >> Policy >> General >> Route Control Profile. If the switch is not configured to reject inbound route advertisements belonging to the local AS, this is a finding. Fix_Text Configure the router to reject inbound route advertisements for any prefixes belonging to the local AS. From the relevant BGP peer configuration, create a route-map to filter local AS prefixes. Apply the route-map to the inbound BGP policy. Within the inbound policy, add a prefix filter rule that explicitly rejects any routes with a prefix matching the local AS number. 1. Navigate to Tenants >> {{your_Tenant}} >> Networking >> L3Outs >> {{your_L3Outs}} >> Route Map for import and export route control. 2. Apply that route MAP to the external EPG in the following location: Tenants >> {{your_Tenant}} >> Networking >> L3Outs >> {{your_L3Outs}} >> External EPGs >> Policy >> General >> Route Control Profile. Note: An alternative to route maps is to use subnets under the External EPG with the correct route controls assigned as discussed in vendor documentation (Reference the L3 out white paper). Not_Reviewed Vuln_Num V-272063 Rule_ID SV-272063r1168094_rule Severity medium Rule_Title The BGP Cisco ACI must be configured to reject outbound route advertisements for any prefixes that do not belong to any customers or the local autonomous system (AS). Vuln_Discuss Advertisement of routes by an autonomous system for networks that do not belong to any of its customers pulls traffic away from the authorized network. This causes a denial of service (DoS) on the network that allocated the block of addresses and may cause a DoS on the network that is inadvertently advertising it as the originator. It is also possible that a misconfigured or compromised router within the GIG IP core could redistribute IGP routes into BGP, thereby leaking internal routes. An alternative to route maps is to use subnets under the External EPG with the correct route Controls assigned as discussed in vendor documentation (Reference the L3 out white paper). Check_Content Review the ACI configuration to verify it will reject routes belonging to the local AS. 1. Verify a prefix list has been configured containing prefixes belonging to the local AS. Navigate to Tenants >> {{your_Tenant}} >> Networking >> L3Outs >> {{your_L3Outs}} >> Route Map for import and export route control. 2. Verify the prefix list has been applied to all external BGP peers. Navigate to Tenants >> {{your_Tenant}} >> Networking >> L3Outs >> {{your_L3Outs}} >> External EPGs >> Policy >> General >> Route Control Profile. If the ACI is not configured to reject inbound route advertisements belonging to the local AS, this is a finding. Fix_Text Configure the router to reject outbound route advertisements for any prefixes belonging to the local AS. Use a prefix list containing the local AS prefixes and apply it as an outbound filter on the BGP neighbor configuration. 1. Navigate to Tenants >> {{your_Tenant}} >> Networking >> L3Outs >> {{your_L3Outs}} >> Route Map for import and export route control. 2. Then apply that route MAP to the external EPG in the following location: Tenants >> {{your_Tenant}} >> Networking >> L3Outs >> {{your_L3Outs}} >> External EPGs >> Policy >> General >> Route Control Profile. Note: An alternative to route maps is to use subnets under the External EPG with the correct route Controls assigned as discussed in vendor documentation (Reference the L3 out white paper). Not_Reviewed Vuln_Num V-272064 Rule_ID SV-272064r1168097_rule Severity low Rule_Title The BGP Cisco ACI must be configured to reject route advertisements from BGP peers that do not list their autonomous system (AS) number as the first AS in the AS_PATH attribute. Vuln_Discuss Verifying the path a route has traversed will ensure the IP core is not used as a transit network for unauthorized or possibly even internet traffic. All autonomous system boundary routers (ASBRs) must ensure updates received from eBGP peers list their AS number as the first AS in the AS_PATH attribute. An alternative to route maps is to use subnets under the External EPG with the correct route Controls assigned as discussed in vendor documentation (Reference the L3 out white paper). Check_Content By default, Cisco ACI enforces the first AS in the AS_PATH attribute for all route advertisements. Review the configuration to verify the default BGP configuration on the ACI fabric. 1. Navigate to Tenants >> {{your_Tenant}} >> Networking >> L3Outs >> {{your_L3Outs}} >> Route Map for import and export route control. 2. Apply that route MAP to the external EPG in the following location: Tenants >> {{your_Tenant}} >> Networking >> L3Outs >> {{your_L3Outs}} >> External EPGs >> Policy >> General >> Route Control Profile. If the device is not configured to reject updates from peers that do not list their AS number as the first AS in the AS_PATH attribute, this is a finding. Fix_Text Configure the device to deny updates received from eBGP peers that do not list their AS number as the first AS in the AS_PATH attribute. 1. Navigate to Tenants >> {{your_Tenant}} >> Networking >> L3Outs >> {{your_L3Outs}} >> Route Map for import and export route control. 2. Apply that route MAP to the external EPG in the following location: Tenants >> {{your_Tenant}} >> Networking >> L3Outs >> {{your_L3Outs}} >> External EPGs >> Policy >> General >> Route Control Profile. Note: An alternative to route maps is to use subnets under the External EPG with the correct route Controls assigned discussed in vendor documentation (Reference the L3 out white paper). Not_Reviewed Vuln_Num V-272069 Rule_ID SV-272069r1168390_rule Severity medium Rule_Title The multicast Cisco ACI must be configured to bind a Protocol Independent Multicast (PIM) neighbor filter to interfaces that have PIM enabled. Vuln_Discuss PIM is a routing protocol used to build multicast distribution trees for forwarding multicast traffic across the network infrastructure. PIM traffic must be limited to only known PIM neighbors by configuring and binding a PIM neighbor filter to those interfaces that have PIM enabled. If a PIM neighbor filter is not applied to those interfaces that have PIM enabled, unauthorized routers can join the PIM domain, discover and use the rendezvous points, and also advertise their rendezvous points into the domain. This can result in a denial of service (DoS) by traffic flooding or result in the unauthorized transfer of data. Check_Content 1. Review the network's multicast topology diagram. 2. Review the switch configuration to verify only the PIM interfaces as shown in the multicast topology diagram are enabled for PIM. Navigate to Tenants >> {{your_Tenants}} >> Networking >> VRFs >> {{Your_VRF}} >> multicast >> Configuration >> PIM settings >> Reserved Route MAP. If a multicast interface is required to support PIM and it is not enabled, this is a finding. Fix_Text Configure the relevant multicast enabled interfaces by configuring a route map on the PIM settings for the VRF on the GUI. Navigate to Tenants >> {{your_Tenants}} >> Networking >> VRFs >> {{Your_VRF}} >> multicast >> Configuration >> PIM settings >> Reserved Route MAP. Not_Reviewed Vuln_Num V-272073 Rule_ID SV-272073r1168393_rule Severity low Rule_Title The Cisco ACI multicast rendezvous point (RP) must be configured to filter Protocol Independent Multicast (PIM) Register messages received from the designated router (DR) for any undesirable multicast groups and sources. Vuln_Discuss Real-time multicast traffic can entail multiple large flows of data. An attacker can flood a network segment with multicast packets, over-using the available bandwidth and thereby creating a denial-of-service (DoS) condition. Hence, it is imperative that register messages are accepted only for authorized multicast groups and sources. By configuring route maps, the distribution of RP information that is distributed throughout the network can be controlled. Specify the BSRs or mapping agents to be listened to on each client router and the list of candidates to be advertised (listened to) on each BSR and mapping agent to ensure that what is advertised is what is expected. Check_Content View the configuration to check for PIM compliance on the relevant multicast enabled interfaces by configuring a route map on the PIM settings for the VRF on the GUI. Navigate to Tenants >> {{your_Tenants}} >> Networking >> VRFs>> {{Your_VRF}} >> multicast >> Configuration >> PIM settings >> Reserved Route MAP. If the CISCO ACI peering with PIM-SM routers is not configured with a policy to block registration messages for any undesirable multicast groups and sources, this is a finding. Fix_Text Configure an access list on the rendezvous point (RP) to explicitly deny PIM register messages originating from specific source-group combinations, effectively blocking the propagation of those multicast streams across the network; access this configuration. Configure the relevant multicast enabled interfaces by configuring a route map on the PIM settings for the VRF on the GUI. Navigate to Tenants >> {{your_Tenants}} >> Networking >> VRFs>> {{Your_VRF}} >> multicast >> Configuration >> PIM settings >> Reserved Route MAP. Not_Reviewed Vuln_Num V-272074 Rule_ID SV-272074r1168396_rule Severity low Rule_Title The multicast rendezvous point (RP) Cisco ACI must be configured to filter Protocol Independent Multicast (PIM) Join messages received from the designated router (DR) for any undesirable multicast groups. Vuln_Discuss Real-time multicast traffic can entail multiple large flows of data. An attacker can flood a network segment with multicast packets, over-using the available bandwidth and thereby creating a denial-of-service (DoS) condition. Hence, it is imperative that join messages are only accepted for authorized multicast groups. In a Cisco ACI fabric, the border leaf switches are responsible for handling external multicast traffic and are where access control lists (ACLs) to filter PIM Join messages would be applied. Check_Content View the configuration to verify PIM compliance. Configure the relevant multicast enabled interfaces by configuring a route map on the PIM settings for the VRF on the GUI. Navigate to Tenants >> {{your_Tenants}} >> Networking >> VRFs >> {{Your_VRF}} >> multicast >> Configuration >> PIM settings >> Reserved Route MAP. If the Cisco ACI is not configured to filter join messages received from the DR for any undesirable multicast groups, this is a finding. Fix_Text Configure ACLs on the border leaf switches that act as the PIM DRs, specifically targeting the multicast group addresses to be blocked. This essentially prevents unwanted multicast traffic from entering the fabric by filtering the Join messages at the entry point. Configure the relevant multicast enabled interfaces by configuring a route map on the PIM settings for the VRF on the GUI. Navigate to Tenants >> {{your_Tenants}} >> Networking >> VRFs >> {{Your_VRF}} >> multicast >> Configuration >> PIM settings >> Reserved Route MAP. Not_Reviewed Vuln_Num V-272075 Rule_ID SV-272075r1114309_rule Severity low Rule_Title The Cisco ACI must be configured to log all packets that have been dropped. Vuln_Discuss 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. To configure Cisco ACI to log all dropped packets, enable the "OpFlex Drop Log" feature, which allows logging of any packet dropped in the data path, essentially capturing all dropped packets due to policy mismatches or other reasons within the network fabric. This is done by setting the "log" directive within security policies when defining filter rules on contracts within the tenant. Check_Content Use the APIC GUI to navigate to each tenant. Within each contract, review each rule with "Action" set to "Deny". Verify these rules have the "Directive" set to "Log". If packets being dropped at interfaces are not logged, this is a finding. Fix_Text Configure ACLs to log packets that are dropped. Use the APIC GUI to navigate to each tenant: 1. Go to the contract section and either create a new contract or modify an existing one where drop logging is to be implemented. 2. Within the contract, create the necessary filter rules based on the desired criteria (e.g., source/destination IP, port, protocol) and set the "Action" to "Deny" with the "Directive" set to "Log". 3. Assign the contract to the relevant endpoint groups (EPGs) to enforce the policy on traffic between them. Not_Reviewed Vuln_Num V-272076 Rule_ID SV-272076r1168127_rule Severity medium Rule_Title The Cisco ACI must not be configured to have any feature enabled that calls home to the vendor. Vuln_Discuss 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. Check_Content Verify the ACI configuration under Admin >> External Data Collectors >> monitoring Destinations >> smart callhome/callhome is not setup, and that no Intersight configuration is setup at System >> System Settings >> Intersight Connectivity. If the Call Home feature is configured to send messages to unauthorized individuals such as Cisco TAC, this is a finding. Fix_Text Disable the Call Home feature: 1. Navigate to Admin >> External Data Collectors >> monitoring Destinations >> smart callhome. 2. In the General tab, set the Admin State to "Off". 3. Click "Save". Not_Reviewed Vuln_Num V-272077 Rule_ID SV-272077r1168399_rule Severity medium Rule_Title The Cisco ACI must be configured to use encryption for routing protocol authentication. Vuln_Discuss A rogue router could send a fictitious routing update to convince a site's perimeter router to send traffic to an incorrect or even a rogue destination. This diverted traffic could be analyzed to learn confidential information about the site's network or used to disrupt the network's ability to communicate with other networks. This is known as a "traffic attraction attack" and is prevented by configuring neighbor router authentication for routing updates. However, using clear-text authentication provides little benefit since an attacker can intercept traffic and view the authentication key. This would allow the attacker to use the authentication key in an attack. This requirement applies to all IPv4 and IPv6 protocols 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. To configure a Cisco ACI to use encryption for routing protocol authentication, set up a "pre-shared key" (PSK) on the APIC, which will then be used to generate encryption keys for the routing protocol authentication process, essentially encrypting the authentication messages exchanged between switches within the fabric. This feature is typically referred to as "CloudSec Encryption" within the ACI platform. Check_Content Verify PSKs are configured. Navigate to Tenants >> {{your_tenants}} >> Networking >> L3Outs >> {{your_L3Out}} >> Logical Node Profiles >> {{your_node_profile}} >> Logical Interface Profiles >> {{your_interface_Profile} >> OSPF|EIGRP|BGP Interface profile. If PSKs are not configured to use encryption for routing protocol authentication, this is a finding. Fix_Text Configure one or more PSKs used to generate encryption keys for the routing protocol authentication process. Navigate to Tenants >> {{your_tenants}} >> Networking >> L3Outs >> {{your_L3Out}} >> Logical Node Profiles >> {{your_node_profile}} >> Logical Interface Profiles >> {{your_interface_Profile} >> OSPF|EIGRP|BGP Interface profile. Not_Reviewed Vuln_Num V-272078 Rule_ID SV-272078r1168402_rule Severity medium Rule_Title The Cisco ACI must be configured to authenticate all routing protocol messages using a NIST-validated FIPS 198-1 message authentication code algorithm. Vuln_Discuss A rogue router could send a fictitious routing update to convince a site's perimeter router to send traffic to an incorrect or even a rogue destination. This diverted traffic could be analyzed to learn confidential information about the site's network or used to disrupt the network's ability to communicate with other networks. This is known as a "traffic attraction attack" and is prevented by configuring neighbor router authentication for routing updates. However, using clear-text authentication provides little benefit since an attacker can intercept traffic and view the authentication key. This would allow the attacker to use the authentication key in an attack. Since MD5 is vulnerable to "birthday" attacks and may be compromised, routing protocol authentication must use FIPS 198-1 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. Satisfies: SRG-NET-000230-RTR-000002, SRG-NET-000230-RTR-000003 Check_Content If EIGRP, RIP, and IS-IS protocols are used (these protocols only support MD5 authentication), this is a finding. Review the switch configuration using the show bgp and show ospf commands to verify BGP and OSPF. Navigate to Tenants >> {{your_tenants}} >> Networking >> L3Outs >> {{your_L3Out}} >> Logical Node Profiles >> {{your_node_profile}} >> Logical Interface Profiles >> {{your_interface_Profile}>> OSPF|EIGRP|BGP Interface profile. If authentication protocols that affect the routing or forwarding tables are not configured to use key chain (TCP-AO) authentication with 180 maximum lifetime, this is a finding. Fix_Text Configure authentication for every protocol that affects the routing or forwarding tables to use key chain (TCP-AO) authentication. Configure all supported control plane protocols. This typically includes protocols such as BGP and OSPF. Navigate to Tenants >> {{your_tenants}} >> Networking >> L3Outs >> {{your_L3Out}} >> Logical Node Profiles >> {{your_node_profile}} >> Logical Interface Profiles >> {{your_interface_Profile} >> OSPF|EIGRP|BGP Interface profile. Not_Reviewed Vuln_Num V-272079 Rule_ID SV-272079r1168423_rule Severity medium Rule_Title The Cisco ACI must be configured to drop all fragmented Internet Control Message Protocol (ICMP) packets destined to itself. Vuln_Discuss 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. Check_Content If this review is for the DODIN Backbone, mark as Not Applicable. When creating a contract, create a Deny statement that looks at all the fragmented bits and denies only those packets. Review the following two locations: Option 1: Review any standard contract (whitelist) with an explicit deny for the fragment bit to counter act any allows. Tenant >> Contracts >> Standard >> {{your_Contract}} >> {{your_contract_Subject}} >> Policy >> General >> Filters >> create/ add a deny for ICMP traffic. The filter entries should include the following: Ethertype set to IP/ipv6, IP Protocol set to ICMP/ICMPv6, and the Match Only Fragments box checked. Option 2: Review any taboo contract (blacklist) for the fragment bits: Tenant >> Contracts >> Taboo >> {{your_Contract}} >> Policy >> General >> {{your_contract_Subject}} >> Filters >> create/ add a deny for ICMP traffic. The filter entries should include the following: Ethertype set to IP/ipv6, IP Protocol set to ICMP/ICMPv6, and the Match Only Fragments box checked3. Verify ICMP and Fragmented are selected to be denied. If all fragmented ICMP packets destined to Cisco ACI IP addresses are not dropped, this is a finding. Fix_Text Place the deny rule before any permit rules for ICMP traffic to ensure fragmented ICMP packets are dropped first. When you are creating a contract you would want to create a Deny statement that looks at all the fragmented bits and denies only those packets. There are 2 ways to do this. Option 1: Create a standard contract (whitelist) with an explicit deny for the fragment bit to counter act any allows. Navigate to the following location and configure settings: Tenant >> Contracts >> Standard >> {{your_Contract}} >> {{your_contract_Subject}} >> Policy >> General >> Filters >> create/ add a deny for ICMP traffic. The filter entries should include the following: Ethertype set to IP/ipv6, IP Protocol set to ICMP/ICMPv6, and the Match Only Fragments box checked. Option 2: Create a taboo contract (blacklist) for the fragment bits by navigating to the following location: Tenant >> Contracts >> Taboo >> {{your_Contract}} >> Policy >> General >> {{your_contract_Subject}} >> Filters >> create/ add a deny for ICMP traffic. The filter entries should include the following: Ethertype set to IP/ipv6, IP Protocol set to ICMP/ICMPv6, and the Match Only Fragments box checked. Not_Reviewed Vuln_Num V-272081 Rule_ID SV-272081r1168142_rule Severity medium Rule_Title The Cisco ACI must be configured to only permit management traffic that ingresses and egresses the OOBM interface. Vuln_Discuss To configure OOB management on an ACI fabric, use the Application Policy Infrastructure Controller (APIC), the central management point for the network. When setting up OOB access, a specific "contract" that controls which traffic is allowed on the OOB management network is typically defined. All management traffic is immediately forwarded into the management network; it is not exposed to possible tampering. The separation ensures that congestion or failures in the managed network do not affect the management of the device. If the device does not have an OOBM port, the interface functioning as the management interface must be configured so that management traffic does not leak into the managed network and that production traffic does not leak into the management network. Check_Content To setup the OOB to limit what devices/ networks can access it, use the contracts in the following settings: Tenant >> Tenant mgmt >> Node Management Addresses >> Static Node Management Addresses Tenant >> Tenant mgmt >> Node Management EPGs >> Out-of-Band EPG default Tenant >> Tenant mgmt >> External Management Network Instance Profiles >> {{YourInstanceProfile}} If the Cisco ACI is not configured to only permit management traffic that ingresses and egresses the OOBM interface, this is a finding. Fix_Text Navigate to the relevant tenant to setup the OOB to limit what devices/ networks can access it. Utilize contracts in the following settings: Tenant >> Tenant mgmt >> Node Management Addresses >> Static Node Management Addresses Tenant >> Tenant mgmt >> Node Management EPGs >> Out-of-Band EPG default Tenant >> Tenant mgmt >> External Management Network Instance Profiles >> {{YourInstanceProfile}} Not_Reviewed Vuln_Num V-272082 Rule_ID SV-272082r1168145_rule Severity medium Rule_Title The Cisco ACI must be configured to implement message authentication and secure communications for all control plane protocols. Vuln_Discuss A rogue router could send a fictitious routing update to convince a site's perimeter router to send traffic to an incorrect or even a rogue destination. This diverted traffic could be analyzed to learn confidential information about the site's network or used to disrupt the network's ability to communicate with other networks. This is known as a "traffic attraction attack" and is prevented by configuring neighbor router authentication for routing updates. This requirement applies to all IPv4 and IPv6 protocols used to exchange routing or packet forwarding information. This includes BGP, RIP, OSPF, EIGRP, IS-IS and LDP. Check_Content Verify secure communications and message authentication on all control plane protocols is configured. 1. Verify Secure Communication: - Navigate to Fabric >> Fabric Policies >> Policies >> Pod >> Management Access. - Verify SSH and SSL protocols are enabled for APIC management. 2. Verify Message Authentication: - Navigate to Fabric >> Fabric Policies >> Pod Policies >> Policies >> Interconnect. - Verify IPsec for FI communication is enabled. 3. Verify OpFlex for Southbound Communication is set to TLS. 4. Navigate to Fabric >> Fabric Policies >> Pod Policies >> Policies >> Trust Domain. - Verify the Trust Domain is enabled and configured. Verify BGP neighbor authentication keys on Cisco ACI border leaf switches are configured to use a different authentication key for each AS peer. 1. Navigate to Tenants >> All Tenants >> your_tenant >> Networking >> L3Outs >> your_l3out. 2. Expand Logical Node Profiles >> node_profile. 3. Select Logical Interface Profiles >> interface_profile (where the BGP peering is configured). 4. Within the Logical Interface Profile, review each BGP Peer Connectivity profiles for each individual BGP peer. 5. In the BGP Peer Connectivity Profile settings, review the Password to verify each peer has a unique password. If message authentication and secure communications is not configured for all control plane protocols, this is a finding. Fix_Text Configure secure communications and message authentication on all control plane protocols. 1. Verify Secure Communication: - Navigate to Fabric >> Fabric Policies >> Policies >> Pod >> Management Access. - Verify SSH and SSL protocols are enabled for APIC management. Configure the ports used for SSH and SSL connections as needed. 2. Configure Message Authentication: - Navigate to Fabric >> Fabric Policies >> Pod Policies >> Policies >> Interconnect. - Enable IPsec for FI communication to ensure secure communication between the APIC and the switches. - Configure the IPsec parameters, such as the encryption algorithm and authentication method. 3. Configure OpFlex for Southbound Communication to use TLS: Note: OpFlex is a southbound protocol designed to facilitate communications between the SDN Controller and the switches and routers. 4. Enable Trust Domain: - Navigate to Fabric >> Fabric Policies >> Pod Policies >> Policies >> Trust Domain. - Enable the Trust Domain to ensure that only trusted devices can communicate with the APIC. - Configure the Trust Domain parameters, such as the certificate authority and the trusted devices. To configure BGP neighbor authentication keys on Cisco ACI border leaf switches using a different authentication key for each AS peer, configure the BGP Peer Connectivity Profile within the L3Out configuration. 1. In the APIC GUI, go to Tenants >> All Tenants >> your_tenant >> Networking >> L3Outs >> your_l3out. 2. Expand Logical Node Profiles >> node_profile. 3. Select Logical Interface Profiles >> interface_profile (where the BGP peering is configured). 4. Within the Logical Interface Profile, locate or create the BGP Peer Connectivity Profile associated with the peer you want to authenticate. Edit or create a profile. 5. In the BGP Peer Connectivity Profile settings: - Remote Autonomous System Number: Specify the AS number of the peer. - Password: Enter the authentication key/password for this specific peer. - Confirm Password: Re-enter the same password. - Other settings, such as peer controls, address type controls, and route control profiles, can be adjusted as needed for the BGP peering configuration. 6. Repeat the steps for each peer that must be configured. Create separate BGP Peer Connectivity profiles for each individual BGP peer, with different passwords for each. Ensure the peer devices have the matching authentication key/password configured for successful BGP peering. Not_Reviewed Vuln_Num V-272086 Rule_ID SV-272086r1114094_rule Severity medium Rule_Title The Cisco ACI must be configured to have gratuitous ARP (GARP) disabled on all external interfaces. Vuln_Discuss A GARP 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. Check_Content Review the configuration for each L3OUT Bridge Domain to determine if gratuitous ARP is disabled: 1. In the APIC GUI Navigation pane, select "Tenant" and inspect each Tenant's Bridge Domain configuration. 2. Expand "Networking" and right-click each Bridge Domain. 3. View the Layer 3 configuration tab. Verify GARP-based detection is not enabled. If GARP is enabled on any external interface, this is a finding. Fix_Text Disable GARP for each L3OUT Bridge Domain: 1. In the APIC GUI navigation pane, select "Tenant" and complete the following for each tenant listed. 2. Expand "Networking", right-click, "Create Bridge Domain" to open the dialog box, and fill out the form. - In the Layer 3 Configurations tab, GARP based detection must not be enabled. 3. Click "NEXT". 4. Complete the Bridge Domain configuration. 5. Click "Finish". Not_Reviewed Vuln_Num V-272087 Rule_ID SV-272087r1168151_rule Severity medium Rule_Title The Cisco ACI must be configured to have Internet Control Message Protocol (ICMP) mask replies disabled on all external interfaces. Vuln_Discuss The ICMP supports IP traffic by relaying information about paths, routes, and network conditions. Routers automatically send ICMP messages under a wide variety of conditions. Mask Reply ICMP messages are commonly used by attackers for network mapping and diagnosis. Check_Content Review the router configuration and verify IP mask replies have been disabled on all external interfaces using any of the following options: 1. For contracts with external L3out traffic, verify specific allow statements do not allow any ICMP type 17 packets. 2. Verify the Filter for ICMP Type 17 and confirm that every contract that allows ICMP has the type 17 explicit deny to prevent this request. 3. Configure a Taboo contract (blacklist) that explicitly denies ICMP type 17. If IP mask replies are not disabled on all external interfaces, this is a finding. Fix_Text Disable IP mash replies on all external interfaces using any of the following options. 1. ACI is a whitelist model by default, so all traffic is denied by default. When contracts are added, users can be specific with the allow statements to avoid allowing any ICMP type 17 packets. 2. Configure the filter for ICMP Type 17 and confirm every contract that allows ICMP has the type 17 explicit deny to prevent this request. 3. Configure a Taboo contract (blacklist) that explicitly denies ICMP type 17. Not_Reviewed Vuln_Num V-272088 Rule_ID SV-272088r1168406_rule Severity medium Rule_Title The BGP Cisco ACI must be configured to use the maximum prefixes feature to protect against route table flooding and prefix de-aggregation attacks. Vuln_Discuss The effects of prefix de-aggregation can degrade router performance due to the size of routing tables and result in black-holing legitimate traffic. Initiated by an attacker or a misconfigured router, prefix de-aggregation occurs when the announcement of a large prefix is fragmented into a collection of smaller prefix announcements. Maximum prefix limits on peer connections combined with aggressive prefix-size filtering of customers' reachability advertisements will effectively mitigate the de-aggregation risk. BGP maximum prefix must be used on all eBGP routers to limit the number of prefixes it should receive from a particular neighbor, whether customer or peering AS. Consider each neighbor and how many routes that will be advertised and set a threshold slightly higher than the number expected. Check_Content Verify the BGP configuration for each tenant: Tenants >> {{your_Tenant}} >> Networking >> L3Out >> {{your_l3out}} >> Logical Node Profiles >> {{your_Logical_node_Profile}} >> Logical Interface Profiles >> {{your_logical_interface_profile}} >> BGP peer x.x.x.x >> Policy >> BGP Peer Prefix Policy. If the router is not configured to control the number of prefixes received from each peer to protect against route table flooding and prefix de-aggregation attacks, this is a finding. Fix_Text Configure the router to use the maximum prefixes feature to protect against route table flooding and prefix de-aggregation attacks as shown in the example below: For each BGP peer, navigate to Tenants >> {{your_Tenant}} >> Networking >> L3Out >> {{your_l3out}} >> Logical Node Profiles >> {{your_Logical_node_Profile}} >> Logical Interface Profiles >> {{your_logical_interface_profile}} >> BGP peer x.x.x.x >> Policy >> BGP Peer Prefix. Create a policy within the BGP configuration section, where <peer-ip> is the IP address of the BGP peer and <number of prefixes> is the desired maximum prefix limit to be set; the default maximum prefix limit is typically 20,000 prefixes. Not_Reviewed Vuln_Num V-272089 Rule_ID SV-272089r1168408_rule Severity low Rule_Title The BGP Cisco ACI must be configured to limit the prefix size on any inbound route advertisement to /24 or the least significant prefixes issued to the customer. Vuln_Discuss The effects of prefix de-aggregation can degrade router performance due to the size of routing tables and also result in black-holing legitimate traffic. Initiated by an attacker or a misconfigured router, prefix de-aggregation occurs when the announcement of a large prefix is fragmented into a collection of smaller prefix announcements. Check_Content Review the configuration of the RP to verify it is rate limiting the number of PIM register messages. Verify the L3Out option for Route Control Enforcement Import is checked. Navigate to Tenants >> {{your_Tenant}} >> Networking >> L3Out >> {{your_l3out}} >> Policy >> Main >> Route Control Enforcement. If the router is not configured to limit the prefix size on any inbound route advertisement to /24, or the least significant prefixes issued to the customer, this is a finding. Fix_Text Configure the router to limit the prefix size on any route advertisement to /24 or the least significant prefixes issued to the customer. Create a "match rule" within a "route profile" by specifying a prefix list, to be applied to the desired L3Out (external routed network) to filter BGP routes based on the prefixes defined in the list. The route profile is applied to a specific L3Out (external routed network) to control which prefixes are advertised or accepted from external networks. Refer to the L3 out documentation on setting up route maps or using the import controls on the external EPG subnets on this connection. Ensure on the L3Out the option for Route Control Enforcement Import is checked. Tenants >> {{your_Tenant}} >> Networking >> L3Out >> {{your_l3out}} >> Policy >> Main >> Route Control Enforcement Not_Reviewed Vuln_Num V-272091 Rule_ID SV-272091r1168160_rule Severity medium Rule_Title The multicast rendezvous point (RP) must be configured to rate limit the number of Protocol Independent Multicast (PIM) Register messages. Vuln_Discuss When a new source starts transmitting in a PIM Sparse Mode network, the designated router (DR) will encapsulate the multicast packets into register messages and forward them to the RP using unicast. This process can be taxing on the CPU for both the DR and the RP if the source is running at a high data rate and there are many new sources starting at the same time. This scenario can potentially occur immediately after a network failover. The rate limit for the number of register messages should be set to a relatively low value based on the known number of multicast sources within the multicast domain. Satisfies: SRG-NET-000362-RTR-000120 Check_Content Review the PIM configuration: Tenants >> {{your_Tenant}} >> Networking >> VRF >> {{your_VRF}} >> Multicast >> Configuration >> Pattern Policy >> under Register Traffic Policy look for Max Rate (packets per second) If the RP router is not configured to filter PIM register messages, rate limit the number of PIM register messages, and accept multicast packets only from known peers, this is a finding. Fix_Text Configure the switch to filter PIM register messages, rate limit the number of PIM register messages, and accept multicast packets only from known peers. Use the command "ip pim register-rate-limit <rate>", where <rate> specifies the desired maximum number of register messages per second allowed to be sent. Navigate to the following location to configure: Tenants >> {{your_Tenant}} >> Networking >> VRF >> {{your_VRF}} >> Multicast >> Configuration >> Pattern Policy >> under Register Traffic Policy look for Max Rate (packets per second) Not_Reviewed Vuln_Num V-272092 Rule_ID SV-272092r1168163_rule Severity medium Rule_Title The Cisco ACI must be configured to limit the mroute states created by Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) reports on a Cisco APIC Bridge Domain (BD) or interface. Vuln_Discuss Limiting mroute states helps prevent excessive multicast traffic flooding on the network by controlling the number of multicast groups a segment can join. By limiting multicast routes, the APIC can better manage its internal resources and prevent potential performance issues due to excessive multicast traffic. Depending on the ACI configuration, set a global IGMP state limit that would apply across all interfaces, or it may be necessary to configure limits on individual interfaces. Check_Content Review the relevant BD configuration. Verify it is configured to limit the number of multicast routes (mroute states) generated by IGMP or MLD reports. Tenants >> {{your_Tenant}} >> Networking >> Bridge Domain >> {{your_Bridge_Domain}} >> Policy >> General >> IGMP Policy >> set the Maximum Multicast Entries If the ACI is not limiting multicast requests via IGMP or MLD on a global or interfaces basis, this is a finding. Fix_Text Configure a global or interface basis to limit the number of mroute states resulting from IGMP or MLD membership reports. Tenants >> {{your_Tenant}} >> Networking >> Bridge Domain >> {{your_Bridge_Domain}} >> Policy >> General >> IGMP Policy >> set the Maximum Multicast Entries Note: This setting is used to limit the mroute states for the BD or interface created by IGMP reports. Default is disabled, no limit enforced. Valid range is 1-4294967295. Not_Reviewed Vuln_Num V-272094 Rule_ID SV-272094r1168411_rule Severity low Rule_Title Cisco ACI must be configured so the BGP neighbor is directly connected and will not connect a BGP session to a directly connected neighbor device's loopback address. Vuln_Discuss Generalized Time To Live Security Mechanism (GTSM) is designed to protect a router's IP-based control plane from denial-of-service (DoS) attacks. Many attacks focused on CPU load and line-card overload can be prevented by implementing GTSM on all Exterior Border Gateway Protocol speaking routers. ACI mitigates this risk in a different way, as currently there is no option for TTL-security or GTSM support; however, ACI, by default, is setup to validate that the BGP neighbor is directly connected and will not even connect a BGP session to a directly connected neighbor devices loopback address. Check_Content Review the BGP configuration to verify that TTL security has been configured to the default settings. Navigate to Tenants >> {{your_Tenant}} >> Networking >> L3Out >> {{your_l3out}} >> Logical Node Profiles >> {{your_Logical_node_Profile}} >> Logical Interface Profiles >> {{your_logical_interface_profile}} >> BGP peer x.x.x.x >> Policy. Verify the following in the policy: Disable Connected Check is unmarked EBGP Multihop TTL = 1 If the Cisco ACI is not configured to use GTSM for all Exterior BGP peering sessions, this is a finding. Fix_Text If ACI is determined to be configured differently than the default settings, reconfigure to default settings by performing the actions on the BGP connectivity profile (path below). Navigate to Tenants >> {{your_Tenant}} >> Networking >> L3Out >> {{your_l3out}} >> Logical Node Profiles >> {{your_Logical_node_Profile}} >> Logical Interface Profiles >> {{your_logical_interface_profile}} >> BGP peer x.x.x.x >> Policy. Reset the following in the policy: Disable Connected Check is unmarked EBGP Multihop TTL = 1 Not_Reviewed Vuln_Num V-272095 Rule_ID SV-272095r1168413_rule Severity low Rule_Title The Cisco ACI multicast 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 and only from sources that have been approved by the organization. Vuln_Discuss Real-time multicast traffic can entail multiple large flows of data. Large unicast flows tend to be fairly isolated (i.e., occasional file downloads), 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. Satisfies: SRG-NET-000364-RTR-000115 Check_Content 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. Review the configuration to verify filtering IGMP or MLD Membership Report messages, allowing hosts to join only those groups that have been approved. Navigate to the following location to review the settings: Tenants >> {{your_Tenant}} >> Networking >> Bridge Domain >> {{your_Bridge_Domain}} >> Policy >> General If the Cisco ACI is not filtering IGMP or MLD Membership Report messages, this is a finding. Fix_Text Configure IGMP Snooping. Note: There are a number of methods for meeting this requirement; however, it is recommended to use filter Destinations via contracts and PIM destination filter route maps when enabling the Bridge domain to participate in IGMP and MLD Snooping. All but the contract settings can be found at the following GUI path: Tenants >> {{your_Tenant}} >> Networking >> Bridge Domain >> {{your_Bridge_Domain}} >> Policy >> General Not_Reviewed Vuln_Num V-272098 Rule_ID SV-272098r1168415_rule Severity low Rule_Title The Cisco ACI must be configured to use its loopback address as the source address for internal Border Gateway Protocol (iBGP) peering sessions. Vuln_Discuss Using a loopback address as the source address offers a multitude of uses for security, access, management, and scalability of the BGP routers. It is easier to construct appropriate ingress filters for router management plane traffic destined to the network management subnet since the source addresses will be from the range used for loopback interfaces instead of a larger range of addresses used for physical interfaces. Log information recorded by authentication and syslog servers will record the router's loopback address instead of the numerous physical interface addresses. When the loopback address is used as the source for external BGP (eBGP) peering, the BGP session will be harder to hijack since the source address to be used is not known globally, making it more difficult for a hacker to spoof an eBGP neighbor. By using traceroute, a hacker can easily determine the addresses for an eBGP speaker when the IP address of an external interface is used as the source address. The routers within the iBGP domain should also use loopback addresses as the source address when establishing BGP sessions. Check_Content Review the switch configuration to verify a loopback address has been configured. Tenants >> {{your_Tenant}} >> L3Out >> {{your_l3out}} >> Logical Node Profiles >> {{your_Logical_node_Profile}} >> Policy >> BGP Peer Connectivity add your loopback If the switch does not use its loopback address as the source address for all iBGP sessions, this is a finding. Fix_Text Configure BGP for the relevant L3Out to use the switch's loopback address as the source address for all iBGP peering. This configures the switch to use the loopback interface as the source IP for all BGP updates sent to the specified peer. - Navigate to Tenants >> {{your_Tenant}} >> Networking >> L3Out >> {{your_l3out}} >> Logical Node Profiles >> {{your_Logical_node_Profile}} >> Policy >> Node. - Double click the Node(Leaf) and look for the option to select "use Router ID as loopback" or set the loopback address to which to build the BGP connection and unselect "use router ID as Loopback". After setting the loopback address, navigate to Tenants >> {{your_Tenant}} >> L3Out >> {{your_l3out}} >> Logical Node Profiles >> {{your_Logical_node_Profile}} >> Policy >> BGP Peer Connectivity. Add the loopback. Not_Reviewed Vuln_Num V-272101 Rule_ID SV-272101r1168417_rule Severity medium Rule_Title The Cisco ACI must not be configured to use IPv6 site local unicast addresses. Vuln_Discuss 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. Specify the appropriate IPv6 address range within the relevant configuration objects like bridge domains and L3Out, ensuring the addresses fall within the allocated site local unicast prefix, and enable IPv6 routing on the fabric level, allowing the ACI switches to learn and route traffic based on these IPv6 addresses. Check_Content Review the router configuration to ensure FEC0::/10 IP addresses are not defined. Tenants >> {{your_Tenant}} >> Networking >> VRF >> {{your_VRF}} >> Operational >> Route Table >> IPV6 Routes and Tenants >> {{your_Tenant}} >> Networking >> VRF >> {{your_VRF}} >> Operational >> Client Endpoints This will display all IPV6 address in this VRF and on which leaf they reside. If the CLI is preferred, the command is as follows when run from the APIC: fabric {{node_ID}} show ipv6 interface brief or from each node: show ipv6 interface brief If IPv6 site local unicast addresses are defined, this is a finding. Fix_Text Delete unauthorized addresses. Configure the IPv6 addresses on the ACI fabric's leaf switches and virtual network segments (bridge domains) within the desired tenant to use site local unicast addresses. Tenants >> {{your_Tenant}} >> Networking >> VRF >> {{your_VRF}} >> Operational >> Route Table >> IPV6 Routes Remove unauthorized addresses. Remove unauthorized addresses from the Client Endpoints list. Tenants >> {{your_Tenant}} >> Networking >> VRF >> {{your_VRF}} >> Operational >> Client Endpoints Not_Reviewed Vuln_Num V-272103 Rule_ID SV-272103r1168419_rule Severity medium Rule_Title The Cisco ACI must establish organization-defined alternate communication paths for system operations organizational command and control. Vuln_Discuss An incident, whether adversarial- or nonadversarial-based, can disrupt established communication paths used for system operations and organizational command and control. Alternate communication paths reduce the risk of all communications paths being affected by the same incident. To compound the problem, the inability of organizational officials to obtain timely information about disruptions or to provide timely direction to operational elements after a communication path incident, can impact the ability of the organization to respond to such incidents in a timely manner. Establishing alternate communication paths for command and control purposes, including designating alternative decision makers if primary decision makers are unavailable and establishing the extent and limitations of their actions, can greatly facilitate the organization's ability to continue to operate and take appropriate actions during an incident. Check_Content Review the SSP and the ACI configuration to verify logical separation using EPGs, bridge domains, and/or tenants is configured. There are a large number of places to validate that each EPG is using an organizational defined VLAN. That would be dependent on the VLAN pool associated with the Physical/ VMM Domains that the EPG is using. To check the Physical domain in the GUI, use the following path: Tenants >> {{your_Tenant}} >> Application Profiles >> {{your_application_profile}} >> Application EPGs >> {{your_EPG}} > Domains After checking the domain, check the VLAN pool on the physical domains in the GUI: Fabric >> Access Policies >> Physical and External Domains >> Physical Domains >> {{your_domain}} For VMM Domain vlan pools, check the following GUI location: Virtual Networking >> VMware >> {{your_VMM_Domain}} >> Policy >> General If organization-defined alternate communication paths for system operations organizational command and control have not been established, this is a finding. Fix_Text Configure logical separation using EPGs, bridge domains, and/or tenants in accordance with the SSP. There are a large number of spots to validate that each EPG is using an organizational defined VLAN. That would be dependent on the VLAN pool associated with the Physical/ VMM Domains that the EPG is using. 1. Edit or create a physical domain in the GUI using the following path: Tenants >> {{your_Tenant}} >> Application Profiles >> {{your_application_profile}} >> Application EPGs >> {{your_EPG}} > Domains 2. Create a VLAN pool on physical domains in the GUI: Fabric >> Access Policies >> Physical and External Domains >> Physical Domains >> {{your_domain}} 3. For VMM Domain vlan pools, create a policy at the following GUI location: Virtual Networking >> VMware >> {{your_VMM_Domain}} >> Policy >> General Not_Reviewed Vuln_Num V-272104 Rule_ID SV-272104r1168421_rule Severity medium Rule_Title The Cisco ACI must be configured to protect against or limit the effects of denial-of-service (DoS) attacks by employing control plane protection. Vuln_Discuss 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 in ongoing network management functions that keep the routers and links available for providing network services. Any disruption to the RP or the control and management planes can result in mission-critical network outages. A DoS attack targeting the RP can result in excessive CPU and memory utilization. To maintain network stability and RP security, the router must be able to handle specific control plane and management plane traffic destined to the RP. In the past, one method of filtering was to use ingress filters on forwarding interfaces to filter both forwarding path and receiving path traffic. However, this method does not scale well as the number of interfaces grows and the size of the ingress filters grows. Control plane policing increases the security of routers 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 routers against reconnaissance and DoS attacks, allowing the control plane to maintain packet forwarding and protocol states despite an attack or heavy load on the router or multilayer switch. Check_Content Verify a Control Plane Policing (CoPP) policy is applied to the Leaf and or interface policies accordingly: Fabric >> Access Policies >> Policies >> Switch >> CoPP Pre-Filter for Leaf / CoPP Leaf Fabric >> Access Policies >> Policies >> Interface >> CoPP Interface Verify L3Out contracts include the CoPP policy. Inspect the policy at the following location: Tenants >> {{your_Tenant}} >> Networking >> L3Outs >> {{your_l3out}} >> External EPGs >> {{your_External_EPG}} >> Policy >> Contract If the CoPP policy is not configured on all Leaf and/or interfaces, this is a finding. Fix_Text Protect against known types of DoS attacks on the route processor by implementing a CoPP policy. To meet this requirement, configure the COPP policy on each device, QOS to ensure the correct traffic is being dropped, and verify all l3 outs have the correct contracts applied to them. These policies must be applied to the Leaf and or interface policies accordingly. CoPP Policy: Fabric >> Access Policies >> Policies >> Switch >> CoPP Pre-Filter for Leaf / CoPP Leaf Fabric >> Access Policies >> Policies >> Interface >> CoPP Interface QOS: Since there are so many locations and settings required for this aspect, reference the QOS documentation to access these settings: https://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/kb/Cisco-APIC-and-QoS.html Configure L3Out contracts include the CoPP policy. Inspect the policy at the following location: Tenants >> {{your_Tenant}} >> Networking >> L3Outs >> {{your_l3out}} >> External EPGs >> {{your_External_EPG}} >> Policy >> Contract Not_Reviewed