17.06.2015 Views

RedHat 6 STIG PDF - NoPasara

RedHat 6 STIG PDF - NoPasara

RedHat 6 STIG PDF - NoPasara

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

UNCLASSIFIED<br />

Red Hat Enterprise Linux 6 Security Technical Implementation Guide<br />

1<br />

Release: 2 Benchmark Date: 03 Jun 2013<br />

The Red Hat Enterprise Linux 6 Security Technical Implementation<br />

Guide (<strong>STIG</strong>) is published as a tool to improve the security of<br />

Department of Defense (DoD) information systems. Comments or<br />

proposed revisions to this document should be sent via e-mail to the<br />

following address:<br />

disa.letterkenny.FSO.mbx.stig-customer-support-mailbox@mail.mil.<br />

Rule Title: The system must use a separate file system<br />

for /tmp.<br />

<strong>STIG</strong> ID: RHEL-06-000001 Rule ID: SV-50255r1_rule Vuln<br />

ID: V-38455<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

The "/tmp" partition is used as temporary storage by many<br />

programs. Placing "/tmp" in its own partition enables the<br />

setting of more restrictive mount options, which can help<br />

protect programs which use it.<br />

Documentable: No<br />

Check Content:<br />

Run the following command to determine if "/tmp" is on<br />

its own partition or logical volume:<br />

$ mount | grep "on /tmp "<br />

If "/tmp" has its own partition or volume group, a line<br />

will be returned.<br />

If no line is returned, this is a finding.


UNCLASSIFIED<br />

Fix Text:<br />

The "/tmp" directory is a world-writable directory used<br />

for temporary file storage. Ensure it has its own<br />

partition or logical volume at installation time, or<br />

migrate it using LVM.<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: The system must use a separate file system<br />

for /var.<br />

<strong>STIG</strong> ID: RHEL-06-000002 Rule ID: SV-50256r1_rule Vuln<br />

ID: V-38456<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

Ensuring that "/var" is mounted on its own partition<br />

enables the setting of more restrictive mount options.<br />

This helps protect system services such as daemons or<br />

other programs which use it. It is not uncommon for the<br />

"/var" directory to contain world-writable directories,<br />

installed by other software packages.<br />

Documentable: No<br />

Check Content:<br />

Run the following command to determine if "/var" is on<br />

its own partition or logical volume:<br />

$ mount | grep "on /var "<br />

If "/var" has its own partition or volume group, a line<br />

will be returned.<br />

If no line is returned, this is a finding.<br />

Fix Text:<br />

The "/var" directory is used by daemons and other system<br />

UNCLASSIFIED


UNCLASSIFIED<br />

services to store frequently-changing data. Ensure that<br />

"/var" has its own partition or logical volume at<br />

installation time, or migrate it using LVM.<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: The system must use a separate file system<br />

for /var/log.<br />

<strong>STIG</strong> ID: RHEL-06-000003 Rule ID: SV-50263r1_rule Vuln<br />

ID: V-38463<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

Placing "/var/log" in its own partition enables better<br />

separation between log files and other files in "/var/".<br />

Documentable: No<br />

Check Content:<br />

Run the following command to determine if "/var/log" is<br />

on its own partition or logical volume:<br />

$ mount | grep "on /var/log "<br />

If "/var/log" has its own partition or volume group, a<br />

line will be returned.<br />

If no line is returned, this is a finding.<br />

Fix Text:<br />

System logs are stored in the "/var/log" directory.<br />

Ensure that it has its own partition or logical volume<br />

at installation time, or migrate it using LVM.<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Rule Title: The system must use a separate file system<br />

for the system audit data path.<br />

<strong>STIG</strong> ID: RHEL-06-000004 Rule ID: SV-50267r1_rule Vuln<br />

ID: V-38467<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

Placing "/var/log/audit" in its own partition enables<br />

better separation between audit files and other files,<br />

and helps ensure that auditing cannot be halted due to<br />

the partition running out of space.<br />

Documentable: No<br />

Check Content:<br />

Run the following command to determine if<br />

"/var/log/audit" is on its own partition or logical<br />

volume:<br />

$ mount | grep "on /var/log/audit "<br />

If "/var/log/audit" has its own partition or volume<br />

group, a line will be returned.<br />

If no line is returned, this is a finding.<br />

Fix Text:<br />

Audit logs are stored in the "/var/log/audit" directory.<br />

Ensure that it has its own partition or logical volume<br />

at installation time, or migrate it later using LVM. Make<br />

absolutely certain that it is large enough to store all<br />

audit logs that will be created by the auditing daemon.<br />

CCI: CCI-000137<br />

NIST SP 800-53A :: AU-4.1 (i)<br />

NIST SP 800-53 :: AU-4<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Rule Title: The audit system must alert designated staff<br />

members when the audit storage volume approaches<br />

capacity.<br />

<strong>STIG</strong> ID: RHEL-06-000005 Rule ID: SV-50270r1_rule Vuln<br />

ID: V-38470<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

Notifying administrators of an impending disk space<br />

problem may allow them to take corrective action prior<br />

to any disruption.<br />

Documentable: No<br />

Check Content:<br />

Inspect "/etc/audit/auditd.conf" and locate the<br />

following line to determine if the system is configured<br />

to email the administrator when disk space is starting<br />

to run low:<br />

# grep space_left_action /etc/audit/auditd.conf<br />

space_left_action = email<br />

If the system is not configured to send an email to the<br />

system administrator when disk space is starting to run<br />

low, this is a finding.<br />

Fix Text:<br />

The "auditd" service can be configured to take an action<br />

when disk space starts to run low. Edit the file<br />

"/etc/audit/auditd.conf". Modify the following line,<br />

substituting [ACTION] appropriately:<br />

space_left_action = [ACTION]<br />

Possible values for [ACTION] are described in the<br />

"auditd.conf" man page. These include:<br />

UNCLASSIFIED


UNCLASSIFIED<br />

"ignore"<br />

"syslog"<br />

"email"<br />

"exec"<br />

"suspend"<br />

"single"<br />

"halt"<br />

Set this to "email" (instead of the default, which is<br />

"suspend") as it is more likely to get prompt attention.<br />

RHEL-06-000521 ensures that the email generated through<br />

the operation "space_left_action" will be sent to an<br />

administrator.<br />

CCI: CCI-000138<br />

NIST SP 800-53A :: AU-4.1 (ii)<br />

NIST SP 800-53 :: AU-4<br />

Rule Title: The system must use a separate file system<br />

for user home directories.<br />

<strong>STIG</strong> ID: RHEL-06-000007 Rule ID: SV-50273r1_rule Vuln<br />

ID: V-38473<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

Ensuring that "/home" is mounted on its own partition<br />

enables the setting of more restrictive mount options,<br />

and also helps ensure that users cannot trivially fill<br />

partitions used for log or audit data storage.<br />

Documentable: No<br />

Check Content:<br />

Run the following command to determine if "/home" is on<br />

its own partition or logical volume:<br />

UNCLASSIFIED


UNCLASSIFIED<br />

$ mount | grep "on /home "<br />

If "/home" has its own partition or volume group, a line<br />

will be returned.<br />

If no line is returned, this is a finding.<br />

Fix Text:<br />

If user home directories will be stored locally, create<br />

a separate partition for "/home" at installation time (or<br />

migrate it later using LVM). If "/home" will be mounted<br />

from another system such as an NFS server, then creating<br />

a separate partition is not necessary at installation<br />

time, and the mountpoint can instead be configured later.<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: Vendor-provided cryptographic certificates<br />

must be installed to verify the integrity of system<br />

software.<br />

<strong>STIG</strong> ID: RHEL-06-000008 Rule ID: SV-50276r1_rule Vuln<br />

ID: V-38476<br />

Severity: CAT I Class: Unclass<br />

Discussion:<br />

This key is necessary to cryptographically verify<br />

packages are from Red Hat.<br />

Documentable: No<br />

Check Content:<br />

To ensure that the GPG key is installed, run:<br />

$ rpm -q --queryformat "%{SUMMARY}\n" gpg-pubkey<br />

The command should return the string below:<br />

UNCLASSIFIED


UNCLASSIFIED<br />

gpg(Red Hat, Inc. (release key )<br />

If the Red Hat GPG Key is not installed, this is a finding.<br />

Fix Text:<br />

To ensure the system can cryptographically verify base<br />

software packages come from Red Hat (and to connect to<br />

the Red Hat Network to receive them if desired), the Red<br />

Hat GPG key must properly be installed. To ensure the GPG<br />

key is installed, run:<br />

# rhn_register<br />

CCI: CCI-000352<br />

NIST SP 800-53A :: CM-5 (3).1 (ii)<br />

NIST SP 800-53 :: CM-5 (3)<br />

Rule Title: The Red Hat Network Service (rhnsd) service<br />

must not be running, unless using RHN or an RHN Satellite.<br />

<strong>STIG</strong> ID: RHEL-06-000009 Rule ID: SV-50278r1_rule Vuln<br />

ID: V-38478<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

Although systems management and patching is extremely<br />

important to system security, management by a system<br />

outside the enterprise enclave is not desirable for some<br />

environments. However, if the system is being managed by<br />

RHN or RHN Satellite Server the "rhnsd" daemon can remain<br />

on.<br />

Documentable: No<br />

Check Content:<br />

If the system uses RHN or is an RHN Satellite, this is<br />

not applicable.<br />

UNCLASSIFIED


UNCLASSIFIED<br />

To check that the "rhnsd" service is disabled in system<br />

boot configuration, run the following command:<br />

# chkconfig "rhnsd" --list<br />

Output should indicate the "rhnsd" service has either not<br />

been installed, or has been disabled at all runlevels,<br />

as shown in the example below:<br />

# chkconfig "rhnsd" --list<br />

"rhnsd" 0:off 1:off 2:off 3:off 4:off 5:off 6:off<br />

Run the following command to verify "rhnsd" is disabled<br />

through current runtime configuration:<br />

# service rhnsd status<br />

If the service is disabled the command will return the<br />

following output:<br />

rhnsd is stopped<br />

If the service is running, this is a finding.<br />

Fix Text:<br />

The Red Hat Network service automatically queries Red Hat<br />

Network servers to determine whether there are any<br />

actions that should be executed, such as package updates.<br />

This only occurs if the system was registered to an RHN<br />

server or satellite and managed as such. The "rhnsd"<br />

service can be disabled with the following command:<br />

# chkconfig rhnsd off<br />

CCI: CCI-000382<br />

NIST SP 800-53A :: CM-7.1 (iii)<br />

NIST SP 800-53 :: CM-7<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Rule Title: System security patches and updates must be<br />

installed and up-to-date.<br />

<strong>STIG</strong> ID: RHEL-06-000011 Rule ID: SV-50281r1_rule Vuln<br />

ID: V-38481<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

Installing software updates is a fundamental mitigation<br />

against the exploitation of publicly-known<br />

vulnerabilities.<br />

Documentable: No<br />

Check Content:<br />

If the system is joined to the Red Hat Network, a Red Hat<br />

Satellite Server, or a yum server which provides updates,<br />

invoking the following command will indicate if updates<br />

are available:<br />

# yum check-update<br />

If the system is not configured to update from one of these<br />

sources, run the following command to list when each<br />

package was last updated:<br />

$ rpm -qa -last<br />

Compare this to Red Hat Security Advisories (RHSA) listed<br />

at https://access.redhat.com/security/updates/active/<br />

to determine whether the system is missing applicable<br />

security and bugfix updates.<br />

If updates are not installed, this is a finding.<br />

Fix Text:<br />

If the system is joined to the Red Hat Network, a Red Hat<br />

Satellite Server, or a yum server, run the following<br />

command to install updates:<br />

# yum update<br />

UNCLASSIFIED


UNCLASSIFIED<br />

If the system is not configured to use one of these<br />

sources, updates (in the form of RPM packages) can be<br />

manually downloaded from the Red Hat Network and<br />

installed using "rpm".<br />

CCI: CCI-001233<br />

NIST SP 800-53 :: SI-2 (2)<br />

NIST SP 800-53A :: SI-2 (2).1 (ii)<br />

Rule Title: The system package management tool must<br />

cryptographically verify the authenticity of system<br />

software packages during installation.<br />

<strong>STIG</strong> ID: RHEL-06-000013 Rule ID: SV-50283r1_rule Vuln<br />

ID: V-38483<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

Ensuring the validity of packages' cryptographic<br />

signatures prior to installation ensures the provenance<br />

of the software and protects against malicious tampering.<br />

Documentable: No<br />

Check Content:<br />

To determine whether "yum" is configured to use<br />

"gpgcheck", inspect "/etc/yum.conf" and ensure the<br />

following appears in the "[main]" section:<br />

gpgcheck=1<br />

A value of "1" indicates that "gpgcheck" is enabled.<br />

Absence of a "gpgcheck" line or a setting of "0" indicates<br />

that it is disabled.<br />

If GPG checking is not enabled, this is a finding.<br />

If the "yum" system package management tool is not used<br />

to update the system, verify with the SA that installed<br />

packages are cryptographically signed.<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Fix Text:<br />

The "gpgcheck" option should be used to ensure checking<br />

of an RPM package's signature always occurs prior to its<br />

installation. To configure yum to check package<br />

signatures before installing them, ensure the following<br />

line appears in "/etc/yum.conf" in the "[main]" section:<br />

gpgcheck=1<br />

CCI: CCI-000663<br />

NIST SP 800-53 :: SA-7<br />

NIST SP 800-53A :: SA-7.1 (ii)<br />

Rule Title: The system package management tool must<br />

cryptographically verify the authenticity of all<br />

software packages during installation.<br />

<strong>STIG</strong> ID: RHEL-06-000015 Rule ID: SV-50288r1_rule Vuln<br />

ID: V-38487<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

Ensuring all packages' cryptographic signatures are<br />

valid prior to installation ensures the provenance of the<br />

software and protects against malicious tampering.<br />

Documentable: No<br />

Check Content:<br />

To determine whether "yum" has been configured to disable<br />

"gpgcheck" for any repos, inspect all files in<br />

"/etc/yum.repos.d" and ensure the following does not<br />

appear in any sections:<br />

gpgcheck=0<br />

A value of "0" indicates that "gpgcheck" has been disabled<br />

for that repo.<br />

UNCLASSIFIED


UNCLASSIFIED<br />

If GPG checking is disabled, this is a finding.<br />

If the "yum" system package management tool is not used<br />

to update the system, verify with the SA that installed<br />

packages are cryptographically signed.<br />

Fix Text:<br />

To ensure signature checking is not disabled for any<br />

repos, remove any lines from files in "/etc/yum.repos.d"<br />

of the form:<br />

gpgcheck=0<br />

CCI: CCI-000663<br />

NIST SP 800-53 :: SA-7<br />

NIST SP 800-53A :: SA-7.1 (ii)<br />

Rule Title: A file integrity tool must be installed.<br />

<strong>STIG</strong> ID: RHEL-06-000016 Rule ID: SV-50290r1_rule Vuln<br />

ID: V-38489<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

The AIDE package must be installed if it is to be available<br />

for integrity checking.<br />

Documentable: No<br />

Check Content:<br />

If another file integrity tool is installed, this is not<br />

a finding.<br />

Run the following command to determine if the "aide"<br />

package is installed:<br />

# rpm -q aide<br />

UNCLASSIFIED


UNCLASSIFIED<br />

If the package is not installed, this is a finding.<br />

Fix Text:<br />

Install the AIDE package with the command:<br />

# yum install aide<br />

CCI: CCI-001069<br />

NIST SP 800-53A :: RA-5 (7).1 (ii)<br />

NIST SP 800-53 :: RA-5 (7)<br />

Rule Title: There must be no .rhosts or hosts.equiv<br />

files on the system.<br />

<strong>STIG</strong> ID: RHEL-06-000019 Rule ID: SV-50292r1_rule Vuln<br />

ID: V-38491<br />

Severity: CAT I Class: Unclass<br />

Discussion:<br />

Trust files are convenient, but when used in conjunction<br />

with the R-services, they can allow unauthenticated<br />

access to a system.<br />

Documentable: No<br />

Check Content:<br />

The existence of the file "/etc/hosts.equiv" or a file<br />

named ".rhosts" inside a user home directory indicates<br />

the presence of an Rsh trust relationship.<br />

If these files exist, this is a finding.<br />

Fix Text:<br />

The files "/etc/hosts.equiv" and "~/.rhosts" (in each<br />

user's home directory) list remote hosts and users that<br />

are trusted by the local system when using the rshd<br />

daemon. To remove these files, run the following command<br />

to delete them from any location.<br />

# rm /etc/hosts.equiv<br />

UNCLASSIFIED


UNCLASSIFIED<br />

$ rm ~/.rhosts<br />

CCI: CCI-001436<br />

NIST SP 800-53A :: AC-17 (8).1 (ii)<br />

NIST SP 800-53 :: AC-17 (8)<br />

Rule Title: The system must prevent the root account<br />

from logging in from virtual consoles.<br />

<strong>STIG</strong> ID: RHEL-06-000027 Rule ID: SV-50293r1_rule Vuln<br />

ID: V-38492<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

Preventing direct root login to virtual console devices<br />

helps ensure accountability for actions taken on the<br />

system using the root account.<br />

Documentable: No<br />

Check Content:<br />

To check for virtual console entries which permit root<br />

login, run the following command:<br />

# grep '^vc/[0-9]' /etc/securetty<br />

If any output is returned, then root logins over virtual<br />

console devices is permitted.<br />

If root login over virtual console devices is permitted,<br />

this is a finding.<br />

Fix Text:<br />

To restrict root logins through the (deprecated) virtual<br />

console devices, ensure lines of this form do not appear<br />

in "/etc/securetty":<br />

UNCLASSIFIED


UNCLASSIFIED<br />

vc/1<br />

vc/2<br />

vc/3<br />

vc/4<br />

Note: Virtual console entries are not limited to those<br />

listed above. Any lines starting with "vc/" followed by<br />

numerals should be removed.<br />

CCI: CCI-000770<br />

NIST SP 800-53A :: IA-2 (5).2 (ii)<br />

NIST SP 800-53 :: IA-2 (5) (b)<br />

Rule Title: The system must prevent the root account<br />

from logging in from serial consoles.<br />

<strong>STIG</strong> ID: RHEL-06-000028 Rule ID: SV-50295r1_rule Vuln<br />

ID: V-38494<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

Preventing direct root login to serial port interfaces<br />

helps ensure accountability for actions taken on the<br />

systems using the root account.<br />

Documentable: No<br />

Check Content:<br />

To check for serial port entries which permit root login,<br />

run the following command:<br />

# grep '^ttyS[0-9]' /etc/securetty<br />

If any output is returned, then root login over serial<br />

ports is permitted.<br />

If root login over serial ports is permitted, this is a<br />

finding.<br />

Fix Text:<br />

UNCLASSIFIED


UNCLASSIFIED<br />

To restrict root logins on serial ports, ensure lines of<br />

this form do not appear in "/etc/securetty":<br />

ttyS0<br />

ttyS1<br />

Note: Serial port entries are not limited to those<br />

listed above. Any lines starting with "ttyS" followed<br />

by numerals should be removed<br />

CCI: CCI-000770<br />

NIST SP 800-53A :: IA-2 (5).2 (ii)<br />

NIST SP 800-53 :: IA-2 (5) (b)<br />

Rule Title: Default system accounts, other than root,<br />

must be locked.<br />

<strong>STIG</strong> ID: RHEL-06-000029 Rule ID: SV-50297r1_rule Vuln<br />

ID: V-38496<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

Disabling authentication for default system accounts<br />

makes it more difficult for attackers to make use of them<br />

to compromise a system.<br />

Documentable: No<br />

Check Content:<br />

To obtain a listing of all users and the contents of their<br />

shadow password field, run the command:<br />

$ awk -F: '{print $1 ":" $2}' /etc/shadow<br />

Identify the system accounts from this listing. These<br />

will primarily be the accounts with UID numbers less than<br />

500, other than root.<br />

If any system account (other than root) has a valid<br />

password hash, this is a finding.<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Fix Text:<br />

Some accounts are not associated with a human user of the<br />

system, and exist to perform some administrative<br />

function. An attacker should not be able to log into these<br />

accounts.<br />

Disable login access to these accounts with the command:<br />

# passwd -l [SYSACCT]<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: The system must not have accounts configured<br />

with blank or null passwords.<br />

<strong>STIG</strong> ID: RHEL-06-000030 Rule ID: SV-50298r1_rule Vuln<br />

ID: V-38497<br />

Severity: CAT I Class: Unclass<br />

Discussion:<br />

If an account has an empty password, anyone could log in<br />

and run commands with the privileges of that account.<br />

Accounts with empty passwords should never be used in<br />

operational environments.<br />

Documentable: No<br />

Check Content:<br />

To verify that null passwords cannot be used, run the<br />

following command:<br />

# grep nullok /etc/pam.d/system-auth<br />

/etc/pam.d/system-auth-ac<br />

If this produces any output, it may be possible to log<br />

into accounts with empty passwords.<br />

UNCLASSIFIED


UNCLASSIFIED<br />

If NULL passwords can be used, this is a finding.<br />

Fix Text:<br />

If an account is configured for password authentication<br />

but does not have an assigned password, it may be possible<br />

to log into the account without authentication. Remove<br />

any instances of the "nullok" option in<br />

"/etc/pam.d/system-auth-ac" to prevent logins with empty<br />

passwords.<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: The /etc/passwd file must not contain<br />

password hashes.<br />

<strong>STIG</strong> ID: RHEL-06-000031 Rule ID: SV-50300r1_rule Vuln<br />

ID: V-38499<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

The hashes for all user account passwords should be stored<br />

in the file "/etc/shadow" and never in "/etc/passwd",<br />

which is readable by all users.<br />

Documentable: No<br />

Check Content:<br />

To check that no password hashes are stored in<br />

"/etc/passwd", run the following command:<br />

# awk -F: '($2 != "x") {print}' /etc/passwd<br />

If it produces any output, then a password hash is stored<br />

in "/etc/passwd".<br />

If any stored hashes are found in /etc/passwd, this is<br />

a finding.<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Fix Text:<br />

If any password hashes are stored in "/etc/passwd" (in<br />

the second field, instead of an "x"), the cause of this<br />

misconfiguration should be investigated. The account<br />

should have its password reset and the hash should be<br />

properly stored, or the account should be deleted<br />

entirely.<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: The root account must be the only account<br />

having a UID of 0.<br />

<strong>STIG</strong> ID: RHEL-06-000032 Rule ID: SV-50301r1_rule Vuln<br />

ID: V-38500<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

An account has root authority if it has a UID of 0.<br />

Multiple accounts with a UID of 0 afford more opportunity<br />

for potential intruders to guess a password for a<br />

privileged account. Proper configuration of sudo is<br />

recommended to afford multiple system administrators<br />

access to root privileges in an accountable manner.<br />

Documentable: No<br />

Check Content:<br />

To list all password file entries for accounts with UID<br />

0, run the following command:<br />

# awk -F: '($3 == "0") {print}' /etc/passwd<br />

This should print only one line, for the user root.<br />

If any account other than root has a UID of 0, this is<br />

a finding.<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Fix Text:<br />

If any account other than root has a UID of 0, this<br />

misconfiguration should be investigated and the accounts<br />

other than root should be removed or have their UID<br />

changed.<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: The /etc/shadow file must be owned by root.<br />

<strong>STIG</strong> ID: RHEL-06-000033 Rule ID: SV-50303r1_rule Vuln<br />

ID: V-38502<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

The "/etc/shadow" file contains the list of local system<br />

accounts and stores password hashes. Protection of this<br />

file is critical for system security. Failure to give<br />

ownership of this file to root provides the designated<br />

owner with access to sensitive information which could<br />

weaken the system security posture.<br />

Documentable: No<br />

Check Content:<br />

To check the ownership of "/etc/shadow", run the command:<br />

$ ls -l /etc/shadow<br />

If properly configured, the output should indicate the<br />

following owner: "root"<br />

If it does not, this is a finding.<br />

Fix Text:<br />

To properly set the owner of "/etc/shadow", run the<br />

command:<br />

UNCLASSIFIED


UNCLASSIFIED<br />

# chown root /etc/shadow<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: The /etc/shadow file must be group-owned by<br />

root.<br />

<strong>STIG</strong> ID: RHEL-06-000034 Rule ID: SV-50304r1_rule Vuln<br />

ID: V-38503<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

The "/etc/shadow" file stores password hashes.<br />

Protection of this file is critical for system security.<br />

Documentable: No<br />

Check Content:<br />

To check the group ownership of "/etc/shadow", run the<br />

command:<br />

$ ls -l /etc/shadow<br />

If properly configured, the output should indicate the<br />

following group-owner. "root"<br />

If it does not, this is a finding.<br />

Fix Text:<br />

To properly set the group owner of "/etc/shadow", run the<br />

command:<br />

# chgrp root /etc/shadow<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Rule Title: The /etc/shadow file must have mode 0000.<br />

<strong>STIG</strong> ID: RHEL-06-000035 Rule ID: SV-50305r1_rule Vuln<br />

ID: V-38504<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

The "/etc/shadow" file contains the list of local system<br />

accounts and stores password hashes. Protection of this<br />

file is critical for system security. Failure to give<br />

ownership of this file to root provides the designated<br />

owner with access to sensitive information which could<br />

weaken the system security posture.<br />

Documentable: No<br />

Check Content:<br />

To check the permissions of "/etc/shadow", run the<br />

command:<br />

$ ls -l /etc/shadow<br />

If properly configured, the output should indicate the<br />

following permissions: "----------"<br />

If it does not, this is a finding.<br />

Fix Text:<br />

To properly set the permissions of "/etc/shadow", run the<br />

command:<br />

# chmod 0000 /etc/shadow<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: The /etc/gshadow file must be owned by root.<br />

UNCLASSIFIED


UNCLASSIFIED<br />

<strong>STIG</strong> ID: RHEL-06-000036 Rule ID: SV-50243r1_rule Vuln<br />

ID: V-38443<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

The "/etc/gshadow" file contains group password hashes.<br />

Protection of this file is critical for system security.<br />

Documentable: No<br />

Check Content:<br />

To check the ownership of "/etc/gshadow", run the<br />

command:<br />

$ ls -l /etc/gshadow<br />

If properly configured, the output should indicate the<br />

following owner: "root"<br />

If it does not, this is a finding.<br />

Fix Text:<br />

To properly set the owner of "/etc/gshadow", run the<br />

command:<br />

# chown root /etc/gshadow<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: The /etc/gshadow file must be group-owned<br />

by root.<br />

<strong>STIG</strong> ID: RHEL-06-000037 Rule ID: SV-50248r1_rule Vuln<br />

ID: V-38448<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

UNCLASSIFIED


UNCLASSIFIED<br />

The "/etc/gshadow" file contains group password hashes.<br />

Protection of this file is critical for system security.<br />

Documentable: No<br />

Check Content:<br />

To check the group ownership of "/etc/gshadow", run the<br />

command:<br />

$ ls -l /etc/gshadow<br />

If properly configured, the output should indicate the<br />

following group-owner. "root"<br />

If it does not, this is a finding.<br />

Fix Text:<br />

To properly set the group owner of "/etc/gshadow", run<br />

the command:<br />

# chgrp root /etc/gshadow<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: The /etc/gshadow file must have mode 0000.<br />

<strong>STIG</strong> ID: RHEL-06-000038 Rule ID: SV-50249r1_rule Vuln<br />

ID: V-38449<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

The /etc/gshadow file contains group password hashes.<br />

Protection of this file is critical for system security.<br />

Documentable: No<br />

Check Content:<br />

To check the permissions of "/etc/gshadow", run the<br />

UNCLASSIFIED


UNCLASSIFIED<br />

command:<br />

$ ls -l /etc/gshadow<br />

If properly configured, the output should indicate the<br />

following permissions: "----------"<br />

If it does not, this is a finding.<br />

Fix Text:<br />

To properly set the permissions of "/etc/gshadow", run<br />

the command:<br />

# chmod 0000 /etc/gshadow<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: The /etc/passwd file must be owned by root.<br />

<strong>STIG</strong> ID: RHEL-06-000039 Rule ID: SV-50250r1_rule Vuln<br />

ID: V-38450<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

The "/etc/passwd" file contains information about the<br />

users that are configured on the system. Protection of<br />

this file is critical for system security.<br />

Documentable: No<br />

Check Content:<br />

To check the ownership of "/etc/passwd", run the command:<br />

$ ls -l /etc/passwd<br />

If properly configured, the output should indicate the<br />

following owner: "root"<br />

If it does not, this is a finding.<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Fix Text:<br />

To properly set the owner of "/etc/passwd", run the<br />

command:<br />

# chown root /etc/passwd<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: The /etc/passwd file must be group-owned by<br />

root.<br />

<strong>STIG</strong> ID: RHEL-06-000040 Rule ID: SV-50251r1_rule Vuln<br />

ID: V-38451<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

The "/etc/passwd" file contains information about the<br />

users that are configured on the system. Protection of<br />

this file is critical for system security.<br />

Documentable: No<br />

Check Content:<br />

To check the group ownership of "/etc/passwd", run the<br />

command:<br />

$ ls -l /etc/passwd<br />

If properly configured, the output should indicate the<br />

following group-owner. "root"<br />

If it does not, this is a finding.<br />

Fix Text:<br />

To properly set the group owner of "/etc/passwd", run the<br />

command:<br />

UNCLASSIFIED


UNCLASSIFIED<br />

# chgrp root /etc/passwd<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: The /etc/passwd file must have mode 0644 or<br />

less permissive.<br />

<strong>STIG</strong> ID: RHEL-06-000041 Rule ID: SV-50257r1_rule Vuln<br />

ID: V-38457<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

If the "/etc/passwd" file is writable by a group-owner<br />

or the world the risk of its compromise is increased. The<br />

file contains the list of accounts on the system and<br />

associated information, and protection of this file is<br />

critical for system security.<br />

Documentable: No<br />

Check Content:<br />

To check the permissions of "/etc/passwd", run the<br />

command:<br />

$ ls -l /etc/passwd<br />

If properly configured, the output should indicate the<br />

following permissions: "-rw-r--r--"<br />

If it does not, this is a finding.<br />

Fix Text:<br />

To properly set the permissions of "/etc/passwd", run the<br />

command:<br />

# chmod 0644 /etc/passwd<br />

CCI: CCI-000366<br />

UNCLASSIFIED


UNCLASSIFIED<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: The /etc/group file must be owned by root.<br />

<strong>STIG</strong> ID: RHEL-06-000042 Rule ID: SV-50258r1_rule Vuln<br />

ID: V-38458<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

The "/etc/group" file contains information regarding<br />

groups that are configured on the system. Protection of<br />

this file is important for system security.<br />

Documentable: No<br />

Check Content:<br />

To check the ownership of "/etc/group", run the command:<br />

$ ls -l /etc/group<br />

If properly configured, the output should indicate the<br />

following owner: "root"<br />

If it does not, this is a finding.<br />

Fix Text:<br />

To properly set the owner of "/etc/group", run the<br />

command:<br />

# chown root /etc/group<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: The /etc/group file must be group-owned by<br />

root.<br />

UNCLASSIFIED


UNCLASSIFIED<br />

<strong>STIG</strong> ID: RHEL-06-000043 Rule ID: SV-50259r1_rule Vuln<br />

ID: V-38459<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

The "/etc/group" file contains information regarding<br />

groups that are configured on the system. Protection of<br />

this file is important for system security.<br />

Documentable: No<br />

Check Content:<br />

To check the group ownership of "/etc/group", run the<br />

command:<br />

$ ls -l /etc/group<br />

If properly configured, the output should indicate the<br />

following group-owner. "root"<br />

If it does not, this is a finding.<br />

Fix Text:<br />

To properly set the group owner of "/etc/group", run the<br />

command:<br />

# chgrp root /etc/group<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: The /etc/group file must have mode 0644 or<br />

less permissive.<br />

<strong>STIG</strong> ID: RHEL-06-000044 Rule ID: SV-50261r1_rule Vuln<br />

ID: V-38461<br />

Severity: CAT II Class: Unclass<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Discussion:<br />

The "/etc/group" file contains information regarding<br />

groups that are configured on the system. Protection of<br />

this file is important for system security.<br />

Documentable: No<br />

Check Content:<br />

To check the permissions of "/etc/group", run the<br />

command:<br />

$ ls -l /etc/group<br />

If properly configured, the output should indicate the<br />

following permissions: "-rw-r--r--"<br />

If it does not, this is a finding.<br />

Fix Text:<br />

To properly set the permissions of "/etc/group", run the<br />

command:<br />

# chmod 644 /etc/group<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: Library files must have mode 0755 or less<br />

permissive.<br />

<strong>STIG</strong> ID: RHEL-06-000045 Rule ID: SV-50265r1_rule Vuln<br />

ID: V-38465<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

Files from shared library directories are loaded into the<br />

address space of processes (including privileged ones)<br />

or of the kernel itself at runtime. Restrictive<br />

permissions are necessary to protect the integrity of the<br />

UNCLASSIFIED


UNCLASSIFIED<br />

system.<br />

Documentable: No<br />

Check Content:<br />

System-wide shared library files, which are linked to<br />

executables during process load time or run time, are<br />

stored in the following directories by default:<br />

/lib<br />

/lib64<br />

/usr/lib<br />

/usr/lib64<br />

Kernel modules, which can be added to the kernel during<br />

runtime, are stored in "/lib/modules". All files in these<br />

directories should not be group-writable or<br />

world-writable. To find shared libraries that are<br />

group-writable or world-writable, run the following<br />

command for each directory [DIR] which contains shared<br />

libraries:<br />

$ find -L [DIR] -perm /022<br />

If any of these files are group-writable or<br />

world-writable, this is a finding.<br />

Fix Text:<br />

System-wide shared library files, which are linked to<br />

executables during process load time or run time, are<br />

stored in the following directories by default:<br />

/lib<br />

/lib64<br />

/usr/lib<br />

/usr/lib64<br />

If any file in these directories is found to be<br />

UNCLASSIFIED


UNCLASSIFIED<br />

group-writable or world-writeable correct its permission<br />

with the following command:<br />

# chmod go-w [FILE]<br />

CCI: CCI-001499<br />

NIST SP 800-53 :: CM-5 (6)<br />

NIST SP 800-53A :: CM-5 (6).1<br />

Rule Title: Library files must be owned by root.<br />

<strong>STIG</strong> ID: RHEL-06-000046 Rule ID: SV-50266r1_rule Vuln<br />

ID: V-38466<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

Files from shared library directories are loaded into the<br />

address space of processes (including privileged ones)<br />

or of the kernel itself at runtime. Proper ownership is<br />

necessary to protect the integrity of the system.<br />

Documentable: No<br />

Check Content:<br />

System-wide shared library files, which are linked to<br />

executables during process load time or run time, are<br />

stored in the following directories by default:<br />

/lib<br />

/lib64<br />

/usr/lib<br />

/usr/lib64<br />

Kernel modules, which can be added to the kernel during<br />

runtime, are stored in "/lib/modules". All files in these<br />

directories should not be group-writable or<br />

world-writable. To find shared libraries that are not<br />

owned by "root", run the following command for each<br />

UNCLASSIFIED


UNCLASSIFIED<br />

directory [DIR] which contains shared libraries:<br />

$ find -L [DIR] \! -user root<br />

If any of these files are not owned by root, this is a<br />

finding.<br />

Fix Text:<br />

System-wide shared library files, which are linked to<br />

executables during process load time or run time, are<br />

stored in the following directories by default:<br />

/lib<br />

/lib64<br />

/usr/lib<br />

/usr/lib64<br />

If any file in these directories is found to be owned by<br />

a user other than root, correct its ownership with the<br />

following command:<br />

# chown root [FILE]<br />

CCI: CCI-001499<br />

NIST SP 800-53 :: CM-5 (6)<br />

NIST SP 800-53A :: CM-5 (6).1<br />

Rule Title: All system command files must have mode 0755<br />

or less permissive.<br />

<strong>STIG</strong> ID: RHEL-06-000047 Rule ID: SV-50269r1_rule Vuln<br />

ID: V-38469<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

System binaries are executed by privileged users, as well<br />

as system services, and restrictive permissions are<br />

necessary to ensure execution of these programs cannot<br />

UNCLASSIFIED


UNCLASSIFIED<br />

be co-opted.<br />

Documentable: No<br />

Check Content:<br />

System executables are stored in the following<br />

directories by default:<br />

/bin<br />

/usr/bin<br />

/usr/local/bin<br />

/sbin<br />

/usr/sbin<br />

/usr/local/sbin<br />

All files in these directories should not be<br />

group-writable or world-writable. To find system<br />

executables that are group-writable or world-writable,<br />

run the following command for each directory [DIR] which<br />

contains system executables:<br />

$ find -L [DIR] -perm /022<br />

If any system executables are found to be group-writable<br />

or world-writable, this is a finding.<br />

Fix Text:<br />

System executables are stored in the following<br />

directories by default:<br />

/bin<br />

/usr/bin<br />

/usr/local/bin<br />

/sbin<br />

/usr/sbin<br />

/usr/local/sbin<br />

If any file in these directories is found to be<br />

group-writable or world-writable, correct its permission<br />

UNCLASSIFIED


UNCLASSIFIED<br />

with the following command:<br />

# chmod go-w [FILE]<br />

CCI: CCI-001499<br />

NIST SP 800-53 :: CM-5 (6)<br />

NIST SP 800-53A :: CM-5 (6).1<br />

Rule Title: All system command files must be owned by<br />

root.<br />

<strong>STIG</strong> ID: RHEL-06-000048 Rule ID: SV-50272r1_rule Vuln<br />

ID: V-38472<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

System binaries are executed by privileged users as well<br />

as system services, and restrictive permissions are<br />

necessary to ensure that their execution of these<br />

programs cannot be co-opted.<br />

Documentable: No<br />

Check Content:<br />

System executables are stored in the following<br />

directories by default:<br />

/bin<br />

/usr/bin<br />

/usr/local/bin<br />

/sbin<br />

/usr/sbin<br />

/usr/local/sbin<br />

All files in these directories should not be<br />

group-writable or world-writable. To find system<br />

executables that are not owned by "root", run the<br />

following command for each directory [DIR] which contains<br />

system executables:<br />

UNCLASSIFIED


UNCLASSIFIED<br />

$ find -L [DIR] \! -user root<br />

If any system executables are found to not be owned by<br />

root, this is a finding.<br />

Fix Text:<br />

System executables are stored in the following<br />

directories by default:<br />

/bin<br />

/usr/bin<br />

/usr/local/bin<br />

/sbin<br />

/usr/sbin<br />

/usr/local/sbin<br />

If any file [FILE] in these directories is found to be<br />

owned by a user other than root, correct its ownership<br />

with the following command:<br />

# chown root [FILE]<br />

CCI: CCI-001499<br />

NIST SP 800-53 :: CM-5 (6)<br />

NIST SP 800-53A :: CM-5 (6).1<br />

Rule Title: The system must require passwords to contain<br />

a minimum of 14 characters.<br />

<strong>STIG</strong> ID: RHEL-06-000050 Rule ID: SV-50275r1_rule Vuln<br />

ID: V-38475<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

Requiring a minimum password length makes password<br />

cracking attacks more difficult by ensuring a larger<br />

search space. However, any security benefit from an<br />

UNCLASSIFIED


UNCLASSIFIED<br />

onerous requirement must be carefully weighed against<br />

usability problems, support costs, or counterproductive<br />

behavior that may result.<br />

While it does not negate the password length requirement,<br />

it is preferable to migrate from a password-based<br />

authentication scheme to a stronger one based on PKI<br />

(public key infrastructure).<br />

Documentable: No<br />

Check Content:<br />

To check the minimum password length, run the command:<br />

$ grep PASS_MIN_LEN /etc/login.defs<br />

The DoD requirement is "14".<br />

If it is not set to the required value, this is a finding.<br />

Fix Text:<br />

To specify password length requirements for new accounts,<br />

edit the file "/etc/login.defs" and add or correct the<br />

following lines:<br />

PASS_MIN_LEN 14<br />

The DoD requirement is "14". If a program consults<br />

"/etc/login.defs" and also another PAM module (such as<br />

"pam_cracklib") during a password change operation, then<br />

the most restrictive must be satisfied.<br />

CCI: CCI-000205<br />

NIST SP 800-53A :: IA-5 (1).1 (i)<br />

NIST SP 800-53 :: IA-5 (1) (a)<br />

Rule Title: Users must not be able to change passwords<br />

more than once every 24 hours.<br />

UNCLASSIFIED


UNCLASSIFIED<br />

<strong>STIG</strong> ID: RHEL-06-000051 Rule ID: SV-50277r1_rule Vuln<br />

ID: V-38477<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

Setting the minimum password age protects against users<br />

cycling back to a favorite password after satisfying the<br />

password reuse requirement.<br />

Documentable: No<br />

Check Content:<br />

To check the minimum password age, run the command:<br />

$ grep PASS_MIN_DAYS /etc/login.defs<br />

The DoD requirement is 1.<br />

If it is not set to the required value, this is a finding.<br />

Fix Text:<br />

To specify password minimum age for new accounts, edit<br />

the file "/etc/login.defs" and add or correct the<br />

following line, replacing [DAYS] appropriately:<br />

PASS_MIN_DAYS [DAYS]<br />

A value of 1 day is considered sufficient for many<br />

environments. The DoD requirement is 1.<br />

CCI: CCI-000198<br />

NIST SP 800-53A :: IA-5 (1).1 (v)<br />

NIST SP 800-53 :: IA-5 (1) (d)<br />

Rule Title: User passwords must be changed at least<br />

every 60 days.<br />

<strong>STIG</strong> ID: RHEL-06-000053 Rule ID: SV-50279r1_rule Vuln<br />

ID: V-38479<br />

Severity: CAT II Class: Unclass<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Discussion:<br />

Setting the password maximum age ensures users are<br />

required to periodically change their passwords. This<br />

could possibly decrease the utility of a stolen password.<br />

Requiring shorter password lifetimes increases the risk<br />

of users writing down the password in a convenient<br />

location subject to physical compromise.<br />

Documentable: No<br />

Check Content:<br />

To check the maximum password age, run the command:<br />

$ grep PASS_MAX_DAYS /etc/login.defs<br />

The DoD requirement is 60.<br />

If it is not set to the required value, this is a finding.<br />

Fix Text:<br />

To specify password maximum age for new accounts, edit<br />

the file "/etc/login.defs" and add or correct the<br />

following line, replacing [DAYS] appropriately:<br />

PASS_MAX_DAYS [DAYS]<br />

The DoD requirement is 60.<br />

CCI: CCI-000199<br />

NIST SP 800-53A :: IA-5 (1).1 (v)<br />

NIST SP 800-53 :: IA-5 (1) (d)<br />

Rule Title: Users must be warned 7 days in advance of<br />

password expiration.<br />

<strong>STIG</strong> ID: RHEL-06-000054 Rule ID: SV-50280r1_rule Vuln<br />

ID: V-38480<br />

Severity: CAT III Class: Unclass<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Discussion:<br />

Setting the password warning age enables users to make<br />

the change at a practical time.<br />

Documentable: No<br />

Check Content:<br />

To check the password warning age, run the command:<br />

$ grep PASS_WARN_AGE /etc/login.defs<br />

The DoD requirement is 7.<br />

If it is not set to the required value, this is a finding.<br />

Fix Text:<br />

To specify how many days prior to password expiration that<br />

a warning will be issued to users, edit the file<br />

"/etc/login.defs" and add or correct the following line,<br />

replacing [DAYS] appropriately:<br />

PASS_WARN_AGE [DAYS]<br />

The DoD requirement is 7.<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: The system must require passwords to contain<br />

at least one numeric character.<br />

<strong>STIG</strong> ID: RHEL-06-000056 Rule ID: SV-50282r1_rule Vuln<br />

ID: V-38482<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

Requiring digits makes password guessing attacks more<br />

difficult by ensuring a larger search space.<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Documentable: No<br />

Check Content:<br />

To check how many digits are required in a password, run<br />

the following command:<br />

$ grep pam_cracklib /etc/pam.d/system-auth<br />

The "dcredit" parameter (as a negative number) will<br />

indicate how many digits are required. The DoD requires<br />

at least one digit in a password. This would appear as<br />

"dcredit=-1".<br />

If dcredit is not found or not set to the required value,<br />

this is a finding.<br />

Fix Text:<br />

The pam_cracklib module's "dcredit" parameter controls<br />

requirements for usage of digits in a password. When set<br />

to a negative number, any password will be required to<br />

contain that many digits. When set to a positive number,<br />

pam_cracklib will grant +1 additional length credit for<br />

each digit. Add "dcredit=-1" after pam_cracklib.so to<br />

require use of a digit in passwords.<br />

CCI: CCI-000194<br />

NIST SP 800-53A :: IA-5 (1).1 (v)<br />

NIST SP 800-53 :: IA-5 (1) (a)<br />

Rule Title: The system must require passwords to contain<br />

at least one uppercase alphabetic character.<br />

<strong>STIG</strong> ID: RHEL-06-000057 Rule ID: SV-50370r1_rule Vuln<br />

ID: V-38569<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

Requiring a minimum number of uppercase characters makes<br />

password guessing attacks more difficult by ensuring a<br />

UNCLASSIFIED


UNCLASSIFIED<br />

larger search space.<br />

Documentable: No<br />

Check Content:<br />

To check how many uppercase characters are required in<br />

a password, run the following command:<br />

$ grep pam_cracklib /etc/pam.d/system-auth<br />

The "ucredit" parameter (as a negative number) will<br />

indicate how many uppercase characters are required. The<br />

DoD requires at least one uppercase character in a<br />

password. This would appear as "ucredit=-1".<br />

If ucredit is not found or not set to the required value,<br />

this is a finding.<br />

Fix Text:<br />

The pam_cracklib module's "ucredit=" parameter controls<br />

requirements for usage of uppercase letters in a<br />

password. When set to a negative number, any password will<br />

be required to contain that many uppercase characters.<br />

When set to a positive number, pam_cracklib will grant<br />

+1 additional length credit for each uppercase character.<br />

Add "ucredit=-1" after pam_cracklib.so to require use of<br />

an uppercase character in passwords.<br />

CCI: CCI-000192<br />

NIST SP 800-53A :: IA-5 (1).1 (v)<br />

NIST SP 800-53 :: IA-5 (1) (a)<br />

Rule Title: The system must require passwords to contain<br />

at least one special character.<br />

<strong>STIG</strong> ID: RHEL-06-000058 Rule ID: SV-50371r1_rule Vuln<br />

ID: V-38570<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Requiring a minimum number of special characters makes<br />

password guessing attacks more difficult by ensuring a<br />

larger search space.<br />

Documentable: No<br />

Check Content:<br />

To check how many special characters are required in a<br />

password, run the following command:<br />

$ grep pam_cracklib /etc/pam.d/system-auth<br />

The "ocredit" parameter (as a negative number) will<br />

indicate how many special characters are required. The<br />

DoD requires at least one special character in a password.<br />

This would appear as "ocredit=-1".<br />

If ocredit is not found or not set to the required value,<br />

this is a finding.<br />

Fix Text:<br />

The pam_cracklib module's "ocredit=" parameter controls<br />

requirements for usage of special (or ``other'')<br />

characters in a password. When set to a negative number,<br />

any password will be required to contain that many special<br />

characters. When set to a positive number, pam_cracklib<br />

will grant +1 additional length credit for each special<br />

character. Add "ocredit=-1" after pam_cracklib.so to<br />

require use of a special character in passwords.<br />

CCI: CCI-001619<br />

NIST SP 800-53 :: IA-5 (1) (a)<br />

NIST SP 800-53A :: IA-5 (1).1 (v)<br />

Rule Title: The system must require passwords to contain<br />

at least one lowercase alphabetic character.<br />

<strong>STIG</strong> ID: RHEL-06-000059 Rule ID: SV-50372r1_rule Vuln<br />

ID: V-38571<br />

Severity: CAT III Class: Unclass<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Discussion:<br />

Requiring a minimum number of lowercase characters makes<br />

password guessing attacks more difficult by ensuring a<br />

larger search space.<br />

Documentable: No<br />

Check Content:<br />

To check how many lowercase characters are required in<br />

a password, run the following command:<br />

$ grep pam_cracklib /etc/pam.d/system-auth<br />

The "lcredit" parameter (as a negative number) will<br />

indicate how many special characters are required. The<br />

DoD requires at least one lowercase character in a<br />

password. This would appear as "lcredit=-1".<br />

If lcredit is not found or not set to the required value,<br />

this is a finding.<br />

Fix Text:<br />

The pam_cracklib module's "lcredit=" parameter controls<br />

requirements for usage of lowercase letters in a<br />

password. When set to a negative number, any password will<br />

be required to contain that many lowercase characters.<br />

When set to a positive number, pam_cracklib will grant<br />

+1 additional length credit for each lowercase character.<br />

Add "lcredit=-1" after pam_cracklib.so to require use of<br />

a lowercase character in passwords.<br />

CCI: CCI-000193<br />

NIST SP 800-53A :: IA-5 (1).1 (v)<br />

NIST SP 800-53 :: IA-5 (1) (a)<br />

Rule Title: The system must require at least four<br />

characters be changed between the old and new passwords<br />

during a password change.<br />

<strong>STIG</strong> ID: RHEL-06-000060 Rule ID: SV-50373r1_rule Vuln<br />

UNCLASSIFIED


UNCLASSIFIED<br />

ID: V-38572<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

Requiring a minimum number of different characters during<br />

password changes ensures that newly changed passwords<br />

should not resemble previously compromised ones. Note<br />

that passwords which are changed on compromised systems<br />

will still be compromised, however.<br />

Documentable: No<br />

Check Content:<br />

To check how many characters must differ during a password<br />

change, run the following command:<br />

$ grep pam_cracklib /etc/pam.d/system-auth<br />

The "difok" parameter will indicate how many characters<br />

must differ. The DoD requires four characters differ<br />

during a password change. This would appear as "difok=4".<br />

If difok is not found or not set to the required value,<br />

this is a finding.<br />

Fix Text:<br />

The pam_cracklib module's "difok" parameter controls<br />

requirements for usage of different characters during a<br />

password change. Add "difok=[NUM]" after pam_cracklib.so<br />

to require differing characters when changing passwords,<br />

substituting [NUM] appropriately. The DoD requirement is<br />

4.<br />

CCI: CCI-000195<br />

NIST SP 800-53A :: IA-5 (1).1 (v)<br />

NIST SP 800-53 :: IA-5 (1) (b)<br />

Rule Title: The system must disable accounts after three<br />

consecutive unsuccessful login attempts.<br />

UNCLASSIFIED


UNCLASSIFIED<br />

<strong>STIG</strong> ID: RHEL-06-000061 Rule ID: SV-50374r1_rule Vuln<br />

ID: V-38573<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

Locking out user accounts after a number of incorrect<br />

attempts prevents direct password guessing attacks.<br />

Documentable: No<br />

Check Content:<br />

To ensure the failed password attempt policy is<br />

configured correctly, run the following command:<br />

# grep pam_faillock /etc/pam.d/system-auth-ac<br />

The output should show "deny=3".<br />

If that is not the case, this is a finding.<br />

Fix Text:<br />

To configure the system to lock out accounts after a<br />

number of incorrect login attempts using<br />

"pam_faillock.so":<br />

Add the following lines immediately below the<br />

"pam_unix.so" statement in the AUTH section of<br />

"/etc/pam.d/system-auth-ac":<br />

auth [default=die] pam_faillock.so authfail deny=3<br />

unlock_time=604800 fail_interval=900<br />

auth required pam_faillock.so authsucc deny=3<br />

unlock_time=604800 fail_interval=900<br />

Note that any updates made to<br />

"/etc/pam.d/system-auth-ac" will be overwritten by the<br />

"authconfig" program. The "authconfig" program should<br />

not be used.<br />

UNCLASSIFIED


UNCLASSIFIED<br />

CCI: CCI-000044<br />

NIST SP 800-53 :: AC-7 a<br />

NIST SP 800-53A :: AC-7.1 (ii)<br />

Rule Title: The system must use a FIPS 140-2 approved<br />

cryptographic hashing algorithm for generating account<br />

password hashes (system-auth).<br />

<strong>STIG</strong> ID: RHEL-06-000062 Rule ID: SV-50375r1_rule Vuln<br />

ID: V-38574<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

Using a stronger hashing algorithm makes password<br />

cracking attacks more difficult.<br />

Documentable: No<br />

Check Content:<br />

Inspect the "password" section of<br />

"/etc/pam.d/system-auth" and ensure that the<br />

"pam_unix.so" module includes the argument "sha512".<br />

$ grep sha512 /etc/pam.d/system-auth"<br />

If it does not, this is a finding.<br />

Fix Text:<br />

In "/etc/pam.d/system-auth", the "password" section of<br />

the file controls which PAM modules execute during a<br />

password change. Set the "pam_unix.so" module in the<br />

"password" section to include the argument "sha512", as<br />

shown below:<br />

password sufficient pam_unix.so sha512 [other<br />

arguments...]<br />

This will help ensure when local users change their<br />

UNCLASSIFIED


UNCLASSIFIED<br />

passwords, hashes for the new passwords will be generated<br />

using the SHA-512 algorithm. This is the default.<br />

Note that any updates made to "/etc/pam.d/system-auth"<br />

will be overwritten by the "authconfig" program. The<br />

"authconfig" program should not be used.<br />

CCI: CCI-000803<br />

NIST SP 800-53A :: IA-7.1<br />

NIST SP 800-53 :: IA-7<br />

Rule Title: The system must use a FIPS 140-2 approved<br />

cryptographic hashing algorithm for generating account<br />

password hashes (login.defs).<br />

<strong>STIG</strong> ID: RHEL-06-000063 Rule ID: SV-50377r1_rule Vuln<br />

ID: V-38576<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

Using a stronger hashing algorithm makes password<br />

cracking attacks more difficult.<br />

Documentable: No<br />

Check Content:<br />

Inspect "/etc/login.defs" and ensure the following line<br />

appears:<br />

ENCRYPT_METHOD SHA512<br />

If it does not, this is a finding.<br />

Fix Text:<br />

In "/etc/login.defs", add or correct the following line<br />

to ensure the system will use SHA-512 as the hashing<br />

algorithm:<br />

UNCLASSIFIED


UNCLASSIFIED<br />

ENCRYPT_METHOD SHA512<br />

CCI: CCI-000803<br />

NIST SP 800-53A :: IA-7.1<br />

NIST SP 800-53 :: IA-7<br />

Rule Title: The system must use a FIPS 140-2 approved<br />

cryptographic hashing algorithm for generating account<br />

password hashes (libuser.conf).<br />

<strong>STIG</strong> ID: RHEL-06-000064 Rule ID: SV-50378r1_rule Vuln<br />

ID: V-38577<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

Using a stronger hashing algorithm makes password<br />

cracking attacks more difficult.<br />

Documentable: No<br />

Check Content:<br />

Inspect "/etc/libuser.conf" and ensure the following<br />

line appears in the "[default]" section:<br />

crypt_style = sha512<br />

If it does not, this is a finding.<br />

Fix Text:<br />

In "/etc/libuser.conf", add or correct the following line<br />

in its "[defaults]" section to ensure the system will use<br />

the SHA-512 algorithm for password hashing:<br />

crypt_style = sha512<br />

CCI: CCI-000803<br />

NIST SP 800-53A :: IA-7.1<br />

NIST SP 800-53 :: IA-7<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Rule Title: The system boot loader configuration<br />

file(s) must be owned by root.<br />

<strong>STIG</strong> ID: RHEL-06-000065 Rule ID: SV-50380r1_rule Vuln<br />

ID: V-38579<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

Only root should be able to modify important boot<br />

parameters.<br />

Documentable: No<br />

Check Content:<br />

To check the ownership of "/etc/grub.conf", run the<br />

command:<br />

$ ls -lL /etc/grub.conf<br />

If properly configured, the output should indicate the<br />

following owner: "root"<br />

If it does not, this is a finding.<br />

Fix Text:<br />

The file "/etc/grub.conf" should be owned by the "root"<br />

user to prevent destruction or modification of the file.<br />

To properly set the owner of "/etc/grub.conf", run the<br />

command:<br />

# chown root /etc/grub.conf<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: The system boot loader configuration<br />

UNCLASSIFIED


UNCLASSIFIED<br />

file(s) must be group-owned by root.<br />

<strong>STIG</strong> ID: RHEL-06-000066 Rule ID: SV-50382r1_rule Vuln<br />

ID: V-38581<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

The "root" group is a highly-privileged group.<br />

Furthermore, the group-owner of this file should not have<br />

any access privileges anyway.<br />

Documentable: No<br />

Check Content:<br />

To check the group ownership of "/etc/grub.conf", run the<br />

command:<br />

$ ls -lL /etc/grub.conf<br />

If properly configured, the output should indicate the<br />

following group-owner. "root"<br />

If it does not, this is a finding.<br />

Fix Text:<br />

The file "/etc/grub.conf" should be group-owned by the<br />

"root" group to prevent destruction or modification of<br />

the file. To properly set the group owner of<br />

"/etc/grub.conf", run the command:<br />

# chgrp root /etc/grub.conf<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: The system boot loader configuration<br />

file(s) must have mode 0600 or less permissive.<br />

<strong>STIG</strong> ID: RHEL-06-000067 Rule ID: SV-50384r1_rule Vuln<br />

ID: V-38583<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

Proper permissions ensure that only the root user can<br />

modify important boot parameters.<br />

Documentable: No<br />

Check Content:<br />

To check the permissions of "/etc/grub.conf", run the<br />

command:<br />

$ ls -lL /etc/grub.conf<br />

If properly configured, the output should indicate the<br />

following permissions: "-rw-------"<br />

If it does not, this is a finding.<br />

Fix Text:<br />

File permissions for "/etc/grub.conf" should be set to<br />

600, which is the default. To properly set the permissions<br />

of "/etc/grub.conf", run the command:<br />

# chmod 600 /etc/grub.conf<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: The system boot loader must require<br />

authentication.<br />

<strong>STIG</strong> ID: RHEL-06-000068 Rule ID: SV-50386r1_rule Vuln<br />

ID: V-38585<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

Password protection on the boot loader configuration<br />

UNCLASSIFIED


UNCLASSIFIED<br />

ensures users with physical access cannot trivially alter<br />

important bootloader settings. These include which<br />

kernel to use, and whether to enter single-user mode.<br />

Documentable: No<br />

Check Content:<br />

To verify the boot loader password has been set and<br />

encrypted, run the following command:<br />

# grep password /etc/grub.conf<br />

The output should show the following:<br />

password --encrypted "$6$[rest-of-the-password-hash]"<br />

If it does not, this is a finding.<br />

Fix Text:<br />

The grub boot loader should have password protection<br />

enabled to protect boot-time settings. To do so, select<br />

a password and then generate a hash from it by running<br />

the following command:<br />

# grub-crypt --sha-512<br />

When prompted to enter a password, insert the following<br />

line into "/etc/grub.conf" immediately after the header<br />

comments. (Use the output from "grub-crypt" as the value<br />

of [password-hash]):<br />

password --encrypted [password-hash]<br />

CCI: CCI-000213<br />

NIST SP 800-53A :: AC-3.1<br />

NIST SP 800-53 :: AC-3<br />

Rule Title: The system must require authentication upon<br />

UNCLASSIFIED


UNCLASSIFIED<br />

booting into single-user and maintenance modes.<br />

<strong>STIG</strong> ID: RHEL-06-000069 Rule ID: SV-50387r1_rule Vuln<br />

ID: V-38586<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

This prevents attackers with physical access from<br />

trivially bypassing security on the machine and gaining<br />

root access. Such accesses are further prevented by<br />

configuring the bootloader password.<br />

Documentable: No<br />

Check Content:<br />

To check if authentication is required for single-user<br />

mode, run the following command:<br />

$ grep SINGLE /etc/sysconfig/init<br />

The output should be the following:<br />

SINGLE=/sbin/sulogin<br />

If the output is different, this is a finding.<br />

Fix Text:<br />

Single-user mode is intended as a system recovery method,<br />

providing a single user root access to the system by<br />

providing a boot option at startup. By default, no<br />

authentication is performed if single-user mode is<br />

selected.<br />

To require entry of the root password even if the system<br />

is started in single-user mode, add or correct the<br />

following line in the file "/etc/sysconfig/init":<br />

SINGLE=/sbin/sulogin<br />

CCI: CCI-000213<br />

UNCLASSIFIED


UNCLASSIFIED<br />

NIST SP 800-53A :: AC-3.1<br />

NIST SP 800-53 :: AC-3<br />

Rule Title: The system must not permit interactive boot.<br />

<strong>STIG</strong> ID: RHEL-06-000070 Rule ID: SV-50389r1_rule Vuln<br />

ID: V-38588<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

Using interactive boot, the console user could disable<br />

auditing, firewalls, or other services, weakening system<br />

security.<br />

Documentable: No<br />

Check Content:<br />

To check whether interactive boot is disabled, run the<br />

following command:<br />

$ grep PROMPT /etc/sysconfig/init<br />

If interactive boot is disabled, the output will show:<br />

PROMPT=no<br />

If it does not, this is a finding.<br />

Fix Text:<br />

To disable the ability for users to perform interactive<br />

startups, edit the file "/etc/sysconfig/init". Add or<br />

correct the line:<br />

PROMPT=no<br />

The "PROMPT" option allows the console user to perform<br />

an interactive system startup, in which it is possible<br />

to select the set of services which are started on boot.<br />

UNCLASSIFIED


UNCLASSIFIED<br />

CCI: CCI-000213<br />

NIST SP 800-53A :: AC-3.1<br />

NIST SP 800-53 :: AC-3<br />

Rule Title: The system must allow locking of the console<br />

screen in text mode.<br />

<strong>STIG</strong> ID: RHEL-06-000071 Rule ID: SV-50391r1_rule Vuln<br />

ID: V-38590<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

Installing "screen" ensures a console locking capability<br />

is available for users who may need to suspend console<br />

logins.<br />

Documentable: No<br />

Check Content:<br />

Run the following command to determine if the "screen"<br />

package is installed:<br />

# rpm -q screen<br />

If the package is not installed, this is a finding.<br />

Fix Text:<br />

To enable console screen locking when in text mode,<br />

install the "screen" package:<br />

# yum install screen<br />

Instruct users to begin new terminal sessions with the<br />

following command:<br />

$ screen<br />

UNCLASSIFIED


UNCLASSIFIED<br />

The console can now be locked with the following key<br />

combination:<br />

ctrl+a x<br />

CCI: CCI-000058<br />

NIST SP 800-53 :: AC-11 a<br />

NIST SP 800-53A :: AC-11<br />

Rule Title: The Department of Defense (DoD) login banner<br />

must be displayed immediately prior to, or as part of,<br />

console login prompts.<br />

<strong>STIG</strong> ID: RHEL-06-000073 Rule ID: SV-50394r1_rule Vuln<br />

ID: V-38593<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

An appropriate warning message reinforces policy<br />

awareness during the logon process and facilitates<br />

possible legal action against attackers.<br />

Documentable: No<br />

Check Content:<br />

To check if the system login banner is compliant, run the<br />

following command:<br />

$ cat /etc/issue<br />

If it does not display the required banner, this is a<br />

finding.<br />

Fix Text:<br />

To configure the system login banner:<br />

Edit "/etc/issue". Replace the default text with a<br />

message compliant with the local site policy or a legal<br />

UNCLASSIFIED


UNCLASSIFIED<br />

disclaimer. The DoD required text is either:<br />

"You are accessing a U.S. Government (USG) Information<br />

System (IS) that is provided for USG-authorized use only.<br />

By using this IS (which includes any device attached to<br />

this IS), you consent to the following conditions:<br />

-The USG routinely intercepts and monitors<br />

communications on this IS for purposes including, but not<br />

limited to, penetration testing, COMSEC monitoring,<br />

network operations and defense, personnel misconduct<br />

(PM), law enforcement (LE), and counterintelligence (CI)<br />

investigations.<br />

-At any time, the USG may inspect and seize data stored<br />

on this IS.<br />

-Communications using, or data stored on, this IS are not<br />

private, are subject to routine monitoring,<br />

interception, and search, and may be disclosed or used<br />

for any USG-authorized purpose.<br />

-This IS includes security measures (e.g.,<br />

authentication and access controls) to protect USG<br />

interests -- not for your personal benefit or privacy.<br />

-Notwithstanding the above, using this IS does not<br />

constitute consent to PM, LE or CI investigative<br />

searching or monitoring of the content of privileged<br />

communications, or work product, related to personal<br />

representation or services by attorneys,<br />

psychotherapists, or clergy, and their assistants. Such<br />

communications and work product are private and<br />

confidential. See User Agreement for details."<br />

OR:<br />

"I've read & consent to terms in IS user agreem't."<br />

CCI: CCI-001384<br />

NIST SP 800-53 :: AC-8 c<br />

NIST SP 800-53A :: AC-8.2 (i)<br />

CCI: CCI-001385<br />

NIST SP 800-53 :: AC-8 c<br />

UNCLASSIFIED


UNCLASSIFIED<br />

NIST SP 800-53A :: AC-8.2 (ii)<br />

CCI: CCI-001386<br />

NIST SP 800-53 :: AC-8 c<br />

NIST SP 800-53A :: AC-8.2 (ii)<br />

CCI: CCI-001387<br />

NIST SP 800-53 :: AC-8 c<br />

NIST SP 800-53A :: AC-8.2 (ii)<br />

CCI: CCI-001388<br />

NIST SP 800-53 :: AC-8 c<br />

NIST SP 800-53A :: AC-8.2 (iii)<br />

Rule Title: The system must implement virtual address<br />

space randomization.<br />

<strong>STIG</strong> ID: RHEL-06-000078 Rule ID: SV-50397r1_rule Vuln<br />

ID: V-38596<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

Address space layout randomization (ASLR) makes it more<br />

difficult for an attacker to predict the location of<br />

attack code he or she has introduced into a process's<br />

address space during an attempt at exploitation.<br />

Additionally, ASLR also makes it more difficult for an<br />

attacker to know the location of existing code in order<br />

to repurpose it using return oriented programming (ROP)<br />

techniques.<br />

Documentable: No<br />

Check Content:<br />

The status of the "kernel.randomize_va_space" kernel<br />

parameter can be queried by running the following<br />

command:<br />

$ sysctl kernel.randomize_va_space<br />

UNCLASSIFIED


UNCLASSIFIED<br />

The output of the command should indicate a value of at<br />

least "1" (preferably "2"). If this value is not the<br />

default value, investigate how it could have been<br />

adjusted at runtime, and verify it is not set improperly<br />

in "/etc/sysctl.conf".<br />

If the correct value is not returned, this is a finding.<br />

Fix Text:<br />

To set the runtime status of the<br />

"kernel.randomize_va_space" kernel parameter, run the<br />

following command:<br />

# sysctl -w kernel.randomize_va_space=2<br />

If this is not the system's default value, add the<br />

following line to "/etc/sysctl.conf":<br />

kernel.randomize_va_space = 2<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: The system must limit the ability of<br />

processes to have simultaneous write and execute access<br />

to memory.<br />

<strong>STIG</strong> ID: RHEL-06-000079 Rule ID: SV-50398r1_rule Vuln<br />

ID: V-38597<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

ExecShield uses the segmentation feature on all x86<br />

systems to prevent execution in memory higher than a<br />

certain address. It writes an address as a limit in the<br />

code segment descriptor, to control where code can be<br />

executed, on a per-process basis. When the kernel places<br />

a process's memory regions such as the stack and heap<br />

UNCLASSIFIED


UNCLASSIFIED<br />

higher than this address, the hardware prevents execution<br />

in that address range.<br />

Documentable: No<br />

Check Content:<br />

The status of the "kernel.exec-shield" kernel parameter<br />

can be queried by running the following command:<br />

$ sysctl kernel.exec-shield<br />

The output of the command should indicate a value of "1".<br />

If this value is not the default value, investigate how<br />

it could have been adjusted at runtime, and verify it is<br />

not set improperly in "/etc/sysctl.conf".<br />

If the correct value is not returned, this is a finding.<br />

Fix Text:<br />

To set the runtime status of the "kernel.exec-shield"<br />

kernel parameter, run the following command:<br />

# sysctl -w kernel.exec-shield=1<br />

If this is not the system's default value, add the<br />

following line to "/etc/sysctl.conf":<br />

kernel.exec-shield = 1<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: The system must not send ICMPv4 redirects<br />

by default.<br />

<strong>STIG</strong> ID: RHEL-06-000080 Rule ID: SV-50401r1_rule Vuln<br />

ID: V-38600<br />

Severity: CAT II Class: Unclass<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Discussion:<br />

Sending ICMP redirects permits the system to instruct<br />

other systems to update their routing information. The<br />

ability to send ICMP redirects is only appropriate for<br />

routers.<br />

Documentable: No<br />

Check Content:<br />

The status of the<br />

"net.ipv4.conf.default.send_redirects" kernel<br />

parameter can be queried by running the following<br />

command:<br />

$ sysctl net.ipv4.conf.default.send_redirects<br />

The output of the command should indicate a value of "0".<br />

If this value is not the default value, investigate how<br />

it could have been adjusted at runtime, and verify it is<br />

not set improperly in "/etc/sysctl.conf".<br />

If the correct value is not returned, this is a finding.<br />

Fix Text:<br />

To set the runtime status of the<br />

"net.ipv4.conf.default.send_redirects" kernel<br />

parameter, run the following command:<br />

# sysctl -w net.ipv4.conf.default.send_redirects=0<br />

If this is not the system's default value, add the<br />

following line to "/etc/sysctl.conf":<br />

net.ipv4.conf.default.send_redirects = 0<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: The system must not send ICMPv4 redirects<br />

UNCLASSIFIED


UNCLASSIFIED<br />

from any interface.<br />

<strong>STIG</strong> ID: RHEL-06-000081 Rule ID: SV-50402r1_rule Vuln<br />

ID: V-38601<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

Sending ICMP redirects permits the system to instruct<br />

other systems to update their routing information. The<br />

ability to send ICMP redirects is only appropriate for<br />

routers.<br />

Documentable: No<br />

Check Content:<br />

The status of the "net.ipv4.conf.all.send_redirects"<br />

kernel parameter can be queried by running the following<br />

command:<br />

$ sysctl net.ipv4.conf.all.send_redirects<br />

The output of the command should indicate a value of "0".<br />

If this value is not the default value, investigate how<br />

it could have been adjusted at runtime, and verify it is<br />

not set improperly in "/etc/sysctl.conf".<br />

If the correct value is not returned, this is a finding.<br />

Fix Text:<br />

To set the runtime status of the<br />

"net.ipv4.conf.all.send_redirects" kernel parameter,<br />

run the following command:<br />

# sysctl -w net.ipv4.conf.all.send_redirects=0<br />

If this is not the system's default value, add the<br />

following line to "/etc/sysctl.conf":<br />

net.ipv4.conf.all.send_redirects = 0<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

UNCLASSIFIED


UNCLASSIFIED<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: IP forwarding for IPv4 must not be enabled,<br />

unless the system is a router.<br />

<strong>STIG</strong> ID: RHEL-06-000082 Rule ID: SV-50312r1_rule Vuln<br />

ID: V-38511<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

IP forwarding permits the kernel to forward packets from<br />

one network interface to another. The ability to forward<br />

packets between two networks is only appropriate for<br />

routers.<br />

Documentable: No<br />

Check Content:<br />

If the system serves as a router, this is not applicable.<br />

The status of the "net.ipv4.ip_forward" kernel parameter<br />

can be queried by running the following command:<br />

$ sysctl net.ipv4.ip_forward<br />

The output of the command should indicate a value of "0".<br />

If this value is not the default value, investigate how<br />

it could have been adjusted at runtime, and verify it is<br />

not set improperly in "/etc/sysctl.conf".<br />

If the correct value is not returned, this is a finding.<br />

Fix Text:<br />

To set the runtime status of the "net.ipv4.ip_forward"<br />

kernel parameter, run the following command:<br />

# sysctl -w net.ipv4.ip_forward=0<br />

If this is not the system's default value, add the<br />

following line to "/etc/sysctl.conf":<br />

UNCLASSIFIED


UNCLASSIFIED<br />

net.ipv4.ip_forward = 0<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: The system must not accept IPv4<br />

source-routed packets on any interface.<br />

<strong>STIG</strong> ID: RHEL-06-000083 Rule ID: SV-50324r1_rule Vuln<br />

ID: V-38523<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

Accepting source-routed packets in the IPv4 protocol has<br />

few legitimate uses. It should be disabled unless it is<br />

absolutely required.<br />

Documentable: No<br />

Check Content:<br />

The status of the<br />

"net.ipv4.conf.all.accept_source_route" kernel<br />

parameter can be queried by running the following<br />

command:<br />

$ sysctl net.ipv4.conf.all.accept_source_route<br />

The output of the command should indicate a value of "0".<br />

If this value is not the default value, investigate how<br />

it could have been adjusted at runtime, and verify it is<br />

not set improperly in "/etc/sysctl.conf".<br />

If the correct value is not returned, this is a finding.<br />

Fix Text:<br />

To set the runtime status of the<br />

"net.ipv4.conf.all.accept_source_route" kernel<br />

parameter, run the following command:<br />

UNCLASSIFIED


UNCLASSIFIED<br />

# sysctl -w net.ipv4.conf.all.accept_source_route=0<br />

If this is not the system's default value, add the<br />

following line to "/etc/sysctl.conf":<br />

net.ipv4.conf.all.accept_source_route = 0<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: The system must not accept ICMPv4 redirect<br />

packets on any interface.<br />

<strong>STIG</strong> ID: RHEL-06-000084 Rule ID: SV-50325r1_rule Vuln<br />

ID: V-38524<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

Accepting ICMP redirects has few legitimate uses. It<br />

should be disabled unless it is absolutely required.<br />

Documentable: No<br />

Check Content:<br />

The status of the "net.ipv4.conf.all.accept_redirects"<br />

kernel parameter can be queried by running the following<br />

command:<br />

$ sysctl net.ipv4.conf.all.accept_redirects<br />

The output of the command should indicate a value of "0".<br />

If this value is not the default value, investigate how<br />

it could have been adjusted at runtime, and verify it is<br />

not set improperly in "/etc/sysctl.conf".<br />

If the correct value is not returned, this is a finding.<br />

Fix Text:<br />

UNCLASSIFIED


UNCLASSIFIED<br />

To set the runtime status of the<br />

"net.ipv4.conf.all.accept_redirects" kernel parameter,<br />

run the following command:<br />

# sysctl -w net.ipv4.conf.all.accept_redirects=0<br />

If this is not the system's default value, add the<br />

following line to "/etc/sysctl.conf":<br />

net.ipv4.conf.all.accept_redirects = 0<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: The system must not accept ICMPv4 secure<br />

redirect packets on any interface.<br />

<strong>STIG</strong> ID: RHEL-06-000086 Rule ID: SV-50327r1_rule Vuln<br />

ID: V-38526<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

Accepting "secure" ICMP redirects (from those gateways<br />

listed as default gateways) has few legitimate uses. It<br />

should be disabled unless it is absolutely required.<br />

Documentable: No<br />

Check Content:<br />

The status of the "net.ipv4.conf.all.secure_redirects"<br />

kernel parameter can be queried by running the following<br />

command:<br />

$ sysctl net.ipv4.conf.all.secure_redirects<br />

The output of the command should indicate a value of "0".<br />

If this value is not the default value, investigate how<br />

it could have been adjusted at runtime, and verify it is<br />

UNCLASSIFIED


UNCLASSIFIED<br />

not set improperly in "/etc/sysctl.conf".<br />

If the correct value is not returned, this is a finding.<br />

Fix Text:<br />

To set the runtime status of the<br />

"net.ipv4.conf.all.secure_redirects" kernel parameter,<br />

run the following command:<br />

# sysctl -w net.ipv4.conf.all.secure_redirects=0<br />

If this is not the system's default value, add the<br />

following line to "/etc/sysctl.conf":<br />

net.ipv4.conf.all.secure_redirects = 0<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: The system must log Martian packets.<br />

<strong>STIG</strong> ID: RHEL-06-000088 Rule ID: SV-50329r1_rule Vuln<br />

ID: V-38528<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

The presence of "martian" packets (which have impossible<br />

addresses) as well as spoofed packets, source-routed<br />

packets, and redirects could be a sign of nefarious<br />

network activity. Logging these packets enables this<br />

activity to be detected.<br />

Documentable: No<br />

Check Content:<br />

The status of the "net.ipv4.conf.all.log_martians"<br />

kernel parameter can be queried by running the following<br />

command:<br />

UNCLASSIFIED


UNCLASSIFIED<br />

$ sysctl net.ipv4.conf.all.log_martians<br />

The output of the command should indicate a value of "1".<br />

If this value is not the default value, investigate how<br />

it could have been adjusted at runtime, and verify it is<br />

not set improperly in "/etc/sysctl.conf".<br />

If the correct value is not returned, this is a finding.<br />

Fix Text:<br />

To set the runtime status of the<br />

"net.ipv4.conf.all.log_martians" kernel parameter, run<br />

the following command:<br />

# sysctl -w net.ipv4.conf.all.log_martians=1<br />

If this is not the system's default value, add the<br />

following line to "/etc/sysctl.conf":<br />

net.ipv4.conf.all.log_martians = 1<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: The system must not accept IPv4<br />

source-routed packets by default.<br />

<strong>STIG</strong> ID: RHEL-06-000089 Rule ID: SV-50330r1_rule Vuln<br />

ID: V-38529<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

Accepting source-routed packets in the IPv4 protocol has<br />

few legitimate uses. It should be disabled unless it is<br />

absolutely required.<br />

Documentable: No<br />

Check Content:<br />

UNCLASSIFIED


UNCLASSIFIED<br />

The status of the<br />

"net.ipv4.conf.default.accept_source_route" kernel<br />

parameter can be queried by running the following<br />

command:<br />

$ sysctl net.ipv4.conf.default.accept_source_route<br />

The output of the command should indicate a value of "0".<br />

If this value is not the default value, investigate how<br />

it could have been adjusted at runtime, and verify it is<br />

not set improperly in "/etc/sysctl.conf".<br />

If the correct value is not returned, this is a finding.<br />

Fix Text:<br />

To set the runtime status of the<br />

"net.ipv4.conf.default.accept_source_route" kernel<br />

parameter, run the following command:<br />

# sysctl -w net.ipv4.conf.default.accept_source_route=0<br />

If this is not the system's default value, add the<br />

following line to "/etc/sysctl.conf":<br />

net.ipv4.conf.default.accept_source_route = 0<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: The system must not accept ICMPv4 secure<br />

redirect packets by default.<br />

<strong>STIG</strong> ID: RHEL-06-000090 Rule ID: SV-50333r1_rule Vuln<br />

ID: V-38532<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

Accepting "secure" ICMP redirects (from those gateways<br />

listed as default gateways) has few legitimate uses. It<br />

UNCLASSIFIED


UNCLASSIFIED<br />

should be disabled unless it is absolutely required.<br />

Documentable: No<br />

Check Content:<br />

The status of the<br />

"net.ipv4.conf.default.secure_redirects" kernel<br />

parameter can be queried by running the following<br />

command:<br />

$ sysctl net.ipv4.conf.default.secure_redirects<br />

The output of the command should indicate a value of "0".<br />

If this value is not the default value, investigate how<br />

it could have been adjusted at runtime, and verify it is<br />

not set improperly in "/etc/sysctl.conf".<br />

If the correct value is not returned, this is a finding.<br />

Fix Text:<br />

To set the runtime status of the<br />

"net.ipv4.conf.default.secure_redirects" kernel<br />

parameter, run the following command:<br />

# sysctl -w net.ipv4.conf.default.secure_redirects=0<br />

If this is not the system's default value, add the<br />

following line to "/etc/sysctl.conf":<br />

net.ipv4.conf.default.secure_redirects = 0<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: The system must ignore IPv4 ICMP redirect<br />

messages.<br />

<strong>STIG</strong> ID: RHEL-06-000091 Rule ID: SV-50334r1_rule Vuln<br />

ID: V-38533<br />

Severity: CAT III Class: Unclass<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Discussion:<br />

This feature of the IPv4 protocol has few legitimate uses.<br />

It should be disabled unless it is absolutely required.<br />

Documentable: No<br />

Check Content:<br />

The status of the<br />

"net.ipv4.conf.default.accept_redirects" kernel<br />

parameter can be queried by running the following<br />

command:<br />

$ sysctl net.ipv4.conf.default.accept_redirects<br />

The output of the command should indicate a value of "0".<br />

If this value is not the default value, investigate how<br />

it could have been adjusted at runtime, and verify it is<br />

not set improperly in "/etc/sysctl.conf".<br />

If the correct value is not returned, this is a finding.<br />

Fix Text:<br />

To set the runtime status of the<br />

"net.ipv4.conf.default.accept_redirects" kernel<br />

parameter, run the following command:<br />

# sysctl -w net.ipv4.conf.default.accept_redirects=0<br />

If this is not the system's default value, add the<br />

following line to "/etc/sysctl.conf":<br />

net.ipv4.conf.default.accept_redirects = 0<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: The system must not respond to ICMPv4 sent<br />

UNCLASSIFIED


UNCLASSIFIED<br />

to a broadcast address.<br />

<strong>STIG</strong> ID: RHEL-06-000092 Rule ID: SV-50336r1_rule Vuln<br />

ID: V-38535<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

Ignoring ICMP echo requests (pings) sent to broadcast or<br />

multicast addresses makes the system slightly more<br />

difficult to enumerate on the network.<br />

Documentable: No<br />

Check Content:<br />

The status of the<br />

"net.ipv4.icmp_echo_ignore_broadcasts" kernel<br />

parameter can be queried by running the following<br />

command:<br />

$ sysctl net.ipv4.icmp_echo_ignore_broadcasts<br />

The output of the command should indicate a value of "1".<br />

If this value is not the default value, investigate how<br />

it could have been adjusted at runtime, and verify it is<br />

not set improperly in "/etc/sysctl.conf".<br />

If the correct value is not returned, this is a finding.<br />

Fix Text:<br />

To set the runtime status of the<br />

"net.ipv4.icmp_echo_ignore_broadcasts" kernel<br />

parameter, run the following command:<br />

# sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=1<br />

If this is not the system's default value, add the<br />

following line to "/etc/sysctl.conf":<br />

net.ipv4.icmp_echo_ignore_broadcasts = 1<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

UNCLASSIFIED


UNCLASSIFIED<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: The system must ignore ICMPv4 bogus error<br />

responses.<br />

<strong>STIG</strong> ID: RHEL-06-000093 Rule ID: SV-50338r1_rule Vuln<br />

ID: V-38537<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

Ignoring bogus ICMP error responses reduces log size,<br />

although some activity would not be logged.<br />

Documentable: No<br />

Check Content:<br />

The status of the<br />

"net.ipv4.icmp_ignore_bogus_error_responses" kernel<br />

parameter can be queried by running the following<br />

command:<br />

$ sysctl net.ipv4.icmp_ignore_bogus_error_responses<br />

The output of the command should indicate a value of "1".<br />

If this value is not the default value, investigate how<br />

it could have been adjusted at runtime, and verify it is<br />

not set improperly in "/etc/sysctl.conf".<br />

If the correct value is not returned, this is a finding.<br />

Fix Text:<br />

To set the runtime status of the<br />

"net.ipv4.icmp_ignore_bogus_error_responses" kernel<br />

parameter, run the following command:<br />

# sysctl -w<br />

net.ipv4.icmp_ignore_bogus_error_responses=1<br />

If this is not the system's default value, add the<br />

following line to "/etc/sysctl.conf":<br />

UNCLASSIFIED


UNCLASSIFIED<br />

net.ipv4.icmp_ignore_bogus_error_responses = 1<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: The system must be configured to use TCP<br />

syncookies.<br />

<strong>STIG</strong> ID: RHEL-06-000095 Rule ID: SV-50340r1_rule Vuln<br />

ID: V-38539<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

A TCP SYN flood attack can cause a denial of service by<br />

filling a system's TCP connection table with connections<br />

in the SYN_RCVD state. Syncookies can be used to track<br />

a connection when a subsequent ACK is received, verifying<br />

the initiator is attempting a valid connection and is not<br />

a flood source. This feature is activated when a flood<br />

condition is detected, and enables the system to continue<br />

servicing valid connection requests.<br />

Documentable: No<br />

Check Content:<br />

The status of the "net.ipv4.tcp_syncookies" kernel<br />

parameter can be queried by running the following<br />

command:<br />

$ sysctl net.ipv4.tcp_syncookies<br />

The output of the command should indicate a value of "1".<br />

If this value is not the default value, investigate how<br />

it could have been adjusted at runtime, and verify it is<br />

not set improperly in "/etc/sysctl.conf".<br />

If the correct value is not returned, this is a finding.<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Fix Text:<br />

To set the runtime status of the<br />

"net.ipv4.tcp_syncookies" kernel parameter, run the<br />

following command:<br />

# sysctl -w net.ipv4.tcp_syncookies=1<br />

If this is not the system's default value, add the<br />

following line to "/etc/sysctl.conf":<br />

net.ipv4.tcp_syncookies = 1<br />

CCI: CCI-001095<br />

NIST SP 800-53A :: SC-5 (2).1<br />

NIST SP 800-53 :: SC-5 (2)<br />

Rule Title: The system must use a reverse-path filter<br />

for IPv4 network traffic when possible on all interfaces.<br />

<strong>STIG</strong> ID: RHEL-06-000096 Rule ID: SV-50343r1_rule Vuln<br />

ID: V-38542<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

Enabling reverse path filtering drops packets with source<br />

addresses that should not have been able to be received<br />

on the interface they were received on. It should not be<br />

used on systems which are routers for complicated<br />

networks, but is helpful for end hosts and routers serving<br />

small networks.<br />

Documentable: No<br />

Check Content:<br />

The status of the "net.ipv4.conf.all.rp_filter" kernel<br />

parameter can be queried by running the following<br />

command:<br />

$ sysctl net.ipv4.conf.all.rp_filter<br />

UNCLASSIFIED


UNCLASSIFIED<br />

The output of the command should indicate a value of "1".<br />

If this value is not the default value, investigate how<br />

it could have been adjusted at runtime, and verify it is<br />

not set improperly in "/etc/sysctl.conf".<br />

If the correct value is not returned, this is a finding.<br />

Fix Text:<br />

To set the runtime status of the<br />

"net.ipv4.conf.all.rp_filter" kernel parameter, run the<br />

following command:<br />

# sysctl -w net.ipv4.conf.all.rp_filter=1<br />

If this is not the system's default value, add the<br />

following line to "/etc/sysctl.conf":<br />

net.ipv4.conf.all.rp_filter = 1<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: The system must use a reverse-path filter<br />

for IPv4 network traffic when possible by default.<br />

<strong>STIG</strong> ID: RHEL-06-000097 Rule ID: SV-50345r1_rule Vuln<br />

ID: V-38544<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

Enabling reverse path filtering drops packets with source<br />

addresses that should not have been able to be received<br />

on the interface they were received on. It should not be<br />

used on systems which are routers for complicated<br />

networks, but is helpful for end hosts and routers serving<br />

small networks.<br />

Documentable: No<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Check Content:<br />

The status of the "net.ipv4.conf.default.rp_filter"<br />

kernel parameter can be queried by running the following<br />

command:<br />

$ sysctl net.ipv4.conf.default.rp_filter<br />

The output of the command should indicate a value of "1".<br />

If this value is not the default value, investigate how<br />

it could have been adjusted at runtime, and verify it is<br />

not set improperly in "/etc/sysctl.conf".<br />

If the correct value is not returned, this is a finding.<br />

Fix Text:<br />

To set the runtime status of the<br />

"net.ipv4.conf.default.rp_filter" kernel parameter, run<br />

the following command:<br />

# sysctl -w net.ipv4.conf.default.rp_filter=1<br />

If this is not the system's default value, add the<br />

following line to "/etc/sysctl.conf":<br />

net.ipv4.conf.default.rp_filter = 1<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: The IPv6 protocol handler must not be bound<br />

to the network stack unless needed.<br />

<strong>STIG</strong> ID: RHEL-06-000098 Rule ID: SV-50347r1_rule Vuln<br />

ID: V-38546<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

Any unnecessary network stacks - including IPv6 - should<br />

UNCLASSIFIED


UNCLASSIFIED<br />

be disabled, to reduce the vulnerability to exploitation.<br />

Documentable: No<br />

Check Content:<br />

If the system uses IPv6, this is not applicable.<br />

If the system is configured to prevent the loading of the<br />

"ipv6" kernel module, it will contain a line of the form:<br />

options ipv6 disable=1<br />

Such lines may be inside any file in "/etc/modprobe.d"<br />

or the deprecated "/etc/modprobe.conf". This permits<br />

insertion of the IPv6 kernel module (which other parts<br />

of the system expect to be present), but otherwise keeps<br />

it inactive. Run the following command to search for such<br />

lines in all files in "/etc/modprobe.d" and the<br />

deprecated "/etc/modprobe.conf":<br />

$ grep -r ipv6 /etc/modprobe.conf /etc/modprobe.d<br />

If the IPv6 kernel module is loaded, this is a finding.<br />

Fix Text:<br />

To prevent the IPv6 kernel module ("ipv6") from loading<br />

the IPv6 networking stack, add the following line to<br />

"/etc/modprobe.d/disabled.conf" (or another file in<br />

"/etc/modprobe.d"):<br />

options ipv6 disable=1<br />

This permits the IPv6 module to be loaded (and thus<br />

satisfy other modules that depend on it), while disabling<br />

support for the IPv6 protocol.<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Rule Title: The system must ignore ICMPv6 redirects by<br />

default.<br />

<strong>STIG</strong> ID: RHEL-06-000099 Rule ID: SV-50349r1_rule Vuln<br />

ID: V-38548<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

An illicit ICMP redirect message could result in a<br />

man-in-the-middle attack.<br />

Documentable: No<br />

Check Content:<br />

The status of the<br />

"net.ipv6.conf.default.accept_redirects" kernel<br />

parameter can be queried by running the following<br />

command:<br />

$ sysctl net.ipv6.conf.default.accept_redirects<br />

The output of the command should indicate a value of "0".<br />

If this value is not the default value, investigate how<br />

it could have been adjusted at runtime, and verify it is<br />

not set improperly in "/etc/sysctl.conf".<br />

If the correct value is not returned, this is a finding.<br />

Fix Text:<br />

To set the runtime status of the<br />

"net.ipv6.conf.default.accept_redirects" kernel<br />

parameter, run the following command:<br />

# sysctl -w net.ipv6.conf.default.accept_redirects=0<br />

If this is not the system's default value, add the<br />

following line to "/etc/sysctl.conf":<br />

net.ipv6.conf.default.accept_redirects = 0<br />

UNCLASSIFIED


UNCLASSIFIED<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: The system must employ a local IPv6<br />

firewall.<br />

<strong>STIG</strong> ID: RHEL-06-000103 Rule ID: SV-50350r1_rule Vuln<br />

ID: V-38549<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

The "ip6tables" service provides the system's host-based<br />

firewalling capability for IPv6 and ICMPv6.<br />

Documentable: No<br />

Check Content:<br />

If IPv6 is disabled, this is not applicable.<br />

Run the following command to determine the current status<br />

of the "ip6tables" service:<br />

# service ip6tables status<br />

If the service is enabled, it should return the following:<br />

ip6tables is running...<br />

If the service is not running, this is a finding.<br />

Fix Text:<br />

The "ip6tables" service can be enabled with the following<br />

command:<br />

# chkconfig ip6tables on<br />

UNCLASSIFIED


UNCLASSIFIED<br />

CCI: CCI-001118<br />

NIST SP 800-53A :: SC-7 (12).1<br />

NIST SP 800-53 :: SC-7 (12)<br />

Rule Title: The operating system must connect to<br />

external networks or information systems only through<br />

managed IPv6 interfaces consisting of boundary<br />

protection devices arranged in accordance with an<br />

organizational security architecture.<br />

<strong>STIG</strong> ID: RHEL-06-000106 Rule ID: SV-50352r1_rule Vuln<br />

ID: V-38551<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

The "ip6tables" service provides the system's host-based<br />

firewalling capability for IPv6 and ICMPv6.<br />

Documentable: No<br />

Check Content:<br />

If IPv6 is disabled, this is not applicable.<br />

Run the following command to determine the current status<br />

of the "ip6tables" service:<br />

# service ip6tables status<br />

If the service is enabled, it should return the following:<br />

ip6tables is running...<br />

If the service is not running, this is a finding.<br />

Fix Text:<br />

The "ip6tables" service can be enabled with the following<br />

command:<br />

UNCLASSIFIED


UNCLASSIFIED<br />

# chkconfig ip6tables on<br />

CCI: CCI-001098<br />

NIST SP 800-53A :: SC-7.1 (iv)<br />

NIST SP 800-53 :: SC-7 b<br />

Rule Title: The operating system must prevent public<br />

IPv6 access into an organizations internal networks,<br />

except as appropriately mediated by managed interfaces<br />

employing boundary protection devices.<br />

<strong>STIG</strong> ID: RHEL-06-000107 Rule ID: SV-50354r1_rule Vuln<br />

ID: V-38553<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

The "ip6tables" service provides the system's host-based<br />

firewalling capability for IPv6 and ICMPv6.<br />

Documentable: No<br />

Check Content:<br />

If IPv6 is disabled, this is not applicable.<br />

Run the following command to determine the current status<br />

of the "ip6tables" service:<br />

# service ip6tables status<br />

If the service is enabled, it should return the following:<br />

ip6tables is running...<br />

If the service is not running, this is a finding.<br />

Fix Text:<br />

The "ip6tables" service can be enabled with the following<br />

command:<br />

UNCLASSIFIED


UNCLASSIFIED<br />

# chkconfig ip6tables on<br />

CCI: CCI-001100<br />

NIST SP 800-53A :: SC-7 (2).1 (ii)<br />

NIST SP 800-53 :: SC-7 (2)<br />

Rule Title: The system must employ a local IPv4<br />

firewall.<br />

<strong>STIG</strong> ID: RHEL-06-000113 Rule ID: SV-50356r1_rule Vuln<br />

ID: V-38555<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

The "iptables" service provides the system's host-based<br />

firewalling capability for IPv4 and ICMP.<br />

Documentable: No<br />

Check Content:<br />

If the system is a cross-domain system, this is not<br />

applicable.<br />

Run the following command to determine the current status<br />

of the "iptables" service:<br />

# service iptables status<br />

If the service is enabled, it should return the following:<br />

iptables is running...<br />

If the service is not running, this is a finding.<br />

Fix Text:<br />

The "iptables" service can be enabled with the following<br />

command:<br />

UNCLASSIFIED


UNCLASSIFIED<br />

# chkconfig iptables on<br />

CCI: CCI-001118<br />

NIST SP 800-53A :: SC-7 (12).1<br />

NIST SP 800-53 :: SC-7 (12)<br />

Rule Title: The operating system must connect to<br />

external networks or information systems only through<br />

managed IPv4 interfaces consisting of boundary<br />

protection devices arranged in accordance with an<br />

organizational security architecture.<br />

<strong>STIG</strong> ID: RHEL-06-000116 Rule ID: SV-50361r1_rule Vuln<br />

ID: V-38560<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

The "iptables" service provides the system's host-based<br />

firewalling capability for IPv4 and ICMP.<br />

Documentable: No<br />

Check Content:<br />

If the system is a cross-domain system, this is not<br />

applicable.<br />

Run the following command to determine the current status<br />

of the "iptables" service:<br />

# service iptables status<br />

If the service is enabled, it should return the following:<br />

iptables is running...<br />

If the service is not running, this is a finding.<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Fix Text:<br />

The "iptables" service can be enabled with the following<br />

command:<br />

# chkconfig iptables on<br />

CCI: CCI-001098<br />

NIST SP 800-53A :: SC-7.1 (iv)<br />

NIST SP 800-53 :: SC-7 b<br />

Rule Title: The operating system must prevent public<br />

IPv4 access into an organizations internal networks,<br />

except as appropriately mediated by managed interfaces<br />

employing boundary protection devices.<br />

<strong>STIG</strong> ID: RHEL-06-000117 Rule ID: SV-50313r1_rule Vuln<br />

ID: V-38512<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

The "iptables" service provides the system's host-based<br />

firewalling capability for IPv4 and ICMP.<br />

Documentable: No<br />

Check Content:<br />

If the system is a cross-domain system, this is not<br />

applicable.<br />

Run the following command to determine the current status<br />

of the "iptables" service:<br />

# service iptables status<br />

If the service is enabled, it should return the following:<br />

iptables is running...<br />

UNCLASSIFIED


UNCLASSIFIED<br />

If the service is not running, this is a finding.<br />

Fix Text:<br />

The "iptables" service can be enabled with the following<br />

command:<br />

# chkconfig iptables on<br />

CCI: CCI-001100<br />

NIST SP 800-53A :: SC-7 (2).1 (ii)<br />

NIST SP 800-53 :: SC-7 (2)<br />

Rule Title: The systems local IPv4 firewall must<br />

implement a deny-all, allow-by-exception policy for<br />

inbound packets.<br />

<strong>STIG</strong> ID: RHEL-06-000120 Rule ID: SV-50314r1_rule Vuln<br />

ID: V-38513<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

In "iptables" the default policy is applied only after<br />

all the applicable rules in the table are examined for<br />

a match. Setting the default policy to "DROP" implements<br />

proper design for a firewall, i.e., any packets which are<br />

not explicitly permitted should not be accepted.<br />

Documentable: No<br />

Check Content:<br />

Inspect the file "/etc/sysconfig/iptables" to determine<br />

the default policy for the INPUT chain. It should be set<br />

to DROP.<br />

# grep ":INPUT" /etc/sysconfig/iptables<br />

If the default policy for the INPUT chain is not set to<br />

DROP, this is a finding.<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Fix Text:<br />

To set the default policy to DROP (instead of ACCEPT) for<br />

the built-in INPUT chain which processes incoming<br />

packets, add or correct the following line in<br />

"/etc/sysconfig/iptables":<br />

:INPUT DROP [0:0]<br />

CCI: CCI-000066<br />

NIST SP 800-53A :: AC-17.1 (v)<br />

NIST SP 800-53 :: AC-17 e<br />

Rule Title: The Datagram Congestion Control Protocol<br />

(DCCP) must be disabled unless required.<br />

<strong>STIG</strong> ID: RHEL-06-000124 Rule ID: SV-50315r1_rule Vuln<br />

ID: V-38514<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

Disabling DCCP protects the system against exploitation<br />

of any flaws in its implementation.<br />

Documentable: No<br />

Check Content:<br />

If the system is configured to prevent the loading of the<br />

"dccp" kernel module, it will contain lines inside any<br />

file in "/etc/modprobe.d" or the<br />

deprecated"/etc/modprobe.conf". These lines instruct<br />

the module loading system to run another program (such<br />

as "/bin/true") upon a module "install" event. Run the<br />

following command to search for such lines in all files<br />

in "/etc/modprobe.d" and the deprecated<br />

"/etc/modprobe.conf":<br />

$ grep -r dccp /etc/modprobe.conf /etc/modprobe.d<br />

UNCLASSIFIED


UNCLASSIFIED<br />

If no line is returned, this is a finding.<br />

Fix Text:<br />

The Datagram Congestion Control Protocol (DCCP) is a<br />

relatively new transport layer protocol, designed to<br />

support streaming media and telephony. To configure the<br />

system to prevent the "dccp" kernel module from being<br />

loaded, add the following line to a file in the directory<br />

"/etc/modprobe.d":<br />

install dccp /bin/true<br />

CCI: CCI-000382<br />

NIST SP 800-53A :: CM-7.1 (iii)<br />

NIST SP 800-53 :: CM-7<br />

Rule Title: The Stream Control Transmission Protocol<br />

(SCTP) must be disabled unless required.<br />

<strong>STIG</strong> ID: RHEL-06-000125 Rule ID: SV-50316r1_rule Vuln<br />

ID: V-38515<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

Disabling SCTP protects the system against exploitation<br />

of any flaws in its implementation.<br />

Documentable: No<br />

Check Content:<br />

If the system is configured to prevent the loading of the<br />

"sctp" kernel module, it will contain lines inside any<br />

file in "/etc/modprobe.d" or the<br />

deprecated"/etc/modprobe.conf". These lines instruct<br />

the module loading system to run another program (such<br />

as "/bin/true") upon a module "install" event. Run the<br />

following command to search for such lines in all files<br />

in "/etc/modprobe.d" and the deprecated<br />

"/etc/modprobe.conf":<br />

UNCLASSIFIED


UNCLASSIFIED<br />

$ grep -r sctp /etc/modprobe.conf /etc/modprobe.d<br />

If no line is returned, this is a finding.<br />

Fix Text:<br />

The Stream Control Transmission Protocol (SCTP) is a<br />

transport layer protocol, designed to support the idea<br />

of message-oriented communication, with several streams<br />

of messages within one connection. To configure the<br />

system to prevent the "sctp" kernel module from being<br />

loaded, add the following line to a file in the directory<br />

"/etc/modprobe.d":<br />

install sctp /bin/true<br />

CCI: CCI-000382<br />

NIST SP 800-53A :: CM-7.1 (iii)<br />

NIST SP 800-53 :: CM-7<br />

Rule Title: The Reliable Datagram Sockets (RDS)<br />

protocol must be disabled unless required.<br />

<strong>STIG</strong> ID: RHEL-06-000126 Rule ID: SV-50317r1_rule Vuln<br />

ID: V-38516<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

Disabling RDS protects the system against exploitation<br />

of any flaws in its implementation.<br />

Documentable: No<br />

Check Content:<br />

If the system is configured to prevent the loading of the<br />

"rds" kernel module, it will contain lines inside any file<br />

in "/etc/modprobe.d" or the<br />

deprecated"/etc/modprobe.conf". These lines instruct<br />

UNCLASSIFIED


UNCLASSIFIED<br />

the module loading system to run another program (such<br />

as "/bin/true") upon a module "install" event. Run the<br />

following command to search for such lines in all files<br />

in "/etc/modprobe.d" and the deprecated<br />

"/etc/modprobe.conf":<br />

$ grep -r rds /etc/modprobe.conf /etc/modprobe.d<br />

If no line is returned, this is a finding.<br />

Fix Text:<br />

The Reliable Datagram Sockets (RDS) protocol is a<br />

transport layer protocol designed to provide reliable<br />

high- bandwidth, low-latency communications between<br />

nodes in a cluster. To configure the system to prevent<br />

the "rds" kernel module from being loaded, add the<br />

following line to a file in the directory<br />

"/etc/modprobe.d":<br />

install rds /bin/true<br />

CCI: CCI-000382<br />

NIST SP 800-53A :: CM-7.1 (iii)<br />

NIST SP 800-53 :: CM-7<br />

Rule Title: The Transparent Inter-Process<br />

Communication (TIPC) protocol must be disabled unless<br />

required.<br />

<strong>STIG</strong> ID: RHEL-06-000127 Rule ID: SV-50318r1_rule Vuln<br />

ID: V-38517<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

Disabling TIPC protects the system against exploitation<br />

of any flaws in its implementation.<br />

Documentable: No<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Check Content:<br />

If the system is configured to prevent the loading of the<br />

"tipc" kernel module, it will contain lines inside any<br />

file in "/etc/modprobe.d" or the<br />

deprecated"/etc/modprobe.conf". These lines instruct<br />

the module loading system to run another program (such<br />

as "/bin/true") upon a module "install" event. Run the<br />

following command to search for such lines in all files<br />

in "/etc/modprobe.d" and the deprecated<br />

"/etc/modprobe.conf":<br />

$ grep -r tipc /etc/modprobe.conf /etc/modprobe.d<br />

If no line is returned, this is a finding.<br />

Fix Text:<br />

The Transparent Inter-Process Communication (TIPC)<br />

protocol is designed to provide communications between<br />

nodes in a cluster. To configure the system to prevent<br />

the "tipc" kernel module from being loaded, add the<br />

following line to a file in the directory<br />

"/etc/modprobe.d":<br />

install tipc /bin/true<br />

CCI: CCI-000382<br />

NIST SP 800-53A :: CM-7.1 (iii)<br />

NIST SP 800-53 :: CM-7<br />

Rule Title: All rsyslog-generated log files must be<br />

owned by root.<br />

<strong>STIG</strong> ID: RHEL-06-000133 Rule ID: SV-50319r1_rule Vuln<br />

ID: V-38518<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

UNCLASSIFIED


UNCLASSIFIED<br />

The log files generated by rsyslog contain valuable<br />

information regarding system configuration, user<br />

authentication, and other such information. Log files<br />

should be protected from unauthorized access.<br />

Documentable: No<br />

Check Content:<br />

The owner of all log files written by "rsyslog" should<br />

be root. These log files are determined by the second part<br />

of each Rule line in "/etc/rsyslog.conf" and typically<br />

all appear in "/var/log". For each log file [LOGFILE]<br />

referenced in "/etc/rsyslog.conf", run the following<br />

command to inspect the file's owner:<br />

$ ls -l [LOGFILE]<br />

If the owner is not root, this is a finding.<br />

Fix Text:<br />

The owner of all log files written by "rsyslog" should<br />

be root. These log files are determined by the second part<br />

of each Rule line in "/etc/rsyslog.conf" typically all<br />

appear in "/var/log". For each log file [LOGFILE]<br />

referenced in "/etc/rsyslog.conf", run the following<br />

command to inspect the file's owner:<br />

$ ls -l [LOGFILE]<br />

If the owner is not "root", run the following command to<br />

correct this:<br />

# chown root [LOGFILE]<br />

CCI: CCI-001314<br />

NIST SP 800-53 :: SI-11 c<br />

NIST SP 800-53A :: SI-11.1 (iv)<br />

Rule Title: All rsyslog-generated log files must be<br />

UNCLASSIFIED


UNCLASSIFIED<br />

group-owned by root.<br />

<strong>STIG</strong> ID: RHEL-06-000134 Rule ID: SV-50320r1_rule Vuln<br />

ID: V-38519<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

The log files generated by rsyslog contain valuable<br />

information regarding system configuration, user<br />

authentication, and other such information. Log files<br />

should be protected from unauthorized access.<br />

Documentable: No<br />

Check Content:<br />

The group-owner of all log files written by "rsyslog"<br />

should be root. These log files are determined by the<br />

second part of each Rule line in "/etc/rsyslog.conf" and<br />

typically all appear in "/var/log". For each log file<br />

[LOGFILE] referenced in "/etc/rsyslog.conf", run the<br />

following command to inspect the file's group owner:<br />

$ ls -l [LOGFILE]<br />

If the group-owner is not root, this is a finding.<br />

Fix Text:<br />

The group-owner of all log files written by "rsyslog"<br />

should be root. These log files are determined by the<br />

second part of each Rule line in "/etc/rsyslog.conf" and<br />

typically all appear in "/var/log". For each log file<br />

[LOGFILE] referenced in "/etc/rsyslog.conf", run the<br />

following command to inspect the file's group owner:<br />

$ ls -l [LOGFILE]<br />

If the owner is not "root", run the following command to<br />

correct this:<br />

# chgrp root [LOGFILE]<br />

UNCLASSIFIED


UNCLASSIFIED<br />

CCI: CCI-001314<br />

NIST SP 800-53 :: SI-11 c<br />

NIST SP 800-53A :: SI-11.1 (iv)<br />

Rule Title: All rsyslog-generated log files must have<br />

mode 0600 or less permissive.<br />

<strong>STIG</strong> ID: RHEL-06-000135 Rule ID: SV-50424r1_rule Vuln<br />

ID: V-38623<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

Log files can contain valuable information regarding<br />

system configuration. If the system log files are not<br />

protected, unauthorized users could change the logged<br />

data, eliminating their forensic value.<br />

Documentable: No<br />

Check Content:<br />

The file permissions for all log files written by rsyslog<br />

should be set to 600, or more restrictive. These log files<br />

are determined by the second part of each Rule line in<br />

"/etc/rsyslog.conf" and typically all appear in<br />

"/var/log". For each log file [LOGFILE] referenced in<br />

"/etc/rsyslog.conf", run the following command to<br />

inspect the file's permissions:<br />

$ ls -l [LOGFILE]<br />

The permissions should be 600, or more restrictive.<br />

If the permissions are not correct, this is a finding.<br />

Fix Text:<br />

The file permissions for all log files written by rsyslog<br />

should be set to 600, or more restrictive. These log files<br />

are determined by the second part of each Rule line in<br />

"/etc/rsyslog.conf" and typically all appear in<br />

"/var/log". For each log file [LOGFILE] referenced in<br />

UNCLASSIFIED


UNCLASSIFIED<br />

"/etc/rsyslog.conf", run the following command to<br />

inspect the file's permissions:<br />

$ ls -l [LOGFILE]<br />

If the permissions are not 600 or more restrictive, run<br />

the following command to correct this:<br />

# chmod 0600 [LOGFILE]<br />

CCI: CCI-001314<br />

NIST SP 800-53 :: SI-11 c<br />

NIST SP 800-53A :: SI-11.1 (iv)<br />

Rule Title: The operating system must back up audit<br />

records on an organization defined frequency onto a<br />

different system or media than the system being audited.<br />

<strong>STIG</strong> ID: RHEL-06-000136 Rule ID: SV-50321r1_rule Vuln<br />

ID: V-38520<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

A log server (loghost) receives syslog messages from one<br />

or more systems. This data can be used as an additional<br />

log source in the event a system is compromised and its<br />

local logs are suspect. Forwarding log messages to a<br />

remote loghost also provides system administrators with<br />

a centralized place to view the status of multiple hosts<br />

within the enterprise.<br />

Documentable: No<br />

Check Content:<br />

To ensure logs are sent to a remote host, examine the file<br />

"/etc/rsyslog.conf". If using UDP, a line similar to the<br />

following should be present:<br />

*.* @[loghost.example.com]<br />

UNCLASSIFIED


UNCLASSIFIED<br />

If using TCP, a line similar to the following should be<br />

present:<br />

*.* @@[loghost.example.com]<br />

If using RELP, a line similar to the following should be<br />

present:<br />

*.* :omrelp:[loghost.example.com]<br />

If none of these are present, this is a finding.<br />

Fix Text:<br />

To configure rsyslog to send logs to a remote log server,<br />

open "/etc/rsyslog.conf" and read and understand the last<br />

section of the file, which describes the multiple<br />

directives necessary to activate remote logging. Along<br />

with these other directives, the system can be configured<br />

to forward its logs to a particular log server by adding<br />

or correcting one of the following lines, substituting<br />

"[loghost.example.com]" appropriately. The choice of<br />

protocol depends on the environment of the system;<br />

although TCP and RELP provide more reliable message<br />

delivery, they may not be supported in all environments.<br />

To use UDP for log message delivery:<br />

*.* @[loghost.example.com]<br />

To use TCP for log message delivery:<br />

*.* @@[loghost.example.com]<br />

To use RELP for log message delivery:<br />

*.* :omrelp:[loghost.example.com]<br />

UNCLASSIFIED


UNCLASSIFIED<br />

CCI: CCI-001348<br />

NIST SP 800-53 :: AU-9 (2)<br />

NIST SP 800-53A :: AU-9 (2).1 (iii)<br />

Rule Title: The operating system must support the<br />

requirement to centrally manage the content of audit<br />

records generated by organization defined information<br />

system components.<br />

<strong>STIG</strong> ID: RHEL-06-000137 Rule ID: SV-50322r1_rule Vuln<br />

ID: V-38521<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

A log server (loghost) receives syslog messages from one<br />

or more systems. This data can be used as an additional<br />

log source in the event a system is compromised and its<br />

local logs are suspect. Forwarding log messages to a<br />

remote loghost also provides system administrators with<br />

a centralized place to view the status of multiple hosts<br />

within the enterprise.<br />

Documentable: No<br />

Check Content:<br />

To ensure logs are sent to a remote host, examine the file<br />

"/etc/rsyslog.conf". If using UDP, a line similar to the<br />

following should be present:<br />

*.* @[loghost.example.com]<br />

If using TCP, a line similar to the following should be<br />

present:<br />

*.* @@[loghost.example.com]<br />

If using RELP, a line similar to the following should be<br />

present:<br />

UNCLASSIFIED


UNCLASSIFIED<br />

*.* :omrelp:[loghost.example.com]<br />

If none of these are present, this is a finding.<br />

Fix Text:<br />

To configure rsyslog to send logs to a remote log server,<br />

open "/etc/rsyslog.conf" and read and understand the last<br />

section of the file, which describes the multiple<br />

directives necessary to activate remote logging. Along<br />

with these other directives, the system can be configured<br />

to forward its logs to a particular log server by adding<br />

or correcting one of the following lines, substituting<br />

"[loghost.example.com]" appropriately. The choice of<br />

protocol depends on the environment of the system;<br />

although TCP and RELP provide more reliable message<br />

delivery, they may not be supported in all environments.<br />

To use UDP for log message delivery:<br />

*.* @[loghost.example.com]<br />

To use TCP for log message delivery:<br />

*.* @@[loghost.example.com]<br />

To use RELP for log message delivery:<br />

*.* :omrelp:[loghost.example.com]<br />

CCI: CCI-000169<br />

NIST SP 800-53A :: AU-12.1 (ii)<br />

NIST SP 800-53 :: AU-12 a<br />

Rule Title: System logs must be rotated daily.<br />

<strong>STIG</strong> ID: RHEL-06-000138 Rule ID: SV-50425r1_rule Vuln<br />

ID: V-38624<br />

Severity: CAT III Class: Unclass<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Discussion:<br />

Log files that are not properly rotated run the risk of<br />

growing so large that they fill up the /var/log partition.<br />

Valuable logging information could be lost if the<br />

/var/log partition becomes full.<br />

Documentable: No<br />

Check Content:<br />

Run the following commands to determine the current<br />

status of the "logrotate" service:<br />

# grep logrotate /var/log/cron*<br />

If the logrotate service is not run on a daily basis by<br />

cron, this is a finding.<br />

Fix Text:<br />

The "logrotate" service should be installed or<br />

reinstalled if it is not installed and operating<br />

properly, by running the following command:<br />

# yum reinstall logrotate<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: The operating system must produce audit<br />

records containing sufficient information to establish<br />

the identity of any user/subject associated with the<br />

event.<br />

<strong>STIG</strong> ID: RHEL-06-000145 Rule ID: SV-50429r1_rule Vuln<br />

ID: V-38628<br />

Severity: CAT II Class: Unclass<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Discussion:<br />

Ensuring the "auditd" service is active ensures audit<br />

records generated by the kernel can be written to disk,<br />

or that appropriate actions will be taken if other<br />

obstacles exist.<br />

Documentable: No<br />

Check Content:<br />

Run the following command to determine the current status<br />

of the "auditd" service:<br />

# service auditd status<br />

If the service is enabled, it should return the following:<br />

auditd is running...<br />

If the service is not running, this is a finding.<br />

Fix Text:<br />

The "auditd" service is an essential userspace component<br />

of the Linux Auditing System, as it is responsible for<br />

writing audit records to disk. The "auditd" service can<br />

be enabled with the following command:<br />

# chkconfig auditd on<br />

CCI: CCI-001487<br />

NIST SP 800-53 :: AU-3<br />

NIST SP 800-53A :: AU-3.1<br />

Rule Title: The operating system must employ automated<br />

mechanisms to facilitate the monitoring and control of<br />

remote access methods.<br />

<strong>STIG</strong> ID: RHEL-06-000148 Rule ID: SV-50432r1_rule Vuln<br />

ID: V-38631<br />

Severity: CAT II Class: Unclass<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Discussion:<br />

Ensuring the "auditd" service is active ensures audit<br />

records generated by the kernel can be written to disk,<br />

or that appropriate actions will be taken if other<br />

obstacles exist.<br />

Documentable: No<br />

Check Content:<br />

Run the following command to determine the current status<br />

of the "auditd" service:<br />

# service auditd status<br />

If the service is enabled, it should return the following:<br />

auditd is running...<br />

If the service is not running, this is a finding.<br />

Fix Text:<br />

The "auditd" service is an essential userspace component<br />

of the Linux Auditing System, as it is responsible for<br />

writing audit records to disk. The "auditd" service can<br />

be enabled with the following command:<br />

# chkconfig auditd on<br />

CCI: CCI-000067<br />

NIST SP 800-53A :: AC-17 (1).1<br />

NIST SP 800-53 :: AC-17 (1)<br />

Rule Title: The operating system must produce audit<br />

records containing sufficient information to establish<br />

what type of events occurred.<br />

<strong>STIG</strong> ID: RHEL-06-000154 Rule ID: SV-50433r1_rule Vuln<br />

UNCLASSIFIED


UNCLASSIFIED<br />

ID: V-38632<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

Ensuring the "auditd" service is active ensures audit<br />

records generated by the kernel can be written to disk,<br />

or that appropriate actions will be taken if other<br />

obstacles exist.<br />

Documentable: No<br />

Check Content:<br />

Run the following command to determine the current status<br />

of the "auditd" service:<br />

# service auditd status<br />

If the service is enabled, it should return the following:<br />

auditd is running...<br />

If the service is not running, this is a finding.<br />

Fix Text:<br />

The "auditd" service is an essential userspace component<br />

of the Linux Auditing System, as it is responsible for<br />

writing audit records to disk. The "auditd" service can<br />

be enabled with the following command:<br />

# chkconfig auditd on<br />

CCI: CCI-000130<br />

NIST SP 800-53A :: AU-3.1<br />

NIST SP 800-53 :: AU-3<br />

Rule Title: The system must retain enough rotated audit<br />

logs to cover the required log retention period.<br />

UNCLASSIFIED


UNCLASSIFIED<br />

<strong>STIG</strong> ID: RHEL-06-000159 Rule ID: SV-50437r1_rule Vuln<br />

ID: V-38636<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

The total storage for audit log files must be large enough<br />

to retain log information over the period required. This<br />

is a function of the maximum log file size and the number<br />

of logs retained.<br />

Documentable: No<br />

Check Content:<br />

Inspect "/etc/audit/auditd.conf" and locate the<br />

following line to determine how many logs the system is<br />

configured to retain after rotation: "# grep num_logs<br />

/etc/audit/auditd.conf"<br />

num_logs = 5<br />

If the overall system log file(s) retention hasn't been<br />

properly set up, this is a finding.<br />

Fix Text:<br />

Determine how many log files "auditd" should retain when<br />

it rotates logs. Edit the file "/etc/audit/auditd.conf".<br />

Add or modify the following line, substituting [NUMLOGS]<br />

with the correct value:<br />

num_logs = [NUMLOGS]<br />

Set the value to 5 for general-purpose systems. Note that<br />

values less than 2 result in no log rotation.<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Rule Title: The system must set a maximum audit log file<br />

size.<br />

<strong>STIG</strong> ID: RHEL-06-000160 Rule ID: SV-50434r1_rule Vuln<br />

ID: V-38633<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

The total storage for audit log files must be large enough<br />

to retain log information over the period required. This<br />

is a function of the maximum log file size and the number<br />

of logs retained.<br />

Documentable: No<br />

Check Content:<br />

Inspect "/etc/audit/auditd.conf" and locate the<br />

following line to determine how much data the system will<br />

retain in each audit log file: "# grep max_log_file<br />

/etc/audit/auditd.conf"<br />

max_log_file = 6<br />

If the system audit data threshold hasn't been properly<br />

set up, this is a finding.<br />

Fix Text:<br />

Determine the amount of audit data (in megabytes) which<br />

should be retained in each log file. Edit the file<br />

"/etc/audit/auditd.conf". Add or modify the following<br />

line, substituting the correct value for [STOREMB]:<br />

max_log_file = [STOREMB]<br />

Set the value to "6" (MB) or higher for general-purpose<br />

systems. Larger values, of course, support retention of<br />

even more audit data.<br />

CCI: CCI-000366<br />

UNCLASSIFIED


UNCLASSIFIED<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: The system must rotate audit log files that<br />

reach the maximum file size.<br />

<strong>STIG</strong> ID: RHEL-06-000161 Rule ID: SV-50435r1_rule Vuln<br />

ID: V-38634<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

Automatically rotating logs (by setting this to "rotate")<br />

minimizes the chances of the system unexpectedly running<br />

out of disk space by being overwhelmed with log data.<br />

However, for systems that must never discard log data,<br />

or which use external processes to transfer it and reclaim<br />

space, "keep_logs" can be employed.<br />

Documentable: No<br />

Check Content:<br />

Inspect "/etc/audit/auditd.conf" and locate the<br />

following line to determine if the system is configured<br />

to rotate logs when they reach their maximum size: "# grep<br />

max_log_file_action /etc/audit/auditd.conf"<br />

max_log_file_action "rotate"<br />

If the system has not been properly set up to rotate audit<br />

logs, this is a finding.<br />

Fix Text:<br />

The default action to take when the logs reach their<br />

maximum size is to rotate the log files, discarding the<br />

oldest one. To configure the action taken by "auditd",<br />

add or correct the line in "/etc/audit/auditd.conf":<br />

max_log_file_action = [ACTION]<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Possible values for [ACTION] are described in the<br />

"auditd.conf" man page. These include:<br />

"ignore"<br />

"syslog"<br />

"suspend"<br />

"rotate"<br />

"keep_logs"<br />

Set the "[ACTION]" to "rotate" to ensure log rotation<br />

occurs. This is the default. The setting is<br />

case-insensitive.<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: The audit system must be configured to audit<br />

all attempts to alter system time through adjtimex.<br />

<strong>STIG</strong> ID: RHEL-06-000165 Rule ID: SV-50436r1_rule Vuln<br />

ID: V-38635<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

Arbitrary changes to the system time can be used to<br />

obfuscate nefarious activities in log files, as well as<br />

to confuse network services that are highly dependent<br />

upon an accurate system time (such as sshd). All changes<br />

to the system time should be audited.<br />

Documentable: No<br />

Check Content:<br />

To determine if the system is configured to audit calls<br />

to the "adjtimex" system call, run the following command:<br />

UNCLASSIFIED


UNCLASSIFIED<br />

# auditctl -l | grep syscall | grep adjtimex<br />

If the system is configured to audit this activity, it<br />

will return a line.<br />

If the system is not configured to audit time changes,<br />

this is a finding.<br />

Fix Text:<br />

On a 32-bit system, add the following to<br />

"/etc/audit/audit.rules":<br />

# audit_time_rules<br />

-a always,exit -F arch=b32 -S adjtimex -k<br />

audit_time_rules<br />

On a 64-bit system, add the following to<br />

"/etc/audit/audit.rules":<br />

# audit_time_rules<br />

-a always,exit -F arch=b64 -S adjtimex -k<br />

audit_time_rules<br />

The -k option allows for the specification of a key in<br />

string form that can be used for better reporting<br />

capability through ausearch and aureport. Multiple<br />

system calls can be defined on the same line to save space<br />

if desired, but is not required. See an example of<br />

multiple combined syscalls:<br />

-a always,exit -F arch=b64 -S adjtimex -S settimeofday<br />

-S clock_settime<br />

-k audit_time_rules<br />

CCI: CCI-000169<br />

NIST SP 800-53A :: AU-12.1 (ii)<br />

NIST SP 800-53 :: AU-12 a<br />

Rule Title: The audit system must be configured to audit<br />

all attempts to alter system time through settimeofday.<br />

UNCLASSIFIED


UNCLASSIFIED<br />

<strong>STIG</strong> ID: RHEL-06-000167 Rule ID: SV-50323r1_rule Vuln<br />

ID: V-38522<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

Arbitrary changes to the system time can be used to<br />

obfuscate nefarious activities in log files, as well as<br />

to confuse network services that are highly dependent<br />

upon an accurate system time (such as sshd). All changes<br />

to the system time should be audited.<br />

Documentable: No<br />

Check Content:<br />

To determine if the system is configured to audit calls<br />

to the "settimeofday" system call, run the following<br />

command:<br />

# auditctl -l | grep syscall | grep settimeofday<br />

If the system is configured to audit this activity, it<br />

will return a line.<br />

If the system is not configured to audit time changes,<br />

this is a finding.<br />

Fix Text:<br />

On a 32-bit system, add the following to<br />

"/etc/audit/audit.rules":<br />

# audit_time_rules<br />

-a always,exit -F arch=b32 -S settimeofday -k<br />

audit_time_rules<br />

On a 64-bit system, add the following to<br />

"/etc/audit/audit.rules":<br />

# audit_time_rules<br />

-a always,exit -F arch=b64 -S settimeofday -k<br />

audit_time_rules<br />

UNCLASSIFIED


UNCLASSIFIED<br />

The -k option allows for the specification of a key in<br />

string form that can be used for better reporting<br />

capability through ausearch and aureport. Multiple<br />

system calls can be defined on the same line to save space<br />

if desired, but is not required. See an example of<br />

multiple combined syscalls:<br />

-a always,exit -F arch=b64 -S adjtimex -S settimeofday<br />

-S clock_settime<br />

-k audit_time_rules<br />

CCI: CCI-000169<br />

NIST SP 800-53A :: AU-12.1 (ii)<br />

NIST SP 800-53 :: AU-12 a<br />

Rule Title: The audit system must be configured to audit<br />

all attempts to alter system time through stime.<br />

<strong>STIG</strong> ID: RHEL-06-000169 Rule ID: SV-50326r1_rule Vuln<br />

ID: V-38525<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

Arbitrary changes to the system time can be used to<br />

obfuscate nefarious activities in log files, as well as<br />

to confuse network services that are highly dependent<br />

upon an accurate system time (such as sshd). All changes<br />

to the system time should be audited.<br />

Documentable: No<br />

Check Content:<br />

To determine if the system is configured to audit calls<br />

to the "stime" system call, run the following command:<br />

# auditctl -l | grep syscall | grep stime<br />

If the system is configured to audit this activity, it<br />

will return a line.<br />

UNCLASSIFIED


UNCLASSIFIED<br />

If the system is not configured to audit time changes,<br />

this is a finding.<br />

Fix Text:<br />

On a 32-bit system, add the following to<br />

"/etc/audit/audit.rules":<br />

# audit_time_rules<br />

-a always,exit -F arch=b32 -S stime -k audit_time_rules<br />

On a 64-bit system, the "-S time" is not necessary. The<br />

-k option allows for the specification of a key in string<br />

form that can be used for better reporting capability<br />

through ausearch and aureport. Multiple system calls can<br />

be defined on the same line to save space if desired, but<br />

is not required. See an example of multiple combined<br />

syscalls:<br />

-a always,exit -F arch=b64 -S adjtimex -S settimeofday<br />

-S clock_settime<br />

-k audit_time_rules<br />

CCI: CCI-000169<br />

NIST SP 800-53A :: AU-12.1 (ii)<br />

NIST SP 800-53 :: AU-12 a<br />

Rule Title: The audit system must be configured to audit<br />

all attempts to alter system time through clock_settime.<br />

<strong>STIG</strong> ID: RHEL-06-000171 Rule ID: SV-50328r1_rule Vuln<br />

ID: V-38527<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

Arbitrary changes to the system time can be used to<br />

obfuscate nefarious activities in log files, as well as<br />

to confuse network services that are highly dependent<br />

upon an accurate system time (such as sshd). All changes<br />

to the system time should be audited.<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Documentable: No<br />

Check Content:<br />

To determine if the system is configured to audit calls<br />

to the "clock_settime" system call, run the following<br />

command:<br />

# auditctl -l | grep syscall | grep clock_settime<br />

If the system is configured to audit this activity, it<br />

will return a line.<br />

If the system is not configured to audit time changes,<br />

this is a finding.<br />

Fix Text:<br />

On a 32-bit system, add the following to<br />

"/etc/audit/audit.rules":<br />

# audit_time_rules<br />

-a always,exit -F arch=b32 -S clock_settime -k<br />

audit_time_rules<br />

On a 64-bit system, add the following to<br />

"/etc/audit/audit.rules":<br />

# audit_time_rules<br />

-a always,exit -F arch=b64 -S clock_settime -k<br />

audit_time_rules<br />

The -k option allows for the specification of a key in<br />

string form that can be used for better reporting<br />

capability through ausearch and aureport. Multiple<br />

system calls can be defined on the same line to save space<br />

if desired, but is not required. See an example of<br />

multiple combined syscalls:<br />

-a always,exit -F arch=b64 -S adjtimex -S settimeofday<br />

-S clock_settime<br />

-k audit_time_rules<br />

UNCLASSIFIED


UNCLASSIFIED<br />

CCI: CCI-000169<br />

NIST SP 800-53A :: AU-12.1 (ii)<br />

NIST SP 800-53 :: AU-12 a<br />

Rule Title: The audit system must be configured to audit<br />

all attempts to alter system time through /etc/localtime.<br />

<strong>STIG</strong> ID: RHEL-06-000173 Rule ID: SV-50331r1_rule Vuln<br />

ID: V-38530<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

Arbitrary changes to the system time can be used to<br />

obfuscate nefarious activities in log files, as well as<br />

to confuse network services that are highly dependent<br />

upon an accurate system time (such as sshd). All changes<br />

to the system time should be audited.<br />

Documentable: No<br />

Check Content:<br />

To determine if the system is configured to audit attempts<br />

to alter time via the /etc/localtime file, run the<br />

following command:<br />

# auditctl -l | grep "watch=/etc/localtime"<br />

If the system is configured to audit this activity, it<br />

will return a line.<br />

If the system is not configured to audit time changes,<br />

this is a finding.<br />

Fix Text:<br />

Add the following to "/etc/audit/audit.rules":<br />

-w /etc/localtime -p wa -k audit_time_rules<br />

The -k option allows for the specification of a key in<br />

UNCLASSIFIED


UNCLASSIFIED<br />

string form that can be used for better reporting<br />

capability through ausearch and aureport and should<br />

always be used.<br />

CCI: CCI-000169<br />

NIST SP 800-53A :: AU-12.1 (ii)<br />

NIST SP 800-53 :: AU-12 a<br />

Rule Title: The operating system must automatically<br />

audit account creation.<br />

<strong>STIG</strong> ID: RHEL-06-000174 Rule ID: SV-50332r1_rule Vuln<br />

ID: V-38531<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

In addition to auditing new user and group accounts, these<br />

watches will alert the system administrator(s) to any<br />

modifications. Any unexpected users, groups, or<br />

modifications should be investigated for legitimacy.<br />

Documentable: No<br />

Check Content:<br />

To determine if the system is configured to audit account<br />

changes, run the following command:<br />

auditctl -l | egrep<br />

'(/etc/passwd|/etc/shadow|/etc/group|/etc/gshadow|/et<br />

c/security/opasswd)'<br />

If the system is configured to watch for account changes,<br />

lines should be returned for each file specified (and with<br />

"perm=wa" for each).<br />

If the system is not configured to audit account changes,<br />

this is a finding.<br />

Fix Text:<br />

Add the following to "/etc/audit/audit.rules", in order<br />

UNCLASSIFIED


UNCLASSIFIED<br />

to capture events that modify account changes:<br />

# audit_account_changes<br />

-w /etc/group -p wa -k audit_account_changes<br />

-w /etc/passwd -p wa -k audit_account_changes<br />

-w /etc/gshadow -p wa -k audit_account_changes<br />

-w /etc/shadow -p wa -k audit_account_changes<br />

-w /etc/security/opasswd -p wa -k audit_account_changes<br />

CCI: CCI-000018<br />

NIST SP 800-53 :: AC-2 (4)<br />

NIST SP 800-53A :: AC-2 (4).1 (i&ii)<br />

Rule Title: The operating system must automatically<br />

audit account modification.<br />

<strong>STIG</strong> ID: RHEL-06-000175 Rule ID: SV-50335r1_rule Vuln<br />

ID: V-38534<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

In addition to auditing new user and group accounts, these<br />

watches will alert the system administrator(s) to any<br />

modifications. Any unexpected users, groups, or<br />

modifications should be investigated for legitimacy.<br />

Documentable: No<br />

Check Content:<br />

To determine if the system is configured to audit account<br />

changes, run the following command:<br />

auditctl -l | egrep<br />

'(/etc/passwd|/etc/shadow|/etc/group|/etc/gshadow|/et<br />

c/security/opasswd)'<br />

If the system is configured to watch for account changes,<br />

lines should be returned for each file specified (and with<br />

"perm=wa" for each).<br />

UNCLASSIFIED


UNCLASSIFIED<br />

If the system is not configured to audit account changes,<br />

this is a finding.<br />

Fix Text:<br />

Add the following to "/etc/audit/audit.rules", in order<br />

to capture events that modify account changes:<br />

# audit_account_changes<br />

-w /etc/group -p wa -k audit_account_changes<br />

-w /etc/passwd -p wa -k audit_account_changes<br />

-w /etc/gshadow -p wa -k audit_account_changes<br />

-w /etc/shadow -p wa -k audit_account_changes<br />

-w /etc/security/opasswd -p wa -k audit_account_changes<br />

CCI: CCI-001403<br />

NIST SP 800-53A :: AC-2 (4).1 (i&ii)<br />

NIST SP 800-53 :: AC-2 (4)<br />

Rule Title: The operating system must automatically<br />

audit account disabling actions.<br />

<strong>STIG</strong> ID: RHEL-06-000176 Rule ID: SV-50337r1_rule Vuln<br />

ID: V-38536<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

In addition to auditing new user and group accounts, these<br />

watches will alert the system administrator(s) to any<br />

modifications. Any unexpected users, groups, or<br />

modifications should be investigated for legitimacy.<br />

Documentable: No<br />

Check Content:<br />

To determine if the system is configured to audit account<br />

changes, run the following command:<br />

auditctl -l | egrep<br />

'(/etc/passwd|/etc/shadow|/etc/group|/etc/gshadow|/et<br />

UNCLASSIFIED


UNCLASSIFIED<br />

c/security/opasswd)'<br />

If the system is configured to watch for account changes,<br />

lines should be returned for each file specified (and with<br />

"perm=wa" for each).<br />

If the system is not configured to audit account changes,<br />

this is a finding.<br />

Fix Text:<br />

Add the following to "/etc/audit/audit.rules", in order<br />

to capture events that modify account changes:<br />

# audit_account_changes<br />

-w /etc/group -p wa -k audit_account_changes<br />

-w /etc/passwd -p wa -k audit_account_changes<br />

-w /etc/gshadow -p wa -k audit_account_changes<br />

-w /etc/shadow -p wa -k audit_account_changes<br />

-w /etc/security/opasswd -p wa -k audit_account_changes<br />

CCI: CCI-001404<br />

NIST SP 800-53A :: AC-2 (4).1 (i&ii)<br />

NIST SP 800-53 :: AC-2 (4)<br />

Rule Title: The operating system must automatically<br />

audit account termination.<br />

<strong>STIG</strong> ID: RHEL-06-000177 Rule ID: SV-50339r1_rule Vuln<br />

ID: V-38538<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

In addition to auditing new user and group accounts, these<br />

watches will alert the system administrator(s) to any<br />

modifications. Any unexpected users, groups, or<br />

modifications should be investigated for legitimacy.<br />

Documentable: No<br />

Check Content:<br />

UNCLASSIFIED


UNCLASSIFIED<br />

To determine if the system is configured to audit account<br />

changes, run the following command:<br />

auditctl -l | egrep<br />

'(/etc/passwd|/etc/shadow|/etc/group|/etc/gshadow|/et<br />

c/security/opasswd)'<br />

If the system is configured to watch for account changes,<br />

lines should be returned for each file specified (and with<br />

"perm=wa" for each).<br />

If the system is not configured to audit account changes,<br />

this is a finding.<br />

Fix Text:<br />

Add the following to "/etc/audit/audit.rules", in order<br />

to capture events that modify account changes:<br />

# audit_account_changes<br />

-w /etc/group -p wa -k audit_account_changes<br />

-w /etc/passwd -p wa -k audit_account_changes<br />

-w /etc/gshadow -p wa -k audit_account_changes<br />

-w /etc/shadow -p wa -k audit_account_changes<br />

-w /etc/security/opasswd -p wa -k audit_account_changes<br />

CCI: CCI-001405<br />

NIST SP 800-53A :: AC-2 (4).1 (i&ii)<br />

NIST SP 800-53 :: AC-2 (4)<br />

Rule Title: The audit system must be configured to audit<br />

modifications to the systems network configuration.<br />

<strong>STIG</strong> ID: RHEL-06-000182 Rule ID: SV-50341r1_rule Vuln<br />

ID: V-38540<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

The network environment should not be modified by<br />

anything other than administrator action. Any change to<br />

network parameters should be audited.<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Documentable: No<br />

Check Content:<br />

To determine if the system is configured to audit changes<br />

to its network configuration, run the following command:<br />

auditctl -l | egrep<br />

'(sethostname|setdomainname|/etc/issue|/etc/issue.net<br />

|/etc/hosts|/etc/sysconfig/network)'<br />

If the system is configured to watch for network<br />

configuration changes, a line should be returned for each<br />

file specified (and "perm=wa" should be indicated for<br />

each).<br />

If the system is not configured to audit changes of the<br />

network configuration, this is a finding.<br />

Fix Text:<br />

Add the following to "/etc/audit/audit.rules", setting<br />

ARCH to either b32 or b64 as appropriate for your system:<br />

# audit_network_modifications<br />

-a exit,always -F arch=ARCH -S sethostname -S<br />

setdomainname -k audit_network_modifications<br />

-w /etc/issue -p wa -k audit_network_modifications<br />

-w /etc/issue.net -p wa -k audit_network_modifications<br />

-w /etc/hosts -p wa -k audit_network_modifications<br />

-w /etc/sysconfig/network -p wa -k<br />

audit_network_modifications<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: The audit system must be configured to audit<br />

modifications to the systems Mandatory Access Control<br />

(MAC) configuration (SELinux).<br />

<strong>STIG</strong> ID: RHEL-06-000183 Rule ID: SV-50342r1_rule Vuln<br />

UNCLASSIFIED


UNCLASSIFIED<br />

ID: V-38541<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

The system's mandatory access policy (SELinux) should not<br />

be arbitrarily changed by anything other than<br />

administrator action. All changes to MAC policy should<br />

be audited.<br />

Documentable: No<br />

Check Content:<br />

To determine if the system is configured to audit changes<br />

to its SELinux configuration files, run the following<br />

command:<br />

# auditctl -l | grep "dir=/etc/selinux"<br />

If the system is configured to watch for changes to its<br />

SELinux configuration, a line should be returned<br />

(including "perm=wa" indicating permissions that are<br />

watched).<br />

If the system is not configured to audit attempts to<br />

change the MAC policy, this is a finding.<br />

Fix Text:<br />

Add the following to "/etc/audit/audit.rules":<br />

-w /etc/selinux/ -p wa -k MAC-policy<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: The audit system must be configured to audit<br />

all discretionary access control permission<br />

modifications using chmod.<br />

<strong>STIG</strong> ID: RHEL-06-000184 Rule ID: SV-50344r1_rule Vuln<br />

UNCLASSIFIED


UNCLASSIFIED<br />

ID: V-38543<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

The changing of file permissions could indicate that a<br />

user is attempting to gain access to information that<br />

would otherwise be disallowed. Auditing DAC<br />

modifications can facilitate the identification of<br />

patterns of abuse among both authorized and unauthorized<br />

users.<br />

Documentable: No<br />

Check Content:<br />

To determine if the system is configured to audit calls<br />

to the "chmod" system call, run the following command:<br />

# auditctl -l | grep syscall | grep chmod<br />

If the system is configured to audit this activity, it<br />

will return several lines.<br />

If no lines are returned, this is a finding.<br />

Fix Text:<br />

At a minimum, the audit system should collect file<br />

permission changes for all users and root. Add the<br />

following to "/etc/audit/audit.rules":<br />

-a always,exit -F arch=b32 -S chmod -F auid>=500 -F<br />

auid!=4294967295 \<br />

-k perm_mod<br />

-a always,exit -F arch=b32 -S chmod -F auid==0 -k perm_mod<br />

If the system is 64-bit, then also add the following:<br />

-a always,exit -F arch=b64 -S chmod -F auid>=500 -F<br />

auid!=4294967295 \<br />

-k perm_mod<br />

-a always,exit -F arch=b64 -S chmod -F auid==0 -k perm_mod<br />

UNCLASSIFIED


UNCLASSIFIED<br />

CCI: CCI-000172<br />

NIST SP 800-53A :: AU-12.1 (iv)<br />

NIST SP 800-53 :: AU-12 c<br />

Rule Title: The audit system must be configured to audit<br />

all discretionary access control permission<br />

modifications using chown.<br />

<strong>STIG</strong> ID: RHEL-06-000185 Rule ID: SV-50346r1_rule Vuln<br />

ID: V-38545<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

The changing of file permissions could indicate that a<br />

user is attempting to gain access to information that<br />

would otherwise be disallowed. Auditing DAC<br />

modifications can facilitate the identification of<br />

patterns of abuse among both authorized and unauthorized<br />

users.<br />

Documentable: No<br />

Check Content:<br />

To determine if the system is configured to audit calls<br />

to the "chown" system call, run the following command:<br />

# auditctl -l | grep syscall | grep chown<br />

If the system is configured to audit this activity, it<br />

will return several lines.<br />

If no lines are returned, this is a finding.<br />

Fix Text:<br />

At a minimum, the audit system should collect file<br />

permission changes for all users and root. Add the<br />

following to "/etc/audit/audit.rules":<br />

-a always,exit -F arch=b32 -S chown -F auid>=500 -F<br />

auid!=4294967295 \<br />

UNCLASSIFIED


UNCLASSIFIED<br />

-k perm_mod<br />

-a always,exit -F arch=b32 -S chown -F auid==0 -k perm_mod<br />

If the system is 64-bit, then also add the following:<br />

-a always,exit -F arch=b64 -S chown -F auid>=500 -F<br />

auid!=4294967295 \<br />

-k perm_mod<br />

-a always,exit -F arch=b64 -S chown -F auid==0 -k perm_mod<br />

CCI: CCI-000172<br />

NIST SP 800-53A :: AU-12.1 (iv)<br />

NIST SP 800-53 :: AU-12 c<br />

Rule Title: The audit system must be configured to audit<br />

all discretionary access control permission<br />

modifications using fchmod.<br />

<strong>STIG</strong> ID: RHEL-06-000186 Rule ID: SV-50348r1_rule Vuln<br />

ID: V-38547<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

The changing of file permissions could indicate that a<br />

user is attempting to gain access to information that<br />

would otherwise be disallowed. Auditing DAC<br />

modifications can facilitate the identification of<br />

patterns of abuse among both authorized and unauthorized<br />

users.<br />

Documentable: No<br />

Check Content:<br />

To determine if the system is configured to audit calls<br />

to the "fchmod" system call, run the following command:<br />

# auditctl -l | grep syscall | grep fchmod<br />

If the system is configured to audit this activity, it<br />

UNCLASSIFIED


UNCLASSIFIED<br />

will return several lines.<br />

If no lines are returned, this is a finding.<br />

Fix Text:<br />

At a minimum, the audit system should collect file<br />

permission changes for all users and root. Add the<br />

following to "/etc/audit/audit.rules":<br />

-a always,exit -F arch=b32 -S fchmod -F auid>=500 -F<br />

auid!=4294967295 \<br />

-k perm_mod<br />

-a always,exit -F arch=b32 -S fchmod -F auid==0 -k<br />

perm_mod<br />

If the system is 64-bit, then also add the following:<br />

-a always,exit -F arch=b64 -S fchmod -F auid>=500 -F<br />

auid!=4294967295 \<br />

-k perm_mod<br />

-a always,exit -F arch=b64 -S fchmod -F auid==0 -k<br />

perm_mod<br />

CCI: CCI-000172<br />

NIST SP 800-53A :: AU-12.1 (iv)<br />

NIST SP 800-53 :: AU-12 c<br />

Rule Title: The audit system must be configured to audit<br />

all discretionary access control permission<br />

modifications using fchmodat.<br />

<strong>STIG</strong> ID: RHEL-06-000187 Rule ID: SV-50351r1_rule Vuln<br />

ID: V-38550<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

The changing of file permissions could indicate that a<br />

user is attempting to gain access to information that<br />

would otherwise be disallowed. Auditing DAC<br />

modifications can facilitate the identification of<br />

UNCLASSIFIED


UNCLASSIFIED<br />

patterns of abuse among both authorized and unauthorized<br />

users.<br />

Documentable: No<br />

Check Content:<br />

To determine if the system is configured to audit calls<br />

to the "fchmodat" system call, run the following command:<br />

# auditctl -l | grep syscall | grep fchmodat<br />

If the system is configured to audit this activity, it<br />

will return several lines.<br />

If no lines are returned, this is a finding.<br />

Fix Text:<br />

At a minimum, the audit system should collect file<br />

permission changes for all users and root. Add the<br />

following to "/etc/audit/audit.rules":<br />

-a always,exit -F arch=b32 -S fchmodat -F auid>=500 -F<br />

auid!=4294967295 \<br />

-k perm_mod<br />

-a always,exit -F arch=b32 -S fchmodat -F auid==0 -k<br />

perm_mod<br />

If the system is 64-bit, then also add the following:<br />

-a always,exit -F arch=b64 -S fchmodat -F auid>=500 -F<br />

auid!=4294967295 \<br />

-k perm_mod<br />

-a always,exit -F arch=b64 -S fchmodat -F auid==0 -k<br />

perm_mod<br />

CCI: CCI-000172<br />

NIST SP 800-53A :: AU-12.1 (iv)<br />

NIST SP 800-53 :: AU-12 c<br />

Rule Title: The audit system must be configured to audit<br />

UNCLASSIFIED


UNCLASSIFIED<br />

all discretionary access control permission<br />

modifications using fchown.<br />

<strong>STIG</strong> ID: RHEL-06-000188 Rule ID: SV-50353r1_rule Vuln<br />

ID: V-38552<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

The changing of file permissions could indicate that a<br />

user is attempting to gain access to information that<br />

would otherwise be disallowed. Auditing DAC<br />

modifications can facilitate the identification of<br />

patterns of abuse among both authorized and unauthorized<br />

users.<br />

Documentable: No<br />

Check Content:<br />

To determine if the system is configured to audit calls<br />

to the "fchown" system call, run the following command:<br />

# auditctl -l | grep syscall | grep fchown<br />

If the system is configured to audit this activity, it<br />

will return several lines.<br />

If no lines are returned, this is a finding.<br />

Fix Text:<br />

At a minimum, the audit system should collect file<br />

permission changes for all users and root. Add the<br />

following to "/etc/audit/audit.rules":<br />

-a always,exit -F arch=b32 -S fchown -F auid>=500 -F<br />

auid!=4294967295 \<br />

-k perm_mod<br />

-a always,exit -F arch=b32 -S fchown -F auid==0 -k<br />

perm_mod<br />

If the system is 64-bit, then also add the following:<br />

-a always,exit -F arch=b64 -S fchown -F auid>=500 -F<br />

UNCLASSIFIED


UNCLASSIFIED<br />

auid!=4294967295 \<br />

-k perm_mod<br />

-a always,exit -F arch=b64 -S fchown -F auid==0 -k<br />

perm_mod<br />

CCI: CCI-000172<br />

NIST SP 800-53A :: AU-12.1 (iv)<br />

NIST SP 800-53 :: AU-12 c<br />

Rule Title: The audit system must be configured to audit<br />

all discretionary access control permission<br />

modifications using fchownat.<br />

<strong>STIG</strong> ID: RHEL-06-000189 Rule ID: SV-50355r1_rule Vuln<br />

ID: V-38554<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

The changing of file permissions could indicate that a<br />

user is attempting to gain access to information that<br />

would otherwise be disallowed. Auditing DAC<br />

modifications can facilitate the identification of<br />

patterns of abuse among both authorized and unauthorized<br />

users.<br />

Documentable: No<br />

Check Content:<br />

To determine if the system is configured to audit calls<br />

to the "fchownat" system call, run the following command:<br />

# auditctl -l | grep syscall | grep fchownat<br />

If the system is configured to audit this activity, it<br />

will return several lines.<br />

If no lines are returned, this is a finding.<br />

Fix Text:<br />

At a minimum, the audit system should collect file<br />

UNCLASSIFIED


UNCLASSIFIED<br />

permission changes for all users and root. Add the<br />

following to "/etc/audit/audit.rules":<br />

-a always,exit -F arch=b32 -S fchownat -F auid>=500 -F<br />

auid!=4294967295 \<br />

-k perm_mod<br />

-a always,exit -F arch=b32 -S fchownat -F auid==0 -k<br />

perm_mod<br />

If the system is 64-bit, then also add the following:<br />

-a always,exit -F arch=b64 -S fchownat -F auid>=500 -F<br />

auid!=4294967295 \<br />

-k perm_mod<br />

-a always,exit -F arch=b64 -S fchownat -F auid==0 -k<br />

perm_mod<br />

CCI: CCI-000172<br />

NIST SP 800-53A :: AU-12.1 (iv)<br />

NIST SP 800-53 :: AU-12 c<br />

Rule Title: The audit system must be configured to audit<br />

all discretionary access control permission<br />

modifications using fremovexattr.<br />

<strong>STIG</strong> ID: RHEL-06-000190 Rule ID: SV-50357r1_rule Vuln<br />

ID: V-38556<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

The changing of file permissions could indicate that a<br />

user is attempting to gain access to information that<br />

would otherwise be disallowed. Auditing DAC<br />

modifications can facilitate the identification of<br />

patterns of abuse among both authorized and unauthorized<br />

users.<br />

Documentable: No<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Check Content:<br />

To determine if the system is configured to audit calls<br />

to the "fremovexattr" system call, run the following<br />

command:<br />

# auditctl -l | grep syscall | grep fremovexattr<br />

If the system is configured to audit this activity, it<br />

will return several lines.<br />

If no lines are returned, this is a finding.<br />

Fix Text:<br />

At a minimum, the audit system should collect file<br />

permission changes for all users and root. Add the<br />

following to "/etc/audit/audit.rules":<br />

-a always,exit -F arch=b32 -S fremovexattr -F auid>=500<br />

-F auid!=4294967295 \<br />

-k perm_mod<br />

-a always,exit -F arch=b32 -S fremovexattr -F auid==0 -k<br />

perm_mod<br />

If the system is 64-bit, then also add the following:<br />

-a always,exit -F arch=b64 -S fremovexattr -F auid>=500<br />

-F auid!=4294967295 \<br />

-k perm_mod<br />

-a always,exit -F arch=b64 -S fremovexattr -F auid==0 -k<br />

perm_mod<br />

CCI: CCI-000172<br />

NIST SP 800-53A :: AU-12.1 (iv)<br />

NIST SP 800-53 :: AU-12 c<br />

Rule Title: The audit system must be configured to audit<br />

all discretionary access control permission<br />

modifications using fsetxattr.<br />

<strong>STIG</strong> ID: RHEL-06-000191 Rule ID: SV-50358r1_rule Vuln<br />

ID: V-38557<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

The changing of file permissions could indicate that a<br />

user is attempting to gain access to information that<br />

would otherwise be disallowed. Auditing DAC<br />

modifications can facilitate the identification of<br />

patterns of abuse among both authorized and unauthorized<br />

users.<br />

Documentable: No<br />

Check Content:<br />

To determine if the system is configured to audit calls<br />

to the "fsetxattr" system call, run the following<br />

command:<br />

# auditctl -l | grep syscall | grep fsetxattr<br />

If the system is configured to audit this activity, it<br />

will return several lines.<br />

If no lines are returned, this is a finding.<br />

Fix Text:<br />

At a minimum, the audit system should collect file<br />

permission changes for all users and root. Add the<br />

following to "/etc/audit/audit.rules":<br />

-a always,exit -F arch=b32 -S fsetxattr -F auid>=500 -F<br />

auid!=4294967295 \<br />

-k perm_mod<br />

-a always,exit -F arch=b32 -S fsetxattr -F auid==0 -k<br />

perm_mod<br />

If the system is 64-bit, then also add the following:<br />

-a always,exit -F arch=b64 -S fsetxattr -F auid>=500 -F<br />

auid!=4294967295 \<br />

-k perm_mod<br />

-a always,exit -F arch=b64 -S fsetxattr -F auid==0 -k<br />

UNCLASSIFIED


UNCLASSIFIED<br />

perm_mod<br />

CCI: CCI-000172<br />

NIST SP 800-53A :: AU-12.1 (iv)<br />

NIST SP 800-53 :: AU-12 c<br />

Rule Title: The audit system must be configured to audit<br />

all discretionary access control permission<br />

modifications using lchown.<br />

<strong>STIG</strong> ID: RHEL-06-000192 Rule ID: SV-50359r1_rule Vuln<br />

ID: V-38558<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

The changing of file permissions could indicate that a<br />

user is attempting to gain access to information that<br />

would otherwise be disallowed. Auditing DAC<br />

modifications can facilitate the identification of<br />

patterns of abuse among both authorized and unauthorized<br />

users.<br />

Documentable: No<br />

Check Content:<br />

To determine if the system is configured to audit calls<br />

to the "lchown" system call, run the following command:<br />

# auditctl -l | grep syscall | grep lchown<br />

If the system is configured to audit this activity, it<br />

will return several lines.<br />

If no lines are returned, this is a finding.<br />

Fix Text:<br />

At a minimum, the audit system should collect file<br />

permission changes for all users and root. Add the<br />

following to "/etc/audit/audit.rules":<br />

UNCLASSIFIED


UNCLASSIFIED<br />

-a always,exit -F arch=b32 -S lchown -F auid>=500 -F<br />

auid!=4294967295 \<br />

-k perm_mod<br />

-a always,exit -F arch=b32 -S lchown -F auid==0 -k<br />

perm_mod<br />

If the system is 64-bit, then also add the following:<br />

-a always,exit -F arch=b64 -S lchown -F auid>=500 -F<br />

auid!=4294967295 \<br />

-k perm_mod<br />

-a always,exit -F arch=b64 -S lchown -F auid==0 -k<br />

perm_mod<br />

CCI: CCI-000172<br />

NIST SP 800-53A :: AU-12.1 (iv)<br />

NIST SP 800-53 :: AU-12 c<br />

Rule Title: The audit system must be configured to audit<br />

all discretionary access control permission<br />

modifications using lremovexattr.<br />

<strong>STIG</strong> ID: RHEL-06-000193 Rule ID: SV-50360r1_rule Vuln<br />

ID: V-38559<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

The changing of file permissions could indicate that a<br />

user is attempting to gain access to information that<br />

would otherwise be disallowed. Auditing DAC<br />

modifications can facilitate the identification of<br />

patterns of abuse among both authorized and unauthorized<br />

users.<br />

Documentable: No<br />

Check Content:<br />

To determine if the system is configured to audit calls<br />

to the "lremovexattr" system call, run the following<br />

UNCLASSIFIED


UNCLASSIFIED<br />

command:<br />

# auditctl -l | grep syscall | grep lremovexattr<br />

If the system is configured to audit this activity, it<br />

will return several lines.<br />

If no lines are returned, this is a finding.<br />

Fix Text:<br />

At a minimum, the audit system should collect file<br />

permission changes for all users and root. Add the<br />

following to "/etc/audit/audit.rules":<br />

-a always,exit -F arch=b32 -S lremovexattr -F auid>=500<br />

-F auid!=4294967295 \<br />

-k perm_mod<br />

-a always,exit -F arch=b32 -S lremovexattr -F auid==0 -k<br />

perm_mod<br />

If the system is 64-bit, then also add the following:<br />

-a always,exit -F arch=b64 -S lremovexattr -F auid>=500<br />

-F auid!=4294967295 \<br />

-k perm_mod<br />

-a always,exit -F arch=b64 -S lremovexattr -F auid==0 -k<br />

perm_mod<br />

CCI: CCI-000172<br />

NIST SP 800-53A :: AU-12.1 (iv)<br />

NIST SP 800-53 :: AU-12 c<br />

Rule Title: The audit system must be configured to audit<br />

all discretionary access control permission<br />

modifications using lsetxattr.<br />

<strong>STIG</strong> ID: RHEL-06-000194 Rule ID: SV-50362r1_rule Vuln<br />

ID: V-38561<br />

Severity: CAT III Class: Unclass<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Discussion:<br />

The changing of file permissions could indicate that a<br />

user is attempting to gain access to information that<br />

would otherwise be disallowed. Auditing DAC<br />

modifications can facilitate the identification of<br />

patterns of abuse among both authorized and unauthorized<br />

users.<br />

Documentable: No<br />

Check Content:<br />

To determine if the system is configured to audit calls<br />

to the "lsetxattr" system call, run the following<br />

command:<br />

# auditctl -l | grep syscall | grep lsetxattr<br />

If the system is configured to audit this activity, it<br />

will return several lines.<br />

If no lines are returned, this is a finding.<br />

Fix Text:<br />

At a minimum, the audit system should collect file<br />

permission changes for all users and root. Add the<br />

following to "/etc/audit/audit.rules":<br />

-a always,exit -F arch=b32 -S lsetxattr -F auid>=500 -F<br />

auid!=4294967295 \<br />

-k perm_mod<br />

-a always,exit -F arch=b32 -S lsetxattr -F auid==0 -k<br />

perm_mod<br />

If the system is 64-bit, then also add the following:<br />

-a always,exit -F arch=b64 -S lsetxattr -F auid>=500 -F<br />

auid!=4294967295 \<br />

-k perm_mod<br />

-a always,exit -F arch=b64 -S lsetxattr -F auid==0 -k<br />

perm_mod<br />

UNCLASSIFIED


UNCLASSIFIED<br />

CCI: CCI-000172<br />

NIST SP 800-53A :: AU-12.1 (iv)<br />

NIST SP 800-53 :: AU-12 c<br />

Rule Title: The audit system must be configured to audit<br />

all discretionary access control permission<br />

modifications using removexattr.<br />

<strong>STIG</strong> ID: RHEL-06-000195 Rule ID: SV-50364r1_rule Vuln<br />

ID: V-38563<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

The changing of file permissions could indicate that a<br />

user is attempting to gain access to information that<br />

would otherwise be disallowed. Auditing DAC<br />

modifications can facilitate the identification of<br />

patterns of abuse among both authorized and unauthorized<br />

users.<br />

Documentable: No<br />

Check Content:<br />

To determine if the system is configured to audit calls<br />

to the "removexattr" system call, run the following<br />

command:<br />

# auditctl -l | grep syscall | grep removexattr<br />

If the system is configured to audit this activity, it<br />

will return several lines.<br />

If no lines are returned, this is a finding.<br />

Fix Text:<br />

At a minimum, the audit system should collect file<br />

permission changes for all users and root. Add the<br />

following to "/etc/audit/audit.rules":<br />

-a always,exit -F arch=b32 -S removexattr -F auid>=500<br />

UNCLASSIFIED


UNCLASSIFIED<br />

-F auid!=4294967295 \<br />

-k perm_mod<br />

-a always,exit -F arch=b32 -S removexattr -F auid==0 -k<br />

perm_mod<br />

If the system is 64-bit, then also add the following:<br />

-a always,exit -F arch=b64 -S removexattr -F auid>=500<br />

-F auid!=4294967295 \<br />

-k perm_mod<br />

-a always,exit -F arch=b64 -S removexattr -F auid==0 -k<br />

perm_mod<br />

CCI: CCI-000172<br />

NIST SP 800-53A :: AU-12.1 (iv)<br />

NIST SP 800-53 :: AU-12 c<br />

Rule Title: The audit system must be configured to audit<br />

all discretionary access control permission<br />

modifications using setxattr.<br />

<strong>STIG</strong> ID: RHEL-06-000196 Rule ID: SV-50366r1_rule Vuln<br />

ID: V-38565<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

The changing of file permissions could indicate that a<br />

user is attempting to gain access to information that<br />

would otherwise be disallowed. Auditing DAC<br />

modifications can facilitate the identification of<br />

patterns of abuse among both authorized and unauthorized<br />

users.<br />

Documentable: No<br />

Check Content:<br />

To determine if the system is configured to audit calls<br />

to the "setxattr" system call, run the following command:<br />

UNCLASSIFIED


UNCLASSIFIED<br />

# auditctl -l | grep syscall | grep setxattr<br />

If the system is configured to audit this activity, it<br />

will return several lines.<br />

If no lines are returned, this is a finding.<br />

Fix Text:<br />

At a minimum, the audit system should collect file<br />

permission changes for all users and root. Add the<br />

following to "/etc/audit/audit.rules":<br />

-a always,exit -F arch=b32 -S setxattr -F auid>=500 -F<br />

auid!=4294967295 \<br />

-k perm_mod<br />

-a always,exit -F arch=b32 -S setxattr -F auid==0 -k<br />

perm_mod<br />

If the system is 64-bit, then also add the following:<br />

-a always,exit -F arch=b64 -S setxattr -F auid>=500 -F<br />

auid!=4294967295 \<br />

-k perm_mod<br />

-a always,exit -F arch=b64 -S setxattr -F auid==0 -k<br />

perm_mod<br />

CCI: CCI-000172<br />

NIST SP 800-53A :: AU-12.1 (iv)<br />

NIST SP 800-53 :: AU-12 c<br />

Rule Title: The audit system must be configured to audit<br />

failed attempts to access files and programs.<br />

<strong>STIG</strong> ID: RHEL-06-000197 Rule ID: SV-50367r1_rule Vuln<br />

ID: V-38566<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

Unsuccessful attempts to access files could be an<br />

indicator of malicious activity on a system. Auditing<br />

UNCLASSIFIED


UNCLASSIFIED<br />

these events could serve as evidence of potential system<br />

compromise.<br />

Documentable: No<br />

Check Content:<br />

To verify that the audit system collects unauthorized<br />

file accesses, run the following commands:<br />

# grep EACCES /etc/audit/audit.rules<br />

# grep EPERM /etc/audit/audit.rules<br />

If either command lacks output, this is a finding.<br />

Fix Text:<br />

At a minimum, the audit system should collect<br />

unauthorized file accesses for all users and root. Add<br />

the following to "/etc/audit/audit.rules", setting ARCH<br />

to either b32 or b64 as appropriate for your system:<br />

-a always,exit -F arch=ARCH -S creat -S open -S openat<br />

-S truncate \<br />

-S ftruncate -F exit=-EACCES -F auid>=500 -F<br />

auid!=4294967295 -k access<br />

-a always,exit -F arch=ARCH -S creat -S open -S openat<br />

-S truncate \<br />

-S ftruncate -F exit=-EPERM -F auid>=500 -F<br />

auid!=4294967295 -k access<br />

-a always,exit -F arch=ARCH -S creat -S open -S openat<br />

-S truncate \<br />

-S ftruncate -F exit=-EACCES -F auid==0 -k access<br />

-a always,exit -F arch=ARCH -S creat -S open -S openat<br />

-S truncate \<br />

-S ftruncate -F exit=-EPERM -F auid==0 -k access<br />

CCI: CCI-000172<br />

UNCLASSIFIED


UNCLASSIFIED<br />

NIST SP 800-53A :: AU-12.1 (iv)<br />

NIST SP 800-53 :: AU-12 c<br />

Rule Title: The audit system must be configured to audit<br />

all use of setuid programs.<br />

<strong>STIG</strong> ID: RHEL-06-000198 Rule ID: SV-50368r1_rule Vuln<br />

ID: V-38567<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

Privileged programs are subject to<br />

escalation-of-privilege attacks, which attempt to<br />

subvert their normal role of providing some necessary but<br />

limited capability. As such, motivation exists to monitor<br />

these programs for unusual activity.<br />

Documentable: No<br />

Check Content:<br />

To verify that auditing of privileged command use is<br />

configured, run the following command to find relevant<br />

setuid programs:<br />

# find / -xdev -type f -perm -4000 -o -perm -2000<br />

2>/dev/null<br />

Run the following command to verify entries in the audit<br />

rules for all programs found with the previous command:<br />

# grep path /etc/audit/audit.rules<br />

It should be the case that all relevant setuid programs<br />

have a line in the audit rules.<br />

If it is not the case, this is a finding.<br />

Fix Text:<br />

At a minimum, the audit system should collect the<br />

execution of privileged commands for all users and root.<br />

UNCLASSIFIED


UNCLASSIFIED<br />

To find the relevant setuid programs:<br />

# find / -xdev -type f -perm -4000 -o -perm -2000<br />

2>/dev/null<br />

Then, for each setuid program on the system, add a line<br />

of the following form to "/etc/audit/audit.rules", where<br />

[SETUID_PROG_PATH] is the full path to each setuid<br />

program in the list:<br />

-a always,exit -F path=[SETUID_PROG_PATH] -F perm=x -F<br />

auid>=500 -F auid!=4294967295 -k privileged<br />

CCI: CCI-000040<br />

NIST SP 800-53 :: AC-6 (2)<br />

NIST SP 800-53A :: AC-6 (2).1 (iii)<br />

Rule Title: The audit system must be configured to audit<br />

successful file system mounts.<br />

<strong>STIG</strong> ID: RHEL-06-000199 Rule ID: SV-50369r1_rule Vuln<br />

ID: V-38568<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

The unauthorized exportation of data to external media<br />

could result in an information leak where classified<br />

information, Privacy Act information, and intellectual<br />

property could be lost. An audit trail should be created<br />

each time a filesystem is mounted to help identify and<br />

guard against information loss.<br />

Documentable: No<br />

Check Content:<br />

To verify that auditing is configured for all media<br />

exportation events, run the following command:<br />

# auditctl -l | grep syscall | grep mount<br />

UNCLASSIFIED


UNCLASSIFIED<br />

If there is no output, this is a finding.<br />

Fix Text:<br />

At a minimum, the audit system should collect media<br />

exportation events for all users and root. Add the<br />

following to "/etc/audit/audit.rules", setting ARCH to<br />

either b32 or b64 as appropriate for your system:<br />

-a always,exit -F arch=ARCH -S mount -F auid>=500 -F<br />

auid!=4294967295 -k export<br />

-a always,exit -F arch=ARCH -S mount -F auid==0 -k export<br />

CCI: CCI-000172<br />

NIST SP 800-53A :: AU-12.1 (iv)<br />

NIST SP 800-53 :: AU-12 c<br />

Rule Title: The audit system must be configured to audit<br />

user deletions of files and programs.<br />

<strong>STIG</strong> ID: RHEL-06-000200 Rule ID: SV-50376r1_rule Vuln<br />

ID: V-38575<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

Auditing file deletions will create an audit trail for<br />

files that are removed from the system. The audit trail<br />

could aid in system troubleshooting, as well as detecting<br />

malicious processes that attempt to delete log files to<br />

conceal their presence.<br />

Documentable: No<br />

Check Content:<br />

To determine if the system is configured to audit calls<br />

to the "unlink" system call, run the following command:<br />

# auditctl -l | grep syscall | grep unlink | grep -v<br />

UNCLASSIFIED


UNCLASSIFIED<br />

unlinkat<br />

If the system is configured to audit this activity, it<br />

will return several lines.<br />

To determine if the system is configured to audit calls<br />

to the "unlinkat" system call, run the following command:<br />

# auditctl -l | grep syscall | grep unlinkat<br />

If the system is configured to audit this activity, it<br />

will return several lines. To determine if the system is<br />

configured to audit calls to the "rename" system call,<br />

run the following command:<br />

# auditctl -l | grep syscall | grep rename | grep -v<br />

renameat<br />

If the system is configured to audit this activity, it<br />

will return several lines. To determine if the system is<br />

configured to audit calls to the "renameat" system call,<br />

run the following command:<br />

# auditctl -l | grep syscall | grep renameat<br />

If the system is configured to audit this activity, it<br />

will return several lines.<br />

If no line is returned, this is a finding.<br />

Fix Text:<br />

At a minimum, the audit system should collect file<br />

deletion events for all users and root. Add the following<br />

to "/etc/audit/audit.rules", setting ARCH to either b32<br />

or b64 as appropriate for your system:<br />

-a always,exit -F arch=ARCH -S unlink -S unlinkat -S<br />

rename -S renameat \<br />

-F auid>=500 -F auid!=4294967295 -k delete<br />

-a always,exit -F arch=ARCH -S unlink -S unlinkat -S<br />

rename -S renameat \<br />

-F auid==0 -k delete<br />

UNCLASSIFIED


UNCLASSIFIED<br />

CCI: CCI-000172<br />

NIST SP 800-53A :: AU-12.1 (iv)<br />

NIST SP 800-53 :: AU-12 c<br />

Rule Title: The audit system must be configured to audit<br />

changes to the /etc/sudoers file.<br />

<strong>STIG</strong> ID: RHEL-06-000201 Rule ID: SV-50379r1_rule Vuln<br />

ID: V-38578<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

The actions taken by system administrators should be<br />

audited to keep a record of what was executed on the<br />

system, as well as, for accountability purposes.<br />

Documentable: No<br />

Check Content:<br />

To verify that auditing is configured for system<br />

administrator actions, run the following command:<br />

# auditctl -l | grep "watch=/etc/sudoers"<br />

If there is no output, this is a finding.<br />

Fix Text:<br />

At a minimum, the audit system should collect<br />

administrator actions for all users and root. Add the<br />

following to "/etc/audit/audit.rules":<br />

-w /etc/sudoers -p wa -k actions<br />

CCI: CCI-000172<br />

NIST SP 800-53A :: AU-12.1 (iv)<br />

NIST SP 800-53 :: AU-12 c<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Rule Title: The audit system must be configured to audit<br />

the loading and unloading of dynamic kernel modules.<br />

<strong>STIG</strong> ID: RHEL-06-000202 Rule ID: SV-50381r1_rule Vuln<br />

ID: V-38580<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

The addition/removal of kernel modules can be used to<br />

alter the behavior of the kernel and potentially<br />

introduce malicious code into kernel space. It is<br />

important to have an audit trail of modules that have been<br />

introduced into the kernel.<br />

Documentable: No<br />

Check Content:<br />

To determine if the system is configured to audit calls<br />

to the "init_module" system call, run the following<br />

command:<br />

# auditctl -l | grep syscall | grep init_module<br />

If the system is configured to audit this activity, it<br />

will return a line. To determine if the system is<br />

configured to audit calls to the "delete_module" system<br />

call, run the following command:<br />

# auditctl -l | grep syscall | grep delete_module<br />

If the system is configured to audit this activity, it<br />

will return a line.<br />

If no line is returned, this is a finding.<br />

Fix Text:<br />

Add the following to "/etc/audit/audit.rules" in order<br />

to capture kernel module loading and unloading events,<br />

setting ARCH to either b32 or b64 as appropriate for your<br />

system:<br />

UNCLASSIFIED


UNCLASSIFIED<br />

-w /sbin/insmod -p x -k modules<br />

-w /sbin/rmmod -p x -k modules<br />

-w /sbin/modprobe -p x -k modules<br />

-a always,exit -F arch=[ARCH] -S init_module -S<br />

delete_module -k modules<br />

CCI: CCI-000172<br />

NIST SP 800-53A :: AU-12.1 (iv)<br />

NIST SP 800-53 :: AU-12 c<br />

Rule Title: The xinetd service must be disabled if no<br />

network services utilizing it are enabled.<br />

<strong>STIG</strong> ID: RHEL-06-000203 Rule ID: SV-50383r1_rule Vuln<br />

ID: V-38582<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

The xinetd service provides a dedicated listener service<br />

for some programs, which is no longer necessary for<br />

commonly-used network services. Disabling it ensures<br />

that these uncommon services are not running, and also<br />

prevents attacks against xinetd itself.<br />

Documentable: No<br />

Check Content:<br />

If network services are using the xinetd service, this<br />

is not applicable.<br />

To check that the "xinetd" service is disabled in system<br />

boot configuration, run the following command:<br />

# chkconfig "xinetd" --list<br />

Output should indicate the "xinetd" service has either<br />

not been installed, or has been disabled at all runlevels,<br />

as shown in the example below:<br />

UNCLASSIFIED


UNCLASSIFIED<br />

# chkconfig "xinetd" --list<br />

"xinetd" 0:off 1:off 2:off 3:off 4:off 5:off 6:off<br />

Run the following command to verify "xinetd" is disabled<br />

through current runtime configuration:<br />

# service xinetd status<br />

If the service is disabled the command will return the<br />

following output:<br />

xinetd is stopped<br />

If the service is running, this is a finding.<br />

Fix Text:<br />

The "xinetd" service can be disabled with the following<br />

command:<br />

# chkconfig xinetd off<br />

CCI: CCI-000382<br />

NIST SP 800-53A :: CM-7.1 (iii)<br />

NIST SP 800-53 :: CM-7<br />

Rule Title: The xinetd service must be uninstalled if<br />

no network services utilizing it are enabled.<br />

<strong>STIG</strong> ID: RHEL-06-000204 Rule ID: SV-50385r1_rule Vuln<br />

ID: V-38584<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

Removing the "xinetd" package decreases the risk of the<br />

xinetd service's accidental (or intentional) activation.<br />

Documentable: No<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Check Content:<br />

If network services are using the xinetd service, this<br />

is not applicable.<br />

Run the following command to determine if the "xinetd"<br />

package is installed:<br />

# rpm -q xinetd<br />

If the package is installed, this is a finding.<br />

Fix Text:<br />

The "xinetd" package can be uninstalled with the<br />

following command:<br />

# yum erase xinetd<br />

CCI: CCI-000382<br />

NIST SP 800-53A :: CM-7.1 (iii)<br />

NIST SP 800-53 :: CM-7<br />

Rule Title: The telnet-server package must not be<br />

installed.<br />

<strong>STIG</strong> ID: RHEL-06-000206 Rule ID: SV-50388r1_rule Vuln<br />

ID: V-38587<br />

Severity: CAT I Class: Unclass<br />

Discussion:<br />

Removing the "telnet-server" package decreases the risk<br />

of the unencrypted telnet service's accidental (or<br />

intentional) activation.<br />

Mitigation: If the telnet-server package is configured<br />

to only allow encrypted sessions, such as with Kerberos<br />

or the use of encrypted network tunnels, the risk of<br />

exposing sensitive information is mitigated.<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Documentable: No<br />

Check Content:<br />

Run the following command to determine if the<br />

"telnet-server" package is installed:<br />

# rpm -q telnet-server<br />

If the package is installed, this is a finding.<br />

Fix Text:<br />

The "telnet-server" package can be uninstalled with the<br />

following command:<br />

# yum erase telnet-server<br />

CCI: CCI-000381<br />

NIST SP 800-53A :: CM-7.1 (ii)<br />

NIST SP 800-53 :: CM-7<br />

Rule Title: The telnet daemon must not be running.<br />

<strong>STIG</strong> ID: RHEL-06-000211 Rule ID: SV-50390r1_rule Vuln<br />

ID: V-38589<br />

Severity: CAT I Class: Unclass<br />

Discussion:<br />

The telnet protocol uses unencrypted network<br />

communication, which means that data from the login<br />

session, including passwords and all other information<br />

transmitted during the session, can be stolen by<br />

eavesdroppers on the network. The telnet protocol is also<br />

subject to man-in-the-middle attacks.<br />

Mitigation: If an enabled telnet daemon is configured<br />

to only allow encrypted sessions, such as with Kerberos<br />

or the use of encrypted network tunnels, the risk of<br />

UNCLASSIFIED


UNCLASSIFIED<br />

exposing sensitive information is mitigated.<br />

Documentable: No<br />

Check Content:<br />

To check that the "telnet" service is disabled in system<br />

boot configuration, run the following command:<br />

# chkconfig "telnet" --list<br />

Output should indicate the "telnet" service has either<br />

not been installed, or has been disabled at all runlevels,<br />

as shown in the example below:<br />

# chkconfig "telnet" --list<br />

"telnet" 0:off 1:off 2:off 3:off 4:off 5:off 6:off<br />

Run the following command to verify "telnet" is disabled<br />

through current runtime configuration:<br />

# service telnet status<br />

If the service is disabled the command will return the<br />

following output:<br />

telnet is stopped<br />

If the service is running, this is a finding.<br />

Fix Text:<br />

The "telnet" service can be disabled with the following<br />

command:<br />

# chkconfig telnet off<br />

CCI: CCI-000888<br />

NIST SP 800-53A :: MA-4 (6).1<br />

NIST SP 800-53 :: MA-4 (6)<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Rule Title: The rsh-server package must not be<br />

installed.<br />

<strong>STIG</strong> ID: RHEL-06-000213 Rule ID: SV-50392r1_rule Vuln<br />

ID: V-38591<br />

Severity: CAT I Class: Unclass<br />

Discussion:<br />

The "rsh-server" package provides several obsolete and<br />

insecure network services. Removing it decreases the risk<br />

of those services' accidental (or intentional)<br />

activation.<br />

Documentable: No<br />

Check Content:<br />

Run the following command to determine if the<br />

"rsh-server" package is installed:<br />

# rpm -q rsh-server<br />

If the package is installed, this is a finding.<br />

Fix Text:<br />

The "rsh-server" package can be uninstalled with the<br />

following command:<br />

# yum erase rsh-server<br />

CCI: CCI-000381<br />

NIST SP 800-53A :: CM-7.1 (ii)<br />

NIST SP 800-53 :: CM-7<br />

Rule Title: The rshd service must not be running.<br />

<strong>STIG</strong> ID: RHEL-06-000214 Rule ID: SV-50395r1_rule Vuln<br />

ID: V-38594<br />

Severity: CAT I Class: Unclass<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Discussion:<br />

The rsh service uses unencrypted network communications,<br />

which means that data from the login session, including<br />

passwords and all other information transmitted during<br />

the session, can be stolen by eavesdroppers on the<br />

network.<br />

Documentable: No<br />

Check Content:<br />

To check that the "rsh" service is disabled in system boot<br />

configuration, run the following command:<br />

# chkconfig "rsh" --list<br />

Output should indicate the "rsh" service has either not<br />

been installed, or has been disabled at all runlevels,<br />

as shown in the example below:<br />

# chkconfig "rsh" --list<br />

"rsh" 0:off 1:off 2:off 3:off 4:off 5:off 6:off<br />

Run the following command to verify "rsh" is disabled<br />

through current runtime configuration:<br />

# service rsh status<br />

If the service is disabled the command will return the<br />

following output:<br />

rsh is stopped<br />

If the service is running, this is a finding.<br />

Fix Text:<br />

The "rsh" service, which is available with the<br />

"rsh-server" package and runs as a service through<br />

xinetd, should be disabled. The "rsh" service can be<br />

UNCLASSIFIED


UNCLASSIFIED<br />

disabled with the following command:<br />

# chkconfig rsh off<br />

CCI: CCI-000068<br />

NIST SP 800-53A :: AC-17 (2).1<br />

NIST SP 800-53 :: AC-17 (2)<br />

Rule Title: The rexecd service must not be running.<br />

<strong>STIG</strong> ID: RHEL-06-000216 Rule ID: SV-50399r1_rule Vuln<br />

ID: V-38598<br />

Severity: CAT I Class: Unclass<br />

Discussion:<br />

The rexec service uses unencrypted network<br />

communications, which means that data from the login<br />

session, including passwords and all other information<br />

transmitted during the session, can be stolen by<br />

eavesdroppers on the network.<br />

Documentable: No<br />

Check Content:<br />

To check that the "rexec" service is disabled in system<br />

boot configuration, run the following command:<br />

# chkconfig "rexec" --list<br />

Output should indicate the "rexec" service has either not<br />

been installed, or has been disabled at all runlevels,<br />

as shown in the example below:<br />

# chkconfig "rexec" --list<br />

"rexec" 0:off 1:off 2:off 3:off 4:off 5:off 6:off<br />

Run the following command to verify "rexec" is disabled<br />

through current runtime configuration:<br />

UNCLASSIFIED


UNCLASSIFIED<br />

# service rexec status<br />

If the service is disabled the command will return the<br />

following output:<br />

rexec is stopped<br />

If the service is running, this is a finding.<br />

Fix Text:<br />

The "rexec" service, which is available with the<br />

"rsh-server" package and runs as a service through<br />

xinetd, should be disabled. The "rexec" service can be<br />

disabled with the following command:<br />

# chkconfig rexec off<br />

CCI: CCI-000068<br />

NIST SP 800-53A :: AC-17 (2).1<br />

NIST SP 800-53 :: AC-17 (2)<br />

Rule Title: The rlogind service must not be running.<br />

<strong>STIG</strong> ID: RHEL-06-000218 Rule ID: SV-50403r1_rule Vuln<br />

ID: V-38602<br />

Severity: CAT I Class: Unclass<br />

Discussion:<br />

The rlogin service uses unencrypted network<br />

communications, which means that data from the login<br />

session, including passwords and all other information<br />

transmitted during the session, can be stolen by<br />

eavesdroppers on the network.<br />

Documentable: No<br />

Check Content:<br />

To check that the "rlogin" service is disabled in system<br />

UNCLASSIFIED


UNCLASSIFIED<br />

boot configuration, run the following command:<br />

# chkconfig "rlogin" --list<br />

Output should indicate the "rlogin" service has either<br />

not been installed, or has been disabled at all runlevels,<br />

as shown in the example below:<br />

# chkconfig "rlogin" --list<br />

"rlogin" 0:off 1:off 2:off 3:off 4:off 5:off 6:off<br />

Run the following command to verify "rlogin" is disabled<br />

through current runtime configuration:<br />

# service rlogin status<br />

If the service is disabled the command will return the<br />

following output:<br />

rlogin is stopped<br />

If the service is running, this is a finding.<br />

Fix Text:<br />

The "rlogin" service, which is available with the<br />

"rsh-server" package and runs as a service through<br />

xinetd, should be disabled. The "rlogin" service can be<br />

disabled with the following command:<br />

# chkconfig rlogin off<br />

CCI: CCI-001436<br />

NIST SP 800-53A :: AC-17 (8).1 (ii)<br />

NIST SP 800-53 :: AC-17 (8)<br />

Rule Title: The ypserv package must not be installed.<br />

<strong>STIG</strong> ID: RHEL-06-000220 Rule ID: SV-50404r1_rule Vuln<br />

ID: V-38603<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

Removing the "ypserv" package decreases the risk of the<br />

accidental (or intentional) activation of NIS or NIS+<br />

services.<br />

Documentable: No<br />

Check Content:<br />

Run the following command to determine if the "ypserv"<br />

package is installed:<br />

# rpm -q ypserv<br />

If the package is installed, this is a finding.<br />

Fix Text:<br />

The "ypserv" package can be uninstalled with the<br />

following command:<br />

# yum erase ypserv<br />

CCI: CCI-000381<br />

NIST SP 800-53A :: CM-7.1 (ii)<br />

NIST SP 800-53 :: CM-7<br />

Rule Title: The ypbind service must not be running.<br />

<strong>STIG</strong> ID: RHEL-06-000221 Rule ID: SV-50405r1_rule Vuln<br />

ID: V-38604<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

Disabling the "ypbind" service ensures the system is not<br />

acting as a client in a NIS or NIS+ domain.<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Documentable: No<br />

Check Content:<br />

To check that the "ypbind" service is disabled in system<br />

boot configuration, run the following command:<br />

# chkconfig "ypbind" --list<br />

Output should indicate the "ypbind" service has either<br />

not been installed, or has been disabled at all runlevels,<br />

as shown in the example below:<br />

# chkconfig "ypbind" --list<br />

"ypbind" 0:off 1:off 2:off 3:off 4:off 5:off 6:off<br />

Run the following command to verify "ypbind" is disabled<br />

through current runtime configuration:<br />

# service ypbind status<br />

If the service is disabled the command will return the<br />

following output:<br />

ypbind is stopped<br />

If the service is running, this is a finding.<br />

Fix Text:<br />

The "ypbind" service, which allows the system to act as<br />

a client in a NIS or NIS+ domain, should be disabled. The<br />

"ypbind" service can be disabled with the following<br />

command:<br />

# chkconfig ypbind off<br />

CCI: CCI-000382<br />

NIST SP 800-53A :: CM-7.1 (iii)<br />

NIST SP 800-53 :: CM-7<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Rule Title: The tftp-server package must not be<br />

installed.<br />

<strong>STIG</strong> ID: RHEL-06-000222 Rule ID: SV-50407r1_rule Vuln<br />

ID: V-38606<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

Removing the "tftp-server" package decreases the risk of<br />

the accidental (or intentional) activation of tftp<br />

services.<br />

Documentable: No<br />

Check Content:<br />

Run the following command to determine if the<br />

"tftp-server" package is installed:<br />

# rpm -q tftp-server<br />

If the package is installed, this is a finding.<br />

Fix Text:<br />

The "tftp-server" package can be removed with the<br />

following command:<br />

# yum erase tftp-server<br />

CCI: CCI-000381<br />

NIST SP 800-53A :: CM-7.1 (ii)<br />

NIST SP 800-53 :: CM-7<br />

Rule Title: The TFTP service must not be running.<br />

<strong>STIG</strong> ID: RHEL-06-000223 Rule ID: SV-50410r1_rule Vuln<br />

ID: V-38609<br />

Severity: CAT II Class: Unclass<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Discussion:<br />

Disabling the "tftp" service ensures the system is not<br />

acting as a tftp server, which does not provide encryption<br />

or authentication.<br />

Documentable: No<br />

Check Content:<br />

To check that the "tftp" service is disabled in system<br />

boot configuration, run the following command:<br />

# chkconfig "tftp" --list<br />

Output should indicate the "tftp" service has either not<br />

been installed, or has been disabled at all runlevels,<br />

as shown in the example below:<br />

# chkconfig "tftp" --list<br />

"tftp" 0:off 1:off 2:off 3:off 4:off 5:off 6:off<br />

Run the following command to verify "tftp" is disabled<br />

through current runtime configuration:<br />

# service tftp status<br />

If the service is disabled the command will return the<br />

following output:<br />

tftp is stopped<br />

If the service is running, this is a finding.<br />

Fix Text:<br />

The "tftp" service should be disabled. The "tftp" service<br />

can be disabled with the following command:<br />

# chkconfig tftp off<br />

CCI: CCI-001436<br />

UNCLASSIFIED


UNCLASSIFIED<br />

NIST SP 800-53A :: AC-17 (8).1 (ii)<br />

NIST SP 800-53 :: AC-17 (8)<br />

Rule Title: The cron service must be running.<br />

<strong>STIG</strong> ID: RHEL-06-000224 Rule ID: SV-50406r1_rule Vuln<br />

ID: V-38605<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

Due to its usage for maintenance and security-supporting<br />

tasks, enabling the cron daemon is essential.<br />

Documentable: No<br />

Check Content:<br />

Run the following command to determine the current status<br />

of the "crond" service:<br />

# service crond status<br />

If the service is enabled, it should return the following:<br />

crond is running...<br />

If the service is not running, this is a finding.<br />

Fix Text:<br />

The "crond" service is used to execute commands at<br />

preconfigured times. It is required by almost all systems<br />

to perform necessary maintenance tasks, such as notifying<br />

root of system activity. The "crond" service can be<br />

enabled with the following command:<br />

# chkconfig crond on<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

UNCLASSIFIED


UNCLASSIFIED<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: The SSH daemon must be configured to use only<br />

the SSHv2 protocol.<br />

<strong>STIG</strong> ID: RHEL-06-000227 Rule ID: SV-50408r1_rule Vuln<br />

ID: V-38607<br />

Severity: CAT I Class: Unclass<br />

Discussion:<br />

SSH protocol version 1 suffers from design flaws that<br />

result in security vulnerabilities and should not be<br />

used.<br />

Documentable: No<br />

Check Content:<br />

To check which SSH protocol version is allowed, run the<br />

following command:<br />

# grep Protocol /etc/ssh/sshd_config<br />

If configured properly, output should be<br />

Protocol 2<br />

If it is not, this is a finding.<br />

Fix Text:<br />

Only SSH protocol version 2 connections should be<br />

permitted. The default setting in "/etc/ssh/sshd_config"<br />

is correct, and can be verified by ensuring that the<br />

following line appears:<br />

Protocol 2<br />

CCI: CCI-000774<br />

NIST SP 800-53A :: IA-2 (8).1 (ii)<br />

UNCLASSIFIED


UNCLASSIFIED<br />

NIST SP 800-53 :: IA-2 (8)<br />

Rule Title: The SSH daemon must set a timeout interval<br />

on idle sessions.<br />

<strong>STIG</strong> ID: RHEL-06-000230 Rule ID: SV-50409r1_rule Vuln<br />

ID: V-38608<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

Causing idle users to be automatically logged out guards<br />

against compromises one system leading trivially to<br />

compromises on another.<br />

Documentable: No<br />

Check Content:<br />

Run the following command to see what the timeout interval<br />

is:<br />

# grep ClientAliveInterval /etc/ssh/sshd_config<br />

If properly configured, the output should be:<br />

ClientAliveInterval 900<br />

If it is not, this is a finding.<br />

Fix Text:<br />

SSH allows administrators to set an idle timeout<br />

interval. After this interval has passed, the idle user<br />

will be automatically logged out.<br />

To set an idle timeout interval, edit the following line<br />

in "/etc/ssh/sshd_config" as follows:<br />

ClientAliveInterval [interval]<br />

UNCLASSIFIED


UNCLASSIFIED<br />

The timeout [interval] is given in seconds. To have a<br />

timeout of 15 minutes, set [interval] to 900.<br />

If a shorter timeout has already been set for the login<br />

shell, that value will preempt any SSH setting made here.<br />

Keep in mind that some processes may stop SSH from<br />

correctly detecting that the user is idle.<br />

CCI: CCI-001133<br />

NIST SP 800-53A :: SC-10.1 (ii)<br />

NIST SP 800-53 :: SC-10<br />

Rule Title: The SSH daemon must set a timeout count on<br />

idle sessions.<br />

<strong>STIG</strong> ID: RHEL-06-000231 Rule ID: SV-50411r1_rule Vuln<br />

ID: V-38610<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

This ensures a user login will be terminated as soon as<br />

the "ClientAliveCountMax" is reached.<br />

Documentable: No<br />

Check Content:<br />

To ensure the SSH idle timeout will occur when the<br />

"ClientAliveCountMax" is set, run the following command:<br />

# grep ClientAliveCountMax /etc/ssh/sshd_config<br />

If properly configured, output should be:<br />

ClientAliveCountMax 0<br />

If it is not, this is a finding.<br />

Fix Text:<br />

UNCLASSIFIED


UNCLASSIFIED<br />

To ensure the SSH idle timeout occurs precisely when the<br />

"ClientAliveCountMax" is set, edit<br />

"/etc/ssh/sshd_config" as follows:<br />

ClientAliveCountMax 0<br />

CCI: CCI-000879<br />

NIST SP 800-53A :: MA-4.1 (vi)<br />

NIST SP 800-53 :: MA-4 e<br />

Rule Title: The SSH daemon must ignore .rhosts files.<br />

<strong>STIG</strong> ID: RHEL-06-000234 Rule ID: SV-50412r1_rule Vuln<br />

ID: V-38611<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

SSH trust relationships mean a compromise on one host can<br />

allow an attacker to move trivially to other hosts.<br />

Documentable: No<br />

Check Content:<br />

To determine how the SSH daemon's "IgnoreRhosts" option<br />

is set, run the following command:<br />

# grep -i IgnoreRhosts /etc/ssh/sshd_config<br />

If no line, a commented line, or a line indicating the<br />

value "yes" is returned, then the required value is set.<br />

If the required value is not set, this is a finding.<br />

Fix Text:<br />

SSH can emulate the behavior of the obsolete rsh command<br />

in allowing users to enable insecure access to their<br />

accounts via ".rhosts" files.<br />

To ensure this behavior is disabled, add or correct the<br />

following line in "/etc/ssh/sshd_config":<br />

UNCLASSIFIED


UNCLASSIFIED<br />

IgnoreRhosts yes<br />

CCI: CCI-000766<br />

NIST SP 800-53A :: IA-2 (2).1<br />

NIST SP 800-53 :: IA-2 (2)<br />

Rule Title: The SSH daemon must not allow host-based<br />

authentication.<br />

<strong>STIG</strong> ID: RHEL-06-000236 Rule ID: SV-50413r1_rule Vuln<br />

ID: V-38612<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

SSH trust relationships mean a compromise on one host can<br />

allow an attacker to move trivially to other hosts.<br />

Documentable: No<br />

Check Content:<br />

To determine how the SSH daemon's<br />

"HostbasedAuthentication" option is set, run the<br />

following command:<br />

# grep -i HostbasedAuthentication /etc/ssh/sshd_config<br />

If no line, a commented line, or a line indicating the<br />

value "no" is returned, then the required value is set.<br />

If the required value is not set, this is a finding.<br />

Fix Text:<br />

SSH's cryptographic host-based authentication is more<br />

secure than ".rhosts" authentication, since hosts are<br />

cryptographically authenticated. However, it is not<br />

recommended that hosts unilaterally trust one another,<br />

even within an organization.<br />

To disable host-based authentication, add or correct the<br />

UNCLASSIFIED


UNCLASSIFIED<br />

following line in "/etc/ssh/sshd_config":<br />

HostbasedAuthentication no<br />

CCI: CCI-000766<br />

NIST SP 800-53A :: IA-2 (2).1<br />

NIST SP 800-53 :: IA-2 (2)<br />

Rule Title: The system must not permit root logins using<br />

remote access programs such as ssh.<br />

<strong>STIG</strong> ID: RHEL-06-000237 Rule ID: SV-50414r1_rule Vuln<br />

ID: V-38613<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

Permitting direct root login reduces auditable<br />

information about who ran privileged commands on the<br />

system and also allows direct attack attempts on root's<br />

password.<br />

Documentable: No<br />

Check Content:<br />

To determine how the SSH daemon's "PermitRootLogin"<br />

option is set, run the following command:<br />

# grep -i PermitRootLogin /etc/ssh/sshd_config<br />

If a line indicating "no" is returned, then the required<br />

value is set.<br />

If the required value is not set, this is a finding.<br />

Fix Text:<br />

The root user should never be allowed to log in to a system<br />

directly over a network. To disable root login via SSH,<br />

add or correct the following line in<br />

"/etc/ssh/sshd_config":<br />

UNCLASSIFIED


UNCLASSIFIED<br />

PermitRootLogin no<br />

CCI: CCI-000770<br />

NIST SP 800-53A :: IA-2 (5).2 (ii)<br />

NIST SP 800-53 :: IA-2 (5) (b)<br />

Rule Title: The SSH daemon must not allow authentication<br />

using an empty password.<br />

<strong>STIG</strong> ID: RHEL-06-000239 Rule ID: SV-50415r1_rule Vuln<br />

ID: V-38614<br />

Severity: CAT I Class: Unclass<br />

Discussion:<br />

Configuring this setting for the SSH daemon provides<br />

additional assurance that remote login via SSH will<br />

require a password, even in the event of misconfiguration<br />

elsewhere.<br />

Documentable: No<br />

Check Content:<br />

To determine how the SSH daemon's "PermitEmptyPasswords"<br />

option is set, run the following command:<br />

# grep -i PermitEmptyPasswords /etc/ssh/sshd_config<br />

If no line, a commented line, or a line indicating the<br />

value "no" is returned, then the required value is set.<br />

If the required value is not set, this is a finding.<br />

Fix Text:<br />

To explicitly disallow remote login from accounts with<br />

empty passwords, add or correct the following line in<br />

"/etc/ssh/sshd_config":<br />

PermitEmptyPasswords no<br />

Any accounts with empty passwords should be disabled<br />

UNCLASSIFIED


UNCLASSIFIED<br />

immediately, and PAM configuration should prevent users<br />

from being able to assign themselves empty passwords.<br />

CCI: CCI-000766<br />

NIST SP 800-53A :: IA-2 (2).1<br />

NIST SP 800-53 :: IA-2 (2)<br />

Rule Title: The SSH daemon must be configured with the<br />

Department of Defense (DoD) login banner.<br />

<strong>STIG</strong> ID: RHEL-06-000240 Rule ID: SV-50416r1_rule Vuln<br />

ID: V-38615<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

The warning message reinforces policy awareness during<br />

the logon process and facilitates possible legal action<br />

against attackers. Alternatively, systems whose<br />

ownership should not be obvious should ensure usage of<br />

a banner that does not provide easy attribution.<br />

Documentable: No<br />

Check Content:<br />

To determine how the SSH daemon's "Banner" option is set,<br />

run the following command:<br />

# grep -i Banner /etc/ssh/sshd_config<br />

If a line indicating /etc/issue is returned, then the<br />

required value is set.<br />

If the required value is not set, this is a finding.<br />

Fix Text:<br />

To enable the warning banner and ensure it is consistent<br />

across the system, add or correct the following line in<br />

"/etc/ssh/sshd_config":<br />

Banner /etc/issue<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Another section contains information on how to create an<br />

appropriate system-wide warning banner.<br />

CCI: CCI-000048<br />

NIST SP 800-53 :: AC-8 a<br />

NIST SP 800-53A :: AC-8.1 (ii)<br />

Rule Title: The SSH daemon must not permit user<br />

environment settings.<br />

<strong>STIG</strong> ID: RHEL-06-000241 Rule ID: SV-50417r1_rule Vuln<br />

ID: V-38616<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

SSH environment options potentially allow users to bypass<br />

access restriction in some configurations.<br />

Documentable: No<br />

Check Content:<br />

To ensure users are not able to present environment<br />

daemons, run the following command:<br />

# grep PermitUserEnvironment /etc/ssh/sshd_config<br />

If properly configured, output should be:<br />

PermitUserEnvironment no<br />

If it is not, this is a finding.<br />

Fix Text:<br />

To ensure users are not able to present environment<br />

options to the SSH daemon, add or correct the following<br />

line in "/etc/ssh/sshd_config":<br />

UNCLASSIFIED


UNCLASSIFIED<br />

PermitUserEnvironment no<br />

CCI: CCI-001414<br />

NIST SP 800-53A :: AC-4.1 (iii)<br />

NIST SP 800-53 :: AC-4<br />

Rule Title: The SSH daemon must be configured to use only<br />

FIPS 140-2 approved ciphers.<br />

<strong>STIG</strong> ID: RHEL-06-000243 Rule ID: SV-50418r1_rule Vuln<br />

ID: V-38617<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

Approved algorithms should impart some level of<br />

confidence in their implementation. These are also<br />

required for compliance.<br />

Documentable: No<br />

Check Content:<br />

Only FIPS-approved ciphers should be used. To verify that<br />

only FIPS-approved ciphers are in use, run the following<br />

command:<br />

# grep Ciphers /etc/ssh/sshd_config<br />

The output should contain only those ciphers which are<br />

FIPS-approved, namely, the AES and 3DES ciphers.<br />

If that is not the case, this is a finding.<br />

Fix Text:<br />

Limit the ciphers to those algorithms which are<br />

FIPS-approved. Counter (CTR) mode is also preferred over<br />

cipher-block chaining (CBC) mode. The following line in<br />

"/etc/ssh/sshd_config" demonstrates use of<br />

FIPS-approved ciphers:<br />

Ciphers<br />

UNCLASSIFIED


UNCLASSIFIED<br />

aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,<br />

aes192-cbc,aes256-cbc<br />

The man page "sshd_config(5)" contains a list of<br />

supported ciphers.<br />

CCI: CCI-001144<br />

NIST SP 800-53A :: SC-13.1<br />

NIST SP 800-53 :: SC-13<br />

Rule Title: The avahi service must be disabled.<br />

<strong>STIG</strong> ID: RHEL-06-000246 Rule ID: SV-50419r1_rule Vuln<br />

ID: V-38618<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

Because the Avahi daemon service keeps an open network<br />

port, it is subject to network attacks. Its functionality<br />

is convenient but is only appropriate if the local network<br />

can be trusted.<br />

Documentable: No<br />

Check Content:<br />

To check that the "avahi-daemon" service is disabled in<br />

system boot configuration, run the following command:<br />

# chkconfig "avahi-daemon" --list<br />

Output should indicate the "avahi-daemon" service has<br />

either not been installed, or has been disabled at all<br />

runlevels, as shown in the example below:<br />

# chkconfig "avahi-daemon" --list<br />

"avahi-daemon" 0:off 1:off 2:off 3:off 4:off 5:off 6:off<br />

Run the following command to verify "avahi-daemon" is<br />

disabled through current runtime configuration:<br />

UNCLASSIFIED


UNCLASSIFIED<br />

# service avahi-daemon status<br />

If the service is disabled the command will return the<br />

following output:<br />

avahi-daemon is stopped<br />

If the service is running, this is a finding.<br />

Fix Text:<br />

The "avahi-daemon" service can be disabled with the<br />

following command:<br />

# chkconfig avahi-daemon off<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: The system clock must be synchronized<br />

continuously, or at least daily.<br />

<strong>STIG</strong> ID: RHEL-06-000247 Rule ID: SV-50421r1_rule Vuln<br />

ID: V-38620<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

Enabling the "ntpd" service ensures that the "ntpd"<br />

service will be running and that the system will<br />

synchronize its time to any servers specified. This is<br />

important whether the system is configured to be a client<br />

(and synchronize only its own clock) or it is also acting<br />

as an NTP server to other systems. Synchronizing time is<br />

essential for authentication services such as Kerberos,<br />

but it is also important for maintaining accurate logs<br />

and auditing possible security breaches.<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Documentable: No<br />

Check Content:<br />

Run the following command to determine the current status<br />

of the "ntpd" service:<br />

# service ntpd status<br />

If the service is enabled, it should return the following:<br />

ntpd is running...<br />

If the service is not running, this is a finding.<br />

Fix Text:<br />

The "ntpd" service can be enabled with the following<br />

command:<br />

# chkconfig ntpd on<br />

# service ntpd start<br />

CCI: CCI-000160<br />

NIST SP 800-53A :: AU-8 (1).1 (iii)<br />

NIST SP 800-53 :: AU-8 (1)<br />

Rule Title: The system clock must be synchronized to an<br />

authoritative DoD time source.<br />

<strong>STIG</strong> ID: RHEL-06-000248 Rule ID: SV-50422r1_rule Vuln<br />

ID: V-38621<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

Synchronizing with an NTP server makes it possible to<br />

collate system logs from multiple sources or correlate<br />

computer events with real time events. Using a trusted<br />

NTP server provided by your organization is recommended.<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Documentable: No<br />

Check Content:<br />

A remote NTP server should be configured for time<br />

synchronization. To verify one is configured, open the<br />

following file.<br />

/etc/ntp.conf<br />

In the file, there should be a section similar to the<br />

following:<br />

# --- OUR TIMESERVERS -----<br />

server [ntpserver]<br />

If this is not the case, this is a finding.<br />

Fix Text:<br />

To specify a remote NTP server for time synchronization,<br />

edit the file "/etc/ntp.conf". Add or correct the<br />

following lines, substituting the IP or hostname of a<br />

remote NTP server for ntpserver.<br />

server [ntpserver]<br />

This instructs the NTP software to contact that remote<br />

server to obtain time data.<br />

CCI: CCI-000160<br />

NIST SP 800-53A :: AU-8 (1).1 (iii)<br />

NIST SP 800-53 :: AU-8 (1)<br />

Rule Title: Mail relaying must be restricted.<br />

<strong>STIG</strong> ID: RHEL-06-000249 Rule ID: SV-50423r1_rule Vuln<br />

ID: V-38622<br />

Severity: CAT II Class: Unclass<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Discussion:<br />

This ensures "postfix" accepts mail messages (such as<br />

cron job reports) from the local system only, and not from<br />

the network, which protects it from network attack.<br />

Documentable: No<br />

Check Content:<br />

Run the following command to ensure postfix accepts mail<br />

messages from only the local system:<br />

$ grep inet_interfaces /etc/postfix/main.cf<br />

If properly configured, the output should show only<br />

"localhost".<br />

If it does not, this is a finding.<br />

Fix Text:<br />

Edit the file "/etc/postfix/main.cf" to ensure that only<br />

the following "inet_interfaces" line appears:<br />

inet_interfaces = localhost<br />

CCI: CCI-000382<br />

NIST SP 800-53A :: CM-7.1 (iii)<br />

NIST SP 800-53 :: CM-7<br />

Rule Title: If the system is using LDAP for<br />

authentication or account information, the system must<br />

use a TLS connection using FIPS 140-2 approved<br />

cryptographic algorithms.<br />

<strong>STIG</strong> ID: RHEL-06-000252 Rule ID: SV-50426r1_rule Vuln<br />

ID: V-38625<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

The ssl directive specifies whether to use ssl or not.<br />

If not specified it will default to "no". It should be<br />

UNCLASSIFIED


UNCLASSIFIED<br />

set to "start_tls" rather than doing LDAP over SSL.<br />

Documentable: No<br />

Check Content:<br />

If the system does not use LDAP for authentication or<br />

account information, this is not applicable.<br />

To ensure LDAP is configured to use TLS for all<br />

transactions, run the following command:<br />

$ grep start_tls /etc/pam_ldap.conf<br />

If no lines are returned, this is a finding.<br />

Fix Text:<br />

Configure LDAP to enforce TLS use. First, edit the file<br />

"/etc/pam_ldap.conf", and add or correct the following<br />

lines:<br />

ssl start_tls<br />

Then review the LDAP server and ensure TLS has been<br />

configured.<br />

CCI: CCI-001453<br />

NIST SP 800-53A :: AC-17 (2).1<br />

NIST SP 800-53 :: AC-17 (2)<br />

Rule Title: The LDAP client must use a TLS connection<br />

using trust certificates signed by the site CA.<br />

<strong>STIG</strong> ID: RHEL-06-000253 Rule ID: SV-50427r1_rule Vuln<br />

ID: V-38626<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

The tls_cacertdir or tls_cacertfile directives are<br />

UNCLASSIFIED


UNCLASSIFIED<br />

required when tls_checkpeer is configured (which is the<br />

default for openldap versions 2.1 and up). These<br />

directives define the path to the trust certificates<br />

signed by the site CA.<br />

Documentable: No<br />

Check Content:<br />

If the system does not use LDAP for authentication or<br />

account information, this is not applicable.<br />

To ensure TLS is configured with trust certificates, run<br />

the following command:<br />

# grep cert /etc/pam_ldap.conf<br />

If there is no output, or the lines are commented out,<br />

this is a finding.<br />

Fix Text:<br />

Ensure a copy of the site's CA certificate has been placed<br />

in the file "/etc/pki/tls/CA/cacert.pem". Configure LDAP<br />

to enforce TLS use and to trust certificates signed by<br />

the site's CA. First, edit the file "/etc/pam_ldap.conf",<br />

and add or correct either of the following lines:<br />

tls_cacertdir /etc/pki/tls/CA<br />

or<br />

tls_cacertfile /etc/pki/tls/CA/cacert.pem<br />

Then review the LDAP server and ensure TLS has been<br />

configured.<br />

CCI: CCI-000776<br />

NIST SP 800-53A :: IA-2 (9).1 (ii)<br />

NIST SP 800-53 :: IA-2 (9)<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Rule Title: The openldap-servers package must not be<br />

installed unless required.<br />

<strong>STIG</strong> ID: RHEL-06-000256 Rule ID: SV-50428r1_rule Vuln<br />

ID: V-38627<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

Unnecessary packages should not be installed to decrease<br />

the attack surface of the system.<br />

Documentable: No<br />

Check Content:<br />

To verify the "openldap-servers" package is not<br />

installed, run the following command:<br />

$ rpm -q openldap-servers<br />

The output should show the following.<br />

package openldap-servers is not installed<br />

If it does not, this is a finding.<br />

Fix Text:<br />

The "openldap-servers" package should be removed if not<br />

in use. Is this machine the OpenLDAP server? If not,<br />

remove the package.<br />

# yum erase openldap-servers<br />

The openldap-servers RPM is not installed by default on<br />

RHEL6 machines. It is needed only by the OpenLDAP server,<br />

not by the clients which use LDAP for authentication. If<br />

the system is not intended for use as an LDAP Server it<br />

should be removed.<br />

CCI: CCI-000366<br />

UNCLASSIFIED


UNCLASSIFIED<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: The graphical desktop environment must set<br />

the idle timeout to no more than 15 minutes.<br />

<strong>STIG</strong> ID: RHEL-06-000257 Rule ID: SV-50430r1_rule Vuln<br />

ID: V-38629<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

Setting the idle delay controls when the screensaver will<br />

start, and can be combined with screen locking to prevent<br />

access from passersby.<br />

Documentable: No<br />

Check Content:<br />

To check the current idle time-out value, run the<br />

following command:<br />

$ gconftool-2 -g /apps/gnome-screensaver/idle_delay<br />

If properly configured, the output should be "15".<br />

If it is not, this is a finding.<br />

Fix Text:<br />

Run the following command to set the idle time-out value<br />

for inactivity in the GNOME desktop to 15 minutes:<br />

# gconftool-2 \<br />

--direct \<br />

--config-source<br />

xml:readwrite:/etc/gconf/gconf.xml.mandatory \<br />

--type int \<br />

--set /apps/gnome-screensaver/idle_delay 15<br />

CCI: CCI-000057<br />

NIST SP 800-53 :: AC-11 a<br />

UNCLASSIFIED


UNCLASSIFIED<br />

NIST SP 800-53A :: AC-11.1 (ii)<br />

Rule Title: The graphical desktop environment must<br />

automatically lock after 15 minutes of inactivity and the<br />

system must require user to re-authenticate to unlock the<br />

environment.<br />

<strong>STIG</strong> ID: RHEL-06-000258 Rule ID: SV-50431r1_rule Vuln<br />

ID: V-38630<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

Enabling idle activation of the screen saver ensures the<br />

screensaver will be activated after the idle delay.<br />

Applications requiring continuous, real-time screen<br />

display (such as network management products) require the<br />

login session does not have administrator rights and the<br />

display station is located in a controlled-access area.<br />

Documentable: No<br />

Check Content:<br />

To check the screensaver mandatory use status, run the<br />

following command:<br />

$ gconftool-2 -g<br />

/apps/gnome-screensaver/idle_activation_enabled<br />

If properly configured, the output should be "true".<br />

If it is not, this is a finding.<br />

Fix Text:<br />

Run the following command to activate the screensaver in<br />

the GNOME desktop after a period of inactivity:<br />

# gconftool-2 --direct \<br />

--config-source<br />

xml:readwrite:/etc/gconf/gconf.xml.mandatory \<br />

--type bool \<br />

UNCLASSIFIED


UNCLASSIFIED<br />

--set /apps/gnome-screensaver/idle_activation_enabled<br />

true<br />

CCI: CCI-000057<br />

NIST SP 800-53 :: AC-11 a<br />

NIST SP 800-53A :: AC-11.1 (ii)<br />

Rule Title: The graphical desktop environment must have<br />

automatic lock enabled.<br />

<strong>STIG</strong> ID: RHEL-06-000259 Rule ID: SV-50439r1_rule Vuln<br />

ID: V-38638<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

Enabling the activation of the screen lock after an idle<br />

period ensures password entry will be required in order<br />

to access the system, preventing access by passersby.<br />

Documentable: No<br />

Check Content:<br />

To check the status of the idle screen lock activation,<br />

run the following command:<br />

$ gconftool-2 -g /apps/gnome-screensaver/lock_enabled<br />

If properly configured, the output should be "true".<br />

If it is not, this is a finding.<br />

Fix Text:<br />

Run the following command to activate locking of the<br />

screensaver in the GNOME desktop when it is activated:<br />

# gconftool-2 --direct \<br />

--config-source<br />

xml:readwrite:/etc/gconf/gconf.xml.mandatory \<br />

--type bool \<br />

--set /apps/gnome-screensaver/lock_enabled true<br />

UNCLASSIFIED


UNCLASSIFIED<br />

CCI: CCI-000057<br />

NIST SP 800-53 :: AC-11 a<br />

NIST SP 800-53A :: AC-11.1 (ii)<br />

Rule Title: The system must display a publicly-viewable<br />

pattern during a graphical desktop environment session<br />

lock.<br />

<strong>STIG</strong> ID: RHEL-06-000260 Rule ID: SV-50440r1_rule Vuln<br />

ID: V-38639<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

Setting the screensaver mode to blank-only conceals the<br />

contents of the display from passersby.<br />

Documentable: No<br />

Check Content:<br />

To ensure the screensaver is configured to be blank, run<br />

the following command:<br />

$ gconftool-2 -g /apps/gnome-screensaver/mode<br />

If properly configured, the output should be "blank-only"<br />

If it is not, this is a finding.<br />

Fix Text:<br />

Run the following command to set the screensaver mode in<br />

the GNOME desktop to a blank screen:<br />

# gconftool-2<br />

--direct \<br />

--config-source<br />

xml:readwrite:/etc/gconf/gconf.xml.mandatory \<br />

--type string \<br />

--set /apps/gnome-screensaver/mode blank-only<br />

UNCLASSIFIED


UNCLASSIFIED<br />

CCI: CCI-000060<br />

NIST SP 800-53 :: AC-11 (1)<br />

NIST SP 800-53A :: AC-11 (1).1<br />

Rule Title: The Automatic Bug Reporting Tool (abrtd)<br />

service must not be running.<br />

<strong>STIG</strong> ID: RHEL-06-000261 Rule ID: SV-50441r1_rule Vuln<br />

ID: V-38640<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

Mishandling crash data could expose sensitive<br />

information about vulnerabilities in software executing<br />

on the local machine, as well as sensitive information<br />

from within a process's address space or registers.<br />

Documentable: No<br />

Check Content:<br />

To check that the "abrtd" service is disabled in system<br />

boot configuration, run the following command:<br />

# chkconfig "abrtd" --list<br />

Output should indicate the "abrtd" service has either not<br />

been installed, or has been disabled at all runlevels,<br />

as shown in the example below:<br />

# chkconfig "abrtd" --list<br />

"abrtd" 0:off 1:off 2:off 3:off 4:off 5:off 6:off<br />

Run the following command to verify "abrtd" is disabled<br />

through current runtime configuration:<br />

# service abrtd status<br />

If the service is disabled the command will return the<br />

following output:<br />

UNCLASSIFIED


UNCLASSIFIED<br />

abrtd is stopped<br />

If the service is running, this is a finding.<br />

Fix Text:<br />

The Automatic Bug Reporting Tool ("abrtd") daemon<br />

collects and reports crash data when an application crash<br />

is detected. Using a variety of plugins, abrtd can email<br />

crash reports to system administrators, log crash reports<br />

to files, or forward crash reports to a centralized issue<br />

tracking system such as RHTSupport. The "abrtd" service<br />

can be disabled with the following command:<br />

# chkconfig abrtd off<br />

CCI: CCI-000382<br />

NIST SP 800-53A :: CM-7.1 (iii)<br />

NIST SP 800-53 :: CM-7<br />

Rule Title: The atd service must be disabled.<br />

<strong>STIG</strong> ID: RHEL-06-000262 Rule ID: SV-50442r1_rule Vuln<br />

ID: V-38641<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

The "atd" service could be used by an unsophisticated<br />

insider to carry out activities outside of a normal login<br />

session, which could complicate accountability.<br />

Furthermore, the need to schedule tasks with "at" or<br />

"batch" is not common.<br />

Documentable: No<br />

Check Content:<br />

If the system uses the "atd" service, this is not<br />

applicable.<br />

UNCLASSIFIED


UNCLASSIFIED<br />

To check that the "atd" service is disabled in system boot<br />

configuration, run the following command:<br />

# chkconfig "atd" --list<br />

Output should indicate the "atd" service has either not<br />

been installed, or has been disabled at all runlevels,<br />

as shown in the example below:<br />

# chkconfig "atd" --list<br />

"atd" 0:off 1:off 2:off 3:off 4:off 5:off 6:off<br />

Run the following command to verify "atd" is disabled<br />

through current runtime configuration:<br />

# service atd status<br />

If the service is disabled the command will return the<br />

following output:<br />

atd is stopped<br />

If the service is running, this is a finding.<br />

Fix Text:<br />

The "at" and "batch" commands can be used to schedule<br />

tasks that are meant to be executed only once. This allows<br />

delayed execution in a manner similar to cron, except that<br />

it is not recurring. The daemon "atd" keeps track of tasks<br />

scheduled via "at" and "batch", and executes them at the<br />

specified time. The "atd" service can be disabled with<br />

the following command:<br />

# chkconfig atd off<br />

CCI: CCI-000382<br />

NIST SP 800-53A :: CM-7.1 (iii)<br />

NIST SP 800-53 :: CM-7<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Rule Title: The ntpdate service must not be running.<br />

<strong>STIG</strong> ID: RHEL-06-000265 Rule ID: SV-50445r1_rule Vuln<br />

ID: V-38644<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

The "ntpdate" service may only be suitable for systems<br />

which are rebooted frequently enough that clock drift<br />

does not cause problems between reboots. In any event,<br />

the functionality of the ntpdate service is now available<br />

in the ntpd program and should be considered deprecated.<br />

Documentable: No<br />

Check Content:<br />

To check that the "ntpdate" service is disabled in system<br />

boot configuration, run the following command:<br />

# chkconfig "ntpdate" --list<br />

Output should indicate the "ntpdate" service has either<br />

not been installed, or has been disabled at all runlevels,<br />

as shown in the example below:<br />

# chkconfig "ntpdate" --list<br />

"ntpdate" 0:off 1:off 2:off 3:off 4:off 5:off 6:off<br />

Run the following command to verify "ntpdate" is disabled<br />

through current runtime configuration:<br />

# service ntpdate status<br />

If the service is disabled the command will return the<br />

following output:<br />

ntpdate is stopped<br />

UNCLASSIFIED


UNCLASSIFIED<br />

If the service is running, this is a finding.<br />

Fix Text:<br />

The ntpdate service sets the local hardware clock by<br />

polling NTP servers when the system boots. It<br />

synchronizes to the NTP servers listed in<br />

"/etc/ntp/step-tickers" or "/etc/ntp.conf" and then sets<br />

the local hardware clock to the newly synchronized system<br />

time. The "ntpdate" service can be disabled with the<br />

following command:<br />

# chkconfig ntpdate off<br />

CCI: CCI-000382<br />

NIST SP 800-53A :: CM-7.1 (iii)<br />

NIST SP 800-53 :: CM-7<br />

Rule Title: The oddjobd service must not be running.<br />

<strong>STIG</strong> ID: RHEL-06-000266 Rule ID: SV-50447r1_rule Vuln<br />

ID: V-38646<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

The "oddjobd" service may provide necessary<br />

functionality in some environments but it can be disabled<br />

if it is not needed. Execution of tasks by privileged<br />

programs, on behalf of unprivileged ones, has<br />

traditionally been a source of privilege escalation<br />

security issues.<br />

Documentable: No<br />

Check Content:<br />

To check that the "oddjobd" service is disabled in system<br />

boot configuration, run the following command:<br />

# chkconfig "oddjobd" --list<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Output should indicate the "oddjobd" service has either<br />

not been installed, or has been disabled at all runlevels,<br />

as shown in the example below:<br />

# chkconfig "oddjobd" --list<br />

"oddjobd" 0:off 1:off 2:off 3:off 4:off 5:off 6:off<br />

Run the following command to verify "oddjobd" is disabled<br />

through current runtime configuration:<br />

# service oddjobd status<br />

If the service is disabled the command will return the<br />

following output:<br />

oddjobd is stopped<br />

If the service is running, this is a finding.<br />

Fix Text:<br />

The "oddjobd" service exists to provide an interface and<br />

access control mechanism through which specified<br />

privileged tasks can run tasks for unprivileged client<br />

applications. Communication with "oddjobd" is through<br />

the system message bus. The "oddjobd" service can be<br />

disabled with the following command:<br />

# chkconfig oddjobd off<br />

CCI: CCI-000382<br />

NIST SP 800-53A :: CM-7.1 (iii)<br />

NIST SP 800-53 :: CM-7<br />

Rule Title: The qpidd service must not be running.<br />

<strong>STIG</strong> ID: RHEL-06-000267 Rule ID: SV-50449r1_rule Vuln<br />

ID: V-38648<br />

Severity: CAT III Class: Unclass<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Discussion:<br />

The qpidd service is automatically installed when the<br />

"base" package selection is selected during<br />

installation. The qpidd service listens for network<br />

connections which increases the attack surface of the<br />

system. If the system is not intended to receive AMQP<br />

traffic then the "qpidd" service is not needed and should<br />

be disabled or removed.<br />

Documentable: No<br />

Check Content:<br />

To check that the "qpidd" service is disabled in system<br />

boot configuration, run the following command:<br />

# chkconfig "qpidd" --list<br />

Output should indicate the "qpidd" service has either not<br />

been installed, or has been disabled at all runlevels,<br />

as shown in the example below:<br />

# chkconfig "qpidd" --list<br />

"qpidd" 0:off 1:off 2:off 3:off 4:off 5:off 6:off<br />

Run the following command to verify "qpidd" is disabled<br />

through current runtime configuration:<br />

# service qpidd status<br />

If the service is disabled the command will return the<br />

following output:<br />

qpidd is stopped<br />

If the service is running, this is a finding.<br />

Fix Text:<br />

The "qpidd" service provides high speed, secure,<br />

UNCLASSIFIED


UNCLASSIFIED<br />

guaranteed delivery services. It is an implementation of<br />

the Advanced Message Queuing Protocol. By default the<br />

qpidd service will bind to port 5672 and listen for<br />

connection attempts. The "qpidd" service can be disabled<br />

with the following command:<br />

# chkconfig qpidd off<br />

CCI: CCI-000382<br />

NIST SP 800-53A :: CM-7.1 (iii)<br />

NIST SP 800-53 :: CM-7<br />

Rule Title: The rdisc service must not be running.<br />

<strong>STIG</strong> ID: RHEL-06-000268 Rule ID: SV-50451r1_rule Vuln<br />

ID: V-38650<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

General-purpose systems typically have their network and<br />

routing information configured statically by a system<br />

administrator. Workstations or some special-purpose<br />

systems often use DHCP (instead of IRDP) to retrieve<br />

dynamic network configuration information.<br />

Documentable: No<br />

Check Content:<br />

To check that the "rdisc" service is disabled in system<br />

boot configuration, run the following command:<br />

# chkconfig "rdisc" --list<br />

Output should indicate the "rdisc" service has either not<br />

been installed, or has been disabled at all runlevels,<br />

as shown in the example below:<br />

# chkconfig "rdisc" --list<br />

"rdisc" 0:off 1:off 2:off 3:off 4:off 5:off 6:off<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Run the following command to verify "rdisc" is disabled<br />

through current runtime configuration:<br />

# service rdisc status<br />

If the service is disabled the command will return the<br />

following output:<br />

rdisc is stopped<br />

If the service is running, this is a finding.<br />

Fix Text:<br />

The "rdisc" service implements the client side of the ICMP<br />

Internet Router Discovery Protocol (IRDP), which allows<br />

discovery of routers on the local subnet. If a router is<br />

discovered then the local routing table is updated with<br />

a corresponding default route. By default this daemon is<br />

disabled. The "rdisc" service can be disabled with the<br />

following command:<br />

# chkconfig rdisc off<br />

CCI: CCI-000382<br />

NIST SP 800-53A :: CM-7.1 (iii)<br />

NIST SP 800-53 :: CM-7<br />

Rule Title: Remote file systems must be mounted with the<br />

nodev option.<br />

<strong>STIG</strong> ID: RHEL-06-000269 Rule ID: SV-50453r1_rule Vuln<br />

ID: V-38652<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

Legitimate device files should only exist in the /dev<br />

directory. NFS mounts should not present device files to<br />

UNCLASSIFIED


UNCLASSIFIED<br />

users.<br />

Documentable: No<br />

Check Content:<br />

To verify the "nodev" option is configured for all NFS<br />

mounts, run the following command:<br />

$ mount | grep nfs<br />

All NFS mounts should show the "nodev" setting in<br />

parentheses.<br />

If the setting does not show, this is a finding.<br />

Fix Text:<br />

Add the "nodev" option to the fourth column of<br />

"/etc/fstab" for the line which controls mounting of any<br />

NFS mounts.<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: Remote file systems must be mounted with the<br />

nosuid option.<br />

<strong>STIG</strong> ID: RHEL-06-000270 Rule ID: SV-50455r1_rule Vuln<br />

ID: V-38654<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

NFS mounts should not present suid binaries to users. Only<br />

vendor-supplied suid executables should be installed to<br />

their default location on the local filesystem.<br />

Documentable: No<br />

Check Content:<br />

To verify the "nosuid" option is configured for all NFS<br />

UNCLASSIFIED


UNCLASSIFIED<br />

mounts, run the following command:<br />

$ mount | grep nfs<br />

All NFS mounts should show the "nosuid" setting in<br />

parentheses.<br />

If the setting does not show, this is a finding.<br />

Fix Text:<br />

Add the "nosuid" option to the fourth column of<br />

"/etc/fstab" for the line which controls mounting of any<br />

NFS mounts.<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: The noexec option must be added to removable<br />

media partitions.<br />

<strong>STIG</strong> ID: RHEL-06-000271 Rule ID: SV-50456r1_rule Vuln<br />

ID: V-38655<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

Allowing users to execute binaries from removable media<br />

such as USB keys exposes the system to potential<br />

compromise.<br />

Documentable: No<br />

Check Content:<br />

To verify that binaries cannot be directly executed from<br />

removable media, run the following command:<br />

# grep noexec /etc/fstab<br />

The output should show "noexec" in use.<br />

If it does not, this is a finding.<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Fix Text:<br />

The "noexec" mount option prevents the direct execution<br />

of binaries on the mounted filesystem. Users should not<br />

be allowed to execute binaries that exist on partitions<br />

mounted from removable media (such as a USB key). The<br />

"noexec" option prevents code from being executed<br />

directly from the media itself, and may therefore provide<br />

a line of defense against certain types of worms or<br />

malicious code. Add the "noexec" option to the fourth<br />

column of "/etc/fstab" for the line which controls<br />

mounting of any removable media partitions.<br />

CCI: CCI-000087<br />

NIST SP 800-53A :: AC-19.1 (v)<br />

NIST SP 800-53 :: AC-19 e<br />

Rule Title: The system must use SMB client signing for<br />

connecting to samba servers using smbclient.<br />

<strong>STIG</strong> ID: RHEL-06-000272 Rule ID: SV-50457r1_rule Vuln<br />

ID: V-38656<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

Packet signing can prevent man-in-the-middle attacks<br />

which modify SMB packets in transit.<br />

Documentable: No<br />

Check Content:<br />

To verify that Samba clients running smbclient must use<br />

packet signing, run the following command:<br />

# grep signing /etc/samba/smb.conf<br />

The output should show:<br />

client signing = mandatory<br />

UNCLASSIFIED


UNCLASSIFIED<br />

If it is not, this is a finding.<br />

Fix Text:<br />

To require samba clients running "smbclient" to use<br />

packet signing, add the following to the "[global]"<br />

section of the Samba configuration file in<br />

"/etc/samba/smb.conf":<br />

client signing = mandatory<br />

Requiring samba clients such as "smbclient" to use packet<br />

signing ensures they can only communicate with servers<br />

that support packet signing.<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: The system must use SMB client signing for<br />

connecting to samba servers using mount.cifs.<br />

<strong>STIG</strong> ID: RHEL-06-000273 Rule ID: SV-50458r1_rule Vuln<br />

ID: V-38657<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

Packet signing can prevent man-in-the-middle attacks<br />

which modify SMB packets in transit.<br />

Documentable: No<br />

Check Content:<br />

To verify that Samba clients using mount.cifs must use<br />

packet signing, run the following command:<br />

# grep sec /etc/fstab<br />

UNCLASSIFIED


UNCLASSIFIED<br />

The output should show either "krb5i" or "ntlmv2i" in use.<br />

If it does not, this is a finding.<br />

Fix Text:<br />

Require packet signing of clients who mount Samba shares<br />

using the "mount.cifs" program (e.g., those who specify<br />

shares in "/etc/fstab"). To do so, ensure signing options<br />

(either "sec=krb5i" or "sec=ntlmv2i") are used.<br />

See the "mount.cifs(8)" man page for more information.<br />

A Samba client should only communicate with servers who<br />

can support SMB packet signing.<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: The system must prohibit the reuse of<br />

passwords within twenty-four iterations.<br />

<strong>STIG</strong> ID: RHEL-06-000274 Rule ID: SV-50459r1_rule Vuln<br />

ID: V-38658<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

Preventing reuse of previous passwords helps ensure that<br />

a compromised password is not reused by a user.<br />

Documentable: No<br />

Check Content:<br />

To verify the password reuse setting is compliant, run<br />

the following command:<br />

$ grep remember /etc/pam.d/system-auth<br />

The output should show the following at the end of the<br />

line:<br />

UNCLASSIFIED


UNCLASSIFIED<br />

remember=24<br />

If it does not, this is a finding.<br />

Fix Text:<br />

Do not allow users to reuse recent passwords. This can<br />

be accomplished by using the "remember" option for the<br />

"pam_unix" PAM module. In the file<br />

"/etc/pam.d/system-auth", append "remember=24" to the<br />

line which refers to the "pam_unix.so" module, as shown:<br />

password sufficient pam_unix.so [existing_options]<br />

remember=24<br />

The DoD requirement is 24 passwords.<br />

CCI: CCI-000200<br />

NIST SP 800-53A :: IA-5 (1).1 (v)<br />

NIST SP 800-53 :: IA-5 (1) (e)<br />

Rule Title: The operating system must employ<br />

cryptographic mechanisms to protect information in<br />

storage.<br />

<strong>STIG</strong> ID: RHEL-06-000275 Rule ID: SV-50460r1_rule Vuln<br />

ID: V-38659<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

The risk of a system's physical compromise, particularly<br />

mobile systems such as laptops, places its data at risk<br />

of compromise. Encrypting this data mitigates the risk<br />

of its loss if the system is lost.<br />

Documentable: No<br />

Check Content:<br />

Determine if encryption must be used to protect data on<br />

UNCLASSIFIED


UNCLASSIFIED<br />

the system.<br />

If encryption must be used and is not employed, this is<br />

a finding.<br />

Fix Text:<br />

Red Hat Enterprise Linux 6 natively supports partition<br />

encryption through the Linux Unified Key<br />

Setup-on-disk-format (LUKS) technology. The easiest way<br />

to encrypt a partition is during installation time.<br />

For manual installations, select the "Encrypt" checkbox<br />

during partition creation to encrypt the partition. When<br />

this option is selected the system will prompt for a<br />

passphrase to use in decrypting the partition. The<br />

passphrase will subsequently need to be entered manually<br />

every time the system boots.<br />

For automated/unattended installations, it is possible<br />

to use Kickstart by adding the "--encrypted" and<br />

"--passphrase=" options to the definition of each<br />

partition to be encrypted. For example, the following<br />

line would encrypt the root partition:<br />

part / --fstype=ext3 --size=100 --onpart=hda1<br />

--encrypted --passphrase=[PASSPHRASE]<br />

Any [PASSPHRASE] is stored in the Kickstart in plaintext,<br />

and the Kickstart must then be protected accordingly.<br />

Omitting the "--passphrase=" option from the partition<br />

definition will cause the installer to pause and<br />

interactively ask for the passphrase during<br />

installation.<br />

Detailed information on encrypting partitions using LUKS<br />

can be found on the Red Had Documentation web site:<br />

https://docs.redhat.com/docs/en-US/Red_Hat_Enterprise<br />

_Linux/6/html/Security_Guide/sect-Security_Guide-LUKS<br />

_Disk_Encryption.html<br />

CCI: CCI-001019<br />

UNCLASSIFIED


UNCLASSIFIED<br />

NIST SP 800-53A :: MP-4 (1).1<br />

NIST SP 800-53 :: MP-4 (1)<br />

Rule Title: The operating system must protect the<br />

confidentiality and integrity of data at rest.<br />

<strong>STIG</strong> ID: RHEL-06-000276 Rule ID: SV-50462r1_rule Vuln<br />

ID: V-38661<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

The risk of a system's physical compromise, particularly<br />

mobile systems such as laptops, places its data at risk<br />

of compromise. Encrypting this data mitigates the risk<br />

of its loss if the system is lost.<br />

Documentable: No<br />

Check Content:<br />

Determine if encryption must be used to protect data on<br />

the system.<br />

If encryption must be used and is not employed, this is<br />

a finding.<br />

Fix Text:<br />

Red Hat Enterprise Linux 6 natively supports partition<br />

encryption through the Linux Unified Key<br />

Setup-on-disk-format (LUKS) technology. The easiest way<br />

to encrypt a partition is during installation time.<br />

For manual installations, select the "Encrypt" checkbox<br />

during partition creation to encrypt the partition. When<br />

this option is selected the system will prompt for a<br />

passphrase to use in decrypting the partition. The<br />

passphrase will subsequently need to be entered manually<br />

every time the system boots.<br />

For automated/unattended installations, it is possible<br />

to use Kickstart by adding the "--encrypted" and<br />

UNCLASSIFIED


UNCLASSIFIED<br />

"--passphrase=" options to the definition of each<br />

partition to be encrypted. For example, the following<br />

line would encrypt the root partition:<br />

part / --fstype=ext3 --size=100 --onpart=hda1<br />

--encrypted --passphrase=[PASSPHRASE]<br />

Any [PASSPHRASE] is stored in the Kickstart in plaintext,<br />

and the Kickstart must then be protected accordingly.<br />

Omitting the "--passphrase=" option from the partition<br />

definition will cause the installer to pause and<br />

interactively ask for the passphrase during<br />

installation.<br />

Detailed information on encrypting partitions using LUKS<br />

can be found on the Red Had Documentation web site:<br />

https://docs.redhat.com/docs/en-US/Red_Hat_Enterprise<br />

_Linux/6/html/Security_Guide/sect-Security_Guide-LUKS<br />

_Disk_Encryption.html<br />

CCI: CCI-001199<br />

NIST SP 800-53A :: SC-28.1<br />

NIST SP 800-53 :: SC-28<br />

Rule Title: The operating system must employ<br />

cryptographic mechanisms to prevent unauthorized<br />

disclosure of data at rest unless otherwise protected by<br />

alternative physical measures.<br />

<strong>STIG</strong> ID: RHEL-06-000277 Rule ID: SV-50463r1_rule Vuln<br />

ID: V-38662<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

The risk of a system's physical compromise, particularly<br />

mobile systems such as laptops, places its data at risk<br />

of compromise. Encrypting this data mitigates the risk<br />

of its loss if the system is lost.<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Documentable: No<br />

Check Content:<br />

Determine if encryption must be used to protect data on<br />

the system.<br />

If encryption must be used and is not employed, this is<br />

a finding.<br />

Fix Text:<br />

Red Hat Enterprise Linux 6 natively supports partition<br />

encryption through the Linux Unified Key<br />

Setup-on-disk-format (LUKS) technology. The easiest way<br />

to encrypt a partition is during installation time.<br />

For manual installations, select the "Encrypt" checkbox<br />

during partition creation to encrypt the partition. When<br />

this option is selected the system will prompt for a<br />

passphrase to use in decrypting the partition. The<br />

passphrase will subsequently need to be entered manually<br />

every time the system boots.<br />

For automated/unattended installations, it is possible<br />

to use Kickstart by adding the "--encrypted" and<br />

"--passphrase=" options to the definition of each<br />

partition to be encrypted. For example, the following<br />

line would encrypt the root partition:<br />

part / --fstype=ext3 --size=100 --onpart=hda1<br />

--encrypted --passphrase=[PASSPHRASE]<br />

Any [PASSPHRASE] is stored in the Kickstart in plaintext,<br />

and the Kickstart must then be protected accordingly.<br />

Omitting the "--passphrase=" option from the partition<br />

definition will cause the installer to pause and<br />

interactively ask for the passphrase during<br />

installation.<br />

Detailed information on encrypting partitions using LUKS<br />

can be found on the Red Had Documentation web site:<br />

https://docs.redhat.com/docs/en-US/Red_Hat_Enterprise<br />

UNCLASSIFIED


UNCLASSIFIED<br />

_Linux/6/html/Security_Guide/sect-Security_Guide-LUKS<br />

_Disk_Encryption.html<br />

CCI: CCI-001200<br />

NIST SP 800-53A :: SC-28 (1).1 (i)<br />

NIST SP 800-53 :: SC-28 (1)<br />

Rule Title: The system package management tool must<br />

verify permissions on all files and directories<br />

associated with the audit package.<br />

<strong>STIG</strong> ID: RHEL-06-000278 Rule ID: SV-50464r1_rule Vuln<br />

ID: V-38663<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

Permissions on audit binaries and configuration files<br />

that are too generous could allow an unauthorized user<br />

to gain privileges that they should not have. The<br />

permissions set by the vendor should be maintained. Any<br />

deviations from this baseline should be investigated.<br />

Documentable: No<br />

Check Content:<br />

The following command will list which audit files on the<br />

system have permissions different from what is expected<br />

by the RPM database:<br />

# rpm -V audit | grep '^.M'<br />

If there is any output, for each file or directory found,<br />

compare the RPM-expected permissions with the<br />

permissions on the file or directory:<br />

# rpm -q --queryformat "[%{FILENAMES}<br />

%{FILEMODES:perms}\n]" audit | grep [filename]<br />

# ls -lL [filename]<br />

UNCLASSIFIED


UNCLASSIFIED<br />

If the existing permissions are more permissive than<br />

those expected by RPM, this is a finding.<br />

Fix Text:<br />

The RPM package management system can restore file access<br />

permissions of the audit package files and directories.<br />

The following command will update audit files with<br />

permissions different from what is expected by the RPM<br />

database:<br />

# rpm --setperms audit<br />

CCI: CCI-001493<br />

NIST SP 800-53 :: AU-9<br />

NIST SP 800-53A :: AU-9.1<br />

Rule Title: The system package management tool must<br />

verify ownership on all files and directories associated<br />

with the audit package.<br />

<strong>STIG</strong> ID: RHEL-06-000279 Rule ID: SV-50465r1_rule Vuln<br />

ID: V-38664<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

Ownership of audit binaries and configuration files that<br />

is incorrect could allow an unauthorized user to gain<br />

privileges that they should not have. The ownership set<br />

by the vendor should be maintained. Any deviations from<br />

this baseline should be investigated.<br />

Documentable: No<br />

Check Content:<br />

The following command will list which audit files on the<br />

system have ownership different from what is expected by<br />

the RPM database:<br />

# rpm -V audit | grep '^.....U'<br />

UNCLASSIFIED


UNCLASSIFIED<br />

If there is output, this is a finding.<br />

Fix Text:<br />

The RPM package management system can restore file<br />

ownership of the audit package files and directories. The<br />

following command will update audit files with ownership<br />

different from what is expected by the RPM database:<br />

# rpm --setugids audit<br />

CCI: CCI-001494<br />

NIST SP 800-53 :: AU-9<br />

NIST SP 800-53A :: AU-9.1<br />

Rule Title: The system package management tool must<br />

verify group-ownership on all files and directories<br />

associated with the audit package.<br />

<strong>STIG</strong> ID: RHEL-06-000280 Rule ID: SV-50466r1_rule Vuln<br />

ID: V-38665<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

Group-ownership of audit binaries and configuration<br />

files that is incorrect could allow an unauthorized user<br />

to gain privileges that they should not have. The<br />

group-ownership set by the vendor should be maintained.<br />

Any deviations from this baseline should be investigated.<br />

Documentable: No<br />

Check Content:<br />

The following command will list which audit files on the<br />

system have group-ownership different from what is<br />

expected by the RPM database:<br />

# rpm -V audit | grep '^......G'<br />

UNCLASSIFIED


UNCLASSIFIED<br />

If there is output, this is a finding.<br />

Fix Text:<br />

The RPM package management system can restore file<br />

group-ownership of the audit package files and<br />

directories. The following command will update audit<br />

files with group-ownership different from what is<br />

expected by the RPM database:<br />

# rpm --setugids audit<br />

CCI: CCI-001495<br />

NIST SP 800-53 :: AU-9<br />

NIST SP 800-53A :: AU-9.1<br />

Rule Title: The system package management tool must<br />

verify contents of all files associated with the audit<br />

package.<br />

<strong>STIG</strong> ID: RHEL-06-000281 Rule ID: SV-50438r1_rule Vuln<br />

ID: V-38637<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

The hash on important files like audit system executables<br />

should match the information given by the RPM database.<br />

Audit executables with erroneous hashes could be a sign<br />

of nefarious activity on the system.<br />

Documentable: No<br />

Check Content:<br />

The following command will list which audit files on the<br />

system have file hashes different from what is expected<br />

by the RPM database.<br />

# rpm -V audit | grep '$1 ~ /..5/ && $2 != "c"'<br />

UNCLASSIFIED


UNCLASSIFIED<br />

If there is output, this is a finding.<br />

Fix Text:<br />

The RPM package management system can check the hashes<br />

of audit system package files. Run the following command<br />

to list which audit files on the system have hashes that<br />

differ from what is expected by the RPM database:<br />

# rpm -V audit | grep '^..5'<br />

A "c" in the second column indicates that a file is a<br />

configuration file, which may appropriately be expected<br />

to change. If the file that has changed was not expected<br />

to then refresh from distribution media or online<br />

repositories.<br />

rpm -Uvh [affected_package]<br />

OR<br />

yum reinstall [affected_package]<br />

CCI: CCI-001496<br />

NIST SP 800-53 :: AU-9 (3)<br />

NIST SP 800-53A :: AU-9 (3).1<br />

Rule Title: There must be no world-writable files on the<br />

system.<br />

<strong>STIG</strong> ID: RHEL-06-000282 Rule ID: SV-50444r1_rule Vuln<br />

ID: V-38643<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

Data in world-writable files can be modified by any user<br />

on the system. In almost all circumstances, files can be<br />

configured using a combination of user and group<br />

UNCLASSIFIED


UNCLASSIFIED<br />

permissions to support whatever legitimate access is<br />

needed without the risk caused by world-writable files.<br />

Documentable: No<br />

Check Content:<br />

To find world-writable files, run the following command:<br />

# find / -xdev -type f -perm -002<br />

If there is output, this is a finding.<br />

Fix Text:<br />

It is generally a good idea to remove global (other) write<br />

access to a file when it is discovered. However, check<br />

with documentation for specific applications before<br />

making changes. Also, monitor for recurring<br />

world-writable files, as these may be symptoms of a<br />

misconfigured application or user account.<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: The system must use and update a<br />

DoD-approved virus scan program.<br />

<strong>STIG</strong> ID: RHEL-06-000284 Rule ID: SV-50467r1_rule Vuln<br />

ID: V-38666<br />

Severity: CAT I Class: Unclass<br />

Discussion:<br />

Virus scanning software can be used to detect if a system<br />

has been compromised by computer viruses, as well as to<br />

limit their spread to other systems.<br />

Documentable: No<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Check Content:<br />

Inspect the system for a cron job or system service which<br />

executes a virus scanning tool regularly.<br />

To verify the McAfee command line scan tool (uvscan) is<br />

scheduled for regular execution, run the following<br />

command to check for a cron job:<br />

# grep uvscan /etc/cron* /var/spool/cron/*<br />

This will reveal if and when the uvscan program will be<br />

run.<br />

To check on the age of uvscan virus definition files, run<br />

the following command:<br />

# cd /usr/local/uvscan<br />

# ls -la avvscan.dat avvnames.dat avvclean.dat<br />

The uvscan virus definitions should not be older than<br />

seven days.<br />

If virus scanning software does not run daily, or has<br />

signatures that are out of date, this is a finding.<br />

Fix Text:<br />

Install virus scanning software, which uses signatures<br />

to search for the presence of viruses on the filesystem.<br />

The McAfee uvscan virus scanning tool is provided for DoD<br />

systems. Ensure virus definition files are no older than<br />

7 days, or their last release. Configure the virus<br />

scanning software to perform scans dynamically on all<br />

accessed files. If this is not possible, configure the<br />

system to scan all altered files on the system on a daily<br />

basis. If the system processes inbound SMTP mail,<br />

configure the virus scanner to scan all received mail.<br />

CCI: CCI-001668<br />

NIST SP 800-53 :: SI-3 a<br />

NIST SP 800-53A :: SI-3.1 (ii)<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Rule Title: The system must have a host-based intrusion<br />

detection tool installed.<br />

<strong>STIG</strong> ID: RHEL-06-000285 Rule ID: SV-50468r1_rule Vuln<br />

ID: V-38667<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

Adding host-based intrusion detection tools can provide<br />

the capability to automatically take actions in response<br />

to malicious behavior, which can provide additional<br />

agility in reacting to network threats. These tools also<br />

often include a reporting capability to provide network<br />

awareness of system, which may not otherwise exist in an<br />

organization's systems management regime.<br />

Documentable: No<br />

Check Content:<br />

Inspect the system to determine if intrusion detection<br />

software has been installed. Verify the intrusion<br />

detection software is active.<br />

If no host-based intrusion detection tools are installed,<br />

this is a finding.<br />

Fix Text:<br />

The base Red Hat platform already includes a<br />

sophisticated auditing system that can detect intruder<br />

activity, as well as SELinux, which provides host-based<br />

intrusion prevention capabilities by confining<br />

privileged programs and user sessions which may become<br />

compromised.<br />

Install an additional intrusion detection tool to provide<br />

complementary or duplicative monitoring, reporting, and<br />

reaction capabilities to those of the base platform. For<br />

DoD systems, the McAfee Host-based Security System is<br />

provided to fulfill this role.<br />

CCI: CCI-001263<br />

NIST SP 800-53 :: SI-4 (5)<br />

UNCLASSIFIED


UNCLASSIFIED<br />

NIST SP 800-53A :: SI-4 (5).1 (ii)<br />

Rule Title: The x86 Ctrl-Alt-Delete key sequence must<br />

be disabled.<br />

<strong>STIG</strong> ID: RHEL-06-000286 Rule ID: SV-50469r1_rule Vuln<br />

ID: V-38668<br />

Severity: CAT I Class: Unclass<br />

Discussion:<br />

A locally logged-in user who presses Ctrl-Alt-Delete,<br />

when at the console, can reboot the system. If<br />

accidentally pressed, as could happen in the case of mixed<br />

OS environment, this can create the risk of short-term<br />

loss of availability of systems due to unintentional<br />

reboot. In the GNOME graphical environment, risk of<br />

unintentional reboot from the Ctrl-Alt-Delete sequence<br />

is reduced because the user will be prompted before any<br />

action is taken.<br />

Documentable: No<br />

Check Content:<br />

Determine what actions the system takes when the<br />

Ctrl-Alt-Delete key sequence is pressed, run the<br />

following command:<br />

# cat `grep -l control-alt-delete /etc/init/*`<br />

Examine all lines following the "start on<br />

control-alt-delete" line in any files found. By<br />

default, the system uses<br />

"/etc/init/control-alt-delete.conf" to reboot the<br />

system with the following command when the<br />

Ctrl-Alt-Delete key sequence is pressed:<br />

exec /sbin/shutdown -r now "Control-Alt-Delete pressed"<br />

If the system is configured to run any shutdown command,<br />

UNCLASSIFIED


UNCLASSIFIED<br />

this is a finding.<br />

Fix Text:<br />

Configure the system to log a message instead of rebooting<br />

the system by altering the "shutdown" line in<br />

"/etc/init/control-alt-delete.conf" to read as follows:<br />

exec /usr/bin/logger -p security.info "Ctrl-Alt-Delete<br />

pressed"<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: The postfix service must be enabled for mail<br />

delivery.<br />

<strong>STIG</strong> ID: RHEL-06-000287 Rule ID: SV-50470r1_rule Vuln<br />

ID: V-38669<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

Local mail delivery is essential to some system<br />

maintenance and notification tasks.<br />

Documentable: No<br />

Check Content:<br />

Run the following command to determine the current status<br />

of the "postfix" service:<br />

# service postfix status<br />

If the service is enabled, it should return the following:<br />

postfix is running...<br />

If the service is not enabled, this is a finding.<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Fix Text:<br />

The Postfix mail transfer agent is used for local mail<br />

delivery within the system. The default configuration<br />

only listens for connections to the default SMTP port<br />

(port 25) on the loopback interface (127.0.0.1). It is<br />

recommended to leave this service enabled for local mail<br />

delivery. The "postfix" service can be enabled with the<br />

following command:<br />

# chkconfig postfix on<br />

# service postfix start<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: The sendmail package must be removed.<br />

<strong>STIG</strong> ID: RHEL-06-000288 Rule ID: SV-50472r1_rule Vuln<br />

ID: V-38671<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

The sendmail software was not developed with security in<br />

mind and its design prevents it from being effectively<br />

contained by SELinux. Postfix should be used instead.<br />

Documentable: No<br />

Check Content:<br />

Run the following command to determine if the "sendmail"<br />

package is installed:<br />

# rpm -q sendmail<br />

If the package is installed, this is a finding.<br />

Fix Text:<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Sendmail is not the default mail transfer agent and is<br />

not installed by default. The "sendmail" package can be<br />

removed with the following command:<br />

# yum erase sendmail<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: The netconsole service must be disabled<br />

unless required.<br />

<strong>STIG</strong> ID: RHEL-06-000289 Rule ID: SV-50473r1_rule Vuln<br />

ID: V-38672<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

The "netconsole" service is not necessary unless there<br />

is a need to debug kernel panics, which is not common.<br />

Documentable: No<br />

Check Content:<br />

To check that the "netconsole" service is disabled in<br />

system boot configuration, run the following command:<br />

# chkconfig "netconsole" --list<br />

Output should indicate the "netconsole" service has<br />

either not been installed, or has been disabled at all<br />

runlevels, as shown in the example below:<br />

# chkconfig "netconsole" --list<br />

"netconsole" 0:off 1:off 2:off 3:off 4:off 5:off 6:off<br />

Run the following command to verify "netconsole" is<br />

disabled through current runtime configuration:<br />

UNCLASSIFIED


UNCLASSIFIED<br />

# service netconsole status<br />

If the service is disabled the command will return the<br />

following output:<br />

netconsole is stopped<br />

If the service is running, this is a finding.<br />

Fix Text:<br />

The "netconsole" service is responsible for loading the<br />

netconsole kernel module, which logs kernel printk<br />

messages over UDP to a syslog server. This allows<br />

debugging of problems where disk logging fails and serial<br />

consoles are impractical. The "netconsole" service can<br />

be disabled with the following command:<br />

# chkconfig netconsole off<br />

CCI: CCI-000382<br />

NIST SP 800-53A :: CM-7.1 (iii)<br />

NIST SP 800-53 :: CM-7<br />

Rule Title: X Windows must not be enabled unless<br />

required.<br />

<strong>STIG</strong> ID: RHEL-06-000290 Rule ID: SV-50475r1_rule Vuln<br />

ID: V-38674<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

Unnecessary services should be disabled to decrease the<br />

attack surface of the system.<br />

Documentable: No<br />

Check Content:<br />

To verify the default runlevel is 3, run the following<br />

UNCLASSIFIED


UNCLASSIFIED<br />

command:<br />

# grep initdefault /etc/inittab<br />

The output should show the following:<br />

id:3:initdefault:<br />

If it does not, this is a finding.<br />

Fix Text:<br />

Setting the system's runlevel to 3 will prevent automatic<br />

startup of the X server. To do so, ensure the following<br />

line in "/etc/inittab" features a "3" as shown:<br />

id:3:initdefault:<br />

CCI: CCI-001436<br />

NIST SP 800-53A :: AC-17 (8).1 (ii)<br />

NIST SP 800-53 :: AC-17 (8)<br />

Rule Title: The xorg-x11-server-common (X Windows)<br />

package must not be installed, unless required.<br />

<strong>STIG</strong> ID: RHEL-06-000291 Rule ID: SV-50477r1_rule Vuln<br />

ID: V-38676<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

Unnecessary packages should not be installed to decrease<br />

the attack surface of the system.<br />

Documentable: No<br />

Check Content:<br />

To ensure the X Windows package group is removed, run the<br />

following command:<br />

UNCLASSIFIED


UNCLASSIFIED<br />

$ rpm -qi xorg-x11-server-common<br />

The output should be:<br />

package xorg-x11-server-common is not installed<br />

If it is not, this is a finding.<br />

Fix Text:<br />

Removing all packages which constitute the X Window<br />

System ensures users or malicious software cannot start<br />

X. To do so, run the following command:<br />

# yum groupremove "X Window System"<br />

Rule Title: The DHCP client must be disabled if not<br />

needed.<br />

<strong>STIG</strong> ID: RHEL-06-000292 Rule ID: SV-50480r1_rule Vuln<br />

ID: V-38679<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

DHCP relies on trusting the local network. If the local<br />

network is not trusted, then it should not be used.<br />

However, the automatic configuration provided by DHCP is<br />

commonly used and the alternative, manual configuration,<br />

presents an unacceptable burden in many circumstances.<br />

Documentable: No<br />

Check Content:<br />

To verify that DHCP is not being used, examine the<br />

following file for each interface.<br />

# /etc/sysconfig/network-scripts/ifcfg-[IFACE]<br />

If there is any network interface without a associated<br />

UNCLASSIFIED


UNCLASSIFIED<br />

"ifcfg" file, this is a finding.<br />

Look for the following:<br />

BOOTPROTO=static<br />

Also verify the following, substituting the appropriate<br />

values based on your site's addressing scheme:<br />

NETMASK=[local LAN netmask]<br />

IPADDR=[assigned IP address]<br />

GATEWAY=[local LAN default gateway]<br />

If it does not, this is a finding.<br />

Fix Text:<br />

For each interface [IFACE] on the system (e.g. eth0), edit<br />

"/etc/sysconfig/network-scripts/ifcfg-[IFACE]" and<br />

make the following changes.<br />

Correct the BOOTPROTO line to read:<br />

BOOTPROTO=static<br />

Add or correct the following lines, substituting the<br />

appropriate values based on your site's addressing<br />

scheme:<br />

NETMASK=[local LAN netmask]<br />

IPADDR=[assigned IP address]<br />

GATEWAY=[local LAN default gateway]<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: All GIDs referenced in /etc/passwd must be<br />

UNCLASSIFIED


UNCLASSIFIED<br />

defined in /etc/group<br />

<strong>STIG</strong> ID: RHEL-06-000294 Rule ID: SV-50482r1_rule Vuln<br />

ID: V-38681<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

Inconsistency in GIDs between /etc/passwd and /etc/group<br />

could lead to a user having unintended rights.<br />

Documentable: No<br />

Check Content:<br />

To ensure all GIDs referenced in /etc/passwd are defined<br />

in /etc/group, run the following command:<br />

# pwck -rq<br />

There should be no output.<br />

If there is output, this is a finding.<br />

Fix Text:<br />

Add a group to the system for each GID referenced without<br />

a corresponding group.<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: All accounts on the system must have unique<br />

user or account names<br />

<strong>STIG</strong> ID: RHEL-06-000296 Rule ID: SV-50484r1_rule Vuln<br />

ID: V-38683<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

Unique usernames allow for accountability on the system.<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Documentable: No<br />

Check Content:<br />

Run the following command to check for duplicate account<br />

names:<br />

# pwck -rq<br />

If there are no duplicate names, no line will be returned.<br />

If a line is returned, this is a finding.<br />

Fix Text:<br />

Change usernames, or delete accounts, so each has a unique<br />

name.<br />

CCI: CCI-000804<br />

NIST SP 800-53A :: IA-8.1<br />

NIST SP 800-53 :: IA-8<br />

Rule Title: Temporary accounts must be provisioned with<br />

an expiration date.<br />

<strong>STIG</strong> ID: RHEL-06-000297 Rule ID: SV-50486r1_rule Vuln<br />

ID: V-38685<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

When temporary accounts are created, there is a risk they<br />

may remain in place and active after the need for them<br />

no longer exists. Account expiration greatly reduces the<br />

risk of accounts being misused or hijacked.<br />

Documentable: No<br />

Check Content:<br />

For every temporary account, run the following command<br />

to obtain its account aging and expiration information:<br />

# chage -l [USER]<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Verify each of these accounts has an expiration date set<br />

as documented.<br />

If any temporary accounts have no expiration date set or<br />

do not expire within a documented time frame, this is a<br />

finding.<br />

Fix Text:<br />

In the event temporary accounts are required, configure<br />

the system to terminate them after a documented time<br />

period. For every temporary account, run the following<br />

command to set an expiration date on it, substituting<br />

"[USER]" and "[YYYY-MM-DD]" appropriately:<br />

# chage -E [YYYY-MM-DD] [USER]<br />

"[YYYY-MM-DD]" indicates the documented expiration date<br />

for the account.<br />

CCI: CCI-000016<br />

NIST SP 800-53 :: AC-2 (2)<br />

NIST SP 800-53A :: AC-2 (2).1 (ii)<br />

Rule Title: Emergency accounts must be provisioned with<br />

an expiration date.<br />

<strong>STIG</strong> ID: RHEL-06-000298 Rule ID: SV-50491r1_rule Vuln<br />

ID: V-38690<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

When emergency accounts are created, there is a risk they<br />

may remain in place and active after the need for them<br />

no longer exists. Account expiration greatly reduces the<br />

risk of accounts being misused or hijacked.<br />

Documentable: No<br />

Check Content:<br />

UNCLASSIFIED


UNCLASSIFIED<br />

For every emergency account, run the following command<br />

to obtain its account aging and expiration information:<br />

# chage -l [USER]<br />

Verify each of these accounts has an expiration date set<br />

as documented.<br />

If any emergency accounts have no expiration date set or<br />

do not expire within a documented time frame, this is a<br />

finding.<br />

Fix Text:<br />

In the event emergency accounts are required, configure<br />

the system to terminate them after a documented time<br />

period. For every emergency account, run the following<br />

command to set an expiration date on it, substituting<br />

"[USER]" and "[YYYY-MM-DD]" appropriately:<br />

# chage -E [YYYY-MM-DD] [USER]<br />

"[YYYY-MM-DD]" indicates the documented expiration date<br />

for the account.<br />

CCI: CCI-001682<br />

Rule Title: The system must require passwords to contain<br />

no more than three consecutive repeating characters.<br />

<strong>STIG</strong> ID: RHEL-06-000299 Rule ID: SV-50494r1_rule Vuln<br />

ID: V-38693<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

Passwords with excessive repeating characters may be more<br />

vulnerable to password-guessing attacks.<br />

Documentable: No<br />

Check Content:<br />

UNCLASSIFIED


UNCLASSIFIED<br />

To check the maximum value for consecutive repeating<br />

characters, run the following command:<br />

$ grep pam_cracklib /etc/pam.d/system-auth<br />

Look for the value of the "maxrepeat" parameter. The DoD<br />

requirement is 3.<br />

If maxrepeat is not found or not set to the required value,<br />

this is a finding.<br />

Fix Text:<br />

The pam_cracklib module's "maxrepeat" parameter controls<br />

requirements for consecutive repeating characters. Edit<br />

the "/etc/pam.d/system-auth" file to include the<br />

following line prior to the "password include<br />

system-auth-ac" line:<br />

password required pam_cracklib.so maxrepeat=3<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: A file integrity tool must be used at least<br />

weekly to check for unauthorized file changes,<br />

particularly the addition of unauthorized system<br />

libraries or binaries, or for unauthorized modification<br />

to authorized system libraries or binaries.<br />

<strong>STIG</strong> ID: RHEL-06-000302 Rule ID: SV-50496r1_rule Vuln<br />

ID: V-38695<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

By default, AIDE does not install itself for periodic<br />

execution. Periodically running AIDE may reveal<br />

unexpected changes in installed files.<br />

Documentable: No<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Check Content:<br />

To determine that periodic AIDE execution has been<br />

scheduled, run the following command:<br />

# grep aide /etc/crontab<br />

If there is no output or if aide is not run at least weekly,<br />

this is a finding.<br />

Fix Text:<br />

AIDE should be executed on a periodic basis to check for<br />

changes. To implement a daily execution of AIDE at 4:05am<br />

using cron, add the following line to /etc/crontab:<br />

05 4 * * * root /usr/sbin/aide --check<br />

AIDE can be executed periodically through other means;<br />

this is merely one example.<br />

CCI: CCI-000374<br />

NIST SP 800-53A :: CM-6 (2).1 (ii)<br />

NIST SP 800-53 :: CM-6 (2)<br />

Rule Title: The operating system must employ automated<br />

mechanisms, per organization defined frequency, to<br />

detect the addition of unauthorized components/devices<br />

into the operating system.<br />

<strong>STIG</strong> ID: RHEL-06-000303 Rule ID: SV-50497r1_rule Vuln<br />

ID: V-38696<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

By default, AIDE does not install itself for periodic<br />

execution. Periodically running AIDE may reveal<br />

unexpected changes in installed files.<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Documentable: No<br />

Check Content:<br />

To determine that periodic AIDE execution has been<br />

scheduled, run the following command:<br />

# grep aide /etc/crontab<br />

If there is no output, this is a finding.<br />

Fix Text:<br />

AIDE should be executed on a periodic basis to check for<br />

changes. To implement a daily execution of AIDE at 4:05am<br />

using cron, add the following line to /etc/crontab:<br />

05 4 * * * root /usr/sbin/aide --check<br />

AIDE can be executed periodically through other means;<br />

this is merely one example.<br />

CCI: CCI-000416<br />

NIST SP 800-53A :: CM-8 (3).1 (ii)<br />

NIST SP 800-53 :: CM-8 (3) (a)<br />

Rule Title: The operating system must employ automated<br />

mechanisms to detect the presence of unauthorized<br />

software on organizational information systems and<br />

notify designated organizational officials in accordance<br />

with the organization defined frequency.<br />

<strong>STIG</strong> ID: RHEL-06-000304 Rule ID: SV-50499r1_rule Vuln<br />

ID: V-38698<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

By default, AIDE does not install itself for periodic<br />

execution. Periodically running AIDE may reveal<br />

unexpected changes in installed files.<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Documentable: No<br />

Check Content:<br />

To determine that periodic AIDE execution has been<br />

scheduled, run the following command:<br />

# grep aide /etc/crontab<br />

If there is no output, this is a finding.<br />

Fix Text:<br />

AIDE should be executed on a periodic basis to check for<br />

changes. To implement a daily execution of AIDE at 4:05am<br />

using cron, add the following line to /etc/crontab:<br />

05 4 * * * root /usr/sbin/aide --check<br />

AIDE can be executed periodically through other means;<br />

this is merely one example.<br />

CCI: CCI-001069<br />

NIST SP 800-53A :: RA-5 (7).1 (ii)<br />

NIST SP 800-53 :: RA-5 (7)<br />

Rule Title: The operating system must provide a near<br />

real-time alert when any of the organization defined list<br />

of compromise or potential compromise indicators occurs.<br />

<strong>STIG</strong> ID: RHEL-06-000305 Rule ID: SV-50501r1_rule Vuln<br />

ID: V-38700<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

By default, AIDE does not install itself for periodic<br />

execution. Periodically running AIDE may reveal<br />

unexpected changes in installed files.<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Documentable: No<br />

Check Content:<br />

To determine that periodic AIDE execution has been<br />

scheduled, run the following command:<br />

# grep aide /etc/crontab<br />

If there is no output, this is a finding.<br />

Fix Text:<br />

AIDE should be executed on a periodic basis to check for<br />

changes. To implement a daily execution of AIDE at 4:05am<br />

using cron, add the following line to /etc/crontab:<br />

05 4 * * * root /usr/sbin/aide --check<br />

AIDE can be executed periodically through other means;<br />

this is merely one example.<br />

CCI: CCI-001263<br />

NIST SP 800-53 :: SI-4 (5)<br />

NIST SP 800-53A :: SI-4 (5).1 (ii)<br />

Rule Title: The operating system must detect<br />

unauthorized changes to software and information.<br />

<strong>STIG</strong> ID: RHEL-06-000306 Rule ID: SV-50471r1_rule Vuln<br />

ID: V-38670<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

By default, AIDE does not install itself for periodic<br />

execution. Periodically running AIDE may reveal<br />

unexpected changes in installed files.<br />

Documentable: No<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Check Content:<br />

To determine that periodic AIDE execution has been<br />

scheduled, run the following command:<br />

# grep aide /etc/crontab<br />

If there is no output, this is a finding.<br />

Fix Text:<br />

AIDE should be executed on a periodic basis to check for<br />

changes. To implement a daily execution of AIDE at 4:05am<br />

using cron, add the following line to /etc/crontab:<br />

05 4 * * * root /usr/sbin/aide --check<br />

AIDE can be executed periodically through other means;<br />

this is merely one example.<br />

CCI: CCI-001297<br />

NIST SP 800-53 :: SI-7<br />

NIST SP 800-53A :: SI-7.1<br />

Rule Title: The operating system must ensure<br />

unauthorized, security-relevant configuration changes<br />

detected are tracked.<br />

<strong>STIG</strong> ID: RHEL-06-000307 Rule ID: SV-50474r1_rule Vuln<br />

ID: V-38673<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

By default, AIDE does not install itself for periodic<br />

execution. Periodically running AIDE may reveal<br />

unexpected changes in installed files.<br />

Documentable: No<br />

Check Content:<br />

UNCLASSIFIED


UNCLASSIFIED<br />

To determine that periodic AIDE execution has been<br />

scheduled, run the following command:<br />

# grep aide /etc/crontab<br />

If there is no output, this is a finding.<br />

Fix Text:<br />

AIDE should be executed on a periodic basis to check for<br />

changes. To implement a daily execution of AIDE at 4:05am<br />

using cron, add the following line to /etc/crontab:<br />

05 4 * * * root /usr/sbin/aide --check<br />

AIDE can be executed periodically through other means;<br />

this is merely one example.<br />

CCI: CCI-001589<br />

NIST SP 800-53 :: CM-6 (3)<br />

NIST SP 800-53A :: CM-6 (3).1 (ii)<br />

Rule Title: Process core dumps must be disabled unless<br />

needed.<br />

<strong>STIG</strong> ID: RHEL-06-000308 Rule ID: SV-50476r1_rule Vuln<br />

ID: V-38675<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

A core dump includes a memory image taken at the time the<br />

operating system terminates an application. The memory<br />

image could contain sensitive data and is generally<br />

useful only for developers trying to debug problems.<br />

Documentable: No<br />

Check Content:<br />

To verify that core dumps are disabled for all users, run<br />

UNCLASSIFIED


UNCLASSIFIED<br />

the following command:<br />

$ grep core /etc/security/limits.conf<br />

The output should be:<br />

* hard core 0<br />

If it is not, this is a finding.<br />

Fix Text:<br />

To disable core dumps for all users, add the following<br />

line to "/etc/security/limits.conf":<br />

* hard core 0<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: The NFS server must not have the insecure<br />

file locking option enabled.<br />

<strong>STIG</strong> ID: RHEL-06-000309 Rule ID: SV-50478r1_rule Vuln<br />

ID: V-38677<br />

Severity: CAT I Class: Unclass<br />

Discussion:<br />

Allowing insecure file locking could allow for sensitive<br />

data to be viewed or edited by an unauthorized user.<br />

Documentable: No<br />

Check Content:<br />

To verify insecure file locking has been disabled, run<br />

the following command:<br />

# grep insecure_locks /etc/exports<br />

UNCLASSIFIED


UNCLASSIFIED<br />

If there is output, this is a finding.<br />

Fix Text:<br />

By default the NFS server requires secure file-lock<br />

requests, which require credentials from the client in<br />

order to lock a file. Most NFS clients send credentials<br />

with file lock requests, however, there are a few clients<br />

that do not send credentials when requesting a file-lock,<br />

allowing the client to only be able to lock world-readable<br />

files. To get around this, the "insecure_locks" option<br />

can be used so these clients can access the desired<br />

export. This poses a security risk by potentially<br />

allowing the client access to data for which it does not<br />

have authorization. Remove any instances of the<br />

"insecure_locks" option from the file "/etc/exports".<br />

CCI: CCI-000764<br />

NIST SP 800-53A :: IA-2.1<br />

NIST SP 800-53 :: IA-2<br />

Rule Title: The audit system must provide a warning when<br />

allocated audit record storage volume reaches a<br />

documented percentage of maximum audit record storage<br />

capacity.<br />

<strong>STIG</strong> ID: RHEL-06-000311 Rule ID: SV-50479r1_rule Vuln<br />

ID: V-38678<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

Notifying administrators of an impending disk space<br />

problem may allow them to take corrective action prior<br />

to any disruption.<br />

Documentable: No<br />

Check Content:<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Inspect "/etc/audit/auditd.conf" and locate the<br />

following line to determine whether the system is<br />

configured to email the administrator when disk space is<br />

starting to run low:<br />

# grep space_left /etc/audit/auditd.conf<br />

space_left = [num_megabytes]<br />

If the "num_megabytes" value does not correspond to a<br />

documented value for remaining audit partition capacity<br />

or if there is no locally documented value for remaining<br />

audit partition capacity, this is a finding.<br />

Fix Text:<br />

The "auditd" service can be configured to take an action<br />

when disk space starts to run low. Edit the file<br />

"/etc/audit/auditd.conf". Modify the following line,<br />

substituting [ACTION] appropriately:<br />

space_left = [num_megabytes]<br />

The "num_megabytes" value should be set to a fraction of<br />

the total audit storage capacity available that will<br />

allow a system administrator to be notified with enough<br />

time to respond to the situation causing the capacity<br />

issues. This value must also be documented locally.<br />

CCI: CCI-000143<br />

NIST SP 800-53A :: AU-5 (1).1 (ii)<br />

NIST SP 800-53 :: AU-5 (1)<br />

Rule Title: The audit system must identify staff members<br />

to receive notifications of audit log storage volume<br />

capacity issues.<br />

<strong>STIG</strong> ID: RHEL-06-000313 Rule ID: SV-50481r1_rule Vuln<br />

ID: V-38680<br />

Severity: CAT II Class: Unclass<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Discussion:<br />

Email sent to the root account is typically aliased to<br />

the administrators of the system, who can take<br />

appropriate action.<br />

Documentable: No<br />

Check Content:<br />

Inspect "/etc/audit/auditd.conf" and locate the<br />

following line to determine if the system is configured<br />

to send email to an account when it needs to notify an<br />

administrator:<br />

action_mail_acct = root<br />

If auditd is not configured to send emails per identified<br />

actions, this is a finding.<br />

Fix Text:<br />

The "auditd" service can be configured to send email to<br />

a designated account in certain situations. Add or<br />

correct the following line in "/etc/audit/auditd.conf"<br />

to ensure that administrators are notified via email for<br />

those situations:<br />

action_mail_acct = root<br />

CCI: CCI-000139<br />

NIST SP 800-53A :: AU-5.1 (ii)<br />

NIST SP 800-53 :: AU-5 a<br />

Rule Title: The Bluetooth kernel module must be<br />

disabled.<br />

<strong>STIG</strong> ID: RHEL-06-000315 Rule ID: SV-50483r1_rule Vuln<br />

ID: V-38682<br />

Severity: CAT II Class: Unclass<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Discussion:<br />

If Bluetooth functionality must be disabled, preventing<br />

the kernel from loading the kernel module provides an<br />

additional safeguard against its activation.<br />

Documentable: No<br />

Check Content:<br />

If the system is configured to prevent the loading of the<br />

"bluetooth" kernel module, it will contain lines inside<br />

any file in "/etc/modprobe.d" or the<br />

deprecated"/etc/modprobe.conf". These lines instruct<br />

the module loading system to run another program (such<br />

as "/bin/true") upon a module "install" event. Run the<br />

following command to search for such lines in all files<br />

in "/etc/modprobe.d" and the deprecated<br />

"/etc/modprobe.conf":<br />

$ grep -r bluetooth /etc/modprobe.conf /etc/modprobe.d<br />

If the system is configured to prevent the loading of the<br />

"net-pf-31" kernel module, it will contain lines inside<br />

any file in "/etc/modprobe.d" or the<br />

deprecated"/etc/modprobe.conf". These lines instruct<br />

the module loading system to run another program (such<br />

as "/bin/true") upon a module "install" event. Run the<br />

following command to search for such lines in all files<br />

in "/etc/modprobe.d" and the deprecated<br />

"/etc/modprobe.conf":<br />

$ grep -r net-pf-31 /etc/modprobe.conf /etc/modprobe.d<br />

If no line is returned, this is a finding.<br />

Fix Text:<br />

The kernel's module loading system can be configured to<br />

prevent loading of the Bluetooth module. Add the<br />

following to the appropriate "/etc/modprobe.d"<br />

UNCLASSIFIED


UNCLASSIFIED<br />

configuration file to prevent the loading of the<br />

Bluetooth module:<br />

install net-pf-31 /bin/true<br />

install bluetooth /bin/true<br />

CCI: CCI-000085<br />

NIST SP 800-53A :: AC-19.1 (iii)<br />

NIST SP 800-53 :: AC-19 c<br />

Rule Title: The system must limit users to 10<br />

simultaneous system logins, or a site-defined number, in<br />

accordance with operational requirements.<br />

<strong>STIG</strong> ID: RHEL-06-000319 Rule ID: SV-50485r1_rule Vuln<br />

ID: V-38684<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

Limiting simultaneous user logins can insulate the system<br />

from denial of service problems caused by excessive<br />

logins. Automated login processes operating improperly<br />

or maliciously may result in an exceptional number of<br />

simultaneous login sessions.<br />

Documentable: No<br />

Check Content:<br />

Run the following command to ensure the "maxlogins" value<br />

is configured for all users on the system:<br />

# grep "maxlogins" /etc/security/limits.conf<br />

You should receive output similar to the following:<br />

* hard maxlogins 10<br />

If it is not set to 10 or a documented site-defined number,<br />

this is a finding.<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Fix Text:<br />

Limiting the number of allowed users and sessions per user<br />

can limit risks related to denial of service attacks. This<br />

addresses concurrent sessions for a single account and<br />

does not address concurrent sessions by a single user via<br />

multiple accounts. To set the number of concurrent<br />

sessions per user add the following line in<br />

"/etc/security/limits.conf":<br />

* hard maxlogins 10<br />

A documented site-defined number may be substituted for<br />

10 in the above.<br />

CCI: CCI-000054<br />

NIST SP 800-53 :: AC-10<br />

NIST SP 800-53A :: AC-10.1 (ii)<br />

Rule Title: The systems local firewall must implement<br />

a deny-all, allow-by-exception policy for forwarded<br />

packets.<br />

<strong>STIG</strong> ID: RHEL-06-000320 Rule ID: SV-50487r1_rule Vuln<br />

ID: V-38686<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

In "iptables" the default policy is applied only after<br />

all the applicable rules in the table are examined for<br />

a match. Setting the default policy to "DROP" implements<br />

proper design for a firewall, i.e., any packets which are<br />

not explicitly permitted should not be accepted.<br />

Documentable: No<br />

Check Content:<br />

Run the following command to ensure the default "FORWARD"<br />

policy is "DROP":<br />

UNCLASSIFIED


UNCLASSIFIED<br />

grep ":FORWARD" /etc/sysconfig/iptables<br />

The output must be the following:<br />

# grep ":FORWARD" /etc/sysconfig/iptables<br />

:FORWARD DROP [0:0]<br />

If it is not, this is a finding.<br />

Fix Text:<br />

To set the default policy to DROP (instead of ACCEPT) for<br />

the built-in FORWARD chain which processes packets that<br />

will be forwarded from one interface to another, add or<br />

correct the following line in "/etc/sysconfig/iptables":<br />

:FORWARD DROP [0:0]<br />

CCI: CCI-001109<br />

NIST SP 800-53A :: SC-7 (5).1 (i) (ii)<br />

NIST SP 800-53 :: SC-7 (5)<br />

Rule Title: The system must provide VPN connectivity for<br />

communications over untrusted networks.<br />

<strong>STIG</strong> ID: RHEL-06-000321 Rule ID: SV-50488r1_rule Vuln<br />

ID: V-38687<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

Providing the ability for remote users or systems to<br />

initiate a secure VPN connection protects information<br />

when it is transmitted over a wide area network.<br />

Documentable: No<br />

Check Content:<br />

Run the following command to determine if the "openswan"<br />

package is installed:<br />

UNCLASSIFIED


UNCLASSIFIED<br />

# rpm -q openswan<br />

If the package is not installed, this is a finding.<br />

Fix Text:<br />

The Openswan package provides an implementation of IPsec<br />

and IKE, which permits the creation of secure tunnels over<br />

untrusted networks. The "openswan" package can be<br />

installed with the following command:<br />

# yum install openswan<br />

CCI: CCI-001130<br />

NIST SP 800-53A :: SC-9.1<br />

NIST SP 800-53 :: SC-9<br />

Rule Title: A login banner must be displayed immediately<br />

prior to, or as part of, graphical desktop environment<br />

login prompts.<br />

<strong>STIG</strong> ID: RHEL-06-000324 Rule ID: SV-50489r1_rule Vuln<br />

ID: V-38688<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

An appropriate warning message reinforces policy<br />

awareness during the logon process and facilitates<br />

possible legal action against attackers.<br />

Documentable: No<br />

Check Content:<br />

To ensure a login warning banner is enabled, run the<br />

following:<br />

$ gconftool-2 -g<br />

/apps/gdm/simple-greeter/banner_message_enable<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Search for the "banner_message_enable" schema. If<br />

properly configured, the "default" value should be<br />

"true".<br />

If it is not, this is a finding.<br />

Fix Text:<br />

To enable displaying a login warning banner in the GNOME<br />

Display Manager's login screen, run the following<br />

command:<br />

sudo -u gdm gconftool-2 \<br />

--type bool \<br />

--set /apps/gdm/simple-greeter/banner_message_enable<br />

true<br />

To display a banner, this setting must be enabled and then<br />

banner text must also be set.<br />

CCI: CCI-000050<br />

NIST SP 800-53 :: AC-8 b<br />

NIST SP 800-53A :: AC-8.1 (iii)<br />

Rule Title: The Department of Defense (DoD) login banner<br />

must be displayed immediately prior to, or as part of,<br />

graphical desktop environment login prompts.<br />

<strong>STIG</strong> ID: RHEL-06-000326 Rule ID: SV-50490r1_rule Vuln<br />

ID: V-38689<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

An appropriate warning message reinforces policy<br />

awareness during the logon process and facilitates<br />

possible legal action against attackers.<br />

Documentable: No<br />

Check Content:<br />

UNCLASSIFIED


UNCLASSIFIED<br />

To ensure login warning banner text is properly set, run<br />

the following:<br />

$ gconftool-2 -g<br />

/apps/gdm/simple-greeter/banner_message_text<br />

If properly configured, the proper banner text will<br />

appear within this schema.<br />

The DoD required text is either:<br />

"You are accessing a U.S. Government (USG) Information<br />

System (IS) that is provided for USG-authorized use only.<br />

By using this IS (which includes any device attached to<br />

this IS), you consent to the following conditions:<br />

-The USG routinely intercepts and monitors<br />

communications on this IS for purposes including, but not<br />

limited to, penetration testing, COMSEC monitoring,<br />

network operations and defense, personnel misconduct<br />

(PM), law enforcement (LE), and counterintelligence (CI)<br />

investigations.<br />

-At any time, the USG may inspect and seize data stored<br />

on this IS.<br />

-Communications using, or data stored on, this IS are not<br />

private, are subject to routine monitoring,<br />

interception, and search, and may be disclosed or used<br />

for any USG-authorized purpose.<br />

-This IS includes security measures (e.g.,<br />

authentication and access controls) to protect USG<br />

interests -- not for your personal benefit or privacy.<br />

-Notwithstanding the above, using this IS does not<br />

constitute consent to PM, LE or CI investigative<br />

searching or monitoring of the content of privileged<br />

communications, or work product, related to personal<br />

representation or services by attorneys,<br />

psychotherapists, or clergy, and their assistants. Such<br />

communications and work product are private and<br />

confidential. See User Agreement for details."<br />

OR:<br />

UNCLASSIFIED


UNCLASSIFIED<br />

"I've read & consent to terms in IS user agreem't."<br />

If the DoD required banner text is not appear in the<br />

schema, this is a finding.<br />

Fix Text:<br />

To set the text shown by the GNOME Display Manager in the<br />

login screen, run the following command:<br />

sudo -u gdm gconftool-2 \<br />

--type string \<br />

--set /apps/gdm/simple-greeter/banner_message_text \<br />

"[DoD required text]"<br />

Where the DoD required text is either:<br />

"You are accessing a U.S. Government (USG) Information<br />

System (IS) that is provided for USG-authorized use only.<br />

By using this IS (which includes any device attached to<br />

this IS), you consent to the following conditions:<br />

-The USG routinely intercepts and monitors<br />

communications on this IS for purposes including, but not<br />

limited to, penetration testing, COMSEC monitoring,<br />

network operations and defense, personnel misconduct<br />

(PM), law enforcement (LE), and counterintelligence (CI)<br />

investigations.<br />

-At any time, the USG may inspect and seize data stored<br />

on this IS.<br />

-Communications using, or data stored on, this IS are not<br />

private, are subject to routine monitoring,<br />

interception, and search, and may be disclosed or used<br />

for any USG-authorized purpose.<br />

-This IS includes security measures (e.g.,<br />

authentication and access controls) to protect USG<br />

interests -- not for your personal benefit or privacy.<br />

-Notwithstanding the above, using this IS does not<br />

constitute consent to PM, LE or CI investigative<br />

searching or monitoring of the content of privileged<br />

communications, or work product, related to personal<br />

UNCLASSIFIED


UNCLASSIFIED<br />

representation or services by attorneys,<br />

psychotherapists, or clergy, and their assistants. Such<br />

communications and work product are private and<br />

confidential. See User Agreement for details."<br />

OR:<br />

"I've read & consent to terms in IS user agreem't."<br />

When entering a warning banner that spans several lines,<br />

remember to begin and end the string with """. This<br />

command writes directly to the file<br />

"/var/lib/gdm/.gconf/apps/gdm/simple-greeter/%gconf.x<br />

ml", and this file can later be edited directly if<br />

necessary.<br />

CCI: CCI-001384<br />

NIST SP 800-53 :: AC-8 c<br />

NIST SP 800-53A :: AC-8.2 (i)<br />

CCI: CCI-001385<br />

NIST SP 800-53 :: AC-8 c<br />

NIST SP 800-53A :: AC-8.2 (ii)<br />

CCI: CCI-001386<br />

NIST SP 800-53 :: AC-8 c<br />

NIST SP 800-53A :: AC-8.2 (ii)<br />

CCI: CCI-001387<br />

NIST SP 800-53 :: AC-8 c<br />

NIST SP 800-53A :: AC-8.2 (ii)<br />

CCI: CCI-001388<br />

NIST SP 800-53 :: AC-8 c<br />

NIST SP 800-53A :: AC-8.2 (iii)<br />

Rule Title: The Bluetooth service must be disabled.<br />

<strong>STIG</strong> ID: RHEL-06-000331 Rule ID: SV-50492r1_rule Vuln<br />

ID: V-38691<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

Disabling the "bluetooth" service prevents the system<br />

from attempting connections to Bluetooth devices, which<br />

entails some security risk. Nevertheless, variation in<br />

this risk decision may be expected due to the utility of<br />

Bluetooth connectivity and its limited range.<br />

Documentable: No<br />

Check Content:<br />

To check that the "bluetooth" service is disabled in<br />

system boot configuration, run the following command:<br />

# chkconfig "bluetooth" --list<br />

Output should indicate the "bluetooth" service has either<br />

not been installed, or has been disabled at all runlevels,<br />

as shown in the example below:<br />

# chkconfig "bluetooth" --list<br />

"bluetooth" 0:off 1:off 2:off 3:off 4:off 5:off 6:off<br />

Run the following command to verify "bluetooth" is<br />

disabled through current runtime configuration:<br />

# service bluetooth status<br />

If the service is disabled the command will return the<br />

following output:<br />

bluetooth is stopped<br />

If the service is running, this is a finding.<br />

Fix Text:<br />

The "bluetooth" service can be disabled with the<br />

following command:<br />

UNCLASSIFIED


UNCLASSIFIED<br />

# chkconfig bluetooth off<br />

# service bluetooth stop<br />

CCI: CCI-000085<br />

NIST SP 800-53A :: AC-19.1 (iii)<br />

NIST SP 800-53 :: AC-19 c<br />

Rule Title: Accounts must be locked upon 35 days of<br />

inactivity.<br />

<strong>STIG</strong> ID: RHEL-06-000334 Rule ID: SV-50493r1_rule Vuln<br />

ID: V-38692<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

Disabling inactive accounts ensures that accounts which<br />

may not have been responsibly removed are not available<br />

to attackers who may have compromised their credentials.<br />

Documentable: No<br />

Check Content:<br />

To verify the "INACTIVE" setting, run the following<br />

command:<br />

grep "INACTIVE" /etc/default/useradd<br />

The output should indicate the "INACTIVE" configuration<br />

option is set to an appropriate integer as shown in the<br />

example below:<br />

# grep "INACTIVE" /etc/default/useradd<br />

INACTIVE=35<br />

If it does not, this is a finding.<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Fix Text:<br />

To specify the number of days after a password expires<br />

(which signifies inactivity) until an account is<br />

permanently disabled, add or correct the following lines<br />

in "/etc/default/useradd", substituting "[NUM_DAYS]"<br />

appropriately:<br />

INACTIVE=[NUM_DAYS]<br />

A value of 35 is recommended. If a password is currently<br />

on the verge of expiration, then 35 days remain until the<br />

account is automatically disabled. However, if the<br />

password will not expire for another 60 days, then 95 days<br />

could elapse until the account would be automatically<br />

disabled. See the "useradd" man page for more<br />

information. Determining the inactivity timeout must be<br />

done with careful consideration of the length of a<br />

"normal" period of inactivity for users in the particular<br />

environment. Setting the timeout too low incurs support<br />

costs and also has the potential to impact availability<br />

of the system to legitimate users.<br />

CCI: CCI-000017<br />

NIST SP 800-53 :: AC-2 (3)<br />

NIST SP 800-53A :: AC-2 (3).1 (ii)<br />

Rule Title: The operating system must manage<br />

information system identifiers for users and devices by<br />

disabling the user identifier after an organization<br />

defined time period of inactivity.<br />

<strong>STIG</strong> ID: RHEL-06-000335 Rule ID: SV-50495r1_rule Vuln<br />

ID: V-38694<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

Disabling inactive accounts ensures that accounts which<br />

may not have been responsibly removed are not available<br />

UNCLASSIFIED


UNCLASSIFIED<br />

to attackers who may have compromised their credentials.<br />

Documentable: No<br />

Check Content:<br />

To verify the "INACTIVE" setting, run the following<br />

command:<br />

grep "INACTIVE" /etc/default/useradd<br />

The output should indicate the "INACTIVE" configuration<br />

option is set to an appropriate integer as shown in the<br />

example below:<br />

# grep "INACTIVE" /etc/default/useradd<br />

INACTIVE=35<br />

If it does not, this is a finding.<br />

Fix Text:<br />

To specify the number of days after a password expires<br />

(which signifies inactivity) until an account is<br />

permanently disabled, add or correct the following lines<br />

in "/etc/default/useradd", substituting "[NUM_DAYS]"<br />

appropriately:<br />

INACTIVE=[NUM_DAYS]<br />

A value of 35 is recommended. If a password is currently<br />

on the verge of expiration, then 35 days remain until the<br />

account is automatically disabled. However, if the<br />

password will not expire for another 60 days, then 95 days<br />

could elapse until the account would be automatically<br />

disabled. See the "useradd" man page for more<br />

information. Determining the inactivity timeout must be<br />

done with careful consideration of the length of a<br />

"normal" period of inactivity for users in the particular<br />

environment. Setting the timeout too low incurs support<br />

costs and also has the potential to impact availability<br />

of the system to legitimate users.<br />

UNCLASSIFIED


UNCLASSIFIED<br />

CCI: CCI-000795<br />

NIST SP 800-53A :: IA-4.1 (iii)<br />

NIST SP 800-53 :: IA-4 e<br />

Rule Title: The sticky bit must be set on all public<br />

directories.<br />

<strong>STIG</strong> ID: RHEL-06-000336 Rule ID: SV-50498r1_rule Vuln<br />

ID: V-38697<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

Failing to set the sticky bit on public directories allows<br />

unauthorized users to delete files in the directory<br />

structure.<br />

The only authorized public directories are those<br />

temporary directories supplied with the system, or those<br />

designed to be temporary file repositories. The setting<br />

is normally reserved for directories used by the system,<br />

and by users for temporary file storage - such as /tmp<br />

- and for directories requiring global read/write access.<br />

Documentable: No<br />

Check Content:<br />

To find world-writable directories that lack the sticky<br />

bit, run the following command:<br />

# find / -xdev -type d -perm 002 ! -perm 1000<br />

If any world-writable directories are missing the sticky<br />

bit, this is a finding.<br />

Fix Text:<br />

When the so-called 'sticky bit' is set on a directory,<br />

only the owner of a given file may remove that file from<br />

UNCLASSIFIED


UNCLASSIFIED<br />

the directory. Without the sticky bit, any user with write<br />

access to a directory may remove any file in the<br />

directory. Setting the sticky bit prevents users from<br />

removing each other's files. In cases where there is no<br />

reason for a directory to be world-writable, a better<br />

solution is to remove that permission rather than to set<br />

the sticky bit. However, if a directory is used by a<br />

particular application, consult that application's<br />

documentation instead of blindly changing modes.<br />

To set the sticky bit on a world-writable directory [DIR],<br />

run the following command:<br />

# chmod +t [DIR]<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: All public directories must be owned by a<br />

system account.<br />

<strong>STIG</strong> ID: RHEL-06-000337 Rule ID: SV-50500r1_rule Vuln<br />

ID: V-38699<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

Allowing a user account to own a world-writable directory<br />

is undesirable because it allows the owner of that<br />

directory to remove or replace any files that may be<br />

placed in the directory by other users.<br />

Documentable: No<br />

Check Content:<br />

The following command will discover and print<br />

world-writable directories that are not owned by a system<br />

account, given the assumption that only system accounts<br />

have a uid lower than 500. Run it once for each local<br />

partition [PART]:<br />

UNCLASSIFIED


UNCLASSIFIED<br />

# find [PART] -xdev -type d -perm 0002 -uid +500 -print<br />

If there is output, this is a finding.<br />

Fix Text:<br />

All directories in local partitions which are<br />

world-writable should be owned by root or another system<br />

account. If any world-writable directories are not owned<br />

by a system account, this should be investigated.<br />

Following this, the files should be deleted or assigned<br />

to an appropriate group.<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: The TFTP daemon must operate in secure mode<br />

which provides access only to a single directory on the<br />

host file system.<br />

<strong>STIG</strong> ID: RHEL-06-000338 Rule ID: SV-50502r1_rule Vuln<br />

ID: V-38701<br />

Severity: CAT I Class: Unclass<br />

Discussion:<br />

Using the "-s" option causes the TFTP service to only<br />

serve files from the given directory. Serving files from<br />

an intentionally specified directory reduces the risk of<br />

sharing files which should remain private.<br />

Documentable: No<br />

Check Content:<br />

Verify "tftp" is configured by with the "-s" option by<br />

running the following command:<br />

grep "server_args" /etc/xinetd.d/tftp<br />

UNCLASSIFIED


UNCLASSIFIED<br />

The output should indicate the "server_args" variable is<br />

configured with the "-s" flag, matching the example<br />

below:<br />

# grep "server_args" /etc/xinetd.d/tftp<br />

server_args = -s /var/lib/tftpboot<br />

If it does not, this is a finding.<br />

Fix Text:<br />

If running the "tftp" service is necessary, it should be<br />

configured to change its root directory at startup. To<br />

do so, ensure "/etc/xinetd.d/tftp" includes "-s" as a<br />

command line argument, as shown in the following example<br />

(which is also the default):<br />

server_args = -s /var/lib/tftpboot<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: The FTP daemon must be configured for<br />

logging or verbose mode.<br />

<strong>STIG</strong> ID: RHEL-06-000339 Rule ID: SV-50503r1_rule Vuln<br />

ID: V-38702<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

To trace malicious activity facilitated by the FTP<br />

service, it must be configured to ensure that all commands<br />

sent to the ftp server are logged using the verbose vsftpd<br />

log format. The default vsftpd log file is<br />

/var/log/vsftpd.log.<br />

Documentable: No<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Check Content:<br />

Find if logging is applied to the ftp daemon.<br />

Procedures:<br />

If vsftpd is started by xinetd the following command will<br />

indicate the xinetd.d startup file.<br />

# grep vsftpd /etc/xinetd.d/*<br />

# grep server_args [vsftpd xinetd.d startup file]<br />

This will indicate the vsftpd config file used when<br />

starting through xinetd. If the [server_args]line is<br />

missing or does not include the vsftpd configuration<br />

file, then the default config file<br />

(/etc/vsftpd/vsftpd.conf) is used.<br />

# grep xferlog_enable [vsftpd config file]<br />

If xferlog_enable is missing, or is not set to yes, this<br />

is a finding.<br />

Fix Text:<br />

Add or correct the following configuration options within<br />

the "vsftpd" configuration file, located at<br />

"/etc/vsftpd/vsftpd.conf".<br />

xferlog_enable=YES<br />

xferlog_std_format=NO<br />

log_ftp_protocol=YES<br />

CCI: CCI-000130<br />

NIST SP 800-53A :: AU-3.1<br />

NIST SP 800-53 :: AU-3<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Rule Title: The snmpd service must use only SNMP<br />

protocol version 3 or newer.<br />

<strong>STIG</strong> ID: RHEL-06-000340 Rule ID: SV-50461r1_rule Vuln<br />

ID: V-38660<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

Earlier versions of SNMP are considered insecure, as they<br />

potentially allow unauthorized access to detailed system<br />

management information.<br />

Documentable: No<br />

Check Content:<br />

To ensure only SNMPv3 or newer is used, run the following<br />

command:<br />

# grep 'v1\|v2c\|com2sec' /etc/snmp/snmpd.conf | grep -v<br />

'^#'<br />

There should be no output.<br />

If there is output, this is a finding.<br />

Fix Text:<br />

Edit "/etc/snmp/snmpd.conf", removing any references to<br />

"v1", "v2c", or "com2sec". Upon doing that, restart the<br />

SNMP service:<br />

# service snmpd restart<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: The snmpd service must not use a default<br />

password.<br />

<strong>STIG</strong> ID: RHEL-06-000341 Rule ID: SV-50454r1_rule Vuln<br />

UNCLASSIFIED


UNCLASSIFIED<br />

ID: V-38653<br />

Severity: CAT I Class: Unclass<br />

Discussion:<br />

Presence of the default SNMP password enables querying<br />

of different system aspects and could result in<br />

unauthorized knowledge of the system.<br />

Documentable: No<br />

Check Content:<br />

To ensure the default password is not set, run the<br />

following command:<br />

# grep -v "^#" /etc/snmp/snmpd.conf| grep public<br />

There should be no output.<br />

If there is output, this is a finding.<br />

Fix Text:<br />

Edit "/etc/snmp/snmpd.conf", remove default community<br />

string "public". Upon doing that, restart the SNMP<br />

service:<br />

# service snmpd restart<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: The system default umask for the bash shell<br />

must be 077.<br />

<strong>STIG</strong> ID: RHEL-06-000342 Rule ID: SV-50452r1_rule Vuln<br />

ID: V-38651<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

UNCLASSIFIED


UNCLASSIFIED<br />

The umask value influences the permissions assigned to<br />

files when they are created. A misconfigured umask value<br />

could result in files with excessive permissions that can<br />

be read and/or written to by unauthorized users.<br />

Documentable: No<br />

Check Content:<br />

Verify the "umask" setting is configured correctly in the<br />

"/etc/bashrc" file by running the following command:<br />

# grep "umask" /etc/bashrc<br />

All output must show the value of "umask" set to 077, as<br />

shown below:<br />

# grep "umask" /etc/bashrc<br />

umask 077<br />

umask 077<br />

If the above command returns no output, or if the umask<br />

is configured incorrectly, this is a finding.<br />

Fix Text:<br />

To ensure the default umask for users of the Bash shell<br />

is set properly, add or correct the "umask" setting in<br />

"/etc/bashrc" to read as follows:<br />

umask 077<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: The system default umask for the csh shell<br />

must be 077.<br />

<strong>STIG</strong> ID: RHEL-06-000343 Rule ID: SV-50450r1_rule Vuln<br />

ID: V-38649<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

The umask value influences the permissions assigned to<br />

files when they are created. A misconfigured umask value<br />

could result in files with excessive permissions that can<br />

be read and/or written to by unauthorized users.<br />

Documentable: No<br />

Check Content:<br />

Verify the "umask" setting is configured correctly in the<br />

"/etc/csh.cshrc" file by running the following command:<br />

# grep "umask" /etc/csh.cshrc<br />

All output must show the value of "umask" set to 077, as<br />

shown in the below:<br />

# grep "umask" /etc/csh.cshrc<br />

umask 077<br />

If the above command returns no output, or if the umask<br />

is configured incorrectly, this is a finding.<br />

Fix Text:<br />

To ensure the default umask for users of the C shell is<br />

set properly, add or correct the "umask" setting in<br />

"/etc/csh.cshrc" to read as follows:<br />

umask 077<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: The system default umask in /etc/profile<br />

UNCLASSIFIED


UNCLASSIFIED<br />

must be 077.<br />

<strong>STIG</strong> ID: RHEL-06-000344 Rule ID: SV-50448r1_rule Vuln<br />

ID: V-38647<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

The umask value influences the permissions assigned to<br />

files when they are created. A misconfigured umask value<br />

could result in files with excessive permissions that can<br />

be read and/or written to by unauthorized users.<br />

Documentable: No<br />

Check Content:<br />

Verify the "umask" setting is configured correctly in the<br />

"/etc/profile" file by running the following command:<br />

# grep "umask" /etc/profile<br />

All output must show the value of "umask" set to 077, as<br />

shown in the below:<br />

# grep "umask" /etc/profile<br />

umask 077<br />

If the above command returns no output, or if the umask<br />

is configured incorrectly, this is a finding.<br />

Fix Text:<br />

To ensure the default umask controlled by "/etc/profile"<br />

is set properly, add or correct the "umask" setting in<br />

"/etc/profile" to read as follows:<br />

umask 077<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Rule Title: The system default umask in /etc/login.defs<br />

must be 077.<br />

<strong>STIG</strong> ID: RHEL-06-000345 Rule ID: SV-50446r1_rule Vuln<br />

ID: V-38645<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

The umask value influences the permissions assigned to<br />

files when they are created. A misconfigured umask value<br />

could result in files with excessive permissions that can<br />

be read and/or written to by unauthorized users.<br />

Documentable: No<br />

Check Content:<br />

Verify the "umask" setting is configured correctly in the<br />

"/etc/login.defs" file by running the following command:<br />

# grep -i "umask" /etc/login.defs<br />

All output must show the value of "umask" set to 077, as<br />

shown in the below:<br />

# grep -i "umask" /etc/login.defs<br />

UMASK 077<br />

If the above command returns no output, or if the umask<br />

is configured incorrectly, this is a finding.<br />

Fix Text:<br />

To ensure the default umask controlled by<br />

"/etc/login.defs" is set properly, add or correct the<br />

"umask" setting in "/etc/login.defs" to read as follows:<br />

UMASK 077<br />

CCI: CCI-000366<br />

UNCLASSIFIED


UNCLASSIFIED<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: The system default umask for daemons must<br />

be 027 or 022.<br />

<strong>STIG</strong> ID: RHEL-06-000346 Rule ID: SV-50443r1_rule Vuln<br />

ID: V-38642<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

The umask influences the permissions assigned to files<br />

created by a process at run time. An unnecessarily<br />

permissive umask could result in files being created with<br />

insecure permissions.<br />

Documentable: No<br />

Check Content:<br />

To check the value of the "umask", run the following<br />

command:<br />

$ grep umask /etc/init.d/functions<br />

The output should show either "022" or "027".<br />

If it does not, this is a finding.<br />

Fix Text:<br />

The file "/etc/init.d/functions" includes<br />

initialization parameters for most or all daemons started<br />

at boot time. The default umask of 022 prevents creation<br />

of group- or world-writable files. To set the default<br />

umask for daemons, edit the following line, inserting 022<br />

or 027 for [UMASK] appropriately:<br />

umask [UMASK]<br />

Setting the umask to too restrictive a setting can cause<br />

serious errors at runtime. Many daemons on the system<br />

UNCLASSIFIED


UNCLASSIFIED<br />

already individually restrict themselves to a umask of<br />

077 in their own init scripts.<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: There must be no .netrc files on the system.<br />

<strong>STIG</strong> ID: RHEL-06-000347 Rule ID: SV-50420r1_rule Vuln<br />

ID: V-38619<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

Unencrypted passwords for remote FTP servers may be<br />

stored in ".netrc" files. DoD policy requires passwords<br />

be encrypted in storage and not used in access scripts.<br />

Documentable: No<br />

Check Content:<br />

To check the system for the existence of any ".netrc"<br />

files, run the following command:<br />

# find /home -xdev -name .netrc<br />

If any .netrc files exist, this is a finding.<br />

Fix Text:<br />

The ".netrc" files contain login information used to<br />

auto-login into FTP servers and reside in the user's home<br />

directory. These files may contain unencrypted passwords<br />

to remote FTP servers making them susceptible to access<br />

by unauthorized users and should not be used. Any ".netrc"<br />

files should be removed.<br />

CCI: CCI-000196<br />

NIST SP 800-53A :: IA-5 (1).1 (v)<br />

UNCLASSIFIED


UNCLASSIFIED<br />

NIST SP 800-53 :: IA-5 (1) (c)<br />

Rule Title: The FTPS/FTP service on the system must be<br />

configured with the Department of Defense (DoD) login<br />

banner.<br />

<strong>STIG</strong> ID: RHEL-06-000348 Rule ID: SV-50400r1_rule Vuln<br />

ID: V-38599<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

This setting will cause the system greeting banner to be<br />

used for FTP connections as well.<br />

Documentable: No<br />

Check Content:<br />

To verify this configuration, run the following command:<br />

grep "banner_file" /etc/vsftpd/vsftpd.conf<br />

The output should show the value of "banner_file" is set<br />

to "/etc/issue", an example of which is shown below.<br />

# grep "banner_file" /etc/vsftpd/vsftpd.conf<br />

banner_file=/etc/issue<br />

If it does not, this is a finding.<br />

Fix Text:<br />

Edit the vsftpd configuration file, which resides at<br />

"/etc/vsftpd/vsftpd.conf" by default. Add or correct the<br />

following configuration options.<br />

banner_file=/etc/issue<br />

CCI: CCI-000048<br />

NIST SP 800-53 :: AC-8 a<br />

UNCLASSIFIED


UNCLASSIFIED<br />

NIST SP 800-53A :: AC-8.1 (ii)<br />

Rule Title: The system must be configured to require the<br />

use of a CAC, PIV compliant hardware token, or Alternate<br />

Logon Token (ALT) for authentication.<br />

<strong>STIG</strong> ID: RHEL-06-000349 Rule ID: SV-50396r1_rule Vuln<br />

ID: V-38595<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

Smart card login provides two-factor authentication<br />

stronger than that provided by a username/password<br />

combination. Smart cards leverage a PKI (public key<br />

infrastructure) in order to provide and verify<br />

credentials.<br />

Documentable: No<br />

Check Content:<br />

Interview the SA to determine if all accounts not exempted<br />

by policy are using CAC authentication. For DoD systems,<br />

the following systems and accounts are exempt from using<br />

smart card (CAC) authentication:<br />

SIPRNET systems<br />

Standalone systems<br />

Application accounts<br />

Temporary employee accounts, such as students or interns,<br />

who cannot easily receive a CAC or PIV<br />

Operational tactical locations that are not collocated<br />

with RAPIDS workstations to issue CAC or ALT<br />

Test systems, such as those with an Interim Approval to<br />

Test (IATT) and use a separate VPN, firewall, or security<br />

measure preventing access to network and system<br />

components from outside the protection boundary<br />

documented in the IATT.<br />

UNCLASSIFIED


UNCLASSIFIED<br />

If non-exempt accounts are not using CAC authentication,<br />

this is a finding.<br />

Fix Text:<br />

To enable smart card authentication, consult the<br />

documentation at:<br />

https://docs.redhat.com/docs/en-US/Red_Hat_Enterprise<br />

_Linux/6/html/Managing_Smart_Cards/enabling-smart-car<br />

d-login.html<br />

CCI: CCI-000765<br />

NIST SP 800-53A :: IA-2 (1).1<br />

NIST SP 800-53 :: IA-2 (1)<br />

Rule Title: The system must require administrator<br />

action to unlock an account locked by excessive failed<br />

login attempts.<br />

<strong>STIG</strong> ID: RHEL-06-000356 Rule ID: SV-50393r1_rule Vuln<br />

ID: V-38592<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

Locking out user accounts after a number of incorrect<br />

attempts prevents direct password guessing attacks.<br />

Ensuring that an administrator is involved in unlocking<br />

locked accounts draws appropriate attention to such<br />

situations.<br />

Documentable: No<br />

Check Content:<br />

To ensure the failed password attempt policy is<br />

configured correctly, run the following command:<br />

# grep pam_faillock /etc/pam.d/system-auth-ac<br />

UNCLASSIFIED


UNCLASSIFIED<br />

The output should show<br />

"unlock_time="; the largest<br />

acceptable value is 604800 seconds (one week).<br />

If that is not the case, this is a finding.<br />

Fix Text:<br />

To configure the system to lock out accounts after a<br />

number of incorrect login attempts and require an<br />

administrator to unlock the account using<br />

"pam_faillock.so":<br />

Add the following lines immediately below the<br />

"pam_unix.so" statement in the AUTH section of<br />

"/etc/pam.d/system-auth-ac":<br />

auth [default=die] pam_faillock.so authfail deny=3<br />

unlock_time=604800 fail_interval=900<br />

auth required pam_faillock.so authsucc deny=3<br />

unlock_time=604800 fail_interval=900<br />

Note that any updates made to<br />

"/etc/pam.d/system-auth-ac" will be overwritten by the<br />

"authconfig" program. The "authconfig" program should<br />

not be used.<br />

CCI: CCI-000047<br />

NIST SP 800-53 :: AC-7 b<br />

NIST SP 800-53A :: AC-7.1 (iv)<br />

Rule Title: The system must disable accounts after<br />

excessive login failures within a 15-minute interval.<br />

<strong>STIG</strong> ID: RHEL-06-000357 Rule ID: SV-50302r1_rule Vuln<br />

ID: V-38501<br />

Severity: CAT II Class: Unclass<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Discussion:<br />

Locking out user accounts after a number of incorrect<br />

attempts within a specific period of time prevents direct<br />

password guessing attacks.<br />

Documentable: No<br />

Check Content:<br />

To ensure the failed password attempt policy is<br />

configured correctly, run the following command:<br />

# grep pam_faillock /etc/pam.d/system-auth-ac<br />

The output should show<br />

"fail_interval=" where<br />

"interval-in-seconds" is 900 (15 minutes) or greater. If<br />

the "fail_interval" parameter is not set, the default<br />

setting of 900 seconds is acceptable.<br />

If that is not the case, this is a finding.<br />

Fix Text:<br />

To configure the system to lock out accounts after a<br />

number of incorrect login attempts within a 15-minute<br />

interval using "pam_faillock.so":<br />

Add the following lines immediately below the<br />

"pam_env.so" statement in the AUTH section of<br />

"/etc/pam.d/system-auth-ac":<br />

auth [default=die] pam_faillock.so authfail deny=3<br />

unlock_time=604800 fail_interval=900<br />

auth required pam_faillock.so authsucc deny=3<br />

unlock_time=604800 fail_interval=900<br />

Note that any updates made to<br />

"/etc/pam.d/system-auth-ac" will be overwritten by the<br />

"authconfig" program. The "authconfig" program should<br />

UNCLASSIFIED


UNCLASSIFIED<br />

not be used.<br />

CCI: CCI-001452<br />

NIST SP 800-53A :: AC-7.1 (ii)<br />

NIST SP 800-53 :: AC-7 a<br />

Rule Title: Audit log files must have mode 0640 or less<br />

permissive.<br />

<strong>STIG</strong> ID: RHEL-06-000383 Rule ID: SV-50299r1_rule Vuln<br />

ID: V-38498<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

If users can write to audit logs, audit trails can be<br />

modified or destroyed.<br />

Documentable: No<br />

Check Content:<br />

Run the following command to check the mode of the system<br />

audit logs:<br />

grep "^log_file" /etc/audit/auditd.conf|sed<br />

s/^[^\/]*//|xargs stat -c %a:%n<br />

Audit logs must be mode 0640 or less permissive.<br />

If any are more permissive, this is a finding.<br />

Fix Text:<br />

Change the mode of the audit log files with the following<br />

command:<br />

# chmod 0640 [audit_file]<br />

CCI: CCI-000163<br />

NIST SP 800-53A :: AU-9.1<br />

NIST SP 800-53 :: AU-9<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Rule Title: Audit log files must be owned by root.<br />

<strong>STIG</strong> ID: RHEL-06-000384 Rule ID: SV-50296r1_rule Vuln<br />

ID: V-38495<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

If non-privileged users can write to audit logs, audit<br />

trails can be modified or destroyed.<br />

Documentable: No<br />

Check Content:<br />

Run the following command to check the owner of the system<br />

audit logs:<br />

grep "^log_file" /etc/audit/auditd.conf|sed<br />

s/^[^\/]*//|xargs stat -c %U:%n<br />

Audit logs must be owned by root.<br />

If they are not, this is a finding.<br />

Fix Text:<br />

Change the owner of the audit log files with the following<br />

command:<br />

# chown root [audit_file]<br />

CCI: CCI-000162<br />

NIST SP 800-53A :: AU-9.1<br />

NIST SP 800-53 :: AU-9<br />

Rule Title: Audit log directories must have mode 0755<br />

or less permissive.<br />

<strong>STIG</strong> ID: RHEL-06-000385 Rule ID: SV-50294r1_rule Vuln<br />

ID: V-38493<br />

Severity: CAT II Class: Unclass<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Discussion:<br />

If users can delete audit logs, audit trails can be<br />

modified or destroyed.<br />

Documentable: No<br />

Check Content:<br />

Run the following command to check the mode of the system<br />

audit directories:<br />

grep "^log_file" /etc/audit/auditd.conf|sed<br />

's/^[^/]*//; s/[^/]*$//'|xargs stat -c %a:%n<br />

Audit directories must be mode 0755 or less permissive.<br />

If any are more permissive, this is a finding.<br />

Fix Text:<br />

Change the mode of the audit log directories with the<br />

following command:<br />

# chmod go-w [audit_directory]<br />

CCI: CCI-000164<br />

NIST SP 800-53A :: AU-9.1<br />

NIST SP 800-53 :: AU-9<br />

Rule Title: The operating system must enforce<br />

requirements for the connection of mobile devices to<br />

operating systems.<br />

<strong>STIG</strong> ID: RHEL-06-000503 Rule ID: SV-50291r1_rule Vuln<br />

ID: V-38490<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

USB storage devices such as thumb drives can be used to<br />

introduce unauthorized software and other<br />

UNCLASSIFIED


UNCLASSIFIED<br />

vulnerabilities. Support for these devices should be<br />

disabled and the devices themselves should be tightly<br />

controlled.<br />

Documentable: No<br />

Check Content:<br />

If the system is configured to prevent the loading of the<br />

"usb-storage" kernel module, it will contain lines inside<br />

any file in "/etc/modprobe.d" or the<br />

deprecated"/etc/modprobe.conf". These lines instruct<br />

the module loading system to run another program (such<br />

as "/bin/true") upon a module "install" event. Run the<br />

following command to search for such lines in all files<br />

in "/etc/modprobe.d" and the deprecated<br />

"/etc/modprobe.conf":<br />

$ grep -r usb-storage /etc/modprobe.conf /etc/modprobe.d<br />

If no line is returned, this is a finding.<br />

Fix Text:<br />

To prevent USB storage devices from being used, configure<br />

the kernel module loading system to prevent automatic<br />

loading of the USB storage driver. To configure the system<br />

to prevent the "usb-storage" kernel module from being<br />

loaded, add the following line to a file in the directory<br />

"/etc/modprobe.d":<br />

install usb-storage /bin/true<br />

This will prevent the "modprobe" program from loading the<br />

"usb-storage" module, but will not prevent an<br />

administrator (or another program) from using the<br />

"insmod" program to load the module manually.<br />

Rule Title: The operating system must conduct backups<br />

of user-level information contained in the operating<br />

UNCLASSIFIED


UNCLASSIFIED<br />

system per organization defined frequency to conduct<br />

backups consistent with recovery time and recovery point<br />

objectives.<br />

<strong>STIG</strong> ID: RHEL-06-000504 Rule ID: SV-50289r1_rule Vuln<br />

ID: V-38488<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

Operating system backup is a critical step in maintaining<br />

data assurance and availability. User-level information<br />

is data generated by information system and/or<br />

application users. Backups shall be consistent with<br />

organizational recovery time and recovery point<br />

objectives.<br />

Documentable: No<br />

Check Content:<br />

Ask an administrator if a process exists to back up user<br />

data from the system.<br />

If such a process does not exist, this is a finding.<br />

Fix Text:<br />

Procedures to back up user data from the system must be<br />

established and executed. The Red Hat operating system<br />

provides utilities for automating such a process.<br />

Commercial and open-source products are also available.<br />

Implement a process whereby user data is backed up from<br />

the system in accordance with local policies.<br />

CCI: CCI-000535<br />

NIST SP 800-53 :: CP-9 (a)<br />

NIST SP 800-53A :: CP-9.1 (iv)<br />

Rule Title: The operating system must conduct backups<br />

of system-level information contained in the information<br />

UNCLASSIFIED


UNCLASSIFIED<br />

system per organization defined frequency to conduct<br />

backups that are consistent with recovery time and<br />

recovery point objectives.<br />

<strong>STIG</strong> ID: RHEL-06-000505 Rule ID: SV-50287r1_rule Vuln<br />

ID: V-38486<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

Operating system backup is a critical step in maintaining<br />

data assurance and availability. System-level<br />

information includes system-state information,<br />

operating system and application software, and licenses.<br />

Backups must be consistent with organizational recovery<br />

time and recovery point objectives.<br />

Documentable: No<br />

Check Content:<br />

Ask an administrator if a process exists to back up OS<br />

data from the system, including configuration data.<br />

If such a process does not exist, this is a finding.<br />

Fix Text:<br />

Procedures to back up OS data from the system must be<br />

established and executed. The Red Hat operating system<br />

provides utilities for automating such a process.<br />

Commercial and open-source products are also available.<br />

Implement a process whereby OS data is backed up from the<br />

system in accordance with local policies.<br />

CCI: CCI-000537<br />

NIST SP 800-53 :: CP-9 (b)<br />

NIST SP 800-53A :: CP-9.1 (v)<br />

Rule Title: The operating system, upon successful<br />

logon, must display to the user the date and time of the<br />

UNCLASSIFIED


UNCLASSIFIED<br />

last logon or access via a local console or tty.<br />

<strong>STIG</strong> ID: RHEL-06-000506 Rule ID: SV-50286r1_rule Vuln<br />

ID: V-38485<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

Users need to be aware of activity that occurs regarding<br />

their accounts. Providing users with information<br />

regarding the date and time of their last successful login<br />

allows the user to determine if any unauthorized activity<br />

has occurred and gives them an opportunity to notify<br />

administrators.<br />

At console or tty logon, a user must be presented with<br />

the last successful login date and time. The "hushlogin"<br />

file determines whether this occurs.<br />

Documentable: No<br />

Check Content:<br />

Verify there are no "hushlogin" files active on the<br />

system:<br />

# ls -l /etc/hushlogins<br />

For each home directory stored in "/etc/passwd":<br />

# ls ~/.hushlogin<br />

If there are any "hushlogin" files on the system, this<br />

is a finding.<br />

Fix Text:<br />

Remove any "hushlogin" files from the system:<br />

# rm /etc/hushlogins<br />

# rm ~/.hushlogin<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Rule Title: The operating system, upon successful<br />

logon, must display to the user the date and time of the<br />

last logon or access via ssh.<br />

<strong>STIG</strong> ID: RHEL-06-000507 Rule ID: SV-50285r1_rule Vuln<br />

ID: V-38484<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

Users need to be aware of activity that occurs regarding<br />

their account. Providing users with information<br />

regarding the date and time of their last successful login<br />

allows the user to determine if any unauthorized activity<br />

has occurred and gives them an opportunity to notify<br />

administrators.<br />

At ssh login, a user must be presented with the last<br />

successful login date and time.<br />

Documentable: No<br />

Check Content:<br />

Verify the value associated with the "PrintLastLog"<br />

keyword in /etc/ssh/sshd_config:<br />

# grep -i PrintLastLog /etc/ssh/sshd_config<br />

If the value is not set to "yes", this is a finding. If<br />

the "PrintLastLog" keyword is not present, this is not<br />

a finding.<br />

Fix Text:<br />

Update the "PrintLastLog" keyword to "yes" in<br />

/etc/ssh/sshd_config:<br />

PrintLastLog yes<br />

While it is acceptable to remove the keyword entirely<br />

since the default action for the SSH daemon is to print<br />

the last login date and time, it is preferred to have the<br />

value explicitly documented.<br />

UNCLASSIFIED


UNCLASSIFIED<br />

CCI: CCI-000052<br />

NIST SP 800-53 :: AC-9<br />

NIST SP 800-53A :: AC-9.1<br />

Rule Title: The system must allow locking of graphical<br />

desktop sessions.<br />

<strong>STIG</strong> ID: RHEL-06-000508 Rule ID: SV-50274r1_rule Vuln<br />

ID: V-38474<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

The ability to lock graphical desktop sessions manually<br />

allows users to easily secure their accounts should they<br />

need to depart from their workstations temporarily.<br />

Documentable: No<br />

Check Content:<br />

Verify the keybindings for the Gnome screensaver:<br />

# gconftool-2 --direct --config-source<br />

xml:readwrite:/etc/gconf/gconf.xml.mandatory --get<br />

/apps/gnome_settings_daemon/keybindings/screensaver<br />

If no output is visible, this is a finding.<br />

Fix Text:<br />

Run the following command to set the Gnome desktop<br />

keybinding for locking the screen:<br />

# gconftool-2<br />

--direct \<br />

--config-source<br />

xml:readwrite:/etc/gconf/gconf.xml.mandatory \<br />

--type string \<br />

--set<br />

/apps/gnome_settings_daemon/keybindings/screensaver<br />

UNCLASSIFIED


UNCLASSIFIED<br />

"l"<br />

Another keyboard sequence may be substituted for<br />

"l", which is the default for the Gnome<br />

desktop.<br />

CCI: CCI-000058<br />

NIST SP 800-53 :: AC-11 a<br />

NIST SP 800-53A :: AC-11<br />

Rule Title: The system must forward audit records to the<br />

syslog service.<br />

<strong>STIG</strong> ID: RHEL-06-000509 Rule ID: SV-50271r1_rule Vuln<br />

ID: V-38471<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

The auditd service does not include the ability to send<br />

audit records to a centralized server for management<br />

directly. It does, however, include an audit event<br />

multiplexor plugin (audispd) to pass audit records to the<br />

local syslog server.<br />

Documentable: No<br />

Check Content:<br />

Verify the audispd plugin is active:<br />

# grep active /etc/audisp/plugins.d/syslog.conf<br />

If the "active" setting is missing or set to "no", this<br />

is a finding.<br />

Fix Text:<br />

Set the "active" line in<br />

"/etc/audisp/plugins.d/syslog.conf" to "yes". Restart<br />

the auditd process.<br />

UNCLASSIFIED


UNCLASSIFIED<br />

# service auditd restart<br />

CCI: CCI-000136<br />

NIST SP 800-53A :: AU-3 (2).1 (ii)<br />

NIST SP 800-53 :: AU-3 (2)<br />

Rule Title: The audit system must take appropriate<br />

action when the audit storage volume is full.<br />

<strong>STIG</strong> ID: RHEL-06-000510 Rule ID: SV-50268r1_rule Vuln<br />

ID: V-38468<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

Taking appropriate action in case of a filled audit<br />

storage volume will minimize the possibility of losing<br />

audit records.<br />

Documentable: No<br />

Check Content:<br />

Inspect "/etc/audit/auditd.conf" and locate the<br />

following line to determine if the system is configured<br />

to take appropriate action when the audit storage volume<br />

is full:<br />

# grep disk_full_action /etc/audit/auditd.conf<br />

disk_full_action = [ACTION]<br />

If the system is configured to "suspend" when the volume<br />

is full or "ignore" that it is full, this is a finding.<br />

Fix Text:<br />

The "auditd" service can be configured to take an action<br />

when disk space starts to run low. Edit the file<br />

"/etc/audit/auditd.conf". Modify the following line,<br />

substituting [ACTION] appropriately:<br />

UNCLASSIFIED


UNCLASSIFIED<br />

disk_full_action = [ACTION]<br />

Possible values for [ACTION] are described in the<br />

"auditd.conf" man page. These include:<br />

"ignore"<br />

"syslog"<br />

"exec"<br />

"suspend"<br />

"single"<br />

"halt"<br />

Set this to "syslog", "exec", "single", or "halt".<br />

CCI: CCI-000140<br />

NIST SP 800-53A :: AU-5.1 (iv)<br />

NIST SP 800-53 :: AU-5 b<br />

Rule Title: The audit system must take appropriate<br />

action when there are disk errors on the audit storage<br />

volume.<br />

<strong>STIG</strong> ID: RHEL-06-000511 Rule ID: SV-50264r1_rule Vuln<br />

ID: V-38464<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

Taking appropriate action in case of disk errors will<br />

minimize the possibility of losing audit records.<br />

Documentable: No<br />

Check Content:<br />

Inspect "/etc/audit/auditd.conf" and locate the<br />

following line to determine if the system is configured<br />

to take appropriate action when disk errors occur:<br />

# grep disk_error_action /etc/audit/auditd.conf<br />

UNCLASSIFIED


UNCLASSIFIED<br />

disk_error_action = [ACTION]<br />

If the system is configured to "suspend" when disk errors<br />

occur or "ignore" them, this is a finding.<br />

Fix Text:<br />

Edit the file "/etc/audit/auditd.conf". Modify the<br />

following line, substituting [ACTION] appropriately:<br />

disk_error_action = [ACTION]<br />

Possible values for [ACTION] are described in the<br />

"auditd.conf" man page. These include:<br />

"ignore"<br />

"syslog"<br />

"exec"<br />

"suspend"<br />

"single"<br />

"halt"<br />

Set this to "syslog", "exec", "single", or "halt".<br />

CCI: CCI-000140<br />

NIST SP 800-53A :: AU-5.1 (iv)<br />

NIST SP 800-53 :: AU-5 b<br />

Rule Title: The RPM package management tool must<br />

cryptographically verify the authenticity of all<br />

software packages during installation.<br />

<strong>STIG</strong> ID: RHEL-06-000514 Rule ID: SV-50262r1_rule Vuln<br />

ID: V-38462<br />

Severity: CAT I Class: Unclass<br />

Discussion:<br />

Ensuring all packages' cryptographic signatures are<br />

UNCLASSIFIED


UNCLASSIFIED<br />

valid prior to installation ensures the provenance of the<br />

software and protects against malicious tampering.<br />

Documentable: No<br />

Check Content:<br />

Verify RPM signature validation is not disabled:<br />

# grep nosignature /etc/rpmrc /usr/lib/rpm/rpmrc<br />

/usr/lib/rpm/redhat/rpmrc ~root/.rpmrc<br />

If any configuration is found, this is a finding.<br />

Fix Text:<br />

Edit the RPM configuration files containing the<br />

"nosignature" option and remove the option.<br />

CCI: CCI-000352<br />

NIST SP 800-53A :: CM-5 (3).1 (ii)<br />

NIST SP 800-53 :: CM-5 (3)<br />

Rule Title: The NFS server must not have the all_squash<br />

option enabled.<br />

<strong>STIG</strong> ID: RHEL-06-000515 Rule ID: SV-50260r1_rule Vuln<br />

ID: V-38460<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

The "all_squash" option maps all client requests to a<br />

single anonymous uid/gid on the NFS server, negating the<br />

ability to track file access by user ID.<br />

Documentable: No<br />

Check Content:<br />

If the NFS server is read-only, in support of unrestricted<br />

access to organizational content, this is not applicable.<br />

The related "root_squash" option provides protection<br />

against remote administrator-level access to NFS server<br />

UNCLASSIFIED


UNCLASSIFIED<br />

content. Its use is not a finding.<br />

To verify the "all_squash" option has been disabled, run<br />

the following command:<br />

# grep all_squash /etc/exports<br />

If there is output, this is a finding.<br />

Fix Text:<br />

Remove any instances of the "all_squash" option from the<br />

file "/etc/exports". Restart the NFS daemon for the<br />

changes to take effect.<br />

# service nfs restart<br />

CCI: CCI-000764<br />

NIST SP 800-53A :: IA-2.1<br />

NIST SP 800-53 :: IA-2<br />

Rule Title: The system package management tool must<br />

verify ownership on all files and directories associated<br />

with packages.<br />

<strong>STIG</strong> ID: RHEL-06-000516 Rule ID: SV-50254r1_rule Vuln<br />

ID: V-38454<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

Ownership of system binaries and configuration files that<br />

is incorrect could allow an unauthorized user to gain<br />

privileges that they should not have. The ownership set<br />

by the vendor should be maintained. Any deviations from<br />

this baseline should be investigated.<br />

Documentable: No<br />

Check Content:<br />

UNCLASSIFIED


UNCLASSIFIED<br />

The following command will list which files on the system<br />

have ownership different from what is expected by the RPM<br />

database:<br />

# rpm -Va | grep '^.....U'<br />

If there is output, this is a finding.<br />

Fix Text:<br />

The RPM package management system can restore ownership<br />

of package files and directories. The following command<br />

will update files and directories with ownership<br />

different from what is expected by the RPM database:<br />

# rpm -qf [file or directory name]<br />

# rpm --setugids [package]<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: The system package management tool must<br />

verify group-ownership on all files and directories<br />

associated with packages.<br />

<strong>STIG</strong> ID: RHEL-06-000517 Rule ID: SV-50253r1_rule Vuln<br />

ID: V-38453<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

Group-ownership of system binaries and configuration<br />

files that is incorrect could allow an unauthorized user<br />

to gain privileges that they should not have. The<br />

group-ownership set by the vendor should be maintained.<br />

Any deviations from this baseline should be investigated.<br />

Documentable: No<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Check Content:<br />

The following command will list which files on the system<br />

have group-ownership different from what is expected by<br />

the RPM database:<br />

# rpm -Va | grep '^......G'<br />

If there is output, this is a finding.<br />

Fix Text:<br />

The RPM package management system can restore<br />

group-ownership of the package files and directories. The<br />

following command will update files and directories with<br />

group-ownership different from what is expected by the<br />

RPM database:<br />

# rpm -qf [file or directory name]<br />

# rpm --setugids [package]<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: The system package management tool must<br />

verify permissions on all files and directories<br />

associated with packages.<br />

<strong>STIG</strong> ID: RHEL-06-000518 Rule ID: SV-50252r1_rule Vuln<br />

ID: V-38452<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

Permissions on system binaries and configuration files<br />

that are too generous could allow an unauthorized user<br />

to gain privileges that they should not have. The<br />

permissions set by the vendor should be maintained. Any<br />

deviations from this baseline should be investigated.<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Documentable: No<br />

Check Content:<br />

The following command will list which files and<br />

directories on the system have permissions different from<br />

what is expected by the RPM database:<br />

# rpm -Va | grep '^.M'<br />

If there is any output, for each file or directory found,<br />

find the associated RPM package and compare the<br />

RPM-expected permissions with the actual permissions on<br />

the file or directory:<br />

# rpm -qf [file or directory name]<br />

# rpm -q --queryformat "[%{FILENAMES}<br />

%{FILEMODES:perms}\n]" [package] | grep [filename]<br />

# ls -lL [filename]<br />

If the existing permissions are more permissive than<br />

those expected by RPM, this is a finding.<br />

Fix Text:<br />

The RPM package management system can restore file access<br />

permissions of package files and directories. The<br />

following command will update permissions on files and<br />

directories with permissions different from what is<br />

expected by the RPM database:<br />

# rpm --setperms [package]<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: The system package management tool must<br />

verify contents of all files associated with packages.<br />

<strong>STIG</strong> ID: RHEL-06-000519 Rule ID: SV-50247r1_rule Vuln<br />

ID: V-38447<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

The hash on important files like system executables<br />

should match the information given by the RPM database.<br />

Executables with erroneous hashes could be a sign of<br />

nefarious activity on the system.<br />

Documentable: No<br />

Check Content:<br />

The following command will list which files on the system<br />

have file hashes different from what is expected by the<br />

RPM database.<br />

# rpm -Va | grep '$1 ~ /..5/ && $2 != "c"'<br />

If there is output, this is a finding.<br />

Fix Text:<br />

The RPM package management system can check the hashes<br />

of installed software packages, including many that are<br />

important to system security. Run the following command<br />

to list which files on the system have hashes that differ<br />

from what is expected by the RPM database:<br />

# rpm -Va | grep '^..5'<br />

A "c" in the second column indicates that a file is a<br />

configuration file, which may appropriately be expected<br />

to change. If the file that has changed was not expected<br />

to then refresh from distribution media or online<br />

repositories.<br />

rpm -Uvh [affected_package]<br />

OR<br />

yum reinstall [affected_package]<br />

UNCLASSIFIED


UNCLASSIFIED<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: The mail system must forward all mail for<br />

root to one or more system administrators.<br />

<strong>STIG</strong> ID: RHEL-06-000521 Rule ID: SV-50246r1_rule Vuln<br />

ID: V-38446<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

A number of system services utilize email messages sent<br />

to the root user to notify system administrators of active<br />

or impending issues. These messages must be forwarded<br />

to at least one monitored email address.<br />

Documentable: No<br />

Check Content:<br />

Find the list of alias maps used by the Postfix mail<br />

server:<br />

# postconf alias_maps<br />

Query the Postfix alias maps for an alias for "root":<br />

# postmap -q root <br />

If there are no aliases configured for root that forward<br />

to a monitored email address, this is a finding.<br />

Fix Text:<br />

Set up an alias for root that forwards to a monitored email<br />

address:<br />

# echo "root: @mail.mil" >><br />

/etc/aliases<br />

UNCLASSIFIED


UNCLASSIFIED<br />

# newaliases<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

Rule Title: Audit log files must be group-owned by root.<br />

<strong>STIG</strong> ID: RHEL-06-000522 Rule ID: SV-50245r1_rule Vuln<br />

ID: V-38445<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

If non-privileged users can write to audit logs, audit<br />

trails can be modified or destroyed.<br />

Documentable: No<br />

Check Content:<br />

Run the following command to check the group owner of the<br />

system audit logs:<br />

grep "^log_file" /etc/audit/auditd.conf|sed<br />

s/^[^\/]*//|xargs stat -c %G:%n<br />

Audit logs must be group-owned by root.<br />

If they are not, this is a finding.<br />

Fix Text:<br />

Change the group owner of the audit log files with the<br />

following command:<br />

# chgrp root [audit_file]<br />

Rule Title: The systems local IPv6 firewall must<br />

implement a deny-all, allow-by-exception policy for<br />

inbound packets.<br />

UNCLASSIFIED


UNCLASSIFIED<br />

<strong>STIG</strong> ID: RHEL-06-000523 Rule ID: SV-50244r1_rule Vuln<br />

ID: V-38444<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

In "ip6tables" the default policy is applied only after<br />

all the applicable rules in the table are examined for<br />

a match. Setting the default policy to "DROP" implements<br />

proper design for a firewall, i.e., any packets which are<br />

not explicitly permitted should not be accepted.<br />

Documentable: No<br />

Check Content:<br />

Inspect the file "/etc/sysconfig/ip6tables" to determine<br />

the default policy for the INPUT chain. It should be set<br />

to DROP.<br />

# grep ":INPUT" /etc/sysconfig/ip6tables<br />

If the default policy for the INPUT chain is not set to<br />

DROP, this is a finding.<br />

Fix Text:<br />

To set the default policy to DROP (instead of ACCEPT) for<br />

the built-in INPUT chain which processes incoming<br />

packets, add or correct the following line in<br />

"/etc/sysconfig/ip6tables":<br />

:INPUT DROP [0:0]<br />

CCI: CCI-000066<br />

NIST SP 800-53A :: AC-17.1 (v)<br />

NIST SP 800-53 :: AC-17 e<br />

Rule Title: The system must provide automated support<br />

for account management functions.<br />

<strong>STIG</strong> ID: RHEL-06-000524 Rule ID: SV-50239r1_rule Vuln<br />

UNCLASSIFIED


UNCLASSIFIED<br />

ID: V-38439<br />

Severity: CAT II Class: Unclass<br />

Discussion:<br />

A comprehensive account management process that includes<br />

automation helps to ensure the accounts designated as<br />

requiring attention are consistently and promptly<br />

addressed. Enterprise environments make user account<br />

management challenging and complex. A user management<br />

process requiring administrators to manually address<br />

account management functions adds risk of potential<br />

oversight.<br />

Documentable: No<br />

Check Content:<br />

Interview the SA to determine if there is an automated<br />

system for managing user accounts, preferably integrated<br />

with an existing enterprise user management system.<br />

If there is not, this is a finding.<br />

Fix Text:<br />

Implement an automated system for managing user accounts<br />

that minimizes the risk of errors, either intentional or<br />

deliberate. If possible, this system should integrate<br />

with an existing enterprise user management system, such<br />

as, one based Active Directory or Kerberos.<br />

CCI: CCI-000015<br />

NIST SP 800-53 :: AC-2 (1)<br />

NIST SP 800-53A :: AC-2 (1).1<br />

Rule Title: Auditing must be enabled at boot by setting<br />

a kernel parameter.<br />

<strong>STIG</strong> ID: RHEL-06-000525 Rule ID: SV-50238r1_rule Vuln<br />

ID: V-38438<br />

Severity: CAT III Class: Unclass<br />

UNCLASSIFIED


UNCLASSIFIED<br />

Discussion:<br />

Each process on the system carries an "auditable" flag<br />

which indicates whether its activities can be audited.<br />

Although "auditd" takes care of enabling this for all<br />

processes which launch after it does, adding the kernel<br />

argument ensures it is set for every process during boot.<br />

Documentable: No<br />

Check Content:<br />

Inspect the kernel boot arguments (which follow the word<br />

"kernel") in "/etc/grub.conf". If they include<br />

"audit=1", then auditing is enabled at boot time.<br />

If auditing is not enabled at boot time, this is a finding.<br />

Fix Text:<br />

To ensure all processes can be audited, even those which<br />

start prior to the audit daemon, add the argument<br />

"audit=1" to the kernel line in "/etc/grub.conf", in the<br />

manner below:<br />

kernel /vmlinuz-version ro vga=ext<br />

root=/dev/VolGroup00/LogVol00 rhgb quiet audit=1<br />

CCI: CCI-000169<br />

NIST SP 800-53A :: AU-12.1 (ii)<br />

NIST SP 800-53 :: AU-12 a<br />

Rule Title: Automated file system mounting tools must<br />

not be enabled unless needed.<br />

<strong>STIG</strong> ID: RHEL-06-000526 Rule ID: SV-50237r1_rule Vuln<br />

ID: V-38437<br />

Severity: CAT III Class: Unclass<br />

Discussion:<br />

All filesystems that are required for the successful<br />

UNCLASSIFIED


UNCLASSIFIED<br />

operation of the system should be explicitly listed in<br />

"/etc/fstab" by an administrator. New filesystems should<br />

not be arbitrarily introduced via the automounter.<br />

The "autofs" daemon mounts and unmounts filesystems, such<br />

as user home directories shared via NFS, on demand. In<br />

addition, autofs can be used to handle removable media,<br />

and the default configuration provides the cdrom device<br />

as "/misc/cd". However, this method of providing access<br />

to removable media is not common, so autofs can almost<br />

always be disabled if NFS is not in use. Even if NFS is<br />

required, it is almost always possible to configure<br />

filesystem mounts statically by editing "/etc/fstab"<br />

rather than relying on the automounter.<br />

Documentable: No<br />

Check Content:<br />

To verify the "autofs" service is disabled, run the<br />

following command:<br />

chkconfig --list autofs<br />

If properly configured, the output should be the<br />

following:<br />

autofs 0:off 1:off 2:off 3:off 4:off 5:off 6:off<br />

Verify the "autofs" service is not running:<br />

# service autofs status<br />

If the autofs service is enabled or running, this is a<br />

finding.<br />

Fix Text:<br />

If the "autofs" service is not needed to dynamically mount<br />

NFS filesystems or removable media, disable the service<br />

for all runlevels:<br />

UNCLASSIFIED


UNCLASSIFIED<br />

# chkconfig --level 0123456 autofs off<br />

Stop the service if it is already running:<br />

# service autofs stop<br />

CCI: CCI-000366<br />

NIST SP 800-53A :: CM-6.1 (iv)<br />

NIST SP 800-53 :: CM-6 b<br />

UNCLASSIFIED

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!