STIGViewer Support

The boundary protection system (firewall) must be configured to deny network traffic by default and must allow network traffic by exception (i.e., deny all, permit by exception).

Overview

Finding IDVersionRule IDIA ControlsSeverity
V-216150SOL-11.1-050240SV-216150r1045457_ruleCCI-000197medium
Description
A firewall that relies on a deny all, permit by exception strategy requires all traffic to have explicit permission before traversing an interface on the host. The firewall must incorporate stateful packet filtering and logging. Nonlocal maintenance and diagnostic communications often contain sensitive information and must be protected. The security of these remote accesses can be ensured by sending nonlocal maintenance and diagnostic communications through encrypted channels enforced via firewall configurations. Satisfies: SRG-OS-000074, SRG-OS-000096, SRG-OS-000112, SRG-OS-000113, SRG-OS-000125, SRG-OS-000250, SRG-OS-000393
STIGDate
Solaris 11 X86 Security Technical Implementation Guide2026-05-13

Related Frameworks

8 mappings across 5 frameworks
SCF0 mappings

No source states a mapping between these directly.

Also reachable in 3 hops (18) 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
CFG-03Least Functionality
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
IAC-02.2Replay-Resistant Authentication
1.00
MNT-05.3Remote Maintenance Cryptographic Protection
1.00
MON-01Continuous Monitoring
1.00
MON-01.7File Integrity Monitoring (FIM)
1.00
NET-14.2Protection of Confidentiality / Integrity Using Encryption
1.00

+8 more (top 10 by confidence shown)

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-17(1)Monitoring and Control
1.00
AC-17(2)Protection of Confidentiality and Integrity Using Encryption
1.00
AC-2(1)Automated System Account Management
1.00
AC-2(10)Shared and Group Account Credential Change
1.00
AC-2(11)Usage Conditions
1.00
AC-2(2)Automated Temporary and Emergency Account Management
1.00
AC-2(3)Disable Accounts
1.00
AC-2(4)Automated Audit Actions
1.00
AC-3Access Enforcement
1.00
AC-3(7)Role-based Access Control
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 (10) 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.1.13
1.00
3.4.1
1.00
3.4.2
1.00
3.4.6
1.00
3.5.10
1.00
3.5.4
1.00
3.5.7
1.00
3.5.8
1.00
3.5.9
1.00
3.7.5
1.00
CCI8 mappings
NIST CSF 2.00 mappings

No source states a mapping between these directly.

Also reachable in 3 hops (6) 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.

PR.PSPlatform Security
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-216150r1045457_chk)

Ensure that either the IP Filter or Packet Filter Firewall is installed correctly. Determine the OS version to be secured. # uname -v For Solaris 11, 11.1, 11.2, and 11.3, which use IP Filter, the IP Filter Management profile is required. Check that the IP Filter firewall is enabled and configured so that only authorized sessions are allowed. # svcs ipfilter If "ipfilter" is not listed with a state of "online", this is a finding. The IP Filter Management profile is required. Check that the filters are configured properly. # ipfstat -io If the output of this command does not include the following lines, this is a finding. block out log all keep state keep frags block in log all block in log from any to 255.255.255.255/32 block in log from any to 127.0.0.1/32 Even if the lines above are included in the output, it is possible that other lines can contradict the firewall settings. Review the firewall rules and ensure that they conform to organizational and mission requirements. If the firewall rules are not configured to organizational standards, this is a finding. For Solaris 11.3 or newer, which use Packet Filter, the Network Firewall Management rights profile is required. Check that the Packet Filter firewall is enabled and configured so that only authorized sessions are allowed. # svcs firewall:default If "firewall" is not listed with a state of "online", this is a finding. The Network Firewall Management rights profile is required. Check that the filters are configured properly. # pfctl -s rules If the output of this command does not include a line to block and log all traffic as in the following line, this is a finding (does not have to be exactly like the example). block drop log (to pflog0) all Check that the Packet Filter firewall logging daemon is enabled. svcs firewall/pflog:default If "pflog" is not listed with a state of "online", this is a finding.

Fix Text (F-17386r1045456_fix)

The root role is required. For Solaris 11, 11.1, 11.2, and 11.3, which use IP Filter, configure and enable the IP Filters policy. # pfedit /etc/ipf/ipf.conf. Add the following lines to the file: # Do not allow all outbound traffic, keep state, and log block out log all keep state keep frags # Block and log everything else that comes in block in log all block in log from any to 255.255.255.255 block in log from any to 127.0.0.1/32 Enable ipfilter. # svcadm enable ipfilter Notify ipfilter to use the new configuration file. # ipf -Fa -f /etc/ipf/ipf.conf For Solaris 11.3 or newer, which use Packet Filter, configure and enable the Packet Filter’s policy. # pfedit /etc/firewall/pf.conf. Add either of the following lines to the file: # Block and log all traffic on all interfaces in either direction from anywhere to anywhere block log all -or- # Drop traffic and log it to a fllog interface for more detailed inspection or analysis using tools like tcpdump block drop log (to pflog0) all Enable Packet Filter. # svcadm enable firewall:default Enable Packet Filter logging daemon. # svcadm enable firewall/pflog:default Note: Because the default firewall rules block all network access to the system, ensure there is still a method to access the system, such as SSH or console access, prior to activating the firewall rules. Operational requirements may dictate the addition of protocols such as SSH, DNS, NTP, HTTP, and HTTPS to be allowed.