{ "id": 240, "benchmarkId": "Cisco_ACI_RTR_STIG", "slug": "cisco_aci_router_v1", "stigSlug": "cisco_aci_router", "versionStatus": "historical", "status": "accepted", "statusDate": "2025-06-18T00:00:00.000Z", "title": "Cisco ACI Router Security Technical Implementation Guide", "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.", "version": "1", "vendor": null, "createdAt": "2025-10-21T11:23:57.598Z", "updatedAt": "2026-04-25T11:39:35.021Z", "groups": [ { "id": 11706, "benchmarkId": 240, "groupId": "V-272105", "title": "SRG-NET-000193-RTR-000001", "description": "", "ruleId": "SV-272105r1114299_rule", "ruleWeight": "10.0", "ruleSeverity": "low", "ruleVersion": "CACI-RT-000045", "ruleTitle": "The MPLS Cisco ACI with Resource Reservation Protocol Traffic Engineering (RSVP-TE) enabled must be configured with message pacing or refresh reduction to adjust the maximum number of RSVP messages to an output queue based on the link speed and input queue size of adjacent core Cisco ACIs.", "ruleVulnDiscussion": "RSVP-TE can be used to perform constraint-based routing when building LSP tunnels within the network core that will support QoS and traffic engineering requirements. RSVP-TE is also used to enable MPLS Fast Reroute, a network restoration mechanism that will reroute traffic onto a backup LSP in case of a node or link failure along the primary path. When there is a disruption in the MPLS core, such as a link flap or router reboot, the result is a significant amount of RSVP signaling, such as \"PathErr\" and \"ResvErr\" messages that need to be sent for every LSP using that link.\n\nRSVP messages are sent out using either hop-by-hop or with the router alert bit set in the IP header. This means that every router along the path must examine the packet to determine if additional processing is required for these RSVP messages. If there is enough signaling traffic in the network, it is possible for an interface to receive more packets for its input queue than it can hold, resulting in dropped RSVP messages and hence slower RSVP convergence. Increasing the size of the interface input queue can help prevent dropping packets; however, there is still the risk of having a burst of signaling traffic that can fill the queue. Solutions to mitigate this risk are RSVP message pacing or refresh reduction to control the rate at which RSVP messages are sent. RSVP refresh reduction includes the following features: RSVP message bundling, RSVP Message ID to reduce message processing overhead, reliable delivery of RSVP messages using Message ID, and summary refresh to reduce the amount of information transmitted every refresh interval.\n\nTo configure a rate-limit on RSVP bandwidth on a Cisco ACI interface, use the command \"ip rsvp bandwidth\" within the interface configuration mode, specifying the desired bandwidth value in kilobits per second (kbps), which will act as the maximum reservable bandwidth for RSVP traffic on that interface. For more granular control, consider creating a dedicated RSVP policy to further define how bandwidth is allocated based on specific traffic characteristics. Optionally, specify a percentage of the interface bandwidth by using the \"percent\" keyword with the command.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001095", "ruleFixText": "Configure rate limit RSVP messages per interface, as shown in the example below:\n\nSyntax: ip rsvp bandwidth \n\napic(config)# ip rsvp bandwidth 1000000", "ruleFixId": "F-76062r1114113_fix", "ruleCheckSystem": "C-76155r1114298_chk", "ruleCheckContent": "Review the router configuration to determine RSVP messages are rate limited.\n\n1. Determine if MPLS TE is enabled globally and at least one interface. To display statistics information for all the interfaces and VRFs in the system, navigate to Tenant >> infra >> Networking >> SR-MPLS Infra L3Outs.\n\n2. Verify the rsvp bandwidth is set.\n\nip rsvp bandwidth 1000000 \n\nIf the router with RSVP-TE enabled does not rate limit RSVP messages based on the link speed and input queue size of adjacent core routers, this is a finding.", "createdAt": "2025-10-21T11:24:01.439Z", "updatedAt": "2025-10-21T11:24:01.439Z" }, { "id": 11662, "benchmarkId": 240, "groupId": "V-272061", "title": "SRG-NET-000018-RTR-000001", "description": "", "ruleId": "SV-272061r1115721_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "CACI-RT-000001", "ruleTitle": "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.", "ruleVulnDiscussion": "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\nIn 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.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001368", "ruleFixText": "Configure \"contracts\" to define security policies that control traffic between different EPGs. \n\n1. Navigate to the desired tenant and context to create filters.\n\napic(config)# tenant context filter filter ip permit source destination protocol port \n\n2. Create or update an existing contract. Link the previously created filter to a named contract.\n\napic(config)# contract filter \n\n3. Assign contract to EPGs. Associate the created contract with the specific EPGs.\n\napic(config)# epg contract ", "ruleFixId": "F-76018r1115720_fix", "ruleCheckSystem": "C-76111r1063578_chk", "ruleCheckContent": "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 web traffic (HTTP) from the \"WebServer\" EPG to the \"Database\" EPG.\n\n tenant TENANT1\n context Application\n filter WEB_TRAFFIC_FILTER\n filter ip permit source destination protocol tcp port 80\n contract WEBACCESS\n filter WEB_TRAFFIC_FILTER\n epg WebServer\n contract WEBACCESS\n epg Database\n contract WEBACCESS\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.", "createdAt": "2025-10-21T11:24:01.439Z", "updatedAt": "2025-10-21T11:24:01.439Z" }, { "id": 11681, "benchmarkId": 240, "groupId": "V-272080", "title": "SRG-NET-000205-RTR-000006", "description": "", "ruleId": "SV-272080r1113986_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "CACI-RT-000020", "ruleTitle": "The BGP Cisco ACI must be configured to reject outbound route advertisements for any prefixes belonging to the IP core.", "ruleVulnDiscussion": "Outbound route advertisements belonging to the core can result in traffic either looping or being black holed, or at a minimum, using a nonoptimized path.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001097", "ruleFixText": "Configure the router with FHS to suppress Router Advertisements on all external IPv6-enabled interfaces as shown in the example below. View the FHS requirement in the Layer 2 STIG.\n\napic1(config-tenant-fhs-secpol)# router-advertisement-guard", "ruleFixId": "F-76037r1063636_fix", "ruleCheckSystem": "C-76130r1063635_chk", "ruleCheckContent": "If this review is for the DODIN Backbone, mark as not applicable.\n\nVerify the router is configured to deny router-advertisements.\n\napic1(config-tenant-fhs-secpol)# router-advertisement-guard\n\nIf the router is not configured to reject outbound route advertisements for prefixes belonging to the IP core, this is a finding.", "createdAt": "2025-10-21T11:24:01.439Z", "updatedAt": "2025-10-21T11:24:01.439Z" }, { "id": 11663, "benchmarkId": 240, "groupId": "V-272062", "title": "SRG-NET-000018-RTR-000003", "description": "", "ruleId": "SV-272062r1115716_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "CACI-RT-000002", "ruleTitle": "The BGP Cisco ACI must be configured to reject inbound route advertisements for any prefixes belonging to the local autonomous system (AS).", "ruleVulnDiscussion": "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.\n\nFor Cisco APIC, the default setting to prevent route loops from occurring. Sites must use different AS numbers. If this occurs, routing updates from one site is dropped when the other site receives them by default.\n\nTo prevent such a situation from occurring, sites must not enable the \"BGP Autonomous System override\" feature to override the default setting. They must also not enable the \"Disable Peer AS Check\".", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001368", "ruleFixText": "Configure the router to reject inbound route advertisements for any prefixes belonging to the local AS. \n\n1. From the relevant BGP peer configuration, create a route-map to filter local AS prefixes.\n\nRoute-map LOCAL_AS_FILTER permit 10\n match ip address prefix \n set community no-advertise\n\n2. 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.\n\nbgp neighbor \n address-family ipv4 unicast\n inbound route-map MY_LOCAL_AS_FILTER", "ruleFixId": "F-76019r1115715_fix", "ruleCheckSystem": "C-76112r1115714_chk", "ruleCheckContent": "Review the switch configuration to verify it will reject routes belonging to the local AS.\n\n1. Verify a prefix list has been configured containing prefixes belonging to the local AS.\n\nroute-map LOCAL_AS_FILTER permit 10\n match ip address prefix \n set community no-advertise\n\n2. Review the route-map to the inbound BGP policy.\n\nbgp neighbor \n address-family ipv4 unicast\n inbound route-map LOCAL_AS_FILTER\n\nIf the switch is not configured to reject inbound route advertisements belonging to the local AS, this is a finding.", "createdAt": "2025-10-21T11:24:01.439Z", "updatedAt": "2025-10-21T11:24:01.439Z" }, { "id": 11664, "benchmarkId": 240, "groupId": "V-272063", "title": "SRG-NET-000018-RTR-000005", "description": "", "ruleId": "SV-272063r1115719_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "CACI-RT-000003", "ruleTitle": "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).", "ruleVulnDiscussion": "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.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001368", "ruleFixText": "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, as shown in the following examples.\n\n1. Add to the prefix filter list those prefixes belonging to the local autonomous system. \n\napci1(config)# ip prefix-list LOCAL_AS_PREFIX_FILTER seq 70 deny \n\n2. Apply the prefix list filter outbound to each external BGP neighbor.\n\napci1(config)# router bgp neighbor prefix-list LOCAL_AS_PREFIX_FILTER out", "ruleFixId": "F-76020r1115718_fix", "ruleCheckSystem": "C-76113r1115717_chk", "ruleCheckContent": "Review the ACI configuration to verify it will reject routes belonging to the local AS.\n\n1. Verify a prefix list has been configured containing prefixes belonging to the local AS. In the example below, x.13.1.0/24 is the global address space allocated to the local AS.\n\nip prefix-list PREFIX_FILTER seq 74 deny x.13.1.0/24 le 32\n\n2. Verify the prefix list has been applied to all external BGP peers as shown in the example below:\n\nrouter bgp neighbor prefix-list LOCAL_AS_PREFIX_FILTER out\n\nIf the ACI is not configured to reject inbound route advertisements belonging to the local AS, this is a finding.", "createdAt": "2025-10-21T11:24:01.439Z", "updatedAt": "2025-10-21T11:24:01.439Z" }, { "id": 11665, "benchmarkId": 240, "groupId": "V-272064", "title": "SRG-NET-000018-RTR-000006", "description": "", "ruleId": "SV-272064r1113970_rule", "ruleWeight": "10.0", "ruleSeverity": "low", "ruleVersion": "CACI-RT-000004", "ruleTitle": "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.", "ruleVulnDiscussion": "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.\n\nCisco ACI BGP usually enforces the \"first-as\" rule by default.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001368", "ruleFixText": "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.\n\nRemove the configuration item \"no enforce first-as\".", "ruleFixId": "F-76021r1063588_fix", "ruleCheckSystem": "C-76114r1063587_chk", "ruleCheckContent": "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 is does not explicitly state:\n\nno enforce first-as\n\nIf 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.", "createdAt": "2025-10-21T11:24:01.439Z", "updatedAt": "2025-10-21T11:24:01.439Z" }, { "id": 11666, "benchmarkId": 240, "groupId": "V-272065", "title": "SRG-NET-000018-RTR-000007", "description": "", "ruleId": "SV-272065r1115723_rule", "ruleWeight": "10.0", "ruleSeverity": "low", "ruleVersion": "CACI-RT-000005", "ruleTitle": "The Multicast Source Discovery Protocol (MSDP) Cisco ACI must be configured to filter received source-active multicast advertisements for any undesirable multicast groups and sources.", "ruleVulnDiscussion": "The interoperability of BGP extensions for interdomain multicast routing and MSDP enables seamless connectivity of multicast domains between autonomous systems. MP-BGP advertises the unicast prefixes of the multicast sources used by Protocol Independent Multicast (PIM) routers to perform RPF checks and build multicast distribution trees. MSDP is a mechanism used to connect multiple PIM sparse-mode domains, allowing RPs from different domains to share information about active sources. \n\nMSDP helps ACI border leaf switches identify the location of multicast sources in external networks, allowing them to properly route multicast traffic to interested receivers within the ACI fabric. \n\nMSDP within a layer 3 context, allowing the ACI fabric to discover multicast sources located in other multicast domains when connecting to external networks through \"L3Out\" connections, enabling efficient multicast traffic forwarding across different network segments.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001368", "ruleFixText": "Use the ip route-map command with specific filter criteria under the relevant BGP neighbor configuration to block any unwanted multicast prefixes from being advertised.\n\n1. Navigate to BGP neighbor configuration.\n\napci1(config)# router bgp \napci1(config-router)# neighbor remote-as \n\n2. Create a route map.\n\napci1(config-router)# ip route-map permit 10\napci1(config-router)# match ip address prefix \nexit\n\n3. Apply route-map to BGP neighbor.\n\napci1(config)# address-family ipv4 unicast\napci1(config)# route-map permit", "ruleFixId": "F-76022r1115722_fix", "ruleCheckSystem": "C-76115r1063590_chk", "ruleCheckContent": "If this is a DODIN or JRSS system, this is not applicable. \n\nVerify the ip route-map command with specific filter criteria under the relevant BGP neighbor configuration is configured to block any unwanted multicast prefixes from being advertised as shown in the example below:\n\nrouter bgp 100\nneighbor 10.1.1.2 remote-as 200\naddress-family ipv4 unicast\nroute-map BLOCK_MULTICAST permit\n\nIf the ACI is not configured to reject outbound route advertisements that do not belong to any customers or the local AS, this is a finding.", "createdAt": "2025-10-21T11:24:01.439Z", "updatedAt": "2025-10-21T11:24:01.439Z" }, { "id": 11686, "benchmarkId": 240, "groupId": "V-272085", "title": "SRG-NET-000343-RTR-000002", "description": "", "ruleId": "SV-272085r1114092_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "CACI-RT-000025", "ruleTitle": "The Multicast Source Discovery Protocol (MSDP) Cisco ACI must be configured to authenticate all received MSDP packets.", "ruleVulnDiscussion": "MSDP peering with customer network routers presents additional risks to the core, whether from a rogue or misconfigured MSDP-enabled router. MSDP password authentication is used to validate each segment sent on the TCP connection between MSDP peers, protecting the MSDP session against the threat of spoofed packets being injected into the TCP connection stream.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001958", "ruleFixText": "Enable the \"Strict Security on APIC OOB Subnet\" option within the Management Access settings on the APIC:\n1. On the APIC GUI, navigate to Fabric >> Fabric Policies >> Policies >> Pod >> Management Access to find the relevant settings.\n2. Select \"Strict Security on APIC OOB Subnet\".", "ruleFixId": "F-76042r1114091_fix", "ruleCheckSystem": "C-76135r1064206_chk", "ruleCheckContent": "Review the Management Access configuration to determine if received MSDP packets are authenticated:\n1. Navigate to Fabric >> Fabric Policies >> Policies >> Pod >> Management Access.\n2. Verify the option for \"Strict Security on APIC OOB Subnet\" is selected.\n\nIf the router does not require MSDP authentication, this is a finding.", "createdAt": "2025-10-21T11:24:01.439Z", "updatedAt": "2025-10-21T11:24:01.439Z" }, { "id": 11667, "benchmarkId": 240, "groupId": "V-272066", "title": "SRG-NET-000018-RTR-000008", "description": "", "ruleId": "SV-272066r1115725_rule", "ruleWeight": "10.0", "ruleSeverity": "low", "ruleVersion": "CACI-RT-000006", "ruleTitle": "The Cisco ACI Multicast Source Discovery Protocol (MSDP) must be configured to filter source-active (SA) multicast advertisements to external MSDP peers to avoid global visibility of local-only multicast sources and groups.", "ruleVulnDiscussion": "To avoid global visibility of local information, there are a number of source-group (S, G) states in a PIM-SM domain that must not be leaked to another domain, such as multicast sources with private address, administratively scoped multicast addresses, and the auto-RP groups (224.0.1.39 and 224.0.1.40).\n\nAllowing a multicast distribution tree, local to the core, to extend beyond its boundary could enable local multicast traffic to leak into other autonomous systems and customer networks.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001368", "ruleFixText": "Configure the switch to filter source-active multicast advertisements to external MSDP peers to avoid global visibility of local-only multicast sources and groups.\n\n1. Filter all SA messages coming from peer 10.1.1.2 except those for group 224.0.0.1. in the CLI, where is the IP address of the external MSDP peer.\n\napic1(config)# ip msdp sa-filter in 10.1.1.2 list OUTBOUND_MSDP_SA_FILTER\n\n2. ACL definition.\n\napic1(config)# ip access-list extended OUTBOUND_MSDP_SA_FILTER permit ip any 224.0.0.1 any", "ruleFixId": "F-76023r1115724_fix", "ruleCheckSystem": "C-76116r1063593_chk", "ruleCheckContent": "If the ACI implementation does not use MSDP, this is not applicable.\n\nip msdp sa-filter in list OUTBOUND_MSDP_SA_FILTER\n\nIf the device is not configured with an export policy to filter local source-active multicast advertisements, this is a finding.", "createdAt": "2025-10-21T11:24:01.439Z", "updatedAt": "2025-10-21T11:24:01.439Z" }, { "id": 11668, "benchmarkId": 240, "groupId": "V-272067", "title": "SRG-NET-000018-RTR-000009", "description": "", "ruleId": "SV-272067r1113973_rule", "ruleWeight": "10.0", "ruleSeverity": "low", "ruleVersion": "CACI-RT-000007", "ruleTitle": "The Multicast Source Discovery Protocol (MSDP) Cisco ACI must be configured to limit the amount of source-active (SA) messages it accepts on per-peer basis.", "ruleVulnDiscussion": "To reduce any risk of a denial-of-service (DoS) attack from a rogue or misconfigured MSDP router, the router must be configured to limit the number of source-active messages it accepts from each peer.\n\nTo limit the amount of SA messages a Cisco ACI switch accepts from each MSDP peer, configure the \"ip msdp sa-limit\" command on the switch, specifying the maximum number of SA messages allowed per peer; this essentially acts as a per-peer limit to prevent overwhelming the device with multicast source information from a single source.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001368", "ruleFixText": "To limit the amount of SA messages a Cisco ACI switch accepts from each MSDP peer, configure the \"ip msdp sa-limit\" command specifying the maximum number of SA messages allowed per peer. The following is an example:\n\napi1(config)# ip msdp sa-limit 10.1.1.1 MSDP_SA_FILTER", "ruleFixId": "F-76024r1063597_fix", "ruleCheckSystem": "C-76117r1063596_chk", "ruleCheckContent": "If the ACI implementation does not use MSDP, this is not applicable.\n\nReview the switch configuration to determine if it is configured to limit the amount of source-active messages it accepts on a per-peer basis.\n\nshow ip msdp\n\nIf the ACI is not configured to limit the source-active messages it accepts, this is a finding.", "createdAt": "2025-10-21T11:24:01.439Z", "updatedAt": "2025-10-21T11:24:01.439Z" }, { "id": 11669, "benchmarkId": 240, "groupId": "V-272068", "title": "SRG-NET-000019-RTR-000003", "description": "", "ruleId": "SV-272068r1114267_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "CACI-RT-000008", "ruleTitle": "The multicast Cisco ACI must be configured to disable Protocol Independent Multicast (PIM) on all interfaces that are not required to support multicast routing.", "ruleVulnDiscussion": "If multicast traffic is forwarded beyond the intended boundary, it is possible it can be intercepted by unauthorized or unintended personnel. Limiting where, within the network, a given multicast group's data is permitted to flow is an important first step in improving multicast security. \n\nA scope zone is an instance of a connected region of a given scope. Zones of the same scope cannot overlap while zones of a smaller scope will fit completely within a zone of a larger scope. For example, Admin-local scope is smaller than Site-local scope, so the administratively configured boundary fits within the bounds of a site. According to RFC 4007 IPv6 Scoped Address Architecture (section 5), scope zones are also required to be \"convex from a routing perspective\"; that is, packets routed within a zone must not pass through any links that are outside of the zone. This requirement forces each zone to be one contiguous island rather than a series of separate islands. \n\nAs stated in the DOD IPv6 IA Guidance for MO3, \"One should be able to identify all interfaces of a zone by drawing a closed loop on their network diagram, engulfing some routers and passing through some routers to include only some of their interfaces.\" Therefore, it is imperative that the network engineers have documented their multicast topology and thereby know which interfaces are enabled for multicast. Once this is done, the zones can be scoped as required.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001414", "ruleFixText": "From the CLI, use \"no ip pim\" within the interface configuration on the relevant nonmulticast enabled interfaces.\n\nExample:\nconfigure terminal\ninterface Ethernet1/1\nno ip pim", "ruleFixId": "F-76025r1114079_fix", "ruleCheckSystem": "C-76118r1114266_chk", "ruleCheckContent": "1. Review the network's multicast topology diagram.\n\n2. Review the switch configuration to verify only the PIM interfaces as shown in the multicast topology diagram are enabled for PIM as shown in the example below:\n\nExample:\nconfigure terminal\ninterface Ethernet1/1\nno ip pim \n\nIf an interface is not required to support multicast routing and it is enabled, this is a finding.", "createdAt": "2025-10-21T11:24:01.439Z", "updatedAt": "2025-10-21T11:24:01.439Z" }, { "id": 11670, "benchmarkId": 240, "groupId": "V-272069", "title": "SRG-NET-000019-RTR-000004", "description": "", "ruleId": "SV-272069r1114269_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "CACI-RT-000009", "ruleTitle": "The multicast Cisco ACI must be configured to bind a Protocol Independent Multicast (PIM) neighbor filter to interfaces that have PIM enabled.", "ruleVulnDiscussion": "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.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001414", "ruleFixText": "From the CLI, use \"ip pim\" within the interface configuration on the relevant multicast enabled interfaces.\n\nExample:\nconfigure terminal\ninterface Ethernet1/1\nip pim", "ruleFixId": "F-76026r1114081_fix", "ruleCheckSystem": "C-76119r1114268_chk", "ruleCheckContent": "1. Review the network's multicast topology diagram.\n\n2. Review the switch configuration to verify only the PIM interfaces as shown in the multicast topology diagram are enabled for PIM as shown in the example below:\n\nExample:\nconfigure terminal\ninterface Ethernet1/1\nip pim \n\nIf a multicast interface is required to support PIM and it is not enabled, this is a finding.", "createdAt": "2025-10-21T11:24:01.439Z", "updatedAt": "2025-10-21T11:24:01.439Z" }, { "id": 11671, "benchmarkId": 240, "groupId": "V-272070", "title": "SRG-NET-000019-RTR-000005", "description": "", "ruleId": "SV-272070r1113976_rule", "ruleWeight": "10.0", "ruleSeverity": "low", "ruleVersion": "CACI-RT-000010", "ruleTitle": "The multicast edge Cisco ACI must be configured to establish boundaries for administratively scoped multicast traffic.", "ruleVulnDiscussion": "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. Administratively scoped multicast addresses fall within the range of 239.0.0.0 to 239.255.255.255.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001414", "ruleFixText": "Leverage the border leaf switches within the fabric, applying access control lists (ACLs) on the appropriate interfaces to filter multicast packets with administratively scoped addresses.\n\nLog in to the CLI of a border leaf switch within the ACI fabric.\n \nconfigure terminal\nip multicast-routing\naccess-list extended MULTICAST_FILTER\n deny ip 239.0.0.0 239.255.255.255 any\n permit ip any any\n\nApply the created ACL to the outbound direction of the interface facing the external network.", "ruleFixId": "F-76027r1063606_fix", "ruleCheckSystem": "C-76120r1063605_chk", "ruleCheckContent": "Verify the multicast routing table and troubleshoot any issues with multicast traffic flow. \n\nshow ip mroute\n\nIf the ACI is not configured to establish boundaries for administratively scoped multicast traffic, this is a finding.", "createdAt": "2025-10-21T11:24:01.439Z", "updatedAt": "2025-10-21T11:24:01.439Z" }, { "id": 11672, "benchmarkId": 240, "groupId": "V-272071", "title": "SRG-NET-000019-RTR-000011", "description": "", "ruleId": "SV-272071r1114084_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "CACI-RT-000011", "ruleTitle": "The out-of-band management (OOBM) gateway Cisco ACI must be configured to have separate OSPF instances for the managed network and management network.", "ruleVulnDiscussion": "If the gateway router is not a dedicated device for the OOBM network, implementation of several safeguards for containment of management and production traffic boundaries must occur. Since the managed and management network are separate routing domains, configuration of separate OSPF routing instances is critical on the router to segregate traffic from each network.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001414", "ruleFixText": "Configure separate routing instances for the managed and management networks, as shown in the example below:\n\ninterface GigabitEthernet 0/0 \n ip address 10.0.0.1 255.255.255.0\n no shutdown\n ip route-map \"mgmt-routes\" permit\n router bgp 100 // Management network routing instance\n\ninterface GigabitEthernet 0/1\n ip address 192.168.1.1 255.255.255.0\n no shutdown\n ip route-map \"managed-routes\" permit\n router bgp 200 // Managed network routing instance", "ruleFixId": "F-76028r1114083_fix", "ruleCheckSystem": "C-76121r1063922_chk", "ruleCheckContent": "If this review is for the DODIN Backbone, mark as not applicable.\n\nVerify separate routing instances in the Cisco APIC as shown in the following example: \n\ninterface GigabitEthernet 0/0 \n ip address 10.0.0.1 255.255.255.0\n no shutdown\n ip route-map \"mgmt-routes\" permit\n router bgp 100 // Management network routing instance\n\ninterface GigabitEthernet 0/1\n ip address 192.168.1.1 255.255.255.0\n no shutdown\n ip route-map \"managed-routes\" permit\n router bgp 200 // Managed network routing instance \n\nIf separate routing instances are not configured for the managed and management networks, this is a finding.", "createdAt": "2025-10-21T11:24:01.439Z", "updatedAt": "2025-10-21T11:24:01.439Z" }, { "id": 11673, "benchmarkId": 240, "groupId": "V-272072", "title": "SRG-NET-000019-RTR-000012", "description": "", "ruleId": "SV-272072r1113978_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "CACI-RT-000012", "ruleTitle": "The Cisco ACI out-of-band management (OOBM) must be configured to not redistribute routes between the management network routing domain and the managed network routing domain.", "ruleVulnDiscussion": "If the gateway router is not a dedicated device for the OOBM network, several safeguards must be implemented for containment of management and production traffic boundaries; otherwise, it is possible management traffic will not be separated from production traffic.\n\nSince the managed network and the management network are separate routing domains, separate Interior Gateway Protocol routing instances must be configured on the router, one for the managed network and one for the OOBM network. In addition, the routes from the two domains must not be redistributed to each other.\n\nTo configure out-of-band management access on a Cisco APIC using the API:\n1. Navigate to Tenants >> mgmt. \n2. Expand \"Quick Start\" and select Out-of-Band Management Access >> Configure Out-of-Band Management Access. \n3. Here, define the nodes in the OOB network, their IP addresses, allowed subnets for external hosts, and communication filters to control access, essentially creating a dedicated network for managing the devices outside the primary production network.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001414", "ruleFixText": "Disable redistribution on the OOB routing instance:\n\n router bgp 100 // Management network routing instance\n redistribute static route-map deny\n redistribute connected route-map deny\n redistribute connected route-map deny", "ruleFixId": "F-76029r1064184_fix", "ruleCheckSystem": "C-76122r1064183_chk", "ruleCheckContent": "If this review is for the DODIN Backbone, mark as not applicable.\n\nVerify redistribution is disabled on the OOB routing instance:\n\n router bgp 100 // Management network routing instance\n redistribute static route-map deny\n redistribute connected route-map deny\n redistribute connected route-map deny\n\nIf redistribute is not disabled for the OOB instance, this is a finding.", "createdAt": "2025-10-21T11:24:01.439Z", "updatedAt": "2025-10-21T11:24:01.439Z" }, { "id": 11674, "benchmarkId": 240, "groupId": "V-272073", "title": "SRG-NET-000019-RTR-000013", "description": "", "ruleId": "SV-272073r1114086_rule", "ruleWeight": "10.0", "ruleSeverity": "low", "ruleVersion": "CACI-RT-000013", "ruleTitle": "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.", "ruleVulnDiscussion": "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.\n\nBy 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.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001414", "ruleFixText": "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 through the APIC's CLI using the \"accept-register\" command with the desired access list applied to the RP. Specify group or group and source addresses with the match ip multicast command.\n\nPerform the following for each interface that uses IP multicast: \n\n1. Create an extended access list with the desired filter criteria.\n\n# ip access-list extended \n permit ip \n ... (add other allowed source-group combinations) \n deny ip any \n\n2. Access the PIM configuration mode on the RP.\n\nAPIC1 (config-if)# ip pim sparse-mode\n\n3. Apply the access list.\n\n# accept-register ", "ruleFixId": "F-76030r1114085_fix", "ruleCheckSystem": "C-76123r1063614_chk", "ruleCheckContent": "View the configuration to check for PIM compliance.\n\nAPIC1(config)#show running-configuration pim\n\nExample:\n\nip access-list extended PIM_REGISTER_FILTER\n deny ip any 232.0.0.0 0.255.255.255\n permit ip host 10.1.2.6 any\n permit ip host 10.1.2.7 any\n deny ip any any\n\nip pim accept-register list PIM_REGISTER_FILTER\n\nIf the RP router peering with PIM-SM routers is not configured with a policy to block registration messages for any undesirable multicast groups and sources, this is a finding.", "createdAt": "2025-10-21T11:24:01.439Z", "updatedAt": "2025-10-21T11:24:01.439Z" }, { "id": 11675, "benchmarkId": 240, "groupId": "V-272074", "title": "SRG-NET-000019-RTR-000014", "description": "", "ruleId": "SV-272074r1114271_rule", "ruleWeight": "10.0", "ruleSeverity": "low", "ruleVersion": "CACI-RT-000014", "ruleTitle": "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.", "ruleVulnDiscussion": "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.\n\nIn 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.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001414", "ruleFixText": "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.\n\n1. Create an ACL to deny specific multicast groups.\n\nip access-list extended PIM_JOIN_FILTER\n deny ip multicast group 224.0.0.1\n deny ip multicast group 224.0.0.2\n permit ip any any\n\n2. Apply the ACL to the L3Out interface on the border leaf switch.\n\ninterface L3Out_to_External\n ip access-group PIM_JOIN_FILTER in", "ruleFixId": "F-76031r1114270_fix", "ruleCheckSystem": "C-76124r1063617_chk", "ruleCheckContent": "View the configuration to verify PIM compliance.\n\nAPIC1(config)#show running-configuration pim\n\nExample:\n! ACL to deny specific multicast groups\nip access-list extended PIM_JOIN_FILTER\n deny ip multicast group 224.0.0.1\n deny ip multicast group 224.0.0.2\n permit ip any any\n\n! ACL to the L3Out interface on the border leaf switch\ninterface L3Out_to_External\n ip access-group PIM_JOIN_FILTER in\n\nIf the RP is not configured to filter join messages received from the DR for any undesirable multicast groups, this is a finding.", "createdAt": "2025-10-21T11:24:01.439Z", "updatedAt": "2025-10-21T11:24:01.439Z" }, { "id": 11676, "benchmarkId": 240, "groupId": "V-272075", "title": "SRG-NET-000078-RTR-000001", "description": "", "ruleId": "SV-272075r1114309_rule", "ruleWeight": "10.0", "ruleSeverity": "low", "ruleVersion": "CACI-RT-000015", "ruleTitle": "The Cisco ACI must be configured to log all packets that have been dropped.", "ruleVulnDiscussion": "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.\n\nTo 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.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-000134", "ruleFixText": "Configure ACLs to log packets that are dropped. Use the APIC GUI to navigate to each tenant:\n1. Go to the contract section and either create a new contract or modify an existing one where drop logging is to be implemented. \n2. 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\".\n3. Assign the contract to the relevant endpoint groups (EPGs) to enforce the policy on traffic between them.", "ruleFixId": "F-76032r1064190_fix", "ruleCheckSystem": "C-76125r1114308_chk", "ruleCheckContent": "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\".\n\nIf packets being dropped at interfaces are not logged, this is a finding.", "createdAt": "2025-10-21T11:24:01.439Z", "updatedAt": "2025-10-21T11:24:01.439Z" }, { "id": 11677, "benchmarkId": 240, "groupId": "V-272076", "title": "SRG-NET-000131-RTR-000083", "description": "", "ruleId": "SV-272076r1113982_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "CACI-RT-000016", "ruleTitle": "The Cisco ACI must not be configured to have any feature enabled that calls home to the vendor.", "ruleVulnDiscussion": "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.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-002403", "ruleFixText": "Disable the Call Home feature:\n1. Navigate to the \"Admin\" section in the GUI, then expand All >> Communication Management >> Call Home.\n2. In the General tab, set the Admin State to \"Off\".\n3. Click \"Save\".", "ruleFixId": "F-76033r1064193_fix", "ruleCheckSystem": "C-76126r1064192_chk", "ruleCheckContent": "Verify the Call Home feature is disabled:\n1. Navigate to the \"Admin\" section in the GUI, then expand All >> Communication Management >> Call Home.\n2. In the General tab, verify the Admin State is set to \"Off\".\n\nIf the Call Home feature is configured to send messages to unauthorized individuals such as Cisco TAC, this is a finding.", "createdAt": "2025-10-21T11:24:01.439Z", "updatedAt": "2025-10-21T11:24:01.439Z" }, { "id": 11678, "benchmarkId": 240, "groupId": "V-272077", "title": "SRG-NET-000168-RTR-000077", "description": "", "ruleId": "SV-272077r1114087_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "CACI-RT-000017", "ruleTitle": "The Cisco ACI must be configured to use encryption for routing protocol authentication.", "ruleVulnDiscussion": "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.\n\nThis 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.\n\nTo 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.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-000803", "ruleFixText": "Configure one or more PSKs used to generate encryption keys for the routing protocol authentication process:\n\napic1(config)# template cloudsec default\napic1(config-cloudsec)# sakexpirytime____\napic1(config-cloudsec)# pskindex____\napic1(config-cloudsec)# pskstring____", "ruleFixId": "F-76034r1064196_fix", "ruleCheckSystem": "C-76127r1064195_chk", "ruleCheckContent": "Verify PSKs are configured:\n\napic1(config-cloudsec)# show cloudsec summary\n\nIf PSKs are not configured to use encryption for routing protocol authentication, this is a finding.", "createdAt": "2025-10-21T11:24:01.439Z", "updatedAt": "2025-10-21T11:24:01.439Z" }, { "id": 11679, "benchmarkId": 240, "groupId": "V-272078", "title": "SRG-NET-000168-RTR-000078", "description": "", "ruleId": "SV-272078r1114273_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "CACI-RT-000018", "ruleTitle": "The Cisco ACI must be configured to authenticate all routing protocol messages using a NIST-validated FIPS 198-1 message authentication code algorithm.", "ruleVulnDiscussion": "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.\n\nSince 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.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-000803", "ruleFixText": "Configure authentication for every protocol that affects the routing or forwarding tables to use key chain (TCP-AO) authentication. Use the following command on all supported control plane protocols. This typically includes protocols such as BGP and OSPF. The following are examples.\n\n1. Create a TCP-AO key chain.\n\napic1(config)# ip tcp ao key chain \napic1(config)# key \napic1(config-tcpkey chain-tcpkey)# key-string \napic1(config-tcpkey chain-tcpkey)# recv-id \napic1(config-tcpkey chain-tcpkey)# send-id \napic1(config-tcpkey chain-tcpkey)# send-lifetime \napic1(config-tcpkey chain-tcpkey)# recv-lifetime \napic1(config-tcpkey chain-tcpkey)# cryptographic-algorithm hmac-sha256\n\n2. Configure BGP to use the key chain for authentication.\n\napic1(config)# router bgp \napic1(config-router)# neighbor remote-ao \napic1(config-router)# ao \n\n3. Configure OSPF to use the key chain for authentication.\n\napic1(config)# interface Ethernet1/1\napic1(config-if)# ip address
\napic1(config-if)# ip ospf authentication key-chain ", "ruleFixId": "F-76035r1114272_fix", "ruleCheckSystem": "C-76128r1064198_chk", "ruleCheckContent": "If EIGRP, RIP, and IS-IS protocols are used (these protocols only support MD5 authentication), this is a finding.\n\nReview the switch configuration using the show bgp and show ospf commands to verify BGP and OSPF. The configuration should be similar to the example below:\n\nKey-Chain bgp_keys tcp\n Key 1 -- text 0 \"070e234f\"\n send-id 2\n recv-id 2\n cryptographic-algorithm hmac-sha256\n send lifetime 3600\n\nIf authentication protocols that affects the routing or forwarding tables are not configured to use key chain (TCP-AO) authentication with 180 maximum lifetime, this is a finding.", "createdAt": "2025-10-21T11:24:01.439Z", "updatedAt": "2025-10-21T11:24:01.439Z" }, { "id": 11680, "benchmarkId": 240, "groupId": "V-272079", "title": "SRG-NET-000205-RTR-000002", "description": "", "ruleId": "SV-272079r1114312_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "CACI-RT-000019", "ruleTitle": "The Cisco ACI must be configured to drop all fragmented Internet Control Message Protocol (ICMP) packets destined to itself.", "ruleVulnDiscussion": "Fragmented ICMP packets can be generated by hackers for DoS attacks such as Ping O' Death and Teardrop. It is imperative that all fragmented ICMP packets are dropped.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001097", "ruleFixText": "Ensure this deny rule is placed before any permit rules for ICMP traffic to ensure fragmented ICMP packets are dropped first. \n\n1. Navigate Tenant >> Contract >> Filter.\n2. Create or edit a filter (e.g., \"Drop Fragmented ICMP\").\n3. Set Match to include: \n Protocol: ICMP\n Fragmentation: \"Fragmented\"\n4. Set Action to \"Deny\".", "ruleFixId": "F-76036r1114311_fix", "ruleCheckSystem": "C-76129r1114310_chk", "ruleCheckContent": "If this review is for the DODIN Backbone, mark as not applicable.\n\nReview the external and internal ACLs to verify that the router is configured to only allow specific management and control plane traffic from specific sources destined to itself.\n\n1. Navigate Tenant >> Contract >> Filter.\n2. Select the \"Drop Fragmented ICMP\" filter.\n3. Verify ICMP and Fragmented are selected to be denied.\n\nIf all fragmented ICMP packets destined to Cisco ACI IP addresses are not dropped, this is a finding.", "createdAt": "2025-10-21T11:24:01.439Z", "updatedAt": "2025-10-21T11:24:01.439Z" }, { "id": 11682, "benchmarkId": 240, "groupId": "V-272081", "title": "SRG-NET-000205-RTR-000012", "description": "", "ruleId": "SV-272081r1114276_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "CACI-RT-000021", "ruleTitle": "The Cisco ACI must be configured to only permit management traffic that ingresses and egresses the OOBM interface.", "ruleVulnDiscussion": "To configure OOB management on an ACI fabric, use the Application Policy Infrastructure Controller (APIC), which is 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.\n\nAll management traffic is immediately forwarded into the management network, it is not exposed to possible tampering. The separation also ensures that congestion or failures in the managed network do not affect the management of the device. If the device does not have an OOBM port, the interface functioning as the management interface must be configured so that management traffic does not leak into the managed network and that production traffic does not leak into the management network.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001097", "ruleFixText": "Create a dedicated \"OOB\" contract that explicitly permits necessary management protocols on the OOB subnet, then apply this contract to the relevant node management interface.\n\n1. Navigate to the relevant tenant and create a new external network instance profile for the OOB subnet. \n\napic1(config)# tenant \n\n2. Create the OOB contract.\n\napic1(config)# contract MGMT_OOB\napic1(config)# filter ingress\napic1(config)# protocol icmp\napic1(config)# protocol tcp port 22, 80, 443\napic1(config)# protocol udp port 68, 67\napic1(config)# filter egress \napic1(config)# protocol icmp\napic1(config)# protocol tcp port 22, 80, 443\napic1(config)# protocol udp port 68, 67\n\n3. Apply the Contract to the OOB Interface.\n\napic1(config)# interface / \napic1(config-if)# contract mgmt_oob", "ruleFixId": "F-76038r1114275_fix", "ruleCheckSystem": "C-76131r1114274_chk", "ruleCheckContent": "Use the \"show\" command to verify the contract is attached to the management interface and that only permitted management traffic is allowed.\n\nIf the router does not restrict traffic that ingresses and egresses the management interface, this is a finding.\n\n1. Verify the OOB contract is configured to explicitly permit only management traffic.\n\napic1(config)# contract MGMT_OOB\napic1(config)# filter ingress\napic1(config)# protocol icmp\napic1(config)# protocol tcp port 22, 80, 443\napic1(config)# protocol udp port 68, 67\napic1(config)# filter egress \napic1(config)# protocol icmp\napic1(config)# protocol tcp port 22, 80, 443\napic1(config)# protocol udp port 68, 67\n\n2. Verify the contract attached to the OOB Interface.\n\napic1(config)# interface / \napic1(config-if)# contract mgmt_oob", "createdAt": "2025-10-21T11:24:01.439Z", "updatedAt": "2025-10-21T11:24:01.439Z" }, { "id": 11683, "benchmarkId": 240, "groupId": "V-272082", "title": "SRG-NET-000230-RTR-000001", "description": "", "ruleId": "SV-272082r1114265_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "CACI-RT-000022", "ruleTitle": "The Cisco ACI must be configured to implement message authentication and secure communications for all control plane protocols.", "ruleVulnDiscussion": "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.\n\nThis 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.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001184", "ruleFixText": "Configure secure communications and message authentication on all control plane protocols.\n\n1. Enable Secure Communication:\n Navigate to Fabric >> Fabric Policies >> Pod Policies >> Policies >> Management. \n Enable SSH and SSL protocols for APIC management. \n Configure the ports used for SSH and SSL connections as needed.\n\n2. Configure Message Authentication:\n Navigate to Fabric >> Fabric Policies >> Pod Policies >> Policies >> Interconnect. \n Enable IPsec for FI communication to ensure secure communication between the APIC and the switches. \n Configure the IPsec parameters, such as the encryption algorithm and authentication method. \n\n3. Configure OpFlex for Southbound Communication to use TLS:\n Note: OpFlex is a southbound protocol designed to facilitate communications between the SDN Controller and the switches and routers. \n \n4. Enable Trust Domain:\n Navigate to Fabric >> Fabric Policies >> Pod Policies >> Policies >> Trust Domain. \n Enable the Trust Domain to ensure that only trusted devices can communicate with the APIC. \n Configure the Trust Domain parameters, such as the certificate authority and the trusted devices. \n\nTo configure BGP neighbor authentication keys on Cisco ACI border leaf switches, using a different authentication key for each AS peer, you need to configure the BGP Peer Connectivity Profile within the L3Out configuration. \n\n1. In the APIC GUI, go to Tenants >> All Tenants >> your_tenant >> Networking >> L3Outs >> your_l3out. \n2. Expand Logical Node Profiles >> node_profile.\n3. Select Logical Interface Profiles >> interface_profile (where the BGP peering is configured). \n4. 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.\n5. In the BGP Peer Connectivity Profile settings:\n Remote Autonomous System Number: Specify the AS number of the peer.\n Password: Enter the authentication key/password for this specific peer.\n Confirm Password: Re-enter the same password.\n Other settings, such as peer controls, address type controls, and route control profiles, can be adjusted as needed for your BGP peering configuration. \n6. Repeat the steps for each peer you need to configure. 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.", "ruleFixId": "F-76039r1114263_fix", "ruleCheckSystem": "C-76132r1114264_chk", "ruleCheckContent": "Verify secure communications and message authentication on all control plane protocols is configured.\n\n1. Verify Secure Communication:\n Navigate to Fabric >> Fabric Policies >> Pod Policies >> Policies >> Management. \n Verify SSH and SSL protocols are enabled for APIC management. \n\n2. Verify Message Authentication:\n Navigate to Fabric >> Fabric Policies >> Pod Policies >> Policies >> Interconnect. \n Verify IPsec for FI communication is enabled. \n\n3. Verify OpFlex for Southbound Communication is set to TLS.\n\n4. Navigate to Fabric >> Fabric Policies >> Pod Policies >> Policies >> Trust Domain. \n Verify the Trust Domain is enabled and configured.\n\nVerify BGP neighbor authentication keys on Cisco ACI border leaf switches are configured to use a different authentication key for each AS peer. \n\n1. Navigate to Tenants >> All Tenants >> your_tenant >> Networking >> L3Outs >> your_l3out. \n2. Expand Logical Node Profiles >> node_profile.\n3. Select Logical Interface Profiles >> interface_profile (where the BGP peering is configured). \n4. Within the Logical Interface Profile, review each BGP Peer Connectivity profiles for each individual BGP peer.\n5. In the BGP Peer Connectivity Profile settings, review the Password to verify each peer has a unique password.\n\nIf message authentication and secure communications is not configured for all control plane protocols, this is a finding.", "createdAt": "2025-10-21T11:24:01.439Z", "updatedAt": "2025-10-21T11:24:01.439Z" }, { "id": 11684, "benchmarkId": 240, "groupId": "V-272083", "title": "SRG-NET-000230-RTR-000002", "description": "", "ruleId": "SV-272083r1114278_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "CACI-RT-000023", "ruleTitle": "The BGP Cisco ACI must be configured to use a unique key for each autonomous system (AS) it peers with.", "ruleVulnDiscussion": "If the same keys are used between eBGP neighbors, the chance of a hacker compromising any of the BGP sessions increases. It is possible that a malicious user exists in one autonomous system who would know the key used for the eBGP session. This user would then be able to hijack BGP sessions with other trusted neighbors.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001184", "ruleFixText": "Configure unique keys for each AS peered by a Cisco ACI device using TCP-AO by creating separate key chains for each AS, ensuring each key chain contains unique \"send-id\" and \"recv-id\" values for the keys within it, and then associating the appropriate key chain with the BGP neighbor configuration for that specific AS. The following is an example:\n\n1. Create key chain for AS100.\n\napic1(config)# ip tcp authentication key chain AS100\napic1(config)# key 1 send-id 10 recv-id 10\napic1(config)# key 2 send-id 20 recv-id 20\n\n2. Create key chain for AS 200.\n\napic1(config)#ip tcp authentication key chain AS200\napic1(config)# key 1 send-id 30 recv-id 30\napic1(config)# key 2 send-id 40 recv-id 40\n\n3. Configure BGP neighbor with AS100 using key chain AS100.\n\napic1(config)# router bgp 100\napic1(config-router)# neighbor 10.0.0.1 ao AS100\n\n4. Configure BGP neighbor with AS 200 using key chain AS200.\n\napic1(config)# router bgp 200\napic1(config-router)# neighbor 10.0.1.1 ao AS200", "ruleFixId": "F-76040r1114277_fix", "ruleCheckSystem": "C-76133r1063644_chk", "ruleCheckContent": "Review the configuration. Verify the neighbor authentication keys on ACI border leaf switches use a different authentication key for each AS peer. Route maps can also show this view.\n\nip tcp authentication key chain AS100\n key 1 send-id 10 recv-id 10\n key 2 send-id 20 recv-id 20\n\nip tcp authentication key chain AS200\n key 1 send-id 30 recv-id 30\n key 2 send-id 40 recv-id 40\n\nrouter bgp 100\n neighbor 10.0.0.1 ao AS100\n\nrouter bgp 200\n neighbor 10.0.1.1 ao AS200\n\nIf unique keys are not being used, this is a finding.", "createdAt": "2025-10-21T11:24:01.439Z", "updatedAt": "2025-10-21T11:24:01.439Z" }, { "id": 11685, "benchmarkId": 240, "groupId": "V-272084", "title": "SRG-NET-000230-RTR-000003", "description": "", "ruleId": "SV-272084r1114357_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "CACI-RT-000024", "ruleTitle": "The Cisco ACI must be configured to use keys with a duration of 180 days or less for authenticating routing protocol messages.", "ruleVulnDiscussion": "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.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001184", "ruleFixText": "For each authenticated routing protocol session, configure each key to have a lifetime of no more than 180 days. The following is an example.\n\nAdd the lifetime duration value to every TCP-AO Key ID configured.\n\napic1(config)# ip tcp ao key chain \napic1(config)# key \napic1(config-tcpkey chain-tcpkey)# send-lifetime \napic1(config-tcpkey chain-tcpkey)# recv-lifetime ", "ruleFixId": "F-76041r1114356_fix", "ruleCheckSystem": "C-76134r1063647_chk", "ruleCheckContent": "If any key has a lifetime of more than 180 days (expressed in seconds), this is a finding.\n\nReview the switch configuration using the show bgp and show ospf commands to view BGP and OSPF. The configuration will be similar to the example below.\n\nKey-Chain bgp_keys tcp\n Key 1 -- text 0 \"070e234f\"\n send lifetime 3600\n recv-lifetime 3600\n\nIf any key has a lifetime of 180 days or less, this is a finding.", "createdAt": "2025-10-21T11:24:01.439Z", "updatedAt": "2025-10-21T11:24:01.439Z" }, { "id": 11687, "benchmarkId": 240, "groupId": "V-272086", "title": "SRG-NET-000362-RTR-000111", "description": "", "ruleId": "SV-272086r1114094_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "CACI-RT-000026", "ruleTitle": "The Cisco ACI must be configured to have gratuitous ARP (GARP) disabled on all external interfaces.", "ruleVulnDiscussion": "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.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-002385", "ruleFixText": "Disable GARP for each L3OUT Bridge Domain:\n1. In the APIC GUI navigation pane, select \"Tenant\" and complete the following for each tenant listed.\n2. Expand \"Networking\", right-click, \"Create Bridge Domain\" to open the dialog box, and fill out the form.\n- In the Layer 3 Configurations tab, GARP based detection must not be enabled.\n3. Click \"NEXT\".\n4. Complete the Bridge Domain configuration. \n5. Click \"Finish\".", "ruleFixId": "F-76043r1114093_fix", "ruleCheckSystem": "C-76136r1064209_chk", "ruleCheckContent": "Review the configuration for each L3OUT Bridge Domain to determine if gratuitous ARP is disabled:\n1. In the APIC GUI Navigation pane, select \"Tenant\" and inspect each Tenant's Bridge Domain configuration.\n2. Expand \"Networking\" and right-click each Bridge Domain.\n3. View the Layer 3 configuration tab. Verify GARP-based detection is not enabled.\n\nIf GARP is enabled on any external interface, this is a finding.", "createdAt": "2025-10-21T11:24:01.439Z", "updatedAt": "2025-10-21T11:24:01.439Z" }, { "id": 11688, "benchmarkId": 240, "groupId": "V-272087", "title": "SRG-NET-000362-RTR-000114", "description": "", "ruleId": "SV-272087r1113993_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "CACI-RT-000027", "ruleTitle": "The Cisco ACI must be configured to have Internet Control Message Protocol (ICMP) mask replies disabled on all external interfaces.", "ruleVulnDiscussion": "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.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-002385", "ruleFixText": "Disable ip mask-reply on all external interfaces as shown below:\n\napic1(config)# interface Ethernet0/1\napic(config-if)# no ip icmp mask-reply", "ruleFixId": "F-76044r1063657_fix", "ruleCheckSystem": "C-76137r1063656_chk", "ruleCheckContent": "Review the router configuration and verify the ip mask-reply command is not enabled on any external interfaces as shown in the example below: \n\napic1(config)# interface Ethernet0/1\napic(config-if)# no ip icmp mask-reply\n\nIf the ip mask-reply command is configured on any external interface, this is a finding.", "createdAt": "2025-10-21T11:24:01.439Z", "updatedAt": "2025-10-21T11:24:01.439Z" }, { "id": 11689, "benchmarkId": 240, "groupId": "V-272088", "title": "SRG-NET-000362-RTR-000117", "description": "", "ruleId": "SV-272088r1114096_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "CACI-RT-000028", "ruleTitle": "The BGP Cisco ACI must be configured to use the maximum prefixes feature to protect against route table flooding and prefix de-aggregation attacks.", "ruleVulnDiscussion": "The effects of prefix de-aggregation can degrade router performance due to the size of routing tables and also result in black-holing legitimate traffic. Initiated by an attacker or a misconfigured router, prefix de-aggregation occurs when the announcement of a large prefix is fragmented into a collection of smaller prefix announcements.\n\nMaximum prefix limits on peer connections combined with aggressive prefix-size filtering of customers' reachability advertisements will effectively mitigate the de-aggregation risk. BGP maximum prefix must be used on all eBGP routers to limit the number of prefixes that it should receive from a particular neighbor, whether customer or peering AS. Consider each neighbor and how many routes they should be advertising and set a threshold slightly higher than the number expected.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-002385", "ruleFixText": "Configure the router to use the maximum prefixes feature to protect against route table flooding and prefix de-aggregation attacks as shown in the example below:\n\nFor each BGP peer, use the command \"neighbor maximum-prefix \" within the BGP configuration section, where is the IP address of the BGP peer and is the desired maximum prefix limit to be set; the default maximum prefix limit is typically 20,000 prefixes.", "ruleFixId": "F-76045r1114095_fix", "ruleCheckSystem": "C-76138r1063659_chk", "ruleCheckContent": "Verify the BGP configuration for each tenant:\n\nip route protocol BGP\n\nView the BGP peer configuration maximum prefix value:\n\nneighbor 10.0.0.1 maximum-prefix nnnnnnn\n\nIf the router is not configured to control the number of prefixes received from each peer to protect against route table flooding and prefix de-aggregation attacks, this is a finding.", "createdAt": "2025-10-21T11:24:01.439Z", "updatedAt": "2025-10-21T11:24:01.439Z" }, { "id": 11690, "benchmarkId": 240, "groupId": "V-272089", "title": "SRG-NET-000362-RTR-000118", "description": "", "ruleId": "SV-272089r1114282_rule", "ruleWeight": "10.0", "ruleSeverity": "low", "ruleVersion": "CACI-RT-000029", "ruleTitle": "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.", "ruleVulnDiscussion": "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.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-002385", "ruleFixText": "Configure the router to limit the prefix size on any route advertisement to /24 or the least significant prefixes issued to the customer.\n\nCreate a \"match rule\" within a \"route profile\" by specifying a prefix list, which is then applied to the desired L3Out (external routed network) to filter BGP routes based on the prefixes defined in the list.\n\nThe route profile is applied to a specific L3Out (external routed network) to control which prefixes are advertised or accepted from external networks.\n\n1. Configure a prefix list to reject any prefix that is longer than /24.\n\ntenant prefix-list ALLOW_SUBNET\n ip prefix 10.0.0.0/24 permit\n\n2. Create a route profile named \"filter_profile\". \n\ntenant route-profile FILTER_PROFILE\n\n match-rule filter_rule \n match prefix allow_subnet\n\n3. Apply the route profile to an L3Out.\n\ntenant l3extInstP route-profile FILTER_PROFILE", "ruleFixId": "F-76046r1114281_fix", "ruleCheckSystem": "C-76139r1063662_chk", "ruleCheckContent": "Review the configuration of the RP to verify it is rate limiting the number of PIM register messages.\n\ntenant prefix-list ALLOW_SUBNET\n ip prefix 10.0.0.0/24 permit\n match-rule filter_rule \n match prefix allow_subnet\n tenant l3extInstP route-profile FILTER_PROFILE\n\nIf the router is not configured to limit the prefix size on any inbound route advertisement to /24, or the least significant prefixes issued to the customer, this is a finding.", "createdAt": "2025-10-21T11:24:01.439Z", "updatedAt": "2025-10-21T11:24:01.439Z" }, { "id": 11691, "benchmarkId": 240, "groupId": "V-272090", "title": "SRG-NET-000362-RTR-000120", "description": "", "ruleId": "SV-272090r1114314_rule", "ruleWeight": "10.0", "ruleSeverity": "low", "ruleVersion": "CACI-RT-000030", "ruleTitle": "The Cisco ACI multicast rendezvous point (RP) must be configured to limit the multicast forwarding cache so that its resources are not saturated by managing an overwhelming number of Protocol Independent Multicast (PIM) and Multicast Source Discovery Protocol (MSDP) source-active entries.", "ruleVulnDiscussion": "MSDP peering between networks enables sharing of multicast source information. Enclaves with an existing multicast topology using PIM-SM can configure their RP routers to peer with MSDP routers. As a first step of defense against a denial-of-service (DoS) attack, all RP routers must limit the multicast forwarding cache to ensure router resources are not saturated managing an overwhelming number of PIM and MSDP source-active entries.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-002385", "ruleFixText": "Configure the switch to filter PIM register messages, rate limiting the number of PIM register messages, and accept MSDP packets only from known MSDP peers. Use the command \"ip pim register-rate-limit \", where specifies the desired maximum number of register messages per second allowed to be sent.\n\nNavigate to the global configuration mode.\n\n[switch#] configure terminal \n[switch(config)#] ip pim register-rate-limit 10", "ruleFixId": "F-76047r1114099_fix", "ruleCheckSystem": "C-76140r1064216_chk", "ruleCheckContent": "Review the PIM configuration:\n\nip pim register-rate-limit 10\n\nIf the RP router is not configured to filter PIM register messages, rate limiting the number of PIM register messages, and accept MSDP packets only from known MSDP peers, this is a finding.", "createdAt": "2025-10-21T11:24:01.439Z", "updatedAt": "2025-10-21T11:24:01.439Z" }, { "id": 11692, "benchmarkId": 240, "groupId": "V-272091", "title": "SRG-NET-000362-RTR-000121", "description": "", "ruleId": "SV-272091r1114102_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "CACI-RT-000031", "ruleTitle": "The multicast rendezvous point (RP) must be configured to rate limit the number of Protocol Independent Multicast (PIM) Register messages.", "ruleVulnDiscussion": "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.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-002385", "ruleFixText": "Configure the RP to rate limit the number of multicast register messages:\n\napic(config)# tenant \napic(config)# vrf \n apic(config)# ip pim register rate limit 10", "ruleFixId": "F-76048r1114101_fix", "ruleCheckSystem": "C-76141r1064218_chk", "ruleCheckContent": "Review the configuration of the RP to verify that it is rate limiting the number of PIM register messages:\n\ntenant \nvrf \n ip pim register rate limit 10 \n\nIf the RP is not limiting PIM register messages, this is a finding.", "createdAt": "2025-10-21T11:24:01.439Z", "updatedAt": "2025-10-21T11:24:01.439Z" }, { "id": 11693, "benchmarkId": 240, "groupId": "V-272092", "title": "SRG-NET-000362-RTR-000122", "description": "", "ruleId": "SV-272092r1114104_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "CACI-RT-000032", "ruleTitle": "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.", "ruleVulnDiscussion": "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 which would apply across all interfaces, or it may be necessary to configure limits on individual interfaces.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-002385", "ruleFixText": "Configure a global or interface basis to limit the number of mroute states resulting from IGMP or MLD membership reports. \n\nNavigate to the specific BD or interface settings within the APIC configuration. Use the CLI command \"ip igmp limit \" in global configuration mode, which sets a global limit on the number of mroute states allowed across the entire fabric. This limit cannot be configured on a per interface basis in ACI. To limit the number of mroute states created on a BD or interface by MLD reports on a Cisco APIC, configure the \"Maximum Multicast Entries\" parameter within the BD or interface settings.\n\napic# configure terminal \napic(config)# ip igmp limit 100 \n\nor \n\napic(config)#int g0/0\napic(config-if)#ip igmp limit 2\n\nOn the relevant BD or interface, limit the number of multicast routes (mroute states) generated by IGMP or MLD reports. Navigate to the specific BD and interface where the mroute limit is to be set. \n\napic(config)# tenant \napic(config-tenant)# bridge-domain \napic(config-bd)# interface \napic(config-if)# ip mroute limit \n\nNote: Monitor multicast traffic on the network and adjust the \"ip mroute limit\" value as needed to balance performance and resource usage.", "ruleFixId": "F-76049r1114103_fix", "ruleCheckSystem": "C-76142r1064221_chk", "ruleCheckContent": "Review the configuration to verify it is limiting the number of mroute states via IGMP or MLD.\n\nVerify IGMP limits have been configured globally or on each host-facing interface via the ip igmp limit command as shown in the example:\n\ninterface GigabitEthernet0/0\n ip igmp limit nn\n\nReview the relevant Bridge Domain (BD) or interface. Verify it is configured to limit the number of multicast routes (mroute states) generated by IGMP or MLD reports.\n\ntenant \napic(config-tenant)# bridge-domain \napic(config-bd)# interface \napic(config-if)# ip mroute limit \n\nIf the ACI is not limiting multicast requests via IGMP or MLD on a global or interfaces basis, this is a finding.", "createdAt": "2025-10-21T11:24:01.439Z", "updatedAt": "2025-10-21T11:24:01.439Z" }, { "id": 11694, "benchmarkId": 240, "groupId": "V-272093", "title": "SRG-NET-000362-RTR-000123", "description": "", "ruleId": "SV-272093r1113999_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "CACI-RT-000033", "ruleTitle": "The Cisco ACI multicast shortest-path tree (SPT) threshold must be set to the default.", "ruleVulnDiscussion": "On a Cisco ACI, the \"ip pim spt-threshold\" is not set to infinity by default; it is typically set to a finite value, with the default usually being zero, meaning it will always use the SPT for PIM calculations. The standard configuration for \"ip pim spt-threshold\" on Cisco devices is usually set to zero. \n\nThis threshold determines when a router will use the SPT to forward multicast traffic in PIM Sparse Mode. While technically possible, setting the threshold to \"infinity\" would mean the router would never use the SPT, which is generally not the intended behavior. \n\nIn a Cisco ACI fabric, the SPT threshold typically does not need to be manually configured to increase it for multicast, as the system automatically calculates the SPT based on the network topology, and the border leaf switches handle the SPT switchover functionality; however, in specific scenarios where there are a large number of multicast sources, or multicast traffic flow must be optimized, adjusting the SPT threshold may be considered depending on the network requirements. Thus, it is not recommended that this be configured. While technically possible, setting the threshold to \"infinity\" would mean the router would never use the SPT, which is generally not the intended behavior.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-002385", "ruleFixText": "Remove the \"ip pim spt-threshold\" from the configuration.\n\napic(config)# no ip pim spt-threshold ", "ruleFixId": "F-76050r1063675_fix", "ruleCheckSystem": "C-76143r1063674_chk", "ruleCheckContent": "Review the configuration to verify the SPT switchover threshold is not explicitly configured.\n\nIf the \"ip pim spt-threshold command is configured for any value other than zero, this is a finding.", "createdAt": "2025-10-21T11:24:01.439Z", "updatedAt": "2025-10-21T11:24:01.439Z" }, { "id": 11695, "benchmarkId": 240, "groupId": "V-272094", "title": "SRG-NET-000362-RTR-000124", "description": "", "ruleId": "SV-272094r1114284_rule", "ruleWeight": "10.0", "ruleSeverity": "low", "ruleVersion": "CACI-RT-000034", "ruleTitle": "Cisco ACI must be configured to enable the Generalized TTL Security Mechanism (GTSM) for BGP sessions.", "ruleVulnDiscussion": "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. \n\nGTSM is based on the fact that the vast majority of control plane peering is established between adjacent routers, that is, the Exterior Border Gateway Protocol peers are either between connecting interfaces or between loopback interfaces. Since TTL spoofing is considered nearly impossible, a mechanism based on an expected TTL value provides a simple and reasonably robust defense from infrastructure attacks based on forged control plane traffic.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-002385", "ruleFixText": "Configure TTL security on all external BGP neighbors as shown in the example below:\n\n1. Access the BGP Peer Connectivity Profile.\n\npolicy BGP_Peer_Profile\n\n2. Disable Multihop for external neighbor.\n\nno neighbor 10.1.1.1 ebgp-multihop\n\n3. Enable TTL security on the neighbor.\n\nneighbor 10.1.1.1 ttl-security", "ruleFixId": "F-76051r1114283_fix", "ruleCheckSystem": "C-76144r1063677_chk", "ruleCheckContent": "Review the BGP configuration to verify that TTL security has been configured for each external neighbor as shown in the example below:\n\npolicy BGP_Peer_Profile\nno neighbor 10.1.1.1 ebgp-multihop\nneighbor 10.1.1.1 ttl-security\n\nIf the Cisco ACI is not configured to use GTSM for all Exterior BGP peering sessions, this is a finding.", "createdAt": "2025-10-21T11:24:01.439Z", "updatedAt": "2025-10-21T11:24:01.439Z" }, { "id": 11696, "benchmarkId": 240, "groupId": "V-272095", "title": "SRG-NET-000364-RTR-000114", "description": "", "ruleId": "SV-272095r1115727_rule", "ruleWeight": "10.0", "ruleSeverity": "low", "ruleVersion": "CACI-RT-000035", "ruleTitle": "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 that have been approved by the organization.", "ruleVulnDiscussion": "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.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-002403", "ruleFixText": "Configure \"IGMP Snooping\" and create access groups that define which multicast groups are permitted on specific ports. For filtering IPv6 multicast traffic (MLD), use similar commands with the \"mld\" keyword instead of \"igmp\".\n\n1. Navigate to the relevant bridge domain, interface or VLAN and enable IGMP snooping using the command.\n\napic(config)# interface \napic (config-if)# ip igmp snooping\n\nor \n\napic(config)# bd BD-1\napic(config-bd-1)# ip igmp snooping \n\n2. Define a new access group with a name and specify the permitted multicast groups.\n\napic(config)# ip igmp snooping vlan access-group \napic(config)# access-group \napic(config)# permit ip multicast \n\n3. Navigate to the specific port configuration where the filter is to be applied. \n\napic(config)# ip igmp snooping access-group to associate the created access group with the port. \napic(config)# interface Ethernet1/1\napic(config-if)# ip igmp snooping access-group allowed-groups", "ruleFixId": "F-76052r1115726_fix", "ruleCheckSystem": "C-76145r1063680_chk", "ruleCheckContent": "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\nReview the configuration of the designated router (DR) to verify that it is filtering IGMP or MLD Membership Report messages, allowing hosts to join only those groups that have been approved.\n\nIf the Cisco ACI is not filtering IGMP or MLD Membership Report messages, this is a finding.", "createdAt": "2025-10-21T11:24:01.439Z", "updatedAt": "2025-10-21T11:24:01.439Z" }, { "id": 11697, "benchmarkId": 240, "groupId": "V-272096", "title": "SRG-NET-000364-RTR-000115", "description": "", "ruleId": "SV-272096r1114286_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "CACI-RT-000036", "ruleTitle": "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 a multicast group only from sources that have been approved by the organization.", "ruleVulnDiscussion": "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.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-002403", "ruleFixText": "Configure an IGMP snooping policy with source-based filtering, defining which IP addresses are permitted to send multicast traffic to a specific group within a VLAN.\n\n1. Navigate to the relevant interface or bridge domain.\n\n[apic#] switch \n[apic(switch-BD-1)#] ip igmp snooping \n\n2. Within the IGMP Snooping Policy, specify allowed source IP addresses.\n\n[apic(switch-BD-1)#] ip igmp snooping policy\n[apic(switch-)#] ip igmp snooping policy source-filter \n\n3. Assign the created policy to the relevant interface or VLAN.\n\n[apic(switch-BD-1)#] interface \n[apic(switch-BD-1)#] ip igmp snooping policy ", "ruleFixId": "F-76053r1114285_fix", "ruleCheckSystem": "C-76146r1114107_chk", "ruleCheckContent": "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\nReview the configuration to verify that it is filtering IGMP or MLD Membership Report messages, allowing hosts to join only those groups that have been approved.\n\nswitch BD-1\nip igmp snooping \nip igmp snooping policy ApprovedSources\nip igmp snooping policy ApprovedSources source-filter 10.0.0.1\ninterface Vlan10\nip igmp snooping policy ApprovedSources\n\nIf the Cisco API is not filtering IGMP or MLD Membership Report messages, this is a finding.", "createdAt": "2025-10-21T11:24:01.439Z", "updatedAt": "2025-10-21T11:24:01.439Z" }, { "id": 11698, "benchmarkId": 240, "groupId": "V-272097", "title": "SRG-NET-000364-RTR-000116", "description": "", "ruleId": "SV-272097r1114289_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "CACI-RT-000037", "ruleTitle": "Cisco ACI Multicast Source Discovery Protocol (MSDP) must be configured to only accept MSDP packets from known MSDP peers.", "ruleVulnDiscussion": "MSDP peering with customer network routers presents additional risks to the DISN Core, whether from a rogue or misconfigured MSDP-enabled router. To guard against an attack from malicious MSDP traffic, the receive path or interface filter for all MSDP-enabled RP routers must be configured to only accept MSDP packets from known MSDP peers.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-002403", "ruleFixText": "Configure the receive path or interface ACLs to only accept MSDP packets from known MSDP peers. Ensure the IP addresses of all intended MSDP peers have been properly identified and configured before creating the ACL. Regularly review and update ACLs to reflect changes in the network topology and security requirements.\n\n1. Create an ACL allowing only permitted IP addresses.\n\napic(config)# ip access-list extended \napic(config)# permit ip any\napic(config)# permit ip any\n\n2. Apply the ACL as the receive path filter on interface.\n\ninterface \nip msdp incoming filter ", "ruleFixId": "F-76054r1114288_fix", "ruleCheckSystem": "C-76147r1114287_chk", "ruleCheckContent": "Review the switch configuration to determine if there is a receive path or interface filter to only accept MSDP packets from known MSDP peers.\n\n1. Verify that interfaces used for MSDP peering have an inbound ACL as shown in the example below:\n\ninterface GigabitEthernet1/1\n ip address x.1.28.8 255.255.255.0\n ip access-group EXTERNAL_ACL_INBOUND in\n\n2. Verify that the ACL restricts MSDP peering to only known sources.\n\nip access-list extended EXTERNAL_ACL_INBOUND\n permit tcp host x.1.28.2\n permit tcp host x.1.28.2 \n\nIf the switch is not configured to only accept MSDP packets from known MSDP peers, this is a finding.", "createdAt": "2025-10-21T11:24:01.439Z", "updatedAt": "2025-10-21T11:24:01.439Z" }, { "id": 11699, "benchmarkId": 240, "groupId": "V-272098", "title": "SRG-NET-000512-RTR-000001", "description": "", "ruleId": "SV-272098r1114004_rule", "ruleWeight": "10.0", "ruleSeverity": "low", "ruleVersion": "CACI-RT-000038", "ruleTitle": "The Cisco ACI must be configured to use its loopback address as the source address for internal Border Gateway Protocol (iBGP) peering sessions.", "ruleVulnDiscussion": "Using a loopback address as the source address offers a multitude of uses for security, access, management, and scalability of the BGP routers. It is easier to construct appropriate ingress filters for router management plane traffic destined to the network management subnet since the source addresses will be from the range used for loopback interfaces instead of a larger range of addresses used for physical interfaces. Log information recorded by authentication and syslog servers will record the router's loopback address instead of the numerous physical interface addresses.\n\nWhen the loopback address is used as the source for 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.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-000366", "ruleFixText": "Configure the BGP configuration 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. \n\ntenant \n networking \n l3out \n protocol BGP \n neighbor update-source Loopback0", "ruleFixId": "F-76055r1063690_fix", "ruleCheckSystem": "C-76148r1063689_chk", "ruleCheckContent": "Review the switch configuration to verify a loopback address has been configured.\n\ntenant \n networking \n l3out \n protocol BGP \n neighbor 10.1.1.1 update-source Loopback0\n\nIf the switch does not use its loopback address as the source address for all iBGP sessions, this is a finding.", "createdAt": "2025-10-21T11:24:01.439Z", "updatedAt": "2025-10-21T11:24:01.439Z" }, { "id": 11700, "benchmarkId": 240, "groupId": "V-272099", "title": "SRG-NET-000512-RTR-000011", "description": "", "ruleId": "SV-272099r1114110_rule", "ruleWeight": "10.0", "ruleSeverity": "low", "ruleVersion": "CACI-RT-000039", "ruleTitle": "The Multicast Source Discovery Protocol (MSDP) Cisco ACI must be configured to use its loopback address as the source address when originating MSDP traffic.", "ruleVulnDiscussion": "Using a loopback address as the source address offers a multitude of uses for security, access, management, and scalability of MSDP 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.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-000366", "ruleFixText": "Configure the router to use its loopback address is used as the source address when sending MSDP packets.\n\n1. Navigate to Fabric >> Fabric Policies >> Policies >> Pod >> Management Access to find the relevant settings.\n2. Specify the loopback interface IP address as the source address.", "ruleFixId": "F-76056r1063935_fix", "ruleCheckSystem": "C-76149r1114109_chk", "ruleCheckContent": "Verify that the loopback interface is used as the source address for all MSDP packets generated by the router.\n\n1. Navigate to Fabric >> Fabric Policies >> Policies >> Pod >> Management Access on the APIC GUI to find the relevant settings.\n2. Verify the loopback interface IP address is used as the source address.\n\nIf the router does not use its loopback address as the source address when originating MSDP traffic, this is a finding.", "createdAt": "2025-10-21T11:24:01.439Z", "updatedAt": "2025-10-21T11:24:01.439Z" }, { "id": 11701, "benchmarkId": 240, "groupId": "V-272100", "title": "SRG-NET-000512-RTR-000012", "description": "", "ruleId": "SV-272100r1114112_rule", "ruleWeight": "10.0", "ruleSeverity": "low", "ruleVersion": "CACI-RT-000040", "ruleTitle": "The Cisco ACI must be configured to advertise a hop limit of at least 32 in Cisco ACI Advertisement messages for IPv6 stateless auto-configuration deployments.", "ruleVulnDiscussion": "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.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-000366", "ruleFixText": "Configure the switch to advertise a hop limit of at least 32 in router advertisement messages as shown in the example. \n\nDepending on the ACI configuration, it may be necessary to specify the appropriate context (like a specific VLAN or L3Out) before issuing the command.\n\napic1(config)# interface Ethernet 1/1\napic1(config-if)# ipv6 router advertisement hop-limit 32\n\nNote: When configuring using a VPC interface, the ND RA prefix must be enabled for both side A and side B as both are members in the VPC configuration. Enable the ND RA prefix: \n1. In the Work Pane, in the Logical Interface Profile screen, click the SVI tab. \n2. Under Properties, click the check boxes to enable the ND RA Prefix for both Side A and Side B. Choose the identical ND RA Prefix Policy for Side A and Side B.", "ruleFixId": "F-76057r1114111_fix", "ruleCheckSystem": "C-76150r1063695_chk", "ruleCheckContent": "Enter the \"show ipv6 int\" command on the leaf switch to verify the configuration was pushed out correctly to the leaf switch.\n\ninterface Ethernet 1/1\n ipv6 router advertisement hop-limit 32\n\nIf a hop limit of at least 32 is not advertised in Cisco ACI advertisement messages for IPv6 stateless auto-configuration deployments, this is a finding.", "createdAt": "2025-10-21T11:24:01.439Z", "updatedAt": "2025-10-21T11:24:01.439Z" }, { "id": 11702, "benchmarkId": 240, "groupId": "V-272101", "title": "SRG-NET-000512-RTR-000013", "description": "", "ruleId": "SV-272101r1114007_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "CACI-RT-000041", "ruleTitle": "The Cisco ACI must not be configured to use IPv6 site local unicast addresses.", "ruleVulnDiscussion": "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.\n\nSpecify 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.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-000366", "ruleFixText": "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.\n\nipv6 unicast-routing\ninterface gigabitethernet 0/0/0\n ipv6 address 2001:DB8:c18:1::/64 eui-64", "ruleFixId": "F-76058r1064231_fix", "ruleCheckSystem": "C-76151r1063698_chk", "ruleCheckContent": "Review the router configuration to ensure FEC0::/10 IP addresses are not defined. \n\napic1(config) show ipv6 interface gigabitethernet 0/0/0\n\nIf IPv6 site local unicast addresses are defined, this is a finding.", "createdAt": "2025-10-21T11:24:01.439Z", "updatedAt": "2025-10-21T11:24:01.439Z" }, { "id": 11703, "benchmarkId": 240, "groupId": "V-272102", "title": "SRG-NET-000715-RTR-000120", "description": "", "ruleId": "SV-272102r1114291_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "CACI-RT-000042", "ruleTitle": "The Cisco ACI must implement physically or logically separate subnetworks to isolate organization-defined critical system components and functions.", "ruleVulnDiscussion": "Separating critical system components and functions from other noncritical system components and functions through separate subnetworks may be necessary to reduce susceptibility to a catastrophic or debilitating breach or compromise that results in system failure. For example, physically separating the command and control function from the in-flight entertainment function through separate subnetworks in a commercial aircraft provides an increased level of assurance in the trustworthiness of critical system functions.\n\nIn Cisco ACI, subnetwork addresses are configured logically using the policy model, defining separate subnets within different endpoint groups (EPGs) within a tenant, effectively creating logically separate network segments without needing to physically partition the network on the underlying hardware; this separation is achieved through policy-based routing and access control based on the EPGs assigned to different applications or workloads.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-004891", "ruleFixText": "Configure logical separation using EPGs, bridge domains, and/or tenants. The following is an example of an EPG.\n\n1. Configure a VLAN domain.\n\nExample:\napic1(config)# vlan-domain dom1\napic1(config-vlan)# vlan 10-100\n\n2. Create a tenant.\n\nExample:\napic1# configure\napic1(config)# tenant t1\n\n3. Create a private network/VRF.\n\nExample:\napic1(config-tenant)# vrf context ctx1\napic1(config-tenant-vrf)# exit\n\n4. Create a bridge domain.\n\nExample:\napic1(config-tenant)# bridge-domain bd1\napic1(config-tenant-bd)# vrf member ctx1\napic1(config-tenant-bd)# exit\n\n5. Create an application profile and an application EPG.\n\nExample:\napic1(config-tenant)# application AP1\napic1(config-tenant-app)# epg EPG1\napic1(config-tenant-app-epg)# bridge-domain member bd1 \napic1(config-tenant-app-epg)# exit\napic1(config-tenant-app)# exit\napic1(config-tenant)# exit\n\n6. Associate the EPG with a specific port.\n\nExample:\napic1(config)# leaf 1017\napic1(config-leaf)# interface ethernet 1/13\napic1(config-leaf-if)# vlan-domain member dom1\napic1(config-leaf-if)# switchport trunk allowed vlan 20 tenant t1 application AP1 epg EPG1", "ruleFixId": "F-76059r1114290_fix", "ruleCheckSystem": "C-76152r1063701_chk", "ruleCheckContent": "Review the configuration to verify logical separation using EPGs, bridge domains, and/or tenants is configured. The following is an example of an EPG:\n\napic1(config)# leaf 1017\napic1(config-leaf)# interface ethernet 1/13\napic1(config-leaf-if)# vlan-domain member dom1\napic1(config-leaf-if)# switchport trunk allowed vlan 20 tenant t1 application AP1 epg EPG1\n\nIf subnetworks are not configured to isolate organization-defined critical system components and functions, this is a finding.", "createdAt": "2025-10-21T11:24:01.439Z", "updatedAt": "2025-10-21T11:24:01.439Z" }, { "id": 11704, "benchmarkId": 240, "groupId": "V-272103", "title": "SRG-NET-000760-RTR-000160", "description": "", "ruleId": "SV-272103r1114294_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "CACI-RT-000043", "ruleTitle": "The Cisco ACI must establish organization-defined alternate communication paths for system operations organizational command and control.", "ruleVulnDiscussion": "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.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-004931", "ruleFixText": "Configure logical separation using EPGs, bridge domains, and/or tenants in accordance with the SSP. The following is an example of an EPG:\n\n1. Configure a VLAN domain.\n\nExample:\napic1(config)# vlan-domain dom1\napic1(config-vlan)# vlan 10-100\n\n2. Create a tenant.\n\nExample:\napic1# configure\napic1(config)# tenant t1\n\n3. Create a private network/VRF.\n\nExample:\napic1(config-tenant)# vrf context ctx1\napic1(config-tenant-vrf)# exit\n\n4. Create a bridge domain.\n\nExample:\napic1(config-tenant)# bridge-domain bd1\napic1(config-tenant-bd)# vrf member ctx1\napic1(config-tenant-bd)# exit\n\n5. Create an application profile and an application EPG.\n\nExample:\napic1(config-tenant)# application AP1\napic1(config-tenant-app)# epg EPG1\napic1(config-tenant-app-epg)# bridge-domain member bd1 \napic1(config-tenant-app-epg)# exit\napic1(config-tenant-app)# exit\napic1(config-tenant)# exit\n\n6. Associate the EPG with a specific port.\n\nExample:\napic1(config)# leaf 1017\napic1(config-leaf)# interface ethernet 1/13\napic1(config-leaf-if)# vlan-domain member dom1\napic1(config-leaf-if)# switchport trunk allowed vlan 20 tenant t1 application AP1 epg EPG1", "ruleFixId": "F-76060r1114293_fix", "ruleCheckSystem": "C-76153r1114292_chk", "ruleCheckContent": "Review the SSP and the ACI configuration to verify logical separation using EPGs, bridge domains, and/or tenants is configured. The following is an example of an EPG:\n\napic1(config)# leaf 1017\napic1(config-leaf)# interface ethernet 1/13\napic1(config-leaf-if)# vlan-domain member dom1\napic1(config-leaf-if)# switchport trunk allowed vlan 20 tenant t1 application AP1 epg EPG1\n\nIf organization-defined alternate communication paths for system operations organizational command and control have not been established, this is a finding.", "createdAt": "2025-10-21T11:24:01.439Z", "updatedAt": "2025-10-21T11:24:01.439Z" }, { "id": 11705, "benchmarkId": 240, "groupId": "V-272104", "title": "SRG-NET-000362-RTR-000110", "description": "", "ruleId": "SV-272104r1114297_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "CACI-RT-000044", "ruleTitle": "The Cisco ACI must be configured to protect against or limit the effects of denial-of-service (DoS) attacks by employing control plane protection.", "ruleVulnDiscussion": "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.\n\nA 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.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-002385", "ruleFixText": "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\n1. Configure the ACL's specific traffic types.\n\nApic1(config)#ip access-list extended CoPP_CRITICAL\nApic1(config-ext-nacl)#remark our control plane adjacencies are critical\nApic1(config-ext-nacl)#permit ospf host x.x.x.x any\nApic1(config-ext-nacl)#permit ospf host x.x.x.x any\nApic1(config-ext-nacl)#permit pim host x.x.x.x any\nApic1(config-ext-nacl)#permit pim host x.x.x.x any\nApic1(config-ext-nacl)#permit igmp any 224.0.0.0 15.255.255.255\nApic1(config-ext-nacl)#permit tcp host x.x.x.x eq bgp host x.x.x.x\nApic1(config-ext-nacl)#deny ip any any\nApic1(config-ext-nacl)#exit\n\nApic1(config)#ip access-list extended CoPP_IMPORTANT\nApic1(config-ext-nacl)#permit tcp host x.x.x.x eq tacacs any\nApic1(config-ext-nacl)#permit tcp x.x.x.x 0.0.0.255 any eq 22\nApic1(config-ext-nacl)#permit udp host x.x.x.x any eq snmp\nApic1(config-ext-nacl)#permit udp host x.x.x.x eq ntp any\nApic1(config-ext-nacl)#deny ip any any\nApic1(config-ext-nacl)#exit\n\nApic1(config)#ip access-list extended CoPP_NORMAL\nApic1(config-ext-nacl)#remark we will want to rate limit ICMP traffic\nApic1(config-ext-nacl)#deny icmp any host x.x.x.x fragments\nApic1(config-ext-nacl)#permit icmp any any echo\nApic1(config-ext-nacl)#permit icmp any any echo-reply\nApic1(config-ext-nacl)#permit icmp any any time-exceeded\nApic1(config-ext-nacl)#permit icmp any any unreachable\nApic1(config-ext-nacl)#deny ip any any\nApic1(config-ext-nacl)#exit\n\nApic1(config)#ip access-list extended CoPP_UNDESIRABLE\nApic1(config-ext-nacl)#remark management plane traffic that should not be received\nApic1(config-ext-nacl)#permit udp any any eq ntp\nApic1(config-ext-nacl)#permit udp any any eq snmp\nApic1(config-ext-nacl)#permit tcp any any eq 22\nApic1(config-ext-nacl)#permit tcp any any eq 23\nApic1(config-ext-nacl)#remark control plane traffic not configured on router\nApic1(config-ext-nacl)#permit eigrp any any\nApic1(config-ext-nacl)#permit udp any any eq rip\nApic1(config-ext-nacl)#deny ip any any\nApic1(config-ext-nacl)#exit\nApic1(config)#ip access-list extended CoPP_DEFAULT\nApic1(config-ext-nacl)#permit ip any any\nApic1(config-ext-nacl)#exit\n\n2. Configure class maps referencing each of the ACLs.\n\nApic1(config)#class-map match-all CoPP_CRITICAL\nApic1(config-cmap)#match access-group name CoPP_CRITICAL\nApic1(config-cmap)#class-map match-any CoPP_IMPORTANT\nApic1(config-cmap)#match access-group name CoPP_IMPORTANT\nApic1(config-cmap)#match protocol arp\nApic1(config-cmap)#class-map match-all CoPP_NORMAL\nApic1(config-cmap)#match access-group name CoPP_NORMAL\nApic1(config-cmap)#class-map match-any CoPP_UNDESIRABLE\nApic1(config-cmap)#match access-group name CoPP_UNDESIRABLE\nApic1(config-cmap)#class-map match-all CoPP_DEFAULT\nApic1(config-cmap)#match access-group name CoPP_DEFAULT\nApic1(config-cmap)#exit\n\n3. Configure a policy map referencing the configured class maps and apply appropriate bandwidth allowance and policing attributes.\n\nApic1(config)#policy-map CONTROL_PLANE_POLICY\nApic1(config-pmap)#class CoPP_CRITICAL\nApic1(config-pmap-c)#police 512000 8000 conform-action transmit exceed-action transmit\nApic1(config-pmap-c-police)#class CoPP_IMPORTANT\nApic1(config-pmap-c)#police 256000 4000 conform-action transmit exceed-action drop\nApic1(config-pmap-c-police)#class CoPP_NORMAL\nApic1(config-pmap-c)#police 128000 2000 conform-action transmit exceed-action drop\nApic1(config-pmap-c-police)#class CoPP_UNDESIRABLE\nApic1(config-pmap-c)#police 8000 1000 conform-action drop exceed-action drop\nApic1(config-pmap-c-police)#class CoPP_DEFAULT\nApic1(config-pmap-c)#police 64000 1000 conform-action transmit exceed-action drop\nApic1(config-pmap-c-police)#exit\napic(config-pmap-c)#exit\napic(config-pmap)#exit\n\n4. Apply the policy map applying the configuration to an interface on the leaf.\n\napic(config)# leaf 101\n (config-leaf)# int eth 1/10\n (config-leaf-if)# service-policy type CONTROL-PLANE-POLICY", "ruleFixId": "F-76061r1114296_fix", "ruleCheckSystem": "C-76154r1114295_chk", "ruleCheckContent": "Review the configuration to verify Cisco ACI is configured to employ control plane protection.\n\n1. 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\n2. 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 \npermit tcp host [BGP neighbor] eq bgp host [local BGP addr] \npermit tcp host [BGP neighbor] host [local BGP addr] eq bgp \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 \ndeny icmp any host x.x.x.x fragments\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 router \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\n3. 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\n4. Verify that the CoPP policy is enabled. The following is an example configuration: \n\n(config)# leaf 101\n (config-leaf)# int eth 1/10\n (config-leaf-if)# service-policy type control-plane-if \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 router is not configured to protect against known types of DoS attacks by employing organization-defined security safeguards, this is a finding.", "createdAt": "2025-10-21T11:24:01.439Z", "updatedAt": "2025-10-21T11:24:01.439Z" } ], "profiles": [ { "id": 2093, "benchmarkId": 240, "profileId": "MAC-1_Classified", "title": "I - Mission Critical Classified", "description": "", "createdAt": "2025-10-21T11:24:01.600Z", "updatedAt": "2025-10-21T11:24:01.600Z" }, { "id": 2094, "benchmarkId": 240, "profileId": "MAC-1_Public", "title": "I - Mission Critical Public", "description": "", "createdAt": "2025-10-21T11:24:01.600Z", "updatedAt": "2025-10-21T11:24:01.600Z" }, { "id": 2095, "benchmarkId": 240, "profileId": "MAC-1_Sensitive", "title": "I - Mission Critical Sensitive", "description": "", "createdAt": "2025-10-21T11:24:01.600Z", "updatedAt": "2025-10-21T11:24:01.600Z" }, { "id": 2096, "benchmarkId": 240, "profileId": "MAC-2_Classified", "title": "II - Mission Support Classified", "description": "", "createdAt": "2025-10-21T11:24:01.600Z", "updatedAt": "2025-10-21T11:24:01.600Z" }, { "id": 2097, "benchmarkId": 240, "profileId": "MAC-2_Public", "title": "II - Mission Support Public", "description": "", "createdAt": "2025-10-21T11:24:01.600Z", "updatedAt": "2025-10-21T11:24:01.600Z" }, { "id": 2098, "benchmarkId": 240, "profileId": "MAC-2_Sensitive", "title": "II - Mission Support Sensitive", "description": "", "createdAt": "2025-10-21T11:24:01.600Z", "updatedAt": "2025-10-21T11:24:01.600Z" }, { "id": 2099, "benchmarkId": 240, "profileId": "MAC-3_Classified", "title": "III - Administrative Classified", "description": "", "createdAt": "2025-10-21T11:24:01.600Z", "updatedAt": "2025-10-21T11:24:01.600Z" }, { "id": 2100, "benchmarkId": 240, "profileId": "MAC-3_Public", "title": "III - Administrative Public", "description": "", "createdAt": "2025-10-21T11:24:01.600Z", "updatedAt": "2025-10-21T11:24:01.600Z" }, { "id": 2101, "benchmarkId": 240, "profileId": "MAC-3_Sensitive", "title": "III - Administrative Sensitive", "description": "", "createdAt": "2025-10-21T11:24:01.600Z", "updatedAt": "2025-10-21T11:24:01.600Z" } ] }