OpenControls Logo

STIG Viewer

STIGViewer Support

The Cisco ASA must be configured to restrict it from accepting outbound packets that contain an illegitimate address in the source address field via an egress filter or by enabling Unicast Reverse Path Forwarding (uRPF).

Overview

Finding IDVersionRule IDIA ControlsSeverity
V-239871CASA-FW-000290SV-239871r665899_ruleCCI-000366medium
Description
A compromised host in an enclave can be used by a malicious platform to launch cyberattacks on third parties. This is a common practice in "botnets", which are a collection of compromised computers using malware to attack other computers or networks. Denial-of-Service attacks frequently leverage IP source address spoofing to send packets to multiple hosts that, in turn, will then send return traffic to the hosts with the IP addresses that were forged. This can generate significant amounts of traffic. Therefore, protection measures to counteract IP source address spoofing must be taken. When uRPF is enabled in strict mode, the packet must be received on the interface that the device would use to forward the return packet, thereby mitigating IP source address spoofing.
STIGDate
Cisco ASA Firewall Security Technical Implementation Guide2024-06-06

Related Frameworks

1 mapping across 5 frameworks
SCF0 mappings

No source states a mapping between these directly.

Also reachable in 3 hops (8) derived by us, not asserted by any source

Each of these is a route we composed by chaining published mappings. No publisher states a relationship between the two endpoints.

CFG-01Configuration Management Program
1.00
END-01Endpoint Device Management (EDM)
1.00
END-04Malicious Code Protection (Anti-Malware)
1.00
END-06Endpoint File Integrity Monitoring (FIM)
1.00
MON-01Continuous Monitoring
1.00
MON-01.7File Integrity Monitoring (FIM)
1.00
CFG-02Secure Baseline Configurations
0.50
CFG-02.7Approved Configuration Deviations
0.50
NIST 800-530 mappings

No source states a mapping between these directly.

Also reachable in 2 hops (100) derived by us, not asserted by any source

Each of these is a route we composed by chaining published mappings. No publisher states a relationship between the two endpoints.

AC-12Session Termination
1.00
AC-16(1)Dynamic Attribute Association
1.00
AC-17(1)Monitoring and Control
1.00
AC-2Account Management
1.00
AC-2(1)Automated System Account Management
1.00
AC-2(11)Usage Conditions
1.00
AC-2(3)Disable Accounts
1.00
AC-2(4)Automated Audit Actions
1.00
AC-24(1)Transmit Access Authorization Information
1.00
AC-25Reference Monitor
1.00

+90 more (top 10 by confidence shown)

NIST 800-1710 mappings

No source states a mapping between these directly.

Also reachable in 3 hops (2) derived by us, not asserted by any source

Each of these is a route we composed by chaining published mappings. No publisher states a relationship between the two endpoints.

3.4.1
1.00
3.4.2
1.00
CCI1 mapping
CCI-000366
1.00
NIST CSF 2.00 mappings

No source states a mapping between these directly.

Also reachable in 3 hops (5) derived by us, not asserted by any source

Each of these is a route we composed by chaining published mappings. No publisher states a relationship between the two endpoints.

DE.CM-09
1.00
PR.PS-01
1.00
PR.DS-10
0.50
PR.PSPlatform Security
0.50
PR.PS-05
0.50

Who does this work

10 NICE work roles and 9 EC-Council certifications.

This is an inference across published mappings, not a single claim by anyone. This check maps to a control, which maps to a Cybersecurity Framework outcome, which NIST assigns to the work roles below. EC-Council separately maps its certifications to those same roles.

A certification prepares someone for a role. It is not evidence that a holder is qualified, and neither NIST nor EC-Council has stated that any certification here addresses this check.

Work-role assignments published by NIST (NICE Framework Components 2.2.0 and the CSF 2.0 OLIR crosswalk). Certification mappings published by EC-Council.

Details

Check Text (C-239871r665899_chk)

Review the firewall configuration to verify uRPF or an egress filter has been configured on all internal interfaces to restrict the firewall from accepting outbound packets that contain an illegitimate address in the source address field. URF Example: ip verify reverse-path interface INSIDE ACL Example: Step 1: Verify that an ACL has been applied inbound on the inside interfaces as shown in the example below. access-group INSIDE_IN in interface INSIDE Step 2: Verify that the ACL only allows packets from legitimate internal source addresses. object-group network LAN_SUBNETS network-object 10.1.10.0 255.255.255.0 network-object 10.1.12.0 255.255.255.0 network-object 10.1.13.0 255.255.255.0 network-object 10.1.22.0 255.255.255.0 … … … access-list INSIDE_IN extended permit ip object-group LAN_SUBNETS any access-list INSIDE_IN extended deny ip any any Note: Traffic that is permitted must be in compliance with the PPSM. If uRPF or an egress ACL to restrict the firewall from accepting outbound IP packets that contain an illegitimate address in the source address field has not been configured on all internal interfaces, this is a finding.

Fix Text (F-43063r665898_fix)

Configure the firewall with an egress filter or uRPF on all internal interfaces to restrict the firewall from accepting any outbound packet that contains an illegitimate address in the source field. URF Example: ip verify reverse-path interface INSIDE ACL Example: Step 1: Configure an object group containing the allowed subnets as shown in the example below. ASA(config)# object-group network LAN_SUBNETS ASA(config-network-object-group)# network-object 10.1.10.0 255.255.255.0 ASA(config-network-object-group)# network-object 10.1.12.0 255.255.255.0 ASA(config-network-object-group)# network-object 10.1.13.0 255.255.255.0 ASA(config-network-object-group)# network-object 10.1.22.0 255.255.255.0 ASA(config-network-object-group)# exit Step 2: Configure the ACL. ASA(config)# access-list INSIDE_IN permit ip object-group LAN_SUBNETS any ASA(config)# access-list INSIDE_IN deny ip any any Note: Traffic that is permitted must be in compliance with the PPSM. Step 3: Apply the ACL inbound on the inside interface. ASA(config)# access-group INSIDE_IN in interface INSIDE