CCIs from Operating System Security Requirements Guide Mapped to DRAFT Guide to the Secure Configuration of Red Hat Enterprise Linux 6

SRG ID CCI ID SRG Title SRG Description Rules Mapped

SRG-OS-000001

CCI-000015

The operating system must provide automated support for account management functions.

A comprehensive account management process that includes automation helps to ensure the accounts designated as requiring attention are consistently and promptly addressed. Examples include, but are not limited to using automation to take action on multiple accounts designated as inactive, suspended or terminated, or by disabling accounts located in non-centralized account stores, such as, multiple servers. Enterprise environments make user account management challenging and complex. A user management process requiring administrators to manually address account management functions adds risk of potential oversight.

Set Account Expiration Following Inactivity

To specify the number of days after a password expires (which signifies inactivity) until an account is permanently disabled, add or correct the following lines in /etc/defaults/useradd, substituting NUM_DAYS appropriately:

INACTIVE=NUM_DAYS

A value of 35 is recommended. If a password is currently on the verge of expiration, then 35 days remain until the account is automatically disabled. However, if the password will not expire for another 60 days, then 95 days could elapse until the account would be automatically disabled. See the useradd man page for more information. Determining the inactivity timeout must be done with careful consideration of the length of a "normal" period of inactivity for users in the particular environment. Setting the timeout too low incurs support costs and also has the potential to impact availability of the system to legitimate users.

SRG-OS-000002

CCI-000016

The operating system must automatically terminate temporary accounts after an organization-defined time period for each type of account.

When temporary and emergency accounts are created, there is a risk the temporary account may remain in place and active after the need for the account no longer exists. To address this, in the event temporary accounts are required, accounts designated as temporary in nature must be automatically terminated after an organization-defined time period. Such a process and capability greatly reduces the risk of accounts being misused, hijacked, or data compromised.

Set Account Expiration Following Inactivity

INACTIVE=NUM_DAYS

SRG-OS-000003

CCI-000017

The operating system must automatically disable inactive accounts after an organization-defined time period.

Users are often the first line of defense within an application. Active users take notice of system and data conditions and are usually the first to notify systems administrators when they notice a system or application related anomaly pertaining to their own account. Inactive user accounts pose a risk to systems and applications. Owners of inactive accounts will not notice if unauthorized access to their user account has been obtained. There is a risk that inactive accounts can potentially obtain and maintain undetected access to an application. The operating system must track periods of user inactivity and disable the accounts after an organization-defined period of inactivity.

Set Account Expiration Following Inactivity

INACTIVE=NUM_DAYS

SRG-OS-000004

CCI-000018

The operating system must support the requirement to automatically audit on account creation.

Auditing of account creation is a method and best practice for mitigating the risk of an attacker creating a persistent method of re-establishing access. A comprehensive account management process will ensure an audit trail which documents the creation of accounts and if required notifies administrators. Such a process greatly reduces the risk of accounts being created outside the normal approval process and provides logging that can be used for forensic purposes. Additionally, the audit records of account creation can be compared to the known approved account creation list.

Record Events that Modify User/Group Information

Add the following to /etc/audit/audit.rules, in order to capture events that modify account changes:

# audit_account_changes
-w /etc/group -p wa -k audit_account_changes
-w /etc/passwd -p wa -k audit_account_changes
-w /etc/gshadow -p wa -k audit_account_changes
-w /etc/shadow -p wa -k audit_account_changes
-w /etc/security/opasswd -p wa -k audit_account_changes

SRG-OS-000005

CCI-000020

The operating system must dynamically manage user privileges and associated access authorizations.

While user identities remain relatively constant over time, user privileges may change more frequently based on the ongoing mission/business requirements and operational needs of the organization. The operating system needs to be able to dynamically manage user privileges and access authorization decisions.

Implementation of the Requirement is Unclear

It is unclear how to satisfy this requirement.

SRG-OS-000006

CCI-000021

The operating system must enforce dual authorization, based on organizational policies and procedures for organization-defined privileged commands.

Dual authorization mechanisms require two distinct approving authorities to approve the use of the command prior to it being invoked. An organization may determine certain commands or configuration changes require dual-authorization before being activated. The operating system must have the ability to enforce this dual authorization.

Guidance Does Not Meet this Requirement Due to Impracticality or Scope

The guidance does not meet this requirement. The requirement is impractical or out of scope.

SRG-OS-000007

CCI-000022

The operating system must enforce one or more organization-defined nondiscretionary access control policies over an organization-defined set of users and resources.

Access control policies (e.g., identity-based policies, role-based policies, attribute-based policies) and access enforcement mechanisms (e.g., access control lists, access control matrices, cryptography) are employed by organizations to control access between users (or processes acting on behalf of users) and objects (e.g., devices, files, records, processes, programs, domains) within the operating system.

Ensure SELinux State is Enforcing The SELinux state should be set to enforcing at system boot time. In the file /etc/selinux/config, add or correct the line SELINUX=enforcing to configure the system to boot into enforcing mode.

SRG-OS-000008

CCI-000024

The operating system must prevent access to organization-defined security-relevant information except during secure, non-operable system states.

Security-relevant information is any information within the information system potentially impacting the operation of security functions in a manner that could result in failure to enforce the system security policy or maintain isolation of code and data. Organizations may define specific security relevant information requiring protection. Filtering rules for routers and firewalls, cryptographic key management information, key configuration parameters for security services, and access control lists are examples of security-relevant information. Secure, non-operable system states are states in which the information system is not performing mission/business-related processing (e.g., the system is off-line for maintenance, troubleshooting, boot-up, shutdown). Access to these types of data is to be prevented unless the system is in a maintenance mode or has otherwise been brought off-line. The goal is to minimize the potential that a security configuration or data may be dynamically and perhaps surreptitiously overwritten or changed (without going through a formal system change process documenting the changes).

Guidance Does Not Meet this Requirement Due to Impracticality or Scope

The guidance does not meet this requirement. The requirement is impractical or out of scope.

Product Does Not Meet this Requirement Due to Impracticality or Scope

The product does not meet this requirement. The requirement is impractical or out of scope.

SRG-OS-000009

CCI-000025

The operating system must enforce information flow control using explicit security attributes on information, source, and destination objects as a basis for flow control decisions.

Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to the information. Examples of flow control restrictions include: keeping export controlled information from being transmitted in the clear to the Internet; and blocking outside traffic claiming to be from within the organization and not passing any web requests to the Internet that are not from the internal web proxy. Information flow control policies and enforcement mechanisms are commonly employed by organizations to control the flow of information between designated sources and destinations (e.g., networks, individuals, devices) within information systems and between interconnected systems. Flow control is based on the characteristics of the information and/or the information path. Information flow enforcement mechanisms compare security attributes on all information (data content and data structure), source and destination objects, and respond appropriately (e.g., block, quarantine, alert administrator) when the mechanisms encounter information flows not explicitly allowed by the information flow policy. Information flow enforcement using explicit security attributes can be used, for example, to control the release of certain types of information.

Guidance Does Not Meet this Requirement Due to Impracticality or Scope

The guidance does not meet this requirement. The requirement is impractical or out of scope.

SRG-OS-000010

CCI-000026

The operating system must enforce information flow control using protected processing domains (e.g., domain type-enforcement) as a basis for flow control decisions.

Protected processing domains can be used to separate different data types. The operating system must enforce information flow control to ensure information does not pass into domains that are not authorized to process it.

Enable SELinux

Edit the file /etc/selinux/config. Add or correct the following lines:

SELINUX=enforcing
SELINUXTYPE=targeted

Edit the file /etc/grub.conf. Ensure that the following arguments DO NOT appear on any kernel command line in the file:

selinux=0
enforcing=0

The directive SELINUX=enforcing enables SELinux at boot time. If SELinux is suspected of involvement with boot-time problems (unlikely), it is possible to boot into the warning-only mode SELINUX=permissive for debugging purposes. Make certain to change the mode back to enforcing after debugging, set the filesystems to be relabelled for consistency using the command

touch
/.autorelabel

, and reboot.

However, the RHEL6 default SELinux configuration should be sufficiently reasonable that most systems will boot without serious problems. Some applications that require deep or unusual system privileges, such as virtual machine software, may not be compatible with SELinux in its default configuration. However, this should be uncommon, and SELinux's application support continues to improve. In other cases, SELinux may reveal unusual or insecure program behavior by design.

The directive SELINUXTYPE=targeted configures SELinux to use the default targeted policy.

The SELinux boot mode specified in /etc/selinux/config can be overridden by command-line arguments passed to the kernel. It is necessary to check grub.conf to ensure that this has not been done and to protect the boot process.

SRG-OS-000011

CCI-000027

The operating system must enforce dynamic information flow control based on policy that must allow or disallow information flows based upon changing conditions or operational considerations.

Verify iptables Enabled

The iptables service can be enabled with the following command:

# chkconfig iptables on

SRG-OS-000012

CCI-000028

The operating system must prevent encrypted data from bypassing content checking mechanisms.

Guidance Does Not Meet this Requirement Due to Impracticality or Scope

The guidance does not meet this requirement. The requirement is impractical or out of scope.

Product Does Not Meet this Requirement Due to Impracticality or Scope

The product does not meet this requirement. The requirement is impractical or out of scope.

SRG-OS-000013

CCI-000029

The operating system must enforce organization-defined limitations on the embedding of data types within other data types.

Embedding of data within other data is often used for the clandestine transfer of data. Embedding of data within other data can circumvent protections in place to protect information and systems.

Guidance Does Not Meet this Requirement Due to Impracticality or Scope

The guidance does not meet this requirement. The requirement is impractical or out of scope.

Product Does Not Meet this Requirement Due to Impracticality or Scope

The product does not meet this requirement. The requirement is impractical or out of scope.

SRG-OS-000014

CCI-000030

The operating system must enforce information flow control on metadata.

Guidance Does Not Meet this Requirement Due to Impracticality or Scope

The guidance does not meet this requirement. The requirement is impractical or out of scope.

Product Does Not Meet this Requirement Due to Impracticality or Scope

The product does not meet this requirement. The requirement is impractical or out of scope.

SRG-OS-000015

CCI-000031

The operating system must support organization-defined one-way flows using hardware mechanisms.

Implementation of the Requirement is Unclear

It is unclear how to satisfy this requirement.

SRG-OS-000016

CCI-000032

The operating system must enforce information flow control using organization-defined security policy filters as a basis for flow control decisions.

Product Does Not Meet this Requirement Due to Impracticality or Scope

The product does not meet this requirement. The requirement is impractical or out of scope.

SRG-OS-000017

CCI-000034

The operating system must provide the capability for a privileged administrator to enable/disable organization-defined security policy filters.

Product Meets this Requirement

Red Hat Enterprise Linux meets this requirement by design.

SRG-OS-000018

CCI-000035

The operating system must provide the capability for a privileged administrator to configure the organization-defined security policy filters to support different security policies.

Product Meets this Requirement

Red Hat Enterprise Linux meets this requirement by design.

SRG-OS-000019

CCI-000037

The operating system must implement separation of duties through assigned information system access authorizations.

Separation of duties is a prevalent Information Technology control implemented at different layers of the information system, including the operating system and in applications. It serves to eliminate or reduce the possibility that a single user may carry out a prohibited action. Separation of duties requires the person accountable for approving an action is not the same person who is tasked with implementing or carrying out the action. Additionally, the person or entity accountable for monitoring the activity must be separate as well. Examples of separation of duties include: (i) mission functions and distinct information system support functions are divided among different individuals/roles; (ii) different individuals perform operating system support functions (e.g., system management, systems programming, configuration management, quality assurance and testing, network security); (iii) security personnel who administer access control functions do not administer audit functions; and (iv) different administrator accounts for different roles.

Guidance Does Not Meet this Requirement Due to Impracticality or Scope

The guidance does not meet this requirement. The requirement is impractical or out of scope.

SRG-OS-000020

CCI-000040

The operating system must audit any use of privileged accounts, or roles, with access to organization-defined security functions or security-relevant information, when accessing other system functions.

This requirement is intended to limit exposure due to operating from within a privileged account or role. The inclusion of role is intended to address those situations where an access control policy such as Role Based Access Control (RBAC) is being implemented and where a change of role provides the same degree of assurance in the change of access authorizations for both the user and all processes acting on behalf of the user as would be provided by a change between a privileged and non-privileged account. To limit exposure and provide forensic history of activity when operating from within a privileged account or role, the operating system must support organizational requirements that users of information system accounts, or roles, with access to organization-defined list of security functions or security-relevant information, use non-privileged accounts, or roles, when accessing other (non-security) system functions.

Ensure auditd Collects Information on the Use of Privileged Commands

At a minimum the audit system should collect the execution of privileged commands for all users and root. To find the relevant setuid programs:

# find / -type f -perm -4000 -o -perm -2000 2>/dev/null

Then, for each setuid program on the system, add a line of the following form to /etc/audit/audit.rules, where SETUID_PROG_PATH is the full path to each setuid program in the list:

-a always,exit -F path=SETUID_PROG_PATH -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged

SRG-OS-000021

CCI-000044

The operating system must enforce the organization-defined limit of consecutive invalid access attempts by a user during the organization-defined time period.

Anytime an authentication method is exposed, allowing for the utilization of an operating system, there is a risk that attempts will be made to obtain unauthorized access. To defeat these attempts, organizations define the number of times a user account may consecutively fail a login attempt. The organization also defines the period of time in which these consecutive failed attempts may occur. By limiting the number of failed login attempts, the risk of unauthorized system access via user password guessing, otherwise known as brute forcing, is reduced. Limits are imposed by locking the account.

Set Deny For Failed Password Attempts

This requires further investigation.

SRG-OS-000022

CCI-000047

The operating system, when the maximum number of unsuccessful attempts is exceeded, must automatically lock the account for an organization-defined time period or must lock the account until released by an administrator IAW organizational policy.

Anytime an authentication method is exposed to allow for the utilization of an operating system, there is a risk that attempts will be made to obtain unauthorized access. To defeat these attempts, organizations define the number of times a user account may consecutively fail a login attempt. The organization also defines the period of time in which these consecutive failed attempts may occur. By limiting the number of failed login attempts, the risk of unauthorized system access via user password guessing, otherwise known as brute forcing, is reduced. Limits are imposed by locking the account.

Set Deny For Failed Password Attempts

This requires further investigation.

SRG-OS-000023

CCI-000048

The operating system must display the DoD approved system use notification message or banner before granting access to the system.

The operating system is required to display the DoD approved system use notification message or banner before granting access to the system. This ensures all the legal requirements are met as far as auditing and monitoring are concerned.

Modify the System Login Banner The contents of the file /etc/issue are displayed on the screen just above the login prompt for users logging directly into a terminal. Remote login programs such as SSH or FTP can be configured to display /etc/issue as well. Instructions for configuring these daemons are available later.

By default, the system will display the version of the OS, the kernel version, and the host name.

Edit /etc/issue. Replace the default text with a message compliant with the local site policy or a legal disclaimer.

Enable GUI Warning Banner

To enable displaying a login warning banner in the GNOME Display Manager's login screen, run the following command:

sudo -u gdm gconftool-2 \
  --type bool \
  --set /apps/gdm/simple-greeter/banner_message_enable true

To display a banner, this setting must be enabled and then banner text must also be set.

Set GUI Warning Banner Text

To set the text shown by the GNOME Display Manager in the login screen, run the following command:

sudo -u gdm gconftool-2 \
  --type string \
  --set /apps/gdm/simple-greeter/banner_message_text \
  "Text of the warning banner here"

When entering a warning banner that spans several lines, remember to begin and end the string with ". This command writes directly to the file /var/lib/gdm/.gconf/apps/gdm/simple-greeter/%gconf.xml, and this file can later be edited directly if necessary.

Enable SSH Warning Banner

To enable the warning banner and ensure it is consistent across the system, add or correct the following line in /etc/ssh/sshd_config:

Banner /etc/issue

Another section contains information on how to create an appropriate system-wide warning banner.

Create Warning Banners for All FTP Users

Edit the vsftpd configuration file, which resides at /etc/vsftpd/vsftpd.conf by default. Add or correct the following configuration options:

banner_file=/etc/issue

SRG-OS-000024

CCI-000050

The operating system must retain the notification message or banner on the screen until users take explicit actions to logon for further access.

To establish acceptance of system usage policy, a click-through banner at operating system logon is required. The banner must prevent further activity on the application unless and until the user executes a positive action to manifest agreement by clicking the indicated acceptance.

Enable GUI Warning Banner

To enable displaying a login warning banner in the GNOME Display Manager's login screen, run the following command:

sudo -u gdm gconftool-2 \
  --type bool \
  --set /apps/gdm/simple-greeter/banner_message_enable true

To display a banner, this setting must be enabled and then banner text must also be set.

SRG-OS-000025

CCI-000052

The operating system, upon successful logon, must display to the user the date and time of the last logon (access).

Users need to be aware of activity that occurs regarding their account. Providing users with information regarding the date and time of their last successful login allows the user to determine if any unauthorized activity has occurred and gives them an opportunity to notify administrators.

A New Policy/Manual Rule is Needed

A new Rule needs to be created in the scap-security-guide content.

SRG-OS-000026

CCI-000053

The operating system, upon successful logon/access, must display to the user the number of unsuccessful logon/access attempts since the last successful logon/access.

Users need to be aware of activity that occurs regarding their account. Providing users with information regarding the number of unsuccessful attempts that were made to login to their account allows the user to determine if any unauthorized activity has occurred and gives them an opportunity to notify administrators.

A New Policy/Manual Rule is Needed

A new Rule needs to be created in the scap-security-guide content.

SRG-OS-000027

CCI-000054

The operating system must limit the number of concurrent sessions for each account to an organization-defined number of sessions.

Limiting the number of allowed users and sessions per user can limit risks related to Denial of Service attacks. The organization may define the maximum number of concurrent sessions for an information system account globally, by account type, by account, or a combination thereof. This requirement addresses concurrent sessions for a single information system account and does not address concurrent sessions by a single user via multiple accounts.

Limit the Number of Concurrent Login Sessions Allowed Per User

Limiting the number of allowed users and sessions per user can limit risks related to Denial of Service attacks. This addresses concurrent sessions for a single account and does not address concurrent sessions by a single user via multiple accounts. To set the number of concurrent sessions per user add the following line in /etc/security/limits.conf:

* hard maxlogins MAX

Where MAX is the maximum number of login sessions allowed.

SRG-OS-000028

CCI-000056

The operating system must retain the session lock until the user reestablishes access using established identification and authentication procedures.

A session lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the system but does not want to log out because of the temporary nature of the absence. Once invoked, the session lock shall remain in place until the user re-authenticates. No other system activity aside from re-authentication can unlock the system.

Product Meets this Requirement

Red Hat Enterprise Linux meets this requirement by design.

SRG-OS-000029

CCI-000057

The operating system must initiate a session lock after the organization-defined time period of inactivity.

A session time-out lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the system but does not log out because of the temporary nature of the absence. The organization defines the period of inactivity to pass before a session lock is initiated so this must be configurable.

Set GNOME Login Inactivity Timeout

The idle time-out value for period of inactivity GNOME desktop lockout should be 15 minutes.

# gconftool-2 \
  --direct \
  --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory \
  --type int \
  --set /apps/gnome-screensaver/idle_delay 15

GNOME Desktop Screensaver Mandatory Use

Idle activation of the screen saver should be enabled

# gconftool-2 --direct \
  --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory \
  --type bool \
  --set /apps/gnome-screensaver/idle_activation_enabled true

Enable Screen Lock Activation After Idle Period

Idle activation of the screen lock should be enabled.

# gconftool-2 --direct \
  --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory \
  --type bool \
  --set /apps/gnome-screensaver/lock_enabled true

SRG-OS-000030

CCI-000058

The operating system must provide the capability for users to directly initiate session lock mechanisms.

A session lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the system but does not want to log out because of the temporary nature of the absence. Rather than be forced to wait for a period of time to expire before the user session can be locked, the operating system needs to provide users with the ability to manually invoke a session lock so users may secure their account should the need arise for them to temporarily vacate the immediate physical vicinity.

Install the vlock Package

To enable console screen locking, install the vlock package:

# yum install vlock

Instruct users to invoke the program when necessary, in order to prevent passersby from abusing their login:

$ vlock

The -a option can be used to prevent switching to other virtual consoles.

SRG-OS-000031

CCI-000060

The operating system session lock mechanism, when activated on a device with a display screen, must place a publicly viewable pattern onto the associated display, hiding what was previously visible on the screen.

A session time-out lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the system but does not log out because of the temporary nature of the absence. The session lock will also include an obfuscation of the display screen to prevent other users from reading what was previously displayed.

Implement Blank Screen Saver

The screen saver should be blank.

# gconftool-2
  --direct \
  --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory \
  --type string \
  --set /apps/gnome-screensaver/mode blank-only

SRG-OS-000032

CCI-000067

The operating system must employ automated mechanisms to facilitate the monitoring and control of remote access methods.

Remote network access is accomplished by leveraging common communication protocols and establishing a remote connection. Remote access is any access to an organizational information system by a user (or an information system) communicating through an external, non-organization-controlled network (e.g., the Internet). Examples of remote access methods include dial-up, broadband, and wireless. Automated monitoring of remote access sessions allows organizations to audit user activities on a variety of information system components (e.g., servers, workstations, notebook/laptop computers) and to ensure compliance with remote access policy.

Enable auditd Service

The auditd service is an essential userspace component of the Linux Auditing System, as it is responsible for writing audit records to disk. The auditd service can be enabled with the following command:

# chkconfig auditd on

SRG-OS-000033

CCI-000068

The operating system must use cryptography to protect the confidentiality of remote access sessions.

Remote network access is accomplished by leveraging common communication protocols and establishing a remote connection. These connections will occur over the public Internet. Remote access is any access to an organizational information system by a user (or an information system) communicating through an external, non-organization-controlled network (e.g., the Internet). Examples of remote access methods include dial-up, broadband, and wireless. Using cryptography ensures confidentiality of the remote access connections.

Configure OpenSSH Server if Necessary If the system needs to act as an SSH server, then certain changes should be made to the OpenSSH daemon configuration file /etc/ssh/sshd_config. The following recommendations can be applied to this file. See the sshd_config(5) man page for more detailed information.

SRG-OS-000034

CCI-000085

The operating system must monitor for unauthorized connections of mobile devices to organizational information systems.

Mobile devices include portable storage media (e.g., USB memory sticks, external hard disk drives) and portable computing and communications devices with information storage capability (e.g., notebook/laptop computers, personal digital assistants, cellular telephones, digital cameras, audio recording devices). Organization-controlled mobile devices include those devices for which the organization has the authority to specify and the ability to enforce specific security requirements. Usage restrictions and implementation guidance related to mobile devices include, configuration management, device identification and authentication, implementation of mandatory protective software (e.g., malicious code detection, firewall), scanning devices for malicious code, updating virus protection software, scanning for critical software updates and patches, conducting primary operating system (and possibly other resident software) integrity checks, and disabling unnecessary hardware (e.g., wireless, infrared). In order to detect unauthorized mobile device connections, organizations must first identify and document what mobile devices are authorized.

Disable Modprobe Loading of USB Storage Driver

If USB storage devices should not be used, the modprobe program used for automatic kernel module loading should be configured to not load the USB storage driver upon demand. Add the following line to the appropriate file in /etc/modprobe.d/ to prevent loading of the usb-storage kernel module:

install usb-storage /bin/true

This will prevent the modprobe program from loading the usb-storage module, but will not prevent an administrator (or another program) from using the insmod program to load the module manually.

Disable Kernel Support for USB via Bootloader Configuration

Another means of disabling USB storage is to disable all USB support provided by the operating system. This can be accomplished by adding the nousb argument to the kernel’s boot loader configuration. To disable kernel support for USB, append “nousb” to the kernel line in /etc/grub.conf as follows:

kernel /vmlinuz-VERSION ro vga=ext root=/dev/VolGroup00/LogVol00 rhgb quiet nousb

WARNING: Disabling all kernel support for USB will cause problems for systems with USB-based keyboards, mice, or printers. This guidance is inappropriate for systems which require USB connectivity.

Disable Booting from USB Devices

An attacker with physical access could try to boot the system from a USB flash drive and then access any data on the system’s hard drive, circumventing the normal operating system’s access controls. To prevent this, configure the BIOS to disallow booting from USB drives. Also configure the BIOS or firmware password as described in the section titled "Set BIOS Password" to prevent unauthorized configuration changes.

Disable the Automounter

The autofs daemon mounts and unmounts filesystems, such as user home directories shared via NFS, on demand. In addition, autofs can be used to handle removable media, and the default configuration provides the cdrom device as /misc/cd. However, this method of providing access to removable media is not common, so autofs can almost always be disabled if NFS is not in use. Even if NFS is required, it is almost always possible to configure filesystem mounts statically by editing /etc/fstab rather than relying on the automounter.

If the autofs service is not needed to dynamically mount NFS filesystems or removable media, disable the service for all runlevels:

# chkconfig --level 0123456 autofs off

Disable GNOME Automounting

The system’s default desktop environment, GNOME, will mount devices and removable media (such as DVDs, CDs and USB flash drives) whenever they are inserted into the system. Disable automount and autorun within GNOME by running the following:

# gconftool-2 --direct \
	--config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory \
	--type bool \
	--set /apps/nautilus/preferences/media_automount false
# gconftool-2 --direct \
	--config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory \
	--type bool \
	--set /apps/nautilus/preferences/media_autorun_never true

These settings can be verified by running the following:

$ gconftool-2 --direct \
	--config-source xml:read:/etc/gconf/gconf.xml.mandatory \
	--get /apps/nautilus/preferences/media_automount
$ gconftool-2 --direct \
	--config-source xml:read:/etc/gconf/gconf.xml.mandatory \
	--get /apps/nautilus/preferences/media_autorun_never

Disable WiFi or Bluetooth BIOS

Some systems that include built-in wireless support offer the ability to disable the device through the BIOS. This is system-specific; consult your hardware manual or explore the BIOS setup during boot.

Deactivate Wireless Network Interfaces

Deactivating wireless network interfaces should prevent normal usage of the wireless capability.

First, identify the interfaces available with the command:

# ifconfig -a

>Additionally,the following command may also be used to determine whether wireless support ('extensions') is included for a particular interface, though this may not always be a clear indicator:

# iwconfig

After identifying any wireless interfaces (which may have names like wlan0, ath0, wifi0, em1 or eth0), deactivate the interface with the command:

# ifdown interface

These changes will only last until the next reboot. To disable the interface for future boots, remove the appropriate interface file from /etc/sysconfig/network-scripts:

# rm /etc/sysconfig/network-scripts/ifcfg-interface

Disable Bluetooth Service

The bluetooth service can be disabled with the following command:

# chkconfig bluetooth off

Disable Bluetooth Kernel Modules

The kernel's module loading system can be configured to prevent loading of the Bluetooth module. Add the following to the appropriate /etc/modprobe.d configuration file to prevent the loading of the Bluetooth module:

install net-pf-31 /bin/true
install bluetooth /bin/true

Configure auditd Rules for Comprehensive Auditing

The auditd program can perform comprehensive monitoring of system activity. This section describes recommended configuration settings for comprehensive auditing, but a full description of the auditing system’s capabilities is beyond the scope of this guide. The mailing list linux-audit@redhat.com exists to facilitate community discussion of the auditing system.

The audit subsystem supports extensive collection of events, including:

Tracing of arbitrary system calls (identified by name or number) on entry or exit.
Filtering by PID, UID, call success, system call argument (with some limitations), etc.
Monitoring of specific files for modifications to the file’s contents or metadata.

Auditing rules at startup are controlled by the file /etc/audit/audit.rules. Add rules to it to meet the auditing requirements for your organization. Each line in /etc/audit/audit.rules represents a series of arguments that can be passed to auditctl and can be individually tested during runtime. See documentation in /usr/share/doc/audit-VERSION and in the related man pages for more details.

If copying any example audit rulesets from /usr/share/doc/audit-VERSION, be sure to comment out the lines containing arch= which are not appropriate for your system’s architecture. Then review and understand the following rules, ensuring rules are activated as needed for the appropriate architecture.

After reviewing all the rules, reading the following sections, and editing as needed, the new rules can be activated as follows:

# service auditd restart

SRG-OS-000035

CCI-000087

The operating system must disable information system functionality that provides the capability for automatic execution of code on mobile devices without user direction.

Mobile devices include portable storage media (e.g., USB memory sticks, external hard disk drives) and portable computing and communications devices with information storage capability (e.g., notebook/laptop computers, personal digital assistants, cellular telephones, digital cameras, audio recording devices). Auto execution vulnerabilities can result in malicious programs being automatically executed. Examples of information system functionality providing the capability for automatic execution of code are Auto Run and Auto Play. Auto Run and Auto Play are components of the Microsoft Windows operating system that dictate what actions the system takes when a drive is mounted. This requirement is designed to address vulnerabilities that arise when mobile devices such as USB memory sticks or other mobile storage devices are automatically mounted and applications are automatically invoked without user knowledge or acceptance.

Add noexec Option to Removable Media Partitions The noexec mount option prevents the direct execution of binaries on the mounted filesystem. Users should not be allowed to execute binaries that exist on partitions mounted from removable media (such as a USB key). The noexec option prevents code from being executed directly from the media itself, and may therefore provide a line of defense against certain types of worms or malicious code.

SRG-OS-000036

CCI-000099

The operating system must employ automated mechanisms to enable authorized users to make information sharing decisions based on access authorizations of sharing partners and access restrictions on information to be shared.

Depending on the information sharing circumstance, the sharing partner may be defined at the individual, group, or organization level and information may be defined by specific content, type, or security categorization. The operating system must restrict data in some manner (e.g., privileged medical, contract-sensitive, proprietary, personally identifiable information, special access programs/compartments) and must provide the capability to automatically enable authorized users to make information sharing decisions based upon access authorizations.

Product Meets this Requirement

Red Hat Enterprise Linux meets this requirement by design.

SRG-OS-000037

CCI-000130

The operating system must produce audit records containing sufficient information to establish what type of events occurred.

Operating system auditing capability is critical for accurate forensic analysis. Audit record content that may be necessary to satisfy the requirement of this control includes, time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, file names involved, and access control or flow control rules invoked.

Enable auditd Service

# chkconfig auditd on

Enable Auditing for Processes Which Start Prior to the Audit Daemon

To ensure that all processes can be audited, even those which start prior to the audit daemon, add the argument audit=1 to the kernel line in /etc/grub.conf, in the manner below:

kernel /vmlinuz-version ro vga=ext root=/dev/VolGroup00/LogVol00 rhgb quiet audit=1

Configure auditd Rules for Comprehensive Auditing

Tracing of arbitrary system calls (identified by name or number) on entry or exit.
Filtering by PID, UID, call success, system call argument (with some limitations), etc.
Monitoring of specific files for modifications to the file’s contents or metadata.

# service auditd restart

SRG-OS-000038

CCI-000131

The operating system must produce audit records containing sufficient information to establish when (date and time) the events occurred.

Product Meets this Requirement

Red Hat Enterprise Linux meets this requirement by design.

SRG-OS-000039

CCI-000132

The operating system must produce audit records containing sufficient information to establish where the events occurred.

Product Meets this Requirement

Red Hat Enterprise Linux meets this requirement by design.

SRG-OS-000040

CCI-000133

The operating system must produce audit records containing sufficient information to establish the sources of the events.

Operating system auditing capability is critical for accurate forensic analysis. Audit record content that may be necessary to satisfy the requirement of this control includes, time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked.

Product Meets this Requirement

Red Hat Enterprise Linux meets this requirement by design.

SRG-OS-000041

CCI-000134

The operating system must produce audit records containing sufficient information to establish the outcome (success or failure) of the events.

Operating system auditing capability is critical for accurate forensic analysis. Audit record content that may be necessary to satisfy the requirement of this control, includes, for example, time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, file names involved, and access control or flow control rules invoked. Success and failure indicators ascertain the outcome of a particular event. As such, they also provide a means to measure the impact of an event and help authorized personnel to determine the appropriate response.

Product Meets this Requirement

Red Hat Enterprise Linux meets this requirement by design.

SRG-OS-000042

CCI-000135

The operating system must include organization-defined additional, more detailed information in the audit records for audit events identified by type, location, or subject.

Information system auditing capability is critical for accurate forensic analysis. Audit record content that may be necessary to satisfy the requirement of this control, includes, time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, file names involved, and access control or flow control rules invoked.

System Accounting with auditd

The audit service provides substantial capabilities for recording system activities. By default, the service audits about SELinux AVC denials and certain types of security-relevant events such as system logins, account modifications, and authentication events performed by programs such as sudo. Under its default configuration, auditd has modest disk space requirements, and should not noticeably impact system performance.

Government networks often have substantial auditing requirements and auditd can be configured to meet these requirements. Examining some example audit records demonstrates how the Linux audit system satisfies common requirements. The following example from Fedora Documentation available at

http://docs.fedoraproject.org/en-US/Fedora/13/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-Fixing_Problems-Raw_Audit_Messages.html

shows the substantial amount of information captured in a two typical "raw" audit messages, followed by a breakdown of the most important fields. In this example the message is SELinux-related and reports an AVC denial (and the associated system call) that occurred when the Apache HTTP Server attempted to access the /var/www/html/file1 file (labeled with the samba_share_t type):

type=AVC msg=audit(1226874073.147:96): avc:  denied  { getattr } for pid=2465 comm="httpd"
path="/var/www/html/file1" dev=dm-0 ino=284133 scontext=unconfined_u:system_r:httpd_t:s0 
tcontext=unconfined_u:object_r:samba_share_t:s0 tclass=file

type=SYSCALL msg=audit(1226874073.147:96): arch=40000003 syscall=196 success=no exit=-13 
a0=b98df198 a1=bfec85dc a2=54dff4 a3=2008171 items=0 ppid=2463 pid=2465 auid=502 uid=48
gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=6 comm="httpd"
exe="/usr/sbin/httpd" subj=unconfined_u:system_r:httpd_t:s0 key=(null)

msg=audit(1226874073.147:96)
- The number in parentheses is the unformatted time stamp (Epoch time) for the event, which can be converted to standard time by using the date command.
{ getattr }
- The item in braces indicates the permission that was denied. getattr indicates the source process was trying to read the target file's status information. This occurs before reading files. This action is denied due to the file being accessed having the wrong label. Commonly seen permissions include getattr, read, and write.
comm="httpd"
- The executable that launched the process. The full path of the executable is found in the exe= section of the system call (SYSCALL) message, which in this case, is exe="/usr/sbin/httpd".
path="/var/www/html/file1"
- The path to the object (target) the process attempted to access.
scontext="unconfined_u:system_r:httpd_t:s0"
- The SELinux context of the process that attempted the denied action. In this case, it is the SELinux context of the Apache HTTP Server, which is running in the httpd_t domain.
tcontext="unconfined_u:object_r:samba_share_t:s0"
- The SELinux context of the object (target) the process attempted to access. In this case, it is the SELinux context of file1. Note: the samba_share_t type is not accessible to processes running in the httpd_t domain.
From the system call (SYSCALL) message, two items are of interest:
- success=no: indicates whether the denial (AVC) was enforced or not. success=no indicates the system call was not successful (SELinux denied access). success=yes indicates the system call was successful - this can be seen for permissive domains or unconfined domains, such as initrc_t and kernel_t.
- exe="/usr/sbin/httpd": the full path to the executable that launched the process, which in this case, is exe="/usr/sbin/httpd".

SRG-OS-000043

CCI-000136

The operating system must support the requirement to centrally manage the content of audit records generated by organization-defined information system components.

Operating system auditing capability is critical for accurate forensic analysis. Audit record content that may be necessary to satisfy the requirement of this control, includes, for example, time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, file names involved, and access control or flow control rules invoked. Centralized management of audit records and logs provides for efficiency in maintenance of records, as well as, the backup and archiving of those records. When organizations define application components that require requiring centralized audit log management, operating systems need to support the requirement.

Ensure Logs Sent To Remote Host

To configure rsyslog to send logs to a remote log server, open /etc/rsyslog.conf and read and understand the last section of the file, which describes the multiple directives necessary to activate remote logging. Along with these other directives, the system can be configured to forward its logs to a particular log server by adding or correcting one of the following lines, substituting loghost.example.com appropriately. The choice of protocol depends on the environment of the system; although TCP and RELP provide more reliable message delivery, they may not be supported in all environments.
To use UDP for log message delivery:

*.* @loghost.example.com

To use TCP for log message delivery:

*.* @@loghost.example.com

To use RELP for log message delivery:

*.* :omrelp:loghost.example.com

SRG-OS-000044

CCI-000137

The operating system must allocate audit record storage capacity.

Ensure /var/log/audit Located On Separate Partition Audit logs are stored in the /var/log/audit directory. Ensure that it has its own partition or logical volume at installation time, or migrate it later using LVM. Make absolutely certain that it is large enough to store all audit logs that will be created by the auditing daemon.

SRG-OS-000045

CCI-000138

The operating system must configure auditing to reduce the likelihood of storage capacity being exceeded.

Configure auditd Data Retention The audit system writes data to /var/log/audit/audit.log. By default, auditd rotates 5 logs by size (6MB), retaining a maximum of 30MB of data in total, and refuses to write entries when the disk is too full. This minimizes the risk of audit data filling its partition and impacting other services. This also minimizes the risk of the audit daemon temporarily disabling the system if it cannot write audit log (which it can be configured to do). For a busy system or a system which is thoroughly auditing system activity, the default settings for data retention may be insuffcient. The log file size needed will depend heavily on what types of events are being audited. First configure auditing to log all the events of interest. Then monitor the log size manually for awhile to determine what file size will allow you to keep the required data for the correct time period.

Using a dedicated partition for /var/log/audit prevents the auditd logs from disrupting system functionality if they fill, and, more importantly, prevents other activity in /var from filling the partition and stopping the audit trail. (The audit logs are size-limited and therefore unlikely to grow without bound unless configured to do so.) Some machines may have requirements that no actions occur which cannot be audited. If this is the case, then auditd can be configured to halt the machine if it runs out of space. Note: Since older logs are rotated, configuring auditd this way does not prevent older logs from being rotated away before they can be viewed. If your system is configured to halt when logging cannot be performed, make sure this can never happen under normal circumstances! Ensure that /var/log/audit is on its own partition, and that this partition is larger than the maximum amount of data auditd will retain normally.

SRG-OS-000046

CCI-000139

The operating system must alert designated organizational officials in the event of an audit processing failure.

Configure auditd mail_acct Action on Low Disk Space

The auditd service can be configured to send email to a designated account in certain situations. Add or correct the following line in /etc/audit/auditd.conf to ensure that administrators are notified via email for those situations:

action_mail_acct = root

SRG-OS-000047

CCI-000140

The operating system must take organization-defined actions upon audit failure (e.g., shut down information system, overwrite oldest audit records, stop generating audit records).

It is critical when a system is at risk of failing to process audit logs as required, it detects and takes action to mitigate the failure. Audit processing failures include, software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded.

Configure auditd space_left Action on Low Disk Space

The auditd service can be configured to take an action when disk space starts to run low. Edit the file /etc/audit/auditd.conf. Modify the following line, substituting ACTION appropriately:

space_left_action = ACTION

Possible values for ACTION are described in the auditd.conf man page. These include:

ignore
syslog
email
exec
suspend
single
halt

Set this to email (instead of the default, which is suspend) as it is more likely to get prompt attention.

Configure auditd admin_space_left Action on Low Disk Space

The auditd service can be configured to take an action when disk space is running low but prior to running out of space completely. Edit the file /etc/audit/auditd.conf. Add or modify the following line, substituting ACTION appropriately:

admin_space_left_action = ACTION

Possible values for ACTION are described in the auditd.conf man page. These include:

ignore
syslog
email
exec
suspend
single
halt

Set this value to single to cause the system to switch to single user mode for corrective action. For certain systems, the need for availability outweighs the need to log all actions, and a different setting should be determined.

SRG-OS-000048

CCI-000143

The operating system must provide a warning when allocated audit record storage volume reaches an organization-defined percentage of maximum audit record storage capacity.

It is critical for the appropriate personnel to be aware if a system is at risk of failing to process audit logs as required. Audit processing failures include, software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded. If audit log capacity were to be exceeded then events that subsequently occur will not be recorded.

Configure auditd space_left Action on Low Disk Space

The auditd service can be configured to take an action when disk space starts to run low. Edit the file /etc/audit/auditd.conf. Modify the following line, substituting ACTION appropriately:

space_left_action = ACTION

Possible values for ACTION are described in the auditd.conf man page. These include:

ignore
syslog
email
exec
suspend
single
halt

Set this to email (instead of the default, which is suspend) as it is more likely to get prompt attention.

Configure auditd admin_space_left Action on Low Disk Space

admin_space_left_action = ACTION

Possible values for ACTION are described in the auditd.conf man page. These include:

ignore
syslog
email
exec
suspend
single
halt

SRG-OS-000049

CCI-000144

The operating system must provide a real-time alert when organization-defined audit failure events occur.

It is critical for the appropriate personnel to be aware if a system is at risk of failing to process audit logs as required. Audit processing failures include, software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded. Organizations must define audit failure events requiring an application to send an alarm. When those defined events occur, the application will provide a real-time alert to the appropriate personnel.

Configure auditd space_left Action on Low Disk Space

The auditd service can be configured to take an action when disk space starts to run low. Edit the file /etc/audit/auditd.conf. Modify the following line, substituting ACTION appropriately:

space_left_action = ACTION

Possible values for ACTION are described in the auditd.conf man page. These include:

ignore
syslog
email
exec
suspend
single
halt

Set this to email (instead of the default, which is suspend) as it is more likely to get prompt attention.

Configure auditd admin_space_left Action on Low Disk Space

admin_space_left_action = ACTION

Possible values for ACTION are described in the auditd.conf man page. These include:

ignore
syslog
email
exec
suspend
single
halt

SRG-OS-000051

CCI-000154

Operating system must support the capability to centralize the review and analysis of audit records from multiple components within the system.

Successful incident response and auditing relies on timely, accurate system information and analysis in order to allow the organization to identify and respond to potential incidents in a proficient manner. Segregation of logging data to multiple disparate computer systems is counterproductive and makes log analysis and log event alarming difficult to implement and manage, particularly when the system or application has multiple logging components written to different locations or systems. To support the centralized capability, the operating system must be able to provide the information in a format that can be extracted and used allowing the application performing the centralization of the log records to meet this requirement.

Product Meets this Requirement

Red Hat Enterprise Linux meets this requirement by design.

SRG-OS-000052

CCI-000156

The operating system must support an audit reduction capability.

Audit reduction is used to reduce the volume of audit records in order to facilitate manual review. Before a security review information systems and/or applications with an audit reduction capability may remove many audit records known to have little security significance. An audit reduction capability provides support for near real-time audit review and analysis requirements and after-the-fact investigations of security incidents. The operating system must integrate into the information system or organizational audit reduction capability.

Product Meets this Requirement

Red Hat Enterprise Linux meets this requirement by design.

SRG-OS-000053

CCI-000157

The operating system audit records must be able to be used by a report generation capability.

Logging the actions of specific events provides a means to investigate an attack, recognize resource utilization or capacity thresholds, or to simply identify a network element that has been configured improperly. In order to determine what is happening within the network infrastructure or to resolve and trace an attack, it is imperative to correlate the log data from multiple network elements to acquire a clear understanding as to what happened or is happening. The operating system audit records must be able to be consumed by the audit report generation capability.

System Accounting with auditd

http://docs.fedoraproject.org/en-US/Fedora/13/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-Fixing_Problems-Raw_Audit_Messages.html

type=AVC msg=audit(1226874073.147:96): avc:  denied  { getattr } for pid=2465 comm="httpd"
path="/var/www/html/file1" dev=dm-0 ino=284133 scontext=unconfined_u:system_r:httpd_t:s0 
tcontext=unconfined_u:object_r:samba_share_t:s0 tclass=file

type=SYSCALL msg=audit(1226874073.147:96): arch=40000003 syscall=196 success=no exit=-13 
a0=b98df198 a1=bfec85dc a2=54dff4 a3=2008171 items=0 ppid=2463 pid=2465 auid=502 uid=48
gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=6 comm="httpd"
exe="/usr/sbin/httpd" subj=unconfined_u:system_r:httpd_t:s0 key=(null)

msg=audit(1226874073.147:96)
- The number in parentheses is the unformatted time stamp (Epoch time) for the event, which can be converted to standard time by using the date command.
{ getattr }
- The item in braces indicates the permission that was denied. getattr indicates the source process was trying to read the target file's status information. This occurs before reading files. This action is denied due to the file being accessed having the wrong label. Commonly seen permissions include getattr, read, and write.
comm="httpd"
- The executable that launched the process. The full path of the executable is found in the exe= section of the system call (SYSCALL) message, which in this case, is exe="/usr/sbin/httpd".
path="/var/www/html/file1"
- The path to the object (target) the process attempted to access.
scontext="unconfined_u:system_r:httpd_t:s0"
- The SELinux context of the process that attempted the denied action. In this case, it is the SELinux context of the Apache HTTP Server, which is running in the httpd_t domain.
tcontext="unconfined_u:object_r:samba_share_t:s0"
- The SELinux context of the object (target) the process attempted to access. In this case, it is the SELinux context of file1. Note: the samba_share_t type is not accessible to processes running in the httpd_t domain.
From the system call (SYSCALL) message, two items are of interest:
- success=no: indicates whether the denial (AVC) was enforced or not. success=no indicates the system call was not successful (SELinux denied access). success=yes indicates the system call was successful - this can be seen for permissive domains or unconfined domains, such as initrc_t and kernel_t.
- exe="/usr/sbin/httpd": the full path to the executable that launched the process, which in this case, is exe="/usr/sbin/httpd".

SRG-OS-000054

CCI-000158

The operating system must provide the capability to automatically process audit records for events of interest based upon selectable, event criteria.

Audit reduction is used to reduce the volume of audit records in order to facilitate manual review. Before a security review information systems and/or applications with an audit reduction capability may remove many audit records known to have little security significance. This is generally accomplished by removing records generated by specified classes of events, such as records generated by nightly backups. An audit reduction capability provides support for near real-time audit review and analysis based on policy requirements regarding what must be audited on the system and after-the-fact investigations of security incidents. Audit reduction and reporting tools do not alter original audit records.

Enable auditd Service

# chkconfig auditd on

SRG-OS-000055

CCI-000159

The operating system must use internal system clocks to generate time stamps for audit records.

Determining the correct time a particular event occurred on a system is critical when conducting forensic analysis and investigating system events. Time stamps generated by the information system shall include both date and time. The time may be expressed in Coordinated Universal Time (UTC), a modern continuation of Greenwich Mean Time (GMT), or local time with an offset from UTC.

Product Meets this Requirement

Red Hat Enterprise Linux meets this requirement by design.

SRG-OS-000056

CCI-000160

The operating system must synchronize internal information system clocks on an organization-defined frequency with an organization-defined authoritative time source.

Determining the correct time a particular application event occurred on a system is critical when conducting forensic analysis and investigating system events. Synchronization of system clocks is needed in order to correctly correlate the timing of events that occur across multiple systems. To meet this requirement the organization will define an authoritative time source and frequency to which each system will synchronize its internal clock. An example is utilizing the NTP protocol to synchronize with centralized NTP servers. Time stamps generated by the information system shall include both date and time. The time may be expressed in Coordinated Universal Time (UTC), a modern continuation of Greenwich Mean Time (GMT), or local time with an offset from UTC.

Enable the NTP Daemon

The ntpd service can be enabled with the following command:

# chkconfig ntpd on

Specify a Remote NTP Server

To specify a remote NTP server for time synchronization, edit the file /etc/ntp.conf. Add or correct the following lines, substituting the IP or hostname of a remote NTP server for ntpserver:

server ntpserver

This instructs the NTP software to contact that remote server to obtain time data.

SRG-OS-000057

CCI-000162

The operating system must protect audit information from unauthorized read access.

If audit data were to become compromised then competent forensic analysis and discovery of the true source of potentially malicious system activity is difficult if not impossible to achieve. To ensure the veracity of audit data the operating system must protect audit information from unauthorized access. This requirement can be achieved through multiple methods which will depend upon system architecture and design. Some commonly employed methods include ensuring log files have the proper file system permissions utilizing file system protections and limiting log data location. Audit information includes all information (e.g., audit records, audit settings, audit reports) needed to successfully audit information system activity.

Product Meets this Requirement

Red Hat Enterprise Linux meets this requirement by design.

SRG-OS-000058

CCI-000163

The operating system must protect audit information from unauthorized modification.

If audit data were to become compromised then competent forensic analysis and discovery of the true source of potentially malicious system activity is impossible to achieve. To ensure the veracity of audit data the operating system must protect audit information from unauthorized modification. Audit information includes all information (e.g., audit records, audit settings, audit reports) needed to successfully audit information system activity.

Product Meets this Requirement

Red Hat Enterprise Linux meets this requirement by design.

SRG-OS-000059

CCI-000164

The operating system must protect audit information from unauthorized deletion.

If audit data were to become compromised then competent forensic analysis and discovery of the true source of potentially malicious system activity is impossible to achieve. To ensure the veracity of audit data the operating system must protect audit information from unauthorized deletion. This requirement can be achieved through multiple methods which will depend upon system architecture and design. Audit information includes all information (e.g., audit records, audit settings, audit reports) needed to successfully audit information system activity.

Product Meets this Requirement

Red Hat Enterprise Linux meets this requirement by design.

SRG-OS-000060

CCI-000165

The operating system must produce audit records on hardware-enforced, write-once media.

The protection of audit records from unauthorized or accidental deletion or modification requires the operating system produce audit records on hardware-enforced write-once media.

Guidance Does Not Meet this Requirement Due to Impracticality or Scope

The guidance does not meet this requirement. The requirement is impractical or out of scope.

SRG-OS-000061

CCI-000166

The operating system must protect against an individual falsely denying having performed a particular action.

Non-repudiation of actions taken is required in order to maintain integrity. Non-repudiation protects individuals against later claims by an author of not having updated a particular file, invoked a specific command, or copied a specific file.

System Accounting with auditd

http://docs.fedoraproject.org/en-US/Fedora/13/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-Fixing_Problems-Raw_Audit_Messages.html

type=AVC msg=audit(1226874073.147:96): avc:  denied  { getattr } for pid=2465 comm="httpd"
path="/var/www/html/file1" dev=dm-0 ino=284133 scontext=unconfined_u:system_r:httpd_t:s0 
tcontext=unconfined_u:object_r:samba_share_t:s0 tclass=file

type=SYSCALL msg=audit(1226874073.147:96): arch=40000003 syscall=196 success=no exit=-13 
a0=b98df198 a1=bfec85dc a2=54dff4 a3=2008171 items=0 ppid=2463 pid=2465 auid=502 uid=48
gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=6 comm="httpd"
exe="/usr/sbin/httpd" subj=unconfined_u:system_r:httpd_t:s0 key=(null)

msg=audit(1226874073.147:96)
- The number in parentheses is the unformatted time stamp (Epoch time) for the event, which can be converted to standard time by using the date command.
{ getattr }
- The item in braces indicates the permission that was denied. getattr indicates the source process was trying to read the target file's status information. This occurs before reading files. This action is denied due to the file being accessed having the wrong label. Commonly seen permissions include getattr, read, and write.
comm="httpd"
- The executable that launched the process. The full path of the executable is found in the exe= section of the system call (SYSCALL) message, which in this case, is exe="/usr/sbin/httpd".
path="/var/www/html/file1"
- The path to the object (target) the process attempted to access.
scontext="unconfined_u:system_r:httpd_t:s0"
- The SELinux context of the process that attempted the denied action. In this case, it is the SELinux context of the Apache HTTP Server, which is running in the httpd_t domain.
tcontext="unconfined_u:object_r:samba_share_t:s0"
- The SELinux context of the object (target) the process attempted to access. In this case, it is the SELinux context of file1. Note: the samba_share_t type is not accessible to processes running in the httpd_t domain.
From the system call (SYSCALL) message, two items are of interest:
- success=no: indicates whether the denial (AVC) was enforced or not. success=no indicates the system call was not successful (SELinux denied access). success=yes indicates the system call was successful - this can be seen for permissive domains or unconfined domains, such as initrc_t and kernel_t.
- exe="/usr/sbin/httpd": the full path to the executable that launched the process, which in this case, is exe="/usr/sbin/httpd".

SRG-OS-000062

CCI-000169

The operating system must provide audit record generation capability for the auditable events defined in at the organizational level for the organization-defined information system components.

The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records (i.e., auditable events) for example, time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked.

Enable auditd Service

# chkconfig auditd on

Record attempts to alter time through adjtimex

On a 32-bit system, add the following to /etc/audit/audit.rules:

# audit_time_rules
-a always,exit -F arch=b32 -S adjtimex -k audit_time_rules

On a 64-bit system, add the following to /etc/audit/audit.rules:

# audit_time_rules
-a always,exit -F arch=b64 -S adjtimex -k audit_time_rules

The -k option allows for the specification of a key in string form that can be used for better reporting capability through ausearch and aureport. Multiple system calls can be defined on the same line to save space if desired, but is not required. See an example of multiple combined syscalls:

-a always,exit -F arch=b64 -S adjtimex -S settimeofday -S clock_settime 
-k audit_time_rules

Record attempts to alter time through settimeofday

On a 32-bit system, add the following to /etc/audit/audit.rules:

# audit_time_rules
-a always,exit -F arch=b32 -S settimeofday -k audit_time_rules

On a 64-bit system, add the following to /etc/audit/audit.rules:

# audit_time_rules
-a always,exit -F arch=b64 -S settimeofday -k audit_time_rules

-a always,exit -F arch=b64 -S adjtimex -S settimeofday -S clock_settime 
-k audit_time_rules

Record Attempts to Alter Time Through stime

On a 32-bit system, add the following to /etc/audit/audit.rules:

# audit_time_rules
-a always,exit -F arch=b32 -S stime -k audit_time_rules

On a 64-bit system, the "-S time" is not necessary. The -k option allows for the specification of a key in string form that can be used for better reporting capability through ausearch and aureport. Multiple system calls can be defined on the same line to save space if desired, but is not required. See an example of multiple combined syscalls:

-a always,exit -F arch=b64 -S adjtimex -S settimeofday -S clock_settime 
-k audit_time_rules

Record Attempts to Alter Time Through clock_settime

On a 32-bit system, add the following to /etc/audit/audit.rules:

# audit_time_rules
-a always,exit -F arch=b32 -S clock_settime -k audit_time_rules

On a 64-bit system, add the following to /etc/audit/audit.rules:

# audit_time_rules
-a always,exit -F arch=b64 -S clock_settime -k audit_time_rules

-a always,exit -F arch=b64 -S adjtimex -S settimeofday -S clock_settime 
-k audit_time_rules

Record Attempts to Alter the localtime File

Add the following to /etc/audit/audit.rules:

-w /etc/localtime -p wa -k audit_time_rules

The -k option allows for the specification of a key in string form that can be used for better reporting capability through ausearch and aureport and should always be used.

SRG-OS-000063

CCI-000171

The operating system must allow designated organizational personnel to select which auditable events are to be audited by the operating system.

The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records (i.e., auditable events). Organizations will define the organizational personal accountable for selecting auditable events. The operating system must allow the designated personnel to select the items to be audited.

Configure auditd Rules for Comprehensive Auditing

Tracing of arbitrary system calls (identified by name or number) on entry or exit.
Filtering by PID, UID, call success, system call argument (with some limitations), etc.
Monitoring of specific files for modifications to the file’s contents or metadata.

# service auditd restart

SRG-OS-000064

CCI-000172

The operating system must generate audit records for the selected list of auditable events as defined in DoD list of events.

Enable auditd Service

# chkconfig auditd on

Configure auditd Rules for Comprehensive Auditing

Tracing of arbitrary system calls (identified by name or number) on entry or exit.
Filtering by PID, UID, call success, system call argument (with some limitations), etc.
Monitoring of specific files for modifications to the file’s contents or metadata.

# service auditd restart

SRG-OS-000065

CCI-000174

The operating system must support the capability to compile audit records from multiple components within the system into a system-wide (logical or physical) audit trail that is time-correlated to within organization-defined level of tolerance.

Audit generation and audit records can be generated from various components within the information system. The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records (i.e., auditable events). The events that occur must be time-correlated on order to conduct accurate forensic analysis. In addition, the correlation must meet a certain tolerance criteria. The operating system must be able to have audit events correlated to the level of tolerance determined by the organization.

Enable auditd Service

# chkconfig auditd on

SRG-OS-000066

CCI-000185

The operating system, for PKI-based authentication must validate certificates by constructing a certification path with status information to an accepted trust anchor.

A trust anchor is an authoritative entity represented via a public key and associated data. When there is a chain of trust, usually the top entity to be trusted becomes the trust anchor, for example, a Certification Authority (CA). A certification path starts with the Subject certificate and proceeds through a number of intermediate certificates up to a trusted root certificate, typically issued by a trusted CA. Path validation is necessary for a relying party to make an informed trust decision when presented with any certificate that is not already explicitly trusted. Status information for certification paths includes, certificate revocation lists or online certificate status protocol responses.

Enable Client Support

The system ships with certificates from well-known commercial CAs. If your server certificates were signed by one of these established CAs, then this step is not necessary since the clients should include the CA certificate already. If your servers use certificates signed by your own CA, some user applications will warn that the server’s certificate cannot be verified because the CA is not recognized. Other applications may simply fail to accept the certificate and refuse to operate, or continue operating without ever having properly verified the server certificate. To avoid this warning, and properly authenticate the servers, your CA certificate must be exported to every application on every client system that will be connecting to an SSL-enabled server.

SRG-OS-000067

CCI-000186

The operating system, for PKI-based authentication must enforce authorized access to the corresponding private key.

The cornerstone of the PKI is the private key used to encrypt or digitally sign information. If the private key is stolen, this will lead to the compromise of the authentication and non-repudiation gained through PKI because the attacker can use the private key to digitally sign documents and can pretend to be the authorized user. Both the holders of a digital certificate and the issuing authority must protect the computers, storage devices or whatever they use to keep the private keys.

Product Meets this Requirement

Red Hat Enterprise Linux meets this requirement by design.

SRG-OS-000068

CCI-000187

The operating system, for PKI-based authentication must map the authenticated identity to the user account.

The cornerstone of the PKI is the private key used to encrypt or digitally sign information. The key by itself is a cryptographic value that does not contain specific user information. The authenticated identity must be mapped to an account for access and authorization decisions.

Secure Sockets Layer Support

The Secure Sockets Layer (SSL) protocol provides encrypted and authenticated network communications, and many network services include support for it. Using SSL is recommended, especially to avoid any plaintext transmission of sensitive data, even over a local network. The SSL implementation included with the system is called OpenSSL. Recent implementations of SSL may also be referred to as Transport Layer Security (TLS). SSL uses public key cryptography to provide authentication and encryption.

Public key cryptography involves two keys, one called the public key and the other called the private key. These keys are mathematically related such that data encrypted with one key can only be decrypted by the other, and vice versa. As their names suggest, public keys can be distributed to anyone while a private key must remain known only to its owner. SSL uses certificates, which are files that hold cryptographic data: a public key, and a signature of that public key. In SSL authentication, a server presents a client with its certificate as a means of demonstrating that it is who it claims it is.

If everything goes correctly, the client can verify the server’s certificate by determining that the signature inside the certificate could only have been generated by a third party whom the client trusts. This third party is called a Certificate Authority (CA). Each client system should also have certificates from trusted CAs, and the client uses these CA certificates to verify the authenticity of the server’s certificate. After authenticating a server using its certificate and a CA certificate, SSL provides encryption by using the server certificate to securely negotiate a shared secret key.

If your server must communicate using SSL with systems that might not be able to securely accept a new CA certificate prior to any SSL communication, then paying an established CA (whose certificates your clients already have) to sign your server certificates is recommended. The steps for doing this vary by vendor. Once the signed certificates have been obtained, configuration of the services is the same whether they were purchased from a vendor or signed by your own CA.

For setting up an internal network and encrypting local traffic, creating your own CA to sign SSL certificates can be appropriate. The major steps in this process are:

Create a CA to sign certificates
Create SSL certificates for servers using that CA
Enable client support by distributing the CA’s certificate

SRG-OS-000069

CCI-000192

The operating system must enforce password complexity by the number of upper case characters used.

Password complexity or strength is a measure of the effectiveness of a password in resisting guessing and brute-force attacks. Password complexity is one factor of several that determine how long it takes to crack a password. The more complex the password is, the greater the number of possible combinations that need to be tested before the password is compromised. Use of a complex password helps to increase the time and resources required to compromise the password.

Set Password Strength Minimum Uppercase Characters The pam_cracklib module's ucredit= parameter controls requirements for usage of uppercase letters in a password. When set to a negative number, any password will be required to contain that many uppercase characters. When set to a positive number, pam_cracklib will grant +1 additional length credit for each uppercase character.

SRG-OS-000070

CCI-000193

The operating system must enforce password complexity by the number of lower case characters used.

Password complexity, or strength, is a measure of the effectiveness of a password in resisting guessing and brute-force attacks. Password complexity is one factor of several that determine how long it takes to crack a password. The more complex the password is, the greater the number of possible combinations that need to be tested before the password is compromised. Use of a complex password helps to increase the time and resources required to compromise the password.

Set Password Strength Minimum Lowercase Characters The pam_cracklib module's lcredit= parameter controls requirements for usage of lowercase letters in a password. When set to a negative number, any password will be required to contain that many lowercase characters. When set to a positive number, pam_cracklib will grant +1 additional length credit for each lowercase character.

SRG-OS-000071

CCI-000194

The operating system must enforce password complexity by the number of numeric characters used.

Set Password Strength Minimum Digit Characters The pam_cracklib module's dcredit= parameter controls requirements for usage of digits in a password. When set to a negative number, any password will be required to contain that many digits. When set to a positive number, pam_cracklib will grant +1 additional length credit for each digit.

SRG-OS-000072

CCI-000195

The operating system must enforce the number of characters changed when passwords are changed.

Passwords need to be changed at specific policy based intervals. If the operating system allows the user to consecutively reuse extensive portions of their password when they change their password, the end result is a password that may be compromised if the old password was known or guessable.

Set Password Strength Minimum Different Characters The pam_cracklib module's difok= parameter controls requirements for usage of different characters during a password change.

SRG-OS-000073

CCI-000196

The operating system must enforce password encryption for storage.

Passwords need to be protected at all times and encryption is the standard method for protecting passwords while in storage so unauthorized users/processes cannot gain access.

Verify All Account Password Hashes are Shadowed If any password hashes are stored in /etc/passwd (in the second field, instead of an x), the cause of this misconfiguration should be investigated. The account should have its password reset and the hash should be properly stored, or the account should be deleted entirely.

Verify No netrc Files Exist The .netrc files contain login information used to auto-login into FTP servers and reside in the user's home directory. These files may contain unencrypted passwords to remote FTP servers making them susceptible to access by unauthorized users and should not be used. Any .netrc files should be removed.

Disable telnet Service

The telnet service can be disabled with the following command:

# chkconfig telnet off

Use Only Approved Ciphers

Limit the ciphers to those algorithms which are FIPS-approved. Counter (CTR) mode is also preferred over cipher-block chaining (CBC) mode. The following line in /etc/ssh/sshd_config demonstrates use of FIPS-approved ciphers in CTR mode:

Ciphers aes128-ctr,aes192-ctr,aes256-ctr

The man page sshd_config(5) contains a list of supported ciphers. Note that older or less capable versions of SSH client or server software may still be found on systems such as networking equipment, and these may not support CTR mode. This may become an issue if, for example, these systems need to retrieve files from your SSH server using SFTP. TODO: Need to investigate current status of this. Earlier issues with CBC were supposed to be fixed.

SRG-OS-000074

CCI-000197

The operating system must enforce password encryption for transmission.

Passwords need to be protected at all times and encryption is the standard method for protecting passwords during transmission to ensure unauthorized users/processes do not gain access to them.

Disable telnet Service

The telnet service can be disabled with the following command:

# chkconfig telnet off

SRG-OS-000075

CCI-000198

The operating system must enforce minimum password lifetime restrictions.

Passwords need to be changed at specific policy based intervals, however if the information system or application allows the user to immediately and continually change their password then the password could be repeatedly changed in a short period of time defeating the organization’s policy regarding password reuse.

Set Password Minimum Age

To specify password minimum age for new accounts, edit the file /etc/login.defs and add or correct the following line, replacing DAYS appropriately:

PASS_MIN_DAYS DAYS

The DoD requirement is 7.

SRG-OS-000076

CCI-000199

The operating system must enforce maximum password lifetime restrictions.

Passwords need to be changed at specific policy based intervals. Any password no matter how complex can eventually be cracked. One method of minimizing this risk is to use complex passwords and periodically change them. If the operating system does not limit the lifetime of passwords and force users to change their passwords, there is the risk that system passwords could be compromised.

Set Password Maximum Age

To specify password maximum age for new accounts, edit the file /etc/login.defs and add or correct the following line, replacing DAYS appropriately:

PASS_MAX_DAYS DAYS

A value of 180 days is sufficient for many environments. The DoD requirement is 60.

SRG-OS-000077

CCI-000200

The operating system must prohibit password reuse for the organization-defined number of generations.

Password complexity, or strength, is a measure of the effectiveness of a password in resisting guessing and brute-force attacks. To meet password policy requirements, passwords need to be changed at specific policy based intervals. If the operating system allows the user to consecutively reuse their password when the password has exceeded its defined lifetime, the end result is a password that is not changed, per policy requirements.

Limit Password Reuse

Do not allow users to reuse recent passwords. This can be accomplished by using the remember option for the pam_unix PAM module. In order to prevent a user from re-using any of their last passwords, append remember= to the password line which uses the pam_unix module in the file /etc/pam.d/system-auth, as shown:

password sufficient pam_unix.so existing_options remember=

Old (and thus no longer valid) passwords are stored in the file /etc/security/opasswd. The DoD requirement is currently 24 passwords.

SRG-OS-000078

CCI-000205

The operating system must enforce minimum password length.

Password complexity, or strength, is a measure of the effectiveness of a password in resisting guessing and brute-force attacks. Password length is one factor of several that helps to determine strength and how long it takes to crack a password. The shorter the password is, the lower the number of possible combinations that need to be tested before the password is compromised. Use of more characters in a password helps to exponentially increase the time and/or resources required to compromise the password.

Set Password Minimum Length in login.defs

To specify password length requirements for new accounts, edit the file /etc/login.defs and add or correct the following lines:

PASS_MIN_LEN LENGTH

The DoD requirement is 14. If a program consults /etc/login.defs and also another PAM module (such as pam_cracklib) during a password change operation, then the most restrictive must be satisfied. See PAM section for more information about enforcing password quality requirements.

SRG-OS-000079

CCI-000206

The operating system must obscure feedback of authentication information during the authentication process to protect the information from possible exploitation/use by unauthorized individuals.

To prevent the compromise of authentication information, such as passwords during the authentication process, the feedback from the operating system shall not provide any information allowing an unauthorized user to compromise the authentication mechanism. Obfuscation of user provided information that is typed into the system is a method used when addressing this risk. For example, displaying asterisks when a user types in a password, is an example of obscuring feedback of authentication information.

Product Meets this Requirement

Red Hat Enterprise Linux meets this requirement by design.

SRG-OS-000080

CCI-000213

The operating system must enforce approved authorizations for logical access to the system in accordance with applicable policy.

Strong access controls are critical to securing data. Access control policies (e.g., identity-based policies, role-based policies, attribute-based policies) and access enforcement mechanisms (e.g., access control lists, access control matrices, cryptography) must be employed by the operating system when applicable to control access between users (or processes acting on behalf of users) and objects (e.g., devices, files, records, processes, programs, domains) in the operating system.

Set Boot Loader Password

The grub boot loader should have password protection enabled to protect boot-time settings. To do so, select a password and then generate a hash from it by running:

# grub-crypt --sha-512

You will then be prompted to enter a password. Insert the following line into /etc/grub.conf immediately after the header comments. (Use the output from grub-crypt as the value of password-hash):

password --encrypted password-hash

Require Authentication for Single User Mode

Single-user mode is intended as a system recovery method, providing a single user root access to the system by providing a boot option at startup. By default, no authentication is performed if single-user mode is selected.

To require entry of the root password even if the system is started in single-user mode, add or correct the following line in the file /etc/sysconfig/init:

SINGLE=/sbin/sulogin

SRG-OS-000081

CCI-000218

The operating system, when transferring information between different security domains, must identify information flows by data type specification and usage.

Implementation of the Requirement is Unclear

It is unclear how to satisfy this requirement.

SRG-OS-000082

CCI-000219

The operating system, when transferring information between different security domains, must decompose information into policy-relevant subcomponents for submission to policy enforcement mechanisms.

Implementation of the Requirement is Unclear

It is unclear how to satisfy this requirement.

SRG-OS-000083

CCI-000221

The operating system must enforce security policies regarding information on interconnected systems.

The operating system enforces approved authorizations for controlling the flow of information within the system and between interconnected systems in accordance with applicable policy. Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to the information. Transferring information between interconnected information systems of differing security policies introduces risk that such transfers violate one or more policies. While security policy violations may not be absolutely prohibited, policy guidance from information owners/stewards is implemented at the policy enforcement point between the interconnected systems. Specific architectural solutions are mandated, when required, to reduce the potential for undiscovered vulnerabilities.

Guidance Does Not Meet this Requirement Due to Impracticality or Scope

The guidance does not meet this requirement. The requirement is impractical or out of scope.

SRG-OS-000084

CCI-000223

The operating system must bind security attributes to information to facilitate information flow policy enforcement.

Operating system application enforces approved authorizations for controlling the flow of information within the system and between interconnected systems in accordance with applicable policy. Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to the information. Attribution is a critical component of a security concept of operations. The ability to identify source and destination points for information flowing in an information system, allows forensic reconstruction of events when required, and increases policy compliance by attributing policy violations to specific organizations/individuals. Binding security attributes to information allows policy enforcement mechanisms to act on the information and enforce policy.

Product Meets this Requirement

Red Hat Enterprise Linux meets this requirement by design.

SRG-OS-000085

CCI-000224

The operating system must track problems associated with the security attribute binding.

The operating system enforces approved authorizations for controlling the flow of information within the system and between interconnected systems in accordance with applicable policy. Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to the information. Attribution is a critical component of a security concept of operations. Attribution (e.g., the ability to attribute actions to certain individuals) is a critical component of a security concept of operations. The ability to identify source and destination points for information flowing in an information system, allows forensic reconstruction of events when required, and increases policy compliance by attributing policy violations to specific organizations/individuals. In order to identify when problems occur when binding security attributes to information, tracking problems and/or auditing of these events must occur.

Ensure All Files Are Owned by a User

If any files are not owned by a user, then the cause of their lack of ownership should be investigated. Following this, the files should be deleted or assigned to an appropriate user.

Ensure All Files Are Owned by a Group

If any files are not owned by a group, then the cause of their lack of group-ownership should be investigated. Following this, the files should be deleted or assigned to an appropriate group.

SRG-OS-000086

CCI-000226

The operating system must provide the capability for a privileged administrator to configure organization-defined security policy filters to support different security policies.

In order to control changes in policy, a privileged administrator must be able to change policy filters to support different security policies.

Product Meets this Requirement

Red Hat Enterprise Linux meets this requirement by design.

SRG-OS-000087

CCI-000345

The operating system must enforce logical access restrictions associated with changes to the information system.

When dealing with access restrictions pertaining to change control, it should be noted that any changes to the hardware, software, and/or firmware components of the information system can potentially have significant effects on the overall security of the system. Accordingly, only qualified and authorized individuals should be allowed to obtain access to operating system for the purpose of initiating changes, including upgrades and modifications.

Product Meets this Requirement

Red Hat Enterprise Linux meets this requirement by design.

SRG-OS-000088

CCI-000346

The operating system must employ automated mechanisms to enforce access restrictions.

When dealing with access restrictions pertaining to change control, it should be noted that, any changes to the hardware, software, and/or firmware components of the information system and/or application can potentially have significant effects on the overall security of the system. Accordingly, only qualified and authorized individuals should be allowed to obtain access to information system components for the purposes of initiating changes, upgrades, and modifications.

Product Meets this Requirement

Red Hat Enterprise Linux meets this requirement by design.

SRG-OS-000089

CCI-000347

The operating system must employ automated mechanisms to support auditing of the enforcement actions.

Any changes to the hardware, software, and/or firmware components of the information system and/or application can potentially have significant effects on the overall security of the system. Accordingly, only qualified and authorized individuals are allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications. Auditing this information is critical to both the configuration management process and in the event of an intrusion.

Configure auditd Rules for Comprehensive Auditing

Tracing of arbitrary system calls (identified by name or number) on entry or exit.
Filtering by PID, UID, call success, system call argument (with some limitations), etc.
Monitoring of specific files for modifications to the file’s contents or metadata.

# service auditd restart

SRG-OS-000090

CCI-000352

The operating system must prevent the installation of organization-defined critical software programs that are not signed with a certificate that is recognized and approved by the organization.

Any changes to the hardware, software, and/or firmware components of the information system and/or application can potentially have significant effects on the overall security of the system. Accordingly, software defined by the organization as critical software must be signed with a certificate that is recognized and approved by the organization.

Ensure gpgcheck Enabled In Main Yum Configuration

The gpgcheck option should be used to ensure that checking of an RPM package’s signature always occurs prior to its installation. To configure yum to check package signatures before installing them, ensure that the following line appears in /etc/yum.conf in the [main] section:

gpgcheck=1

Ensure gpgcheck Enabled For All Yum Package Repositories

To ensure that signature checking is not disabled for any repos, remove any lines from files in /etc/yum.repos.d of the form:

gpgcheck=0

SRG-OS-000091

CCI-000354

The operating system must enforce a two-person rule for changes to organization-defined information system components and system-level information.

Regarding access restrictions for changes made to organization-defined information system components and system level information. Any changes to the hardware, software, and/or firmware components of the operating system can potentially have significant effects on the overall security of the system. Accordingly, only qualified and authorized individuals are allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications. A two person rule requires two separate individuals acknowledge and approve those changes. Two person rule for changes to critical operating system components helps to reduce risks pertaining to availability and integrity.

Guidance Does Not Meet this Requirement Due to Impracticality or Scope

The guidance does not meet this requirement. The requirement is impractical or out of scope.

SRG-OS-000092

CCI-000371

The operating system must employ automated mechanisms to centrally apply configuration settings.

Configuration settings are the configurable security-related parameters of operating system. Security-related parameters are those parameters impacting the security state of the system including parameters related to meeting other security control requirements. Rather than visiting each and every system when making configuration changes, organizations will employ automated tools that can make changes across all systems. This greatly increases efficiency and manageability of applications in a large scale environment.

Guidance Does Not Meet this Requirement Due to Impracticality or Scope

The guidance does not meet this requirement. The requirement is impractical or out of scope.

SRG-OS-000093

CCI-000372

The operating system must employ automated mechanisms to centrally verify configuration settings.

Configuration settings are the configurable security-related parameters of information technology products that are part of the information system. Security-related parameters are those parameters impacting the security state of the system including parameters related to meeting other security control requirements. Rather than visiting each and every system when verifying configuration changes, organizations will employ automated tools that can make changes across all systems. This greatly increases efficiency and manageability of applications in a large scale environment.

Guidance Does Not Meet this Requirement Due to Impracticality or Scope

The guidance does not meet this requirement. The requirement is impractical or out of scope.

SRG-OS-000094

CCI-000374

The operating system must employ automated mechanisms to respond to unauthorized changes to organization-defined configuration settings.

Configuration settings are the configurable security-related parameters of information technology products that are part of the information system. Security-related parameters are those parameters impacting the security state of the system including parameters related to meeting other security control requirements. Responses to unauthorized changes to configuration settings can include, alerting designated organizational personnel, restoring mandatory/organization-defined configuration settings, or in the extreme case, halting affected information system processing.

Verify Integrity with AIDE AIDE conducts integrity checks by comparing information about files with previously-gathered information. Ideally, the AIDE database should be created immediately after your system is built, and before the system is connected to any network. AIDE is highly configurable, with further configuration information located in /usr/share/doc/aide-VERSION

Configure auditd Rules for Comprehensive Auditing

Tracing of arbitrary system calls (identified by name or number) on entry or exit.
Filtering by PID, UID, call success, system call argument (with some limitations), etc.
Monitoring of specific files for modifications to the file’s contents or metadata.

# service auditd restart

SRG-OS-000095

CCI-000381

The operating system must be configured to provide essential capabilities.

Operating systems are capable of providing a wide variety of functions and services. Some of the functions and services, provided by default, may not be necessary to support essential organizational operations (e.g., key missions, functions) and will reduce the attack surface of the operating system.

SRG-OS-000096

CCI-000382

The operating system must configure the information system to specifically prohibit or restrict the use of organization-defined functions, ports, protocols, and/or services.

Operating systems are capable of providing a wide variety of functions and services. Some of the functions and services, provided by default, may not be necessary to support essential organizational operations (e.g., key missions, functions) or may present unacceptable risk into the information system environment.

Disable Automatic Bug Reporting Tool (abrtd)

The Automatic Bug Reporting Tool (abrtd) daemon collects and reports crash data when an application crash is detected. Using a variety of plugins, abrtd can email crash reports to system administrators, log crash reports to files, or forward crash reports to a centralized issue tracking system such as RHTSupport. The abrtd service can be disabled with the following command:

# chkconfig abrtd off

Disable Advanced Configuration and Power Interface (acpid)

The Advanced Configuration and Power Interface Daemon (acpid) dispatches ACPI events (such as power/reset button depressed) to userspace programs. The acpid service can be disabled with the following command:

# chkconfig acpid off

Disable At Service (atd)

The at and batch commands can be used to schedule tasks that are meant to be executed only once. This allows delayed execution in a manner similar to cron, except that it is not recurring. The daemon atd keeps track of tasks scheduled via at and batch, and executes them at the specified time. The atd service can be disabled with the following command:

# chkconfig atd off

Disable Certmonger Service (certmonger)

Certmonger is a D-Bus based service that attempts to simplify interaction with certifying authorities on networks which use public-key infrastructure. It is often combined with Red Hat's IPA (Identity Policy Audit) security information management solution to aid in the management of certificates. The certmonger service can be disabled with the following command:

# chkconfig certmonger off

Disable Control Group Config (cgconfig)

Control groups allow an administrator to allocate system resources (such as CPU, memory, network bandwidth, etc) among a defined group (or groups) of processes executing on a system. The cgconfig daemon starts at boot and establishes the predefined control groups. The cgconfig service can be disabled with the following command:

# chkconfig cgconfig off

Disable Control Group Rules Engine (cgred)

The cgred service moves tasks into control groups according to parameters set in the /etc/cgrules.conf configuration file. The cgred service can be disabled with the following command:

# chkconfig cgred off

Disable CPU Speed (cpuspeed)

The cpuspeed service can adjust the clock speed of supported CPUs based upon the current processing load thereby conserving power and reducing heat. The cpuspeed service can be disabled with the following command:

# chkconfig cpuspeed off

Disable Hardware Abstraction Layer Service (haldaemon)

The Hardware Abstraction Layer Daemon (haldaemon) collects and maintains information about the system's hardware configuration. This service is required on a workstation running a desktop environment, and may be necessary on any system which deals with removable media or devices. The haldaemon service can be disabled with the following command:

# chkconfig haldaemon off

Disable KDump Kernel Crash Analyzer (kdump)

The kdump service provides a kernel crash dump analyzer. It uses the kexec system call to boot a secondary kernel ("capture" kernel) following a system crash, which can load information from the crashed kernel for analysis. The kdump service can be disabled with the following command:

# chkconfig kdump off

Disable Software RAID Monitor (mdmonitor)

The mdmonitor service is used for monitoring a software RAID (hardware RAID setups do not use this service). The mdmonitor service can be disabled with the following command:

# chkconfig mdmonitor off

Disable D-Bus IPC Service (messagebus)

D-Bus provides an IPC mechanism used by a growing list of programs, such as those used for Gnome, Bluetooth, and Avahi. Due to these dependencies, disabling D-Bus may not be practical for many systems. The messagebus service can be disabled with the following command:

# chkconfig messagebus off

Disable Network Console (netconsole)

The netconsole service is responsible for loading the netconsole kernel module, which logs kernel printk messages over UDP to a syslog server. This allows debugging of problems where disk logging fails and serial consoles are impractical. The netconsole service can be disabled with the following command:

# chkconfig netconsole off

Disable ntpdate Service (ntpdate)

The ntpdate service sets the local hardware clock by polling NTP servers when the system boots. It synchronizes to the NTP servers listed in /etc/ntp/step-tickers or /etc/ntp.conf and then sets the local hardware clock to the newly synchronized system time. The ntpdate service can be disabled with the following command:

# chkconfig ntpdate off

Disable Odd Job Daemon (oddjobd)

The oddjobd service exists to provide an interface and access control mechanism through which specified privileged tasks can run tasks for unprivileged client applications. Communication with oddjobd through the system message bus. The oddjobd service can be disabled with the following command:

# chkconfig oddjobd off

Disable Portreserve (portreserve)

The portreserve service is a TCP port reservation utility that can be used to prevent portmap from binding to well known TCP ports that are required for other services. The portreserve service can be disabled with the following command:

# chkconfig portreserve off

Disable Apache Qpid (qpidd)

The qpidd service provides high speed, secure, guaranteed delivery services. It is an implementation of the Advanced Message Queuing Protocol. By default the qpidd service will bind to port 5672 and listen for connection attempts. The qpidd service can be disabled with the following command:

# chkconfig qpidd off

Disable Quota Netlink (quota_nld)

The quota_nld service provides notifications to users of disk space quota violations. It listens to the kernel via a netlink socket for disk quota violations and notifies the appropriate user of the violation using D-Bus or by sending a message to the terminal that the user has last accessed. The quota_nld service can be disabled with the following command:

# chkconfig quota_nld off

Disable Network Router Discovery Daemon (rdisc)

The rdisc service implements the client side of the ICMP Internet Router Discovery Protocol (IRDP), which allows discovery of routers on the local subnet. If a router is discovered then the local routing table is updated with a corresponding default route. By default this daemon is disabled. The rdisc service can be disabled with the following command:

# chkconfig rdisc off

Disable Red Hat Network Service (rhnsd)

The Red Hat Network service automatically queries Red Hat Network servers to determine whether there are any actions that should be executed, such as package updates. This only occurs if the system was registered to an RHN server or satellite and managed as such. The rhnsd service can be disabled with the following command:

# chkconfig rhnsd off

Disable Red Hat Subscription Manager Daemon (rhsmcertd)

The Red Hat Subscription Manager (rhsmcertd) periodically checks for changes in the entitlement certificates for a registered system and updates it accordingly. The rhsmcertd service can be disabled with the following command:

# chkconfig rhsmcertd off

Disable Cyrus SASL Authentication Daemon (saslauthd)

The saslauthd service handles plaintext authentication requests on behalf of the SASL library. The service isolates all code requiring superuser privileges for SASL authentication into a single process, and can also be used to provide proxy authentication services to clients that do not understand SASL based authentication. The saslauthd service can be disabled with the following command:

# chkconfig saslauthd off

Disable SMART Disk Monitoring Service (smartd)

SMART (Self-Monitoring, Analysis, and Reporting Technology) is a feature of hard drives that allows them to detect symptoms of disk failure and relay an appropriate warning. The smartd service can be disabled with the following command:

# chkconfig smartd off

Disable System Statistics Reset Service (sysstat)

The sysstat service resets various I/O and CPU performance statistics to zero in order to begin counting from a fresh state at boot time. The sysstat service can be disabled with the following command:

# chkconfig sysstat off

SRG-OS-000097

CCI-000386

The operating system must employ automated mechanisms to prevent program execution in accordance with the organization defined specifications.

Operating systems are capable of providing a wide variety of functions and services. Execution must be disabled based on organization defined specifications.

Product Meets this Requirement

Red Hat Enterprise Linux meets this requirement by design.

SRG-OS-000098

CCI-000416

The operating system must employ automated mechanisms, per organization-defined frequency, to detect the addition of unauthorized components/devices into the operating system.

Baselining of systems allows for a mechanism to determine when unauthorized additions or changes are made. It also ensures the appropriate patch management is in place for the components on the system.

Configure Periodic Execution of AIDE

AIDE should be executed on a periodic basis to check for changes. To implement a daily execution of AIDE at 4:05am using cron, add the following line to /etc/crontab:

05 4 * * * root /usr/sbin/aide --check

AIDE can be executed periodically through other means; this is merely one example.

SRG-OS-000099

CCI-000535

The operating system must conduct backups of user-level information contained in the operating system per organization-defined frequency to conduct backups consistent with recovery time and recovery point objectives.

Operating system backup is a critical step in maintaining data assurance and availability. User-level information is data generated by information system and/or application users. Backups shall be consistent with organizational recovery time and recovery point objectives.

Guidance Does Not Meet this Requirement Due to Impracticality or Scope

The guidance does not meet this requirement. The requirement is impractical or out of scope.

SRG-OS-000100

CCI-000537

The operating system must conduct backups of system-level information contained in the information system per organization-defined frequency to conduct backups that are consistent with recovery time and recovery point objectives.

Operating system backup is a critical step in maintaining data assurance and availability. System-level information includes system-state information, operating system and application software, and licenses. Backups must be consistent with organizational recovery time and recovery point objectives.

Guidance Does Not Meet this Requirement Due to Impracticality or Scope

The guidance does not meet this requirement. The requirement is impractical or out of scope.

SRG-OS-000101

CCI-000539

The operating system must conduct backups of operating system documentation including security-related documentation per organization-defined frequency to conduct backups that is consistent with recovery time and recovery point objectives.

Operating system backup is a critical step in maintaining data assurance and availability. Information system and security related documentation contains information pertaining to system configuration and security settings. Backups shall be consistent with organizational recovery time and recovery point objectives.

Guidance Does Not Meet this Requirement Due to Impracticality or Scope

The guidance does not meet this requirement. The requirement is impractical or out of scope.

SRG-OS-000102

CCI-000553

The operating system must implement transaction recovery for transaction-based systems.

Recovery and reconstitution constitutes executing an operating system contingency plan comprised of activities to restore essential missions and business functions. Transaction rollback and transaction journaling are examples of mechanisms supporting transaction recovery. While this is typically a database function, operating systems could be transactional in nature with respect to file processing.

Product Does Not Meet this Requirement Due to Impracticality or Scope

The product does not meet this requirement. The requirement is impractical or out of scope.

SRG-OS-000103

CCI-000663

The operating system must enforce explicit rules governing the installation of software by users.

The operating system must enforce software installation by users based upon what types of software installations are permitted (e.g., updates and security patches to existing software) and what types of installations are prohibited (e.g., software whose pedigree with regard to being potentially malicious is unknown or suspect) by the organization.

Ensure gpgcheck Enabled In Main Yum Configuration

gpgcheck=1

Ensure gpgcheck Enabled For All Yum Package Repositories

To ensure that signature checking is not disabled for any repos, remove any lines from files in /etc/yum.repos.d of the form:

gpgcheck=0

SRG-OS-000104

CCI-000764

The operating system must uniquely identify and must authenticate organizational users (or processes acting on behalf of organizational users).

To assure accountability and prevent unauthorized access, organizational users shall be identified and authenticated. Organizational users include employees or individuals the organization deems to have equivalent status of employees (e.g., contractors, guest researchers, individuals from allied nations). Users (and any processes acting on behalf of users) are uniquely identified and authenticated for all accesses other than those accesses explicitly identified and documented by the organization outlining specific user actions that can be performed on the information system without identification or authentication.

Ensure Insecure File Locking is Not Allowed By default the NFS server requires secure file-lock requests, which require credentials from the client in order to lock a file. Most NFS clients send credentials with file lock requests, however, there are a few clients that do not send credentials when requesting a file-lock, allowing the client to only be able to lock world-readable files. To get around this, the insecure_locks option can be used so these clients can access the desired export. This poses a security risk by potentially allowing the client access to data for which it does not have authorization. Remove any instances of the insecure_locks option from the file /etc/exports.

SRG-OS-000105

CCI-000765

The operating system must use multifactor authentication for network access to privileged accounts.

Using Smart Cards for System Login

The use of smart cards, like Common Access Cards (CAC), for system login provides stronger, two-factor authentication than using a username/password. Smart cards take advantage of Public Key Infrastructure (PKI) to store encrypted digital certificates that can be used to authenticate the card owner.

In Red Hat Enterprise Linux servers and workstations, smart card login is not enabled by default and must be enabled in the system settings. Detailed procedures on how to configure a system to use smart card authentication for login can be found in the Red Hat Documentation web site:

https://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Managing_Smart_Cards/enabling-smart-card-login.html

It is recommended to use smart cards wherever feasible as part of a multifactor authentication system.

SRG-OS-000106

CCI-000766

The operating system must use multifactor authentication for network access to non-privileged accounts.

Using Smart Cards for System Login

https://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Managing_Smart_Cards/enabling-smart-card-login.html

It is recommended to use smart cards wherever feasible as part of a multifactor authentication system.

SRG-OS-000107

CCI-000767

The operating system must use multifactor authentication for local access to privileged accounts.

Using Smart Cards for System Login

https://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Managing_Smart_Cards/enabling-smart-card-login.html

It is recommended to use smart cards wherever feasible as part of a multifactor authentication system.

SRG-OS-000108

CCI-000768

The operating system must use multifactor authentication for local access to non-privileged accounts.

Using Smart Cards for System Login

https://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Managing_Smart_Cards/enabling-smart-card-login.html

It is recommended to use smart cards wherever feasible as part of a multifactor authentication system.

SRG-OS-000109

CCI-000770

The operating system must require individuals to be authenticated with an individual authenticator prior to using a group authenticator.

To assure individual accountability and prevent unauthorized access, organizational users shall be individually identified and authenticated. Users (and any processes acting on behalf of users) need to be uniquely identified and authenticated for all accesses other than those accesses explicitly identified and documented by the organization which outlines specific user actions that can be performed on the operating system without identification or authentication. Requiring individuals to be authenticated with an individual authenticator prior to using a group authenticator allows for traceability of actions, as well as, adding an additional level of protection of the actions that can be taken with group account knowledge.

Restrict Root Logins Direct root logins should be allowed only for emergency use. In normal situations, the administrator should access the system via a unique unprivileged account, and then use su or sudo to execute privileged commands. Discouraging administrators from accessing the root account directly ensures an audit trail in organizations with multiple administrators. Locking down the channels through which root can connect directly also reduces opportunities for password-guessing against the root account. The login program uses the file /etc/securetty to determine which interfaces should allow root logins. The virtual devices /dev/console and /dev/tty* represent the system consoles (accessible via the Ctrl-Alt-F1 through Ctrl-Alt-F6 keyboard sequences on a default installation). The default securetty file also contains /dev/vc/*. These are likely to be deprecated in most environments, but may be retained for compatibility. Root should also be prohibited from connecting via network protocols. Other sections of this document include guidance describing how to prevent root from logging in via SSH.

Restrict Virtual Console Root Logins

To restrict root logins through the (deprecated) virtual console devices, ensure lines of this form do not appear in /etc/securetty:

vc/1
vc/2
vc/3
vc/4

Restrict Serial Port Root Logins

To restrict root logins on serial ports, ensure lines of this form do not appear in /etc/securetty:

ttyS0
ttyS1

Disable SSH Root Login

The root user should never be allowed to login to a system directly over a network. To disable root login via SSH, add or correct the following line:

PermitRootLogin no

SRG-OS-000110

CCI-000771

The operating system must use multifactor authentication for network access to privileged accounts where one of the factors is provided by a device separate from the information system being accessed.

Multifactor authentication is defined as using two or more factors to achieve authentication. Factors include: (i) something you know (e.g., password/PIN); (ii) something you have (e.g., cryptographic identification device, token); or (iii) something you are (e.g., biometric). A privileged account is defined as an information system account with authorizations of a privileged user. When one of the authentication factors is provided by a device separate from the system that is gaining access, this is referred to as Out of Band 2 Factor Authentication (OOB2FA). OOB2FA employs separate communication channels at least one of which is independently maintained and trusted to authenticate an end user. One channel could be a mobile device that is registered to the user. Upon a logon attempt, the system sends instructions to the device in the form of on-screen prompts instructing the user how to complete the login process.

Using Smart Cards for System Login

https://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Managing_Smart_Cards/enabling-smart-card-login.html

It is recommended to use smart cards wherever feasible as part of a multifactor authentication system.

SRG-OS-000111

CCI-000772

The operating system must use multifactor authentication for network access to non-privileged accounts where one of the factors is provided by a device separate from the operating system being accessed.

Using Smart Cards for System Login

https://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Managing_Smart_Cards/enabling-smart-card-login.html

It is recommended to use smart cards wherever feasible as part of a multifactor authentication system.

SRG-OS-000112

CCI-000774

The operating system must use organization-defined replay-resistant authentication mechanisms for network access to privileged accounts.

An authentication process resists replay attacks if it is impractical to achieve a successful authentication by recording and replaying a previous authentication message. Techniques used to address this include protocols using challenges (e.g., TLS, WS_Security), time synchronous, or challenge-response one-time authenticators.

Allow Only SSH Protocol 2

Only SSH protocol version 2 connections should be permitted. The default setting in /etc/ssh/sshd_config is correct, and can be verified by ensuring that the following line appears:

Protocol 2

SRG-OS-000113

CCI-000776

The operating system must use organization-defined replay-resistant authentication mechanisms for network access to non-privileged accounts.

Allow Only SSH Protocol 2

Only SSH protocol version 2 connections should be permitted. The default setting in /etc/ssh/sshd_config is correct, and can be verified by ensuring that the following line appears:

Protocol 2

Configure LDAP to Use TLS For All Transactions

Configure LDAP to enforce TLS use. First, edit the file /etc/pam_ldap.conf, and add or correct the following lines:

ssl start_tls

Then review the LDAP server and ensure TLS has been configured.

Configure Certificate Directives for LDAP Use of TLS

Ensure a copy of the site's CA certificate has been placed in the file /etc/pki/tls/CA/cacert.pem. Configure LDAP to enforce TLS use and to trust certificates signed by the site's CA. First, edit the file /etc/pam_ldap.conf, and add or correct either of the following lines:

tls_cacertdir /etc/pki/tls/CA

tls_cacertfile /etc/pki/tls/CA/cacert.pem

Then review the LDAP server and ensure TLS has been configured.

SRG-OS-000114

CCI-000778

The operating system must uniquely identify and authenticate an organization-defined list of specific and/or types of devices before establishing a connection.

Configure LDAP to Use TLS For All Transactions

Configure LDAP to enforce TLS use. First, edit the file /etc/pam_ldap.conf, and add or correct the following lines:

ssl start_tls

Then review the LDAP server and ensure TLS has been configured.

Configure Certificate Directives for LDAP Use of TLS

tls_cacertdir /etc/pki/tls/CA

tls_cacertfile /etc/pki/tls/CA/cacert.pem

Then review the LDAP server and ensure TLS has been configured.

SRG-OS-000115

CCI-000779

The operating system must authenticate devices before establishing remote network connections using bidirectional cryptographically based authentication between devices.

Device authentication is a solution enabling an organization to manage devices. It is an additional layer of authentication ensuring only specific pre-authorized devices operated by specific pre-authorized users can access the network. Device authentication requires unique identification and authentication that may be defined by type, by specific device, or by a combination of type and device as deemed appropriate by the organization. Bidirectional authentication provides a means for both connecting parties to mutually authenticate one another and cryptographically based authentication provides a secure means of authenticating without the use of clear text passwords.

SRG-OS-000116

CCI-000780

The operating system must authenticate devices before establishing wireless network connections using bidirectional cryptographically based authentication between devices.

Guidance Does Not Meet this Requirement Due to Impracticality or Scope

The guidance does not meet this requirement. The requirement is impractical or out of scope.

SRG-OS-000117

CCI-000781

The operating system must authenticate devices before establishing network connections using bidirectional cryptographically based authentication between devices.

Device authentication is a solution enabling an organization to manage both users and devices. It is an additional layer of authentication ensuring only specific pre-authorized devices operated by specific pre-authorized users can access the network. Device authentication requires unique identification and authentication that may be defined by type, by specific device, or by a combination of type and device as deemed appropriate by the organization. Bidirectional authentication provides a means for both connecting parties to mutually authenticate one another and cryptographically based authentication provides a secure means of authenticating without the use of clear text passwords.

SRG-OS-000118

CCI-000795

The operating system must manage information system identifiers for users and devices by disabling the user identifier after an organization-defined time period of inactivity.

Inactive user accounts pose a risk to systems and applications. Owners of inactive accounts will not notice if unauthorized access to their user account has been obtained. Attackers able to exploit an inactive account can potentially obtain and maintain undetected access to the operating system. Operating systems need to track periods of user inactivity and disable accounts after an organization-defined period of inactivity. Such a process greatly reduces the risk that accounts will be misused, hijacked, or data compromised.

Set Account Expiration Following Inactivity

INACTIVE=NUM_DAYS

SRG-OS-000119

CCI-000802

The operating system must dynamically manage identifiers, attributes, and associated access authorizations.

Dynamic management of identities and association of attributes and privileges with these identities are anticipated and provisioned. Pre-established trust relationships and mechanisms with appropriate authorities to validate identities and related credentials are essential.

Enable SELinux

Edit the file /etc/selinux/config. Add or correct the following lines:

SELINUX=enforcing
SELINUXTYPE=targeted

Edit the file /etc/grub.conf. Ensure that the following arguments DO NOT appear on any kernel command line in the file:

selinux=0
enforcing=0

touch
/.autorelabel

SRG-OS-000120

CCI-000803

The operating system must use mechanisms for authentication to a cryptographic module meeting the requirements of applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance for such authentication.

Encryption is only as good as the encryption modules utilized. Unapproved cryptographic module algorithms cannot be verified, and cannot be relied upon to provide confidentiality or integrity, and DoD data may be compromised due to weak algorithms. Applications utilizing encryption are required to use approved encryption modules meeting the requirements of applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. FIPS 140-2 is the current standard for validating cryptographic modules and NSA Type-X (where X=1, 2, 3, 4) products are NSA certified hardware based encryption modules.

Use Only Approved Ciphers

Ciphers aes128-ctr,aes192-ctr,aes256-ctr

SRG-OS-000121

CCI-000804

The operating system must uniquely identify and must authenticate non-organizational users (or processes acting on behalf of non-organizational users).

Non-organizational users include all operating system users other than organizational users which include employees or individuals the organization deems to have equivalent status of employees (e.g., contractors, guest researchers, individuals from allied nations). Non-organizational users shall be uniquely identified and authenticated for all accesses other than those accesses explicitly identified and documented by the organization when related to the use of anonymous access.

Product Meets this Requirement

Red Hat Enterprise Linux meets this requirement by design.

SRG-OS-000122

CCI-000831

The operating system must implement a configurable capability to automatically disable the operating system if any of the organization-defined lists of security violations are detected.

When responding to a security incident a capability must exist allowing authorized personnel to disable a particular system if the system exhibits a security violation and the organization determines such an action is warranted. Organizations shall define a list of security violations warranting an immediate disabling of a system.

Enable auditd Service

# chkconfig auditd on

SRG-OS-000123

CCI-001682

The operating system must automatically terminate emergency accounts after an organization-defined time period for each type of account.

When emergency accounts are created, there is a risk that the emergency account may remain in place and active after the need for the account no longer exists. To address this, in the event emergency accounts are required, accounts that are designated as temporary in nature must be automatically terminated after an organization-defined time period. Such a process and capability greatly reduces the risk that accounts will be misused, hijacked, or data compromised.

Guidance Does Not Meet this Requirement Due to Impracticality or Scope

The guidance does not meet this requirement. The requirement is impractical or out of scope.

SRG-OS-000124

CCI-000872

The operating system must employ automated mechanisms to restrict the use of maintenance tools to authorized personnel only.

The intent of this control is to address the security-related issues arising from the software brought into the operating system specifically for diagnostic and repair actions (e.g., a software packet sniffer introduced for the purpose of a particular maintenance activity). Due to the nature of the tools, these tools must be restricted to authorized personnel only.

Product Meets this Requirement

Red Hat Enterprise Linux meets this requirement by design.

SRG-OS-000125

CCI-000877

The operating system must employ strong identification and authentication techniques in the establishment of non-local maintenance and diagnostic sessions.

Non-local maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the Internet) or an internal network. The act of managing systems includes the ability to access system configuration details, diagnostic information, user information, as well as installation of software.

SSH Server The SSH protocol is recommended for remote login and remote file transfer. SSH provides confidentiality and integrity for data exchanged between two systems, as well as server authentication, through the use of public key cryptography. The implementation included with the system is called OpenSSH, and more detailed documentation is available from its website, http://www.openssh.org. Its server program is called sshd and provided by the RPM package openssh-server.

SRG-OS-000126

CCI-000879

The operating system must terminate all sessions and network connections when non-local maintenance is completed.

Non-local maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the Internet) or an internal network. The operating system needs to ensure all sessions and network connections are terminated when non-local maintenance is completed.

Set SSH Idle Timeout Interval

SSH allows administrators to set an idle timeout interval. After this interval has passed, the idle user will be automatically logged out.

To set an idle timeout interval, edit the following line in /etc/ssh/sshd_config as follows:

ClientAliveInterval interval

The timeout interval is given in seconds. To have a timeout of 15 minutes, set interval to 900.

If a shorter timeout has already been set for the login shell, that value will preempt any SSH setting made here. Keep in mind that some processes may stop SSH from correctly detecting that the user is idle.

SRG-OS-000127

CCI-000880

The operating system must audit non-local maintenance and diagnostic sessions.

Non-local maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the Internet) or an internal network, in order to conduct system diagnostics. For traceability of maintenance, logging events associated with a non-local administrative access or diagnostic session must be performed.

Configure auditd Rules for Comprehensive Auditing

Tracing of arbitrary system calls (identified by name or number) on entry or exit.
Filtering by PID, UID, call success, system call argument (with some limitations), etc.
Monitoring of specific files for modifications to the file’s contents or metadata.

# service auditd restart

SRG-OS-000128

CCI-000884

The operating system must protect non-local maintenance sessions through the use of a strong authenticator tightly bound to the user.

Non-local maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the Internet) or an internal network. Identification and authentication techniques used in the establishment of non-local maintenance and diagnostic sessions must be accomplished via strong authenticator (i.e., two factor authentication).

Using Smart Cards for System Login

https://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Managing_Smart_Cards/enabling-smart-card-login.html

It is recommended to use smart cards wherever feasible as part of a multifactor authentication system.

SRG-OS-000129

CCI-000888

The operating system must employ cryptographic mechanisms to protect the integrity and confidentiality of non-local maintenance and diagnostic communications.

Non-local maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the Internet) or an internal network. To protect the integrity and confidentiality of non-local maintenance and diagnostics, all packets associated with these sessions must be encrypted.

SRG-OS-000130

CCI-001009

The operating system must use cryptographic mechanisms to protect and restrict access to information on portable digital media.

When data is written to portable digital media, such as thumb drives, floppy diskettes, compact disks, and magnetic tape, etc., there is risk of data loss. An organizational assessment of risk guides the selection of media and associated information contained on the media requiring restricted access. Organizations need to document in policy and procedures the media requiring restricted access, individuals authorized to access the media, and the specific measures taken to restrict access. Fewer protection measures are needed for media containing information determined by the organization to be in the public domain, to be publicly releasable, or to have limited or no adverse impact if accessed by other than authorized personnel. In these situations, it is assumed the physical access controls where the media resides provide adequate protection. The employment of cryptography is at the discretion of the information owner/steward. When the organization has determined the risk warrants it, data written to portable digital media must be encrypted.

A New Policy/Manual Rule is Needed

A new Rule needs to be created in the scap-security-guide content.

SRG-OS-000131

CCI-001019

The operating system must employ cryptographic mechanisms to protect information in storage.

When data is written to digital media, such as hard drives, mobile computers, external/removable hard drives, personal digital assistants, flash/thumb drives, etc., there is risk of data loss and data compromise. An organizational assessment of risk guides the selection of media and associated information contained on the media requiring restricted access. Organizations need to document in policy and procedures the media requiring restricted access, individuals authorized to access the media, and the specific measures taken to restrict access. Fewer protection measures are needed for media containing information determined by the organization to be in the public domain, to be publicly releasable, or to have limited or no adverse impact if accessed by other than authorized personnel. In these situations, it is assumed the physical access controls where the media resides provide adequate protection. As part of a defense-in-depth strategy, the organization considers routinely encrypting information at rest on selected secondary storage devices. The employment of cryptography is at the discretion of the information owner/steward. The selection of the cryptographic mechanisms used is based upon maintaining the confidentiality and integrity of the information.

A New Policy/Manual Rule is Needed

A new Rule needs to be created in the scap-security-guide content.

SRG-OS-000132

CCI-001082

The operating system must separate user functionality (including user interface services) from operating system management functionality.

Operating system management functionality includes functions necessary to administer machine, network components, workstations, or servers, and typically requires privileged user access. The separation of user functionality from information system management functionality is either physical or logical and is accomplished by using different computers, different central processing units, different instances of the operating system, different network addresses, combinations of these methods, or other methods as appropriate. This may include isolating the administrative interface on a different domain and with additional access controls.

Product Meets this Requirement

Red Hat Enterprise Linux meets this requirement by design.

SRG-OS-000133

CCI-001083

The operating system must prevent the presentation of information system management-related functionality at an interface for general (i.e., non-privileged) users.

Operating system management functionality includes functions necessary to administer the operating, network components, workstations, or servers, and typically requires privileged user access. The separation of user functionality from information system management functionality is either physical or logical and is accomplished by using different computers, different central processing units, different instances of the operating system, different network addresses, combinations of these methods, or other methods as appropriate.

Product Meets this Requirement

Red Hat Enterprise Linux meets this requirement by design.

SRG-OS-000134

CCI-001084

The operating system must isolate security functions from nonsecurity functions.

Enable SELinux

Edit the file /etc/selinux/config. Add or correct the following lines:

SELINUX=enforcing
SELINUXTYPE=targeted

Edit the file /etc/grub.conf. Ensure that the following arguments DO NOT appear on any kernel command line in the file:

selinux=0
enforcing=0

touch
/.autorelabel

SRG-OS-000135

CCI-001086

The operating system must isolate security functions enforcing access and information flow control from both non-security functions and from other security functions.

The operating system isolates security functions from non-security functions by means of an isolation boundary (implemented via partitions and domains) controlling access to and protecting the integrity of the hardware, software, and firmware that perform those security functions.

Enable SELinux

Edit the file /etc/selinux/config. Add or correct the following lines:

SELINUX=enforcing
SELINUXTYPE=targeted

Edit the file /etc/grub.conf. Ensure that the following arguments DO NOT appear on any kernel command line in the file:

selinux=0
enforcing=0

touch
/.autorelabel

SRG-OS-000136

CCI-001087

The operating system must implement an information system isolation boundary to minimize the number of non-security functions included within the boundary containing security functions.

Enable SELinux

Edit the file /etc/selinux/config. Add or correct the following lines:

SELINUX=enforcing
SELINUXTYPE=targeted

Edit the file /etc/grub.conf. Ensure that the following arguments DO NOT appear on any kernel command line in the file:

selinux=0
enforcing=0

touch
/.autorelabel

SRG-OS-000137

CCI-001089

The operating system must implement security functions as a layered structure minimizing interactions between layers of the design and avoiding any dependence by lower layers on the functionality or correctness of higher layers.

Product Meets this Requirement

Red Hat Enterprise Linux meets this requirement by design.

SRG-OS-000138

CCI-001090

The operating system must prevent unauthorized and unintended information transfer via shared system resources.

The purpose of this control is to prevent information, including encrypted representations of information, produced by the actions of a prior user/role (or the actions of a process acting on behalf of a prior user/role) from being available to any current user/role (or current process) obtaining access to a shared system resource (e.g., registers, main memory, secondary storage) after the resource has been released back to the information system. Control of information in shared resources is also referred to as object reuse.

Enable SELinux

Edit the file /etc/selinux/config. Add or correct the following lines:

SELINUX=enforcing
SELINUXTYPE=targeted

Edit the file /etc/grub.conf. Ensure that the following arguments DO NOT appear on any kernel command line in the file:

selinux=0
enforcing=0

touch
/.autorelabel

SRG-OS-000139

CCI-001091

The operating system must not share resources used to interface with systems operating at different security levels.

The purpose of this control is to prevent information, including encrypted representations of information, produced by the actions of a prior user/role (or the actions of a process acting on behalf of a prior user/role) from being available to any current user/role (or current process) obtaining access to a shared system resource (e.g., registers, main memory, secondary storage) after the resource has been released back to the operating system. Shared resources include memory, input/output queues, and network interface cards.

Enable SELinux

Edit the file /etc/selinux/config. Add or correct the following lines:

SELINUX=enforcing
SELINUXTYPE=targeted

Edit the file /etc/grub.conf. Ensure that the following arguments DO NOT appear on any kernel command line in the file:

selinux=0
enforcing=0

touch
/.autorelabel

SRG-OS-000140

CCI-001092

The operating system must protect against or must limit the effects of the organization-defined or referenced types of Denial of Service attacks.

A variety of technologies exist to limit, or in some cases, eliminate the effects of Denial of Service attacks. Employing increased capacity combined with service redundancy may reduce the susceptibility to some Denial of Service attacks.

Set Password Retry Prompts Permitted Per-session

The pam_cracklib module's retry= parameter controls how many times a program will re-prompt a user after an incorrect password entry, on a per-session basis. To configure this, open:

/etc/pam.d/system-auth

Locate the retry= parameter, the DoD required value is 3.

Enable Kernel Parameter to Use TCP Syncookies

To set the runtime status of the net.ipv4.tcp_syncookies kernel parameter, run the following command:

# sysctl -w net.ipv4.tcp_syncookies1

Verify ip6tables Enabled

The ip6tables service can be enabled with the following command:

# chkconfig ip6tables on

Verify iptables Enabled

The iptables service can be enabled with the following command:

# chkconfig iptables on

SRG-OS-000141

CCI-001094

The operating system must restrict the ability of users to launch Denial of Service attacks against other information systems or networks.

When it comes to Denial of Service attacks (DoS), most of the attention is paid to ensuring the systems and applications are not victims of these attacks. While it is true those accountable for systems want to ensure they are not affected by a DoS attack, they also need to ensure their systems are not used to launch such an attack against others. To that extent, a variety of technologies exist to limit, or in some cases, eliminate the effects of DoS attacks.

Guidance Does Not Meet this Requirement Due to Impracticality or Scope

The guidance does not meet this requirement. The requirement is impractical or out of scope.

SRG-OS-000142

CCI-001095

The operating system must manage excess capacity, bandwidth, or other redundancy to limit the effects of information flooding types of Denial of Service attacks.

In the case of Denial of Service attacks, care must be taken when designing the operating system so as to ensure that the operating system makes the best use of system resources.

Enable Kernel Parameter to Use TCP Syncookies

To set the runtime status of the net.ipv4.tcp_syncookies kernel parameter, run the following command:

# sysctl -w net.ipv4.tcp_syncookies1

SRG-OS-000143

CCI-001096

The operating system must limit the use of resources by priority.

Priority protection helps prevent a lower-priority process from delaying or interfering with the operating system servicing any higher-priority process. Operating systems must limit potential high volume usage resources to protect against a Denial of Service.

Product Meets this Requirement

Red Hat Enterprise Linux meets this requirement by design.

SRG-OS-000144

CCI-001097

The operating system must monitor and control communications at the external boundary of the information system and at key internal boundaries within the system.

The operating system must monitor and control communications at the boundary of the operating system.

Verify ip6tables Enabled

The ip6tables service can be enabled with the following command:

# chkconfig ip6tables on

Verify iptables Enabled

The iptables service can be enabled with the following command:

# chkconfig iptables on

SRG-OS-000145

CCI-001098

The operating system must connect to external networks or information systems only through managed interfaces consisting of boundary protection devices arranged in accordance with an organizational security architecture.

The operating system must ensure traffic flows through only managed interfaces. For operating systems on the perimeter of the network (e.g., laptops connecting remotely) this helps protect the data on the endpoint.

Verify ip6tables Enabled

The ip6tables service can be enabled with the following command:

# chkconfig ip6tables on

Verify iptables Enabled

The iptables service can be enabled with the following command:

# chkconfig iptables on

SRG-OS-000146

CCI-001100

The operating system must prevent public access into an organization’s internal networks, except as appropriately mediated by managed interfaces employing boundary protection devices.

Access into an organization’s internal network and to key internal boundaries must be tightly controlled and managed. In the case of the operating system, the key boundary may be the workstation on the public internet.

Verify ip6tables Enabled

The ip6tables service can be enabled with the following command:

# chkconfig ip6tables on

Verify iptables Enabled

The iptables service can be enabled with the following command:

# chkconfig iptables on

SRG-OS-000147

CCI-001109

The operating system at managed interfaces must deny network traffic by default and must allow network traffic by exception (i.e., deny all, permit by exception).

Access into an organizations internal network and to key internal boundaries must be tightly controlled and managed. In the case of the operating system, the boundary may be the workstation on the public internet.

Set Default Iptables Policy for Incoming Packets

To set the default policy to DROP (instead of ACCEPT) for the built-in INPUT chain which processes incoming packets, add or correct the following line in /etc/sysconfig/iptables:

:INPUT DROP [0:0]

Set Default Iptables Policy for Forwarded Packets

To set the default policy to DROP (instead of ACCEPT) for the built-in FORWARD chain which processes packets that will be forwarded from one interface to another, add or correct the following line in /etc/sysconfig/iptables:

:FORWARD DROP [0:0]

SRG-OS-000148

CCI-001111

The operating system must prevent remote devices that have established a non-remote connection with the system from communicating outside of the communication path with resources in external networks.

This control enhancement is implemented within the remote device (e.g., notebook/laptop computer) via configuration settings not configurable by the user of the device. An example of a non-remote communications path from a remote device is a virtual private network. When a non-remote connection is established using a virtual private network, the configuration settings prevent split-tunneling. Split-tunneling might otherwise be used by remote users to communicate with the information system as an extension of the system and to communicate with local resources, such as a printer or file server. Since the remote device, when connected by a non-remote connection, becomes an extension of the information system allowing dual communications paths, such as split-tunneling, in effect allowing unauthorized external connections into the system. This is a split-tunneling requirement that can be controlled via the operating system by disabling interfaces.

Guidance Does Not Meet this Requirement Due to Impracticality or Scope

The guidance does not meet this requirement. The requirement is impractical or out of scope.

SRG-OS-000149

CCI-001112

The operating system must route organization-defined internal communications traffic to organization-defined external networks through authenticated proxy servers within the managed interfaces of boundary protection devices.

A proxy server is designed to hide the identity of the client when making a connection to a server on the outside of its network. This prevents any hackers on the outside of learning IP addresses within the private network. With a proxy acting as the mediator, the client does not interact directly with the servers it is connecting to—the proxy server is in the middle handling both sides of the session.

Guidance Does Not Meet this Requirement Due to Impracticality or Scope

The guidance does not meet this requirement. The requirement is impractical or out of scope.

SRG-OS-000150

CCI-001115

The operating system, at managed interfaces, must deny network traffic and must audit internal users (or malicious code) posing a threat to external information systems.

Detecting internal actions that may pose a security threat to external information systems is sometimes termed extrusion detection. Extrusion detection at the information system boundary includes the analysis of network traffic (incoming, as well as, outgoing) looking for indications of an internal threat to the security of external systems.

Verify ip6tables Enabled

The ip6tables service can be enabled with the following command:

# chkconfig ip6tables on

Verify iptables Enabled

The iptables service can be enabled with the following command:

# chkconfig iptables on

Enable auditd Service

# chkconfig auditd on

Configure auditd Rules for Comprehensive Auditing

Tracing of arbitrary system calls (identified by name or number) on entry or exit.
Filtering by PID, UID, call success, system call argument (with some limitations), etc.
Monitoring of specific files for modifications to the file’s contents or metadata.

# service auditd restart

SRG-OS-000151

CCI-001117

The operating system must check incoming communications to ensure the communications are coming from an authorized source and routed to an authorized destination.

In the case of the operating system, the boundary may be the workstation on the public internet. In order to thwart an attack the operating system must be able to ensure communications are coming from an authorized source and routed to an authorized destination.

Verify ip6tables Enabled

The ip6tables service can be enabled with the following command:

# chkconfig ip6tables on

Verify iptables Enabled

The iptables service can be enabled with the following command:

# chkconfig iptables on

SRG-OS-000152

CCI-001118

The operating system must implement host-based boundary protection mechanisms for servers, workstations, and mobile devices.

A host-based boundary protection mechanism is a host-based firewall. Host-based boundary protection mechanisms are employed on mobile devices, such as notebook/laptop computers and other types of mobile devices. For the operating system, this requirement ensures the operating system either can natively support this requirement or has an application installed to support this requirement.

Verify ip6tables Enabled

The ip6tables service can be enabled with the following command:

# chkconfig ip6tables on

Verify iptables Enabled

The iptables service can be enabled with the following command:

# chkconfig iptables on

SRG-OS-000153

CCI-001123

The operating system must route all networked, privileged accesses through a dedicated, managed interface for purposes of access control and auditing.

Managed interfaces employing boundary protection must be used for operating systems when using privileged accesses.

Verify ip6tables Enabled

The ip6tables service can be enabled with the following command:

# chkconfig ip6tables on

Verify iptables Enabled

The iptables service can be enabled with the following command:

# chkconfig iptables on

Enable auditd Service

# chkconfig auditd on

SRG-OS-000154

CCI-001124

The operating system must prevent discovery of specific system components (or devices) composing a managed interface.

Allowing discovery of operating system resources, names, or components can lead to giving information to an attacker that may be used as an attack vector.

Verify ip6tables Enabled

The ip6tables service can be enabled with the following command:

# chkconfig ip6tables on

Verify iptables Enabled

The iptables service can be enabled with the following command:

# chkconfig iptables on

Set httpd ServerTokens Directive to Prod

ServerTokens Prod restricts information in page headers, returning only the word "Apache."

Add or correct the following directive in /etc/httpd/conf/httpd.conf:

ServerTokens Prod

Set httpd ServerSignature Directive to Off

ServerSignature Off restricts httpd from displaying server version number on error pages.

Add or correct the following directive in /etc/httpd/conf/httpd.conf:

ServerSignature Off

SRG-OS-000155

CCI-001125

The operating system must employ automated mechanisms to enforce strict adherence to protocol format.

Crafted packets not conforming to IEEE standards can be used by malicious people to exploit a host’s protocol stack to create a Denial of Service or force a device reset.

A New Policy/Manual Rule is Needed

A new Rule needs to be created in the scap-security-guide content.

SRG-OS-000156

CCI-001126

The operating system must fail securely in the event of an operational failure of a boundary protection device.

Fail secure is a condition achieved by the operating system employing a set of information system mechanisms to ensure, in the event of an operational failure of a boundary protection device at a managed interface, the system does not enter into an unsecure state where security properties no longer hold.

Guidance Does Not Meet this Requirement Due to Impracticality or Scope

The guidance does not meet this requirement. The requirement is impractical or out of scope.

SRG-OS-000157

CCI-001127

The operating system must protect the integrity of transmitted information.

Ensuring the integrity of transmitted information requires the operating system take feasible measures to employ transmission layer security. This requirement applies to communications across internal and external networks.

Secure Sockets Layer Support

Create a CA to sign certificates
Create SSL certificates for servers using that CA
Enable client support by distributing the CA’s certificate

SRG-OS-000158

CCI-001128

The operating system must employ cryptographic mechanisms to recognize changes to information during transmission unless otherwise protected by alternative physical measures.

Ensuring the integrity of transmitted information requires operating systems take measures to employ some form of cryptographic mechanism in order to recognize changes to information. This is usually achieved through the use of checksums, cryptographic hash, or message authentication.

Secure Sockets Layer Support

Create a CA to sign certificates
Create SSL certificates for servers using that CA
Enable client support by distributing the CA’s certificate

SRG-OS-000159

CCI-001129

The operating system must maintain the integrity of information during aggregation, packaging, and transformation in preparation for transmission.

Ensuring the confidentiality of transmitted information requires the operating system take measures in preparing information for transmission. This can be accomplished via access control or encryption.

Secure Sockets Layer Support

Create a CA to sign certificates
Create SSL certificates for servers using that CA
Enable client support by distributing the CA’s certificate

SRG-OS-000160

CCI-001130

The operating system must protect the confidentiality of transmitted information.

Ensuring the confidentiality of transmitted information requires operating systems take feasible measures to employ transmission layer security. This requirement applies to communications across internal and external networks. When transmitting data, operating systems need to leverage transmission protection mechanisms, such as TLS, SSL, VPNs, or IPSEC.

Secure Sockets Layer Support

Create a CA to sign certificates
Create SSL certificates for servers using that CA
Enable client support by distributing the CA’s certificate

Install openswan Package

The Openswan package provides an implementation of IPsec and IKE, which permits the creation of secure tunnels over untrusted networks. The openswan package can be installed with the following command:

# yum install openswan

SRG-OS-000161

CCI-001131

The operating system must employ cryptographic mechanisms to prevent unauthorized disclosure of information during transmission unless otherwise protected by alternative physical measures.

Secure Sockets Layer Support

Create a CA to sign certificates
Create SSL certificates for servers using that CA
Enable client support by distributing the CA’s certificate

Install openswan Package

# yum install openswan

SRG-OS-000162

CCI-001132

The operating system must maintain the confidentiality of information during aggregation, packaging, and transformation in preparation for transmission.

Confidentiality of the data must be maintained to ensure unauthorized users or processes do not have access to it. This can be accomplished via access control mechanisms or encryption.

Secure Sockets Layer Support

Create a CA to sign certificates
Create SSL certificates for servers using that CA
Enable client support by distributing the CA’s certificate

SRG-OS-000163

CCI-001133

The operating system must terminate the network connection associated with a communications session at the end of the session or after an organization-defined time period of inactivity.

This requirement applies to both internal and external networks. Terminating network connections associated with communications sessions means de-allocating associated TCP/IP address/port pairs at the operating system level. The time period of inactivity may, as the organization deems necessary, be a set of time periods by type of network access or for specific accesses.

Set SSH Idle Timeout Interval

ClientAliveInterval interval

SRG-OS-000164

CCI-001135

The operating system must establish a trusted communications path between the user and organization-defined security functions within the operating system.

The user interface must provide an unspoofable and faithful communication channel between the user and any entity trusted to manipulate authorities on the user's behalf. A trusted path shall be employed for high-confidence connections between the security functions of the information system and the user (e.g., for login).

Secure Sockets Layer Support

Create a CA to sign certificates
Create SSL certificates for servers using that CA
Enable client support by distributing the CA’s certificate

Install openswan Package

# yum install openswan

Allow Only SSH Protocol 2

Only SSH protocol version 2 connections should be permitted. The default setting in /etc/ssh/sshd_config is correct, and can be verified by ensuring that the following line appears:

Protocol 2

SRG-OS-000165

CCI-001140

The operating system must produce, control, and distribute symmetric cryptographic keys using NIST-approved or NSA-approved key management technology and processes.

Cryptographic key management and establishment can be performed using manual procedures or automated mechanisms with supporting manual procedures. In addition to being required for the effective operation of a cryptographic mechanism, effective cryptographic key management provides protections to maintain the availability of the information in the event of the loss of cryptographic keys by users.

A New Policy/Manual Rule is Needed

A new Rule needs to be created in the scap-security-guide content.

SRG-OS-000166

CCI-001141

The operating system must produce, control, and distribute symmetric and asymmetric cryptographic keys using NSA-approved key management technology and processes.

Secure Sockets Layer Support

Create a CA to sign certificates
Create SSL certificates for servers using that CA
Enable client support by distributing the CA’s certificate

SRG-OS-000167

CCI-001142

The operating system must produce, control, and distribute asymmetric cryptographic keys using approved PKI Class 3 certificates or prepositioned keying material.

Secure Sockets Layer Support

Create a CA to sign certificates
Create SSL certificates for servers using that CA
Enable client support by distributing the CA’s certificate

SRG-OS-000168

CCI-001143

The operating system must produce, control, and distribute asymmetric cryptographic keys using approved PKI Class 3 or Class 4 certificates and hardware security tokens that protect the user’s private key.

A New Policy/Manual Rule is Needed

A new Rule needs to be created in the scap-security-guide content.

SRG-OS-000169

CCI-001144

The operating system must implement required cryptographic protections using cryptographic modules that comply with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance.

Cryptography is only as strong as the encryption modules/algorithms that are employed to encrypt the data. Use of weak or un-tested encryption algorithms undermines the purposes of utilizing encryption to protect data.

Use Only Approved Ciphers

Ciphers aes128-ctr,aes192-ctr,aes256-ctr

SRG-OS-000170

CCI-001145

The operating system must employ FIPS-validated cryptography to protect unclassified information.

Cryptography is only as strong as the encryption modules/algorithms employed to encrypt the data. Use of weak or un-tested encryption algorithms undermines the purposes of utilizing encryption to protect data.

Use Only Approved Ciphers

Ciphers aes128-ctr,aes192-ctr,aes256-ctr

SRG-OS-000171

CCI-001146

The operating system must employ NSA-approved cryptography to protect classified information.

Use Only Approved Ciphers

Ciphers aes128-ctr,aes192-ctr,aes256-ctr

SRG-OS-000172

CCI-001147

The operating system must employ FIPS-validated cryptography to protect information when it must be separated from individuals who have the necessary clearances, yet lack the necessary access approvals.

Secure Sockets Layer Support

Create a CA to sign certificates
Create SSL certificates for servers using that CA
Enable client support by distributing the CA’s certificate

SRG-OS-000173

CCI-001148

The operating system must employ FIPS-validate or NSA-approved cryptography to implement digital signatures.

Secure Sockets Layer Support

Create a CA to sign certificates
Create SSL certificates for servers using that CA
Enable client support by distributing the CA’s certificate

SRG-OS-000174

CCI-001149

The operating system must protect the integrity and availability of publicly available information and applications.

The purpose of this control is to ensure organizations explicitly address the protection needs for public information and applications with such protection likely being implemented as part of other security controls.

Guidance Does Not Meet this Requirement Due to Impracticality or Scope

The guidance does not meet this requirement. The requirement is impractical or out of scope.

SRG-OS-000175

CCI-001150

The operating system must prohibit remote activation of collaborative computing devices, excluding the organization-defined exceptions where remote activation is to be allowed.

Collaborative computing devices include networked white boards, cameras, and microphones. Collaborative software examples include instant messaging or chat clients.

Guidance Does Not Meet this Requirement Due to Impracticality or Scope

The guidance does not meet this requirement. The requirement is impractical or out of scope.

SRG-OS-000176

CCI-001154

The operating system must block both inbound and outbound traffic between instant messaging clients, independently configured by end users and external service providers.

Blocking restrictions do not include instant messaging services configured by an organization to perform an authorized function. This requirement specifies blocking any external instant messaging clients not configured and managed by the organization.

Set Default Iptables Policy for Incoming Packets

To set the default policy to DROP (instead of ACCEPT) for the built-in INPUT chain which processes incoming packets, add or correct the following line in /etc/sysconfig/iptables:

:INPUT DROP [0:0]

SRG-OS-000177

CCI-001157

The operating system must associate security attributes with information exchanged between information systems.

When data is exchanged between information systems, the security attributes associated with the data needs to be maintained. Security attributes are an abstraction representing the basic properties or characteristics of an entity with respect to safeguarding information; typically associated with internal data structures (e.g., records, buffers, files) within the operating system and used to enable the implementation of access control and flow control policies, reflect special dissemination, handling or distribution instructions, or support other aspects of the information security policy. Security attributes may be explicitly or implicitly associated with the information contained within the information system.

Guidance Does Not Meet this Requirement Due to Impracticality or Scope

The guidance does not meet this requirement. The requirement is impractical or out of scope.

SRG-OS-000178

CCI-001158

The operating system must validate the integrity of security attributes exchanged between systems.

When data is exchanged between information systems, the security attributes associated with the data needs to be maintained. Security attributes are an abstraction representing the basic properties or characteristics of an entity with respect to safeguarding information; typically associated with internal data structures (e.g., records, buffers, files) within the information system and used to enable the implementation of access control and flow control policies, reflect special dissemination, handling or distribution instructions, or support other aspects of the information security policy. Security attributes may be explicitly or implicitly associated with the information contained within the information system.

Implementation of the Requirement is Unclear

It is unclear how to satisfy this requirement.

SRG-OS-000179

CCI-001159

The operating system must issue or obtain public key certificates under an appropriate certificate policy from an approved service provider.

For user certificates, each organization attains certificates from an approved, shared service provider, as required by OMB policy. For federal agencies operating a legacy public key infrastructure cross-certified with the Federal Bridge Certification Authority at medium assurance or higher, this Certification Authority will suffice. This control focuses on certificates with a visibility external to the information system and does not include certificates related to internal system operations, for example, application-specific time services.

A New Policy/Manual Rule is Needed

A new Rule needs to be created in the scap-security-guide content.

SRG-OS-000180

CCI-001166

The operating system must implement detection and inspection mechanisms to identify unauthorized mobile code.

Decisions regarding the employment of mobile code within organizational information systems are based on the potential for the code to cause damage to the system if used maliciously. Mobile code technologies include Java, JavaScript, ActiveX, PDF, Postscript, Shockwave movies, Flash animations, and VBScript. Usage restrictions and implementation guidance apply to both the selection and use of mobile code installed on organizational servers and mobile code downloaded and executed on individual workstations.

Configure Periodic Execution of AIDE

AIDE should be executed on a periodic basis to check for changes. To implement a daily execution of AIDE at 4:05am using cron, add the following line to /etc/crontab:

05 4 * * * root /usr/sbin/aide --check

AIDE can be executed periodically through other means; this is merely one example.

SRG-OS-000181

CCI-001695

The operating system must prevent the execution of prohibited mobile code.

Decisions regarding the employment of mobile code within operating systems are based on the potential for the code to cause damage to the system if used maliciously. Mobile code technologies include Java, JavaScript, ActiveX, PDF, Postscript, Shockwave movies, Flash animations, and VBScript. Usage restrictions and implementation guidance apply to both the selection and use of mobile code installed on organizational servers and mobile code downloaded and executed on individual workstations.

Product Does Not Meet this Requirement Due to Impracticality or Scope

The product does not meet this requirement. The requirement is impractical or out of scope.

SRG-OS-000182

CCI-001169

The operating system must prevent the download of prohibited mobile code.

Product Does Not Meet this Requirement Due to Impracticality or Scope

The product does not meet this requirement. The requirement is impractical or out of scope.

SRG-OS-000183

CCI-001170

The operating system must prevent the automatic execution of mobile code in organization-defined software applications and must require organization-defined actions prior to executing the code.

Product Does Not Meet this Requirement Due to Impracticality or Scope

The product does not meet this requirement. The requirement is impractical or out of scope.

SRG-OS-000184

CCI-001190

The operating system must fail to an organization-defined known state for organization-defined types of failures.

Failure in a known state can address safety or security in accordance with the mission/business needs of the organization. It helps prevent a loss of confidentiality, integrity, or availability in the event of a failure of the information system or a component of the system. Preserving system state information facilitates system restart and return to the operational mode of the organization with less disruption of mission/business processes.

Enable auditd Service

# chkconfig auditd on

SRG-OS-000185

CCI-001199

The operating system must protect the confidentiality and integrity of information at rest.

This control is intended to address the confidentiality and integrity of information at rest in non-mobile devices and covers user information and system information. Information at rest refers to the state of information when it is located on a secondary storage device (e.g., disk drive, tape drive). The operating system must ensure the data being written to these devices is protected. In most cases, this is done via encryption.

Encrypting Partitions

Red Hat Enterprise Linux 6 natively supports partition encryption through the Linux Unified Key Setup-on-disk-format (LUKS) technology. The easiest way to encrypt a partition is during install time.

For manual installations, selecting the Encrypt checkbox during partition creation is all that is needed to encrypt the partition. When this option is selected the system will prompt for a passphrase to use in decrypting the partition. The passphrase will need to be entered manually every time the system boots.

For automated/unattended installations using Kickstart add the --encrypted and --passphrase= options to the definition of each partition you want encrypted. For example:

part / --fstype=ext3 --size=100 --onpart=hda1 --encrypted --passphrase=yourpassphrase

Where yourpassphrase is a passphrase of your choosing. The passphrase is stored in the Kickstart file in clear-text. If that is of concern, leaving the --passphrase= option off the partition definition will cause the installer to pause and interactively ask for the passphrase during the install.

Detailed information on encrypting partitions using LUKS can be found on the Red Had Documentation web site:
https://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/sect-Security_Guide-LUKS_Disk_Encryption.html

SRG-OS-000186

CCI-001209

The operating system must protect the integrity of information during the processes of data aggregation, packaging, and transformation in preparation for transmission.

Information can be subjected to unauthorized changes (e.g., malicious and/or unintentional modification) at information aggregation or protocol transformation points. It is therefore imperative the operating system take steps to validate and assure the integrity of data while at these stages of processing.

Product Meets this Requirement

Red Hat Enterprise Linux meets this requirement by design.

SRG-OS-000187

CCI-001210

The operating system at organization-defined information system components must load and execute the operating environment from hardware-enforced, read-only media.

Organizations may require the information system to load the operating environment from hardware enforced read-only media. The term operating environment is defined as the code upon which applications are hosted, for example, a monitor, executive, operating system, or application running directly on the hardware platform. Hardware-enforced, read-only media includes CD-R/DVD-R disk drives. Use of non-modifiable storage ensures the integrity of the software program from the point of creation of the read-only image. For this requirement, the operating environment is the operating system.

Guidance Does Not Meet this Requirement Due to Impracticality or Scope

The guidance does not meet this requirement. The requirement is impractical or out of scope.

SRG-OS-000188

CCI-001211

The operating system at organization-defined information system components must load and execute organization-defined applications from hardware-enforced, read-only media.

Use of non-modifiable storage ensures the integrity of the software program from the point of creation of the read-only image. Organizations may require the information system to load specified applications from hardware enforced read-only media. Hardware-enforced, read-only media includes CD-R/DVD-R disk drives.

Guidance Does Not Meet this Requirement Due to Impracticality or Scope

The guidance does not meet this requirement. The requirement is impractical or out of scope.

SRG-OS-000189

CCI-001214

The operating system must employ organization-defined information system components with no writeable storage that are persistent across component restart or power on/off.

Organizations may require operating systems to be non-modifiable or to be stored and executed on non-writeable storage. Use of non-modifiable storage ensures the integrity of the program from the point of creation of the read-only image and eliminates the possibility of malicious code insertion.

Product Meets this Requirement

Red Hat Enterprise Linux meets this requirement by design.

SRG-OS-000190

CCI-001232

The operating system must install software update automatically.

Security faults with software applications and operating systems are discovered daily and vendors are constantly updating and patching their products to address newly discovered security vulnerabilities. Organizations (including any contractor to the organization) are required to promptly install security-relevant software updates (e.g., patches, service packs, hot fixes). Flaws discovered during security assessments, continuous monitoring, incident response activities, or information system error handling, must also be addressed expeditiously.

Ensure Software Patches Installed

The following command prints a list of packages that need to be updated:

# yum check-update

To actually install these updates, run:

# yum update

SRG-OS-000191

CCI-001233

The operating system must employ automated mechanisms or must have an application installed that on an organization-defined frequency determines the state of information system components with regard to flaw remediation.

Organizations are required to identify information systems containing software affected by recently announced software flaws (and potential vulnerabilities resulting from those flaws) and report this information to designated organizational officials with information security responsibilities (e.g., senior information security officers, information system security managers, information systems security officers). To support this requirement, an automated process or mechanism is required. This role is usually assigned to patch management software deployed in order to track the number of systems installed in the network, as well as, the types of software installed on these systems, the corresponding versions and the related flaws that require patching. From an operating system requirement perspective, the operating system must perform this or there must be an application installed performing this function.

Updating Software The yum command line tool is used to install and update software packages. The system also provides two graphical package managers, pirut and pup. The pirut tool is a graphical front-end for yum that allows users to install and update packages while pup is a simple update tool for packages that are already installed. In the Applications menu, pirut is labeled Add/Remove Software and pup is labeled Software Updater.

Red Hat Enteprise Linux systems contain an embedded Installed Software Catalog, or "RPM Database," which records metadata of installed packages. The yum, pirut, and pup tools interface with the Installed Software Catalog to ensure all system metadata is accurate with regard to installed software and security patches, and for this reason, their use is strongly encouraged.

SRG-OS-000192

CCI-001237

The operating system must support automated patch management tools to facilitate flaw remediation to organization-defined information system components.

The organization (including any contractor to the organization) must promptly install security-relevant software updates (e.g., patches, service packs, hot fixes). Flaws discovered during security assessments, continuous monitoring, incident response activities, or information system error handling, must also be addressed.

Product Meets this Requirement

Red Hat Enterprise Linux meets this requirement by design.

SRG-OS-000193

CCI-001239

The operating system must have malicious code protection mechanisms at system entry and exit points to detect and eradicate malicious code transported by electronic mail, electronic mail attachments, web accesses, removable media, or other common means.

In order to minimize potential negative impact to the organization caused by malicious code, it is imperative that malicious code is identified and eradicated prior to entering protected enclaves via operating system entry and exit points. The requirement states that AV and malware protection applications must be used at entry and exit points. For the operating system, this means an anti-virus application must be installed on machines that are the entry and exit points.

Install Virus Scanning Software

Virus scanning software should be installed and configured to perform scans dynamically on accessed files. If this capability is not available, the system should be configured to scan, at a minimum, all altered files on the system on a daily basis.

Virus signature definition files should be updated frequently. It is recommended that definition files be updated at least every 7 days.

SRG-OS-000194

CCI-001248

The operating system must prevent non-privileged users from circumventing malicious code protection capabilities.

Malicious code protection software must be protected so as to prevent a non-privileged user or a malicious piece of software from disabling the protection mechanism. A common tactic of malware is to identify the type of malicious code protection software running on the system and deactivate it.

Product Meets this Requirement

Red Hat Enterprise Linux meets this requirement by design.

SRG-OS-000195

CCI-001250

The operating system must not allow users to introduce removable media into the information system.

Malicious code is known to propagate via removable media such as floppy disks, USB or flash drives, and removable hard drives. In order to prevent propagation and potential infection due to malware contained on removable media the operating system must be able to restrict and/or limit the use of removable media.

Disable Modprobe Loading of USB Storage Driver

install usb-storage /bin/true

This will prevent the modprobe program from loading the usb-storage module, but will not prevent an administrator (or another program) from using the insmod program to load the module manually.

Disable Kernel Support for USB via Bootloader Configuration

kernel /vmlinuz-VERSION ro vga=ext root=/dev/VolGroup00/LogVol00 rhgb quiet nousb

Disable Booting from USB Devices

Disable the Automounter

# chkconfig --level 0123456 autofs off

Disable GNOME Automounting

# gconftool-2 --direct \
	--config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory \
	--type bool \
	--set /apps/nautilus/preferences/media_automount false
# gconftool-2 --direct \
	--config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory \
	--type bool \
	--set /apps/nautilus/preferences/media_autorun_never true

These settings can be verified by running the following:

$ gconftool-2 --direct \
	--config-source xml:read:/etc/gconf/gconf.xml.mandatory \
	--get /apps/nautilus/preferences/media_automount
$ gconftool-2 --direct \
	--config-source xml:read:/etc/gconf/gconf.xml.mandatory \
	--get /apps/nautilus/preferences/media_autorun_never

SRG-OS-000196

CCI-001263

The operating system must provide a near real-time alert when any of the organization-defined list of compromise or potential compromise indicators occurs.

When an intrusion detection security event occurs it is imperative the operating system that has detected the event immediately notify the appropriate support personnel so they can respond accordingly.

Configure Periodic Execution of AIDE

AIDE should be executed on a periodic basis to check for changes. To implement a daily execution of AIDE at 4:05am using cron, add the following line to /etc/crontab:

05 4 * * * root /usr/sbin/aide --check

AIDE can be executed periodically through other means; this is merely one example.

Enable auditd Service

# chkconfig auditd on

SRG-OS-000197

CCI-001265

The operating system must prevent non-privileged users from circumventing intrusion detection and prevention capabilities.

Intrusion detection and prevention capabilities must be architected and implemented to prevent non-privileged users from circumventing such protections. This can be accomplished through the use of user roles, use of proper systems permissions, auditing, logging, etc.

Product Meets this Requirement

Red Hat Enterprise Linux meets this requirement by design.

SRG-OS-000198

CCI-001269

The operating system must protect information obtained from intrusion-monitoring tools from unauthorized access, modification, and deletion.

Intrusion-monitoring tools can accumulate a significant amount of sensitive data; examples could include user account information and application data not related to the intrusion monitoring application itself. Intrusion monitoring tools also obtain information that is critical to conducting forensic analysis on attacks that occur within the network. This data may be sensitive in nature. Information obtained by intrusion monitoring applications in the course of evaluating network and system security needs to be protected. While this is an operating system requirement, the data collected may be in different files or locations depending upon the IDS/IPS product being used.

Product Meets this Requirement

Red Hat Enterprise Linux meets this requirement by design.

SRG-OS-000199

CCI-001291

The operating system must verify the correct operation of security functions in accordance with organization-defined conditions and in accordance with organization-defined frequency (if periodic verification).

Security functional testing involves testing the operating system for conformance to the operating system security function specifications, as well as, for the underlying security model. The need to verify security functionality applies to all security functions. The conformance criteria state the conditions necessary for the operating system to exhibit the desired security behavior or satisfy a security property for example, successful login triggers an audit entry.

Implementation of the Requirement is Unclear

It is unclear how to satisfy this requirement.

SRG-OS-000200

CCI-001294

The operating system must provide notification of failed automated security tests.

The need to verify security functionality applies to all security functions. For those security functions unable to execute automated self-tests the organization either implements compensating security controls or explicitly accepts the risk of not performing the verification as required. Upon detection of security function anomalies or failure of automated self-tests, the operating system must respond in accordance with organization-defined responses and alternative actions.

Implementation of the Requirement is Unclear

It is unclear how to satisfy this requirement.

SRG-OS-000201

CCI-001295

The operating system must provide automated support for the management of distributed security testing.

The need to verify security functionality applies to all security functions.

Implementation of the Requirement is Unclear

It is unclear how to satisfy this requirement.

SRG-OS-000202

CCI-001297

The operating system must detect unauthorized changes to software and information.

Unauthorized changes to the operating system software or information on the system can possibly result in integrity or availability concerns. In order to quickly react to this situation, the operating system must detect these changes.

SRG-OS-000203

CCI-001310

The operating system must check the validity of information inputs.

Invalid user input occurs when a user inserts data or characters the system is unprepared to process that data. This results in unanticipated behavior that could lead to a compromise.

Product Meets this Requirement

Red Hat Enterprise Linux meets this requirement by design.

SRG-OS-000204

CCI-001311

The operating system must identify potentially security-relevant error conditions.

The structure and content of error messages need to be carefully considered by the organization. The extent to which the operating system is able to identify and handle error conditions is guided by organizational policy and operational requirements.

Enable rsyslog Service

The rsyslog service provides syslog-style logging by default on RHEL 6. The rsyslog service can be enabled with the following command:

# chkconfig rsyslog on

Product Meets this Requirement

Red Hat Enterprise Linux meets this requirement by design.

SRG-OS-000205

CCI-001312

The operating system must generate error messages providing information necessary for corrective actions without revealing organization-defined sensitive or potentially harmful information in error logs and administrative messages that could be exploited.

Any operating system providing too much information in error logs and in administrative messages to the screen, risks compromising the data and security of the structure and content of error messages needs to be carefully considered by the organization.

Enable rsyslog Service

The rsyslog service provides syslog-style logging by default on RHEL 6. The rsyslog service can be enabled with the following command:

# chkconfig rsyslog on

Enable auditd Service

# chkconfig auditd on

SRG-OS-000206

CCI-001314

The operating system must reveal error messages only to authorized personnel.

If the operating system provides too much information in error logs and administrative messages to the screen it could lead to compromise. The structure and content of error messages need to be carefully considered by the organization.

Ensure System Log Files Have Correct Permissions

The file permissions for all log files written by rsyslog should be set to 600, or more restrictive. These log files are determined by the second part of each Rule line in /etc/rsyslog.conf and typically all appear in /var/log. For each log file LOGFILE referenced in /etc/rsyslog.conf, run the following command to inspect the file's permissions:

$ ls -l LOGFILE

If the permissions are not 600 or more restrictive, run the following command to correct this:

# chmod 0600 LOGFILE

Product Meets this Requirement

Red Hat Enterprise Linux meets this requirement by design.

SRG-OS-000207

CCI-001328

The operating system must support the requirement that organizations, if an information system component failure is detected must activate an organization-defined alarm and/or automatically shuts down the operating system.

Predictable failure prevention requires organizational planning to address system failure issues. If a subsystem of the operating system, hardware, or the operating system itself, is key to maintaining systems and security fails to function, the system could continue operating in an insecure state. The organization must be prepared for and the operating system must support capability that alarms for such conditions and/or automatically shuts down the operating system or the subsystem of the operating system.

Product Meets this Requirement

Red Hat Enterprise Linux meets this requirement by design.

SRG-OS-000208

CCI-001338

The operating system must associate the identity of the information producer with the information.

Non-repudiation supports audit requirements to provide the appropriate organizational officials the means to identify who produced specific information in the event of an information transfer.

System Accounting with auditd

http://docs.fedoraproject.org/en-US/Fedora/13/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-Fixing_Problems-Raw_Audit_Messages.html

type=AVC msg=audit(1226874073.147:96): avc:  denied  { getattr } for pid=2465 comm="httpd"
path="/var/www/html/file1" dev=dm-0 ino=284133 scontext=unconfined_u:system_r:httpd_t:s0 
tcontext=unconfined_u:object_r:samba_share_t:s0 tclass=file

type=SYSCALL msg=audit(1226874073.147:96): arch=40000003 syscall=196 success=no exit=-13 
a0=b98df198 a1=bfec85dc a2=54dff4 a3=2008171 items=0 ppid=2463 pid=2465 auid=502 uid=48
gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=6 comm="httpd"
exe="/usr/sbin/httpd" subj=unconfined_u:system_r:httpd_t:s0 key=(null)

msg=audit(1226874073.147:96)
- The number in parentheses is the unformatted time stamp (Epoch time) for the event, which can be converted to standard time by using the date command.
{ getattr }
- The item in braces indicates the permission that was denied. getattr indicates the source process was trying to read the target file's status information. This occurs before reading files. This action is denied due to the file being accessed having the wrong label. Commonly seen permissions include getattr, read, and write.
comm="httpd"
- The executable that launched the process. The full path of the executable is found in the exe= section of the system call (SYSCALL) message, which in this case, is exe="/usr/sbin/httpd".
path="/var/www/html/file1"
- The path to the object (target) the process attempted to access.
scontext="unconfined_u:system_r:httpd_t:s0"
- The SELinux context of the process that attempted the denied action. In this case, it is the SELinux context of the Apache HTTP Server, which is running in the httpd_t domain.
tcontext="unconfined_u:object_r:samba_share_t:s0"
- The SELinux context of the object (target) the process attempted to access. In this case, it is the SELinux context of file1. Note: the samba_share_t type is not accessible to processes running in the httpd_t domain.
From the system call (SYSCALL) message, two items are of interest:
- success=no: indicates whether the denial (AVC) was enforced or not. success=no indicates the system call was not successful (SELinux denied access). success=yes indicates the system call was successful - this can be seen for permissive domains or unconfined domains, such as initrc_t and kernel_t.
- exe="/usr/sbin/httpd": the full path to the executable that launched the process, which in this case, is exe="/usr/sbin/httpd".

SRG-OS-000209

CCI-001339

The operating system must validate the binding of the information producer’s identity to the information.

System Accounting with auditd

http://docs.fedoraproject.org/en-US/Fedora/13/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-Fixing_Problems-Raw_Audit_Messages.html

type=AVC msg=audit(1226874073.147:96): avc:  denied  { getattr } for pid=2465 comm="httpd"
path="/var/www/html/file1" dev=dm-0 ino=284133 scontext=unconfined_u:system_r:httpd_t:s0 
tcontext=unconfined_u:object_r:samba_share_t:s0 tclass=file

type=SYSCALL msg=audit(1226874073.147:96): arch=40000003 syscall=196 success=no exit=-13 
a0=b98df198 a1=bfec85dc a2=54dff4 a3=2008171 items=0 ppid=2463 pid=2465 auid=502 uid=48
gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=6 comm="httpd"
exe="/usr/sbin/httpd" subj=unconfined_u:system_r:httpd_t:s0 key=(null)

msg=audit(1226874073.147:96)
- The number in parentheses is the unformatted time stamp (Epoch time) for the event, which can be converted to standard time by using the date command.
{ getattr }
- The item in braces indicates the permission that was denied. getattr indicates the source process was trying to read the target file's status information. This occurs before reading files. This action is denied due to the file being accessed having the wrong label. Commonly seen permissions include getattr, read, and write.
comm="httpd"
- The executable that launched the process. The full path of the executable is found in the exe= section of the system call (SYSCALL) message, which in this case, is exe="/usr/sbin/httpd".
path="/var/www/html/file1"
- The path to the object (target) the process attempted to access.
scontext="unconfined_u:system_r:httpd_t:s0"
- The SELinux context of the process that attempted the denied action. In this case, it is the SELinux context of the Apache HTTP Server, which is running in the httpd_t domain.
tcontext="unconfined_u:object_r:samba_share_t:s0"
- The SELinux context of the object (target) the process attempted to access. In this case, it is the SELinux context of file1. Note: the samba_share_t type is not accessible to processes running in the httpd_t domain.
From the system call (SYSCALL) message, two items are of interest:
- success=no: indicates whether the denial (AVC) was enforced or not. success=no indicates the system call was not successful (SELinux denied access). success=yes indicates the system call was successful - this can be seen for permissive domains or unconfined domains, such as initrc_t and kernel_t.
- exe="/usr/sbin/httpd": the full path to the executable that launched the process, which in this case, is exe="/usr/sbin/httpd".

SRG-OS-000210

CCI-001340

The operating system must maintain reviewer/releaser identity and credentials within the established chain of custody for all information reviewed or released.

When it comes to data review and data release, there must be a correlation between the reviewed data and the person who performs the review. If the reviewer is a human or if the review function is automated but separate from the release/transfer function, the operating system associates the identity of the reviewer of the information to be released with the information and the information label.

Guidance Does Not Meet this Requirement Due to Impracticality or Scope

The guidance does not meet this requirement. The requirement is impractical or out of scope.

SRG-OS-000211

CCI-001341

The operating system must validate the binding of the reviewer’s identity to the information at the transfer/release point prior to release/transfer from one security domain to another security domain.

This non-repudiation control enhancement is intended to mitigate the risk that information could be modified between review and transfer/release particularly when the transfer is occurring between security domains.

Guidance Does Not Meet this Requirement Due to Impracticality or Scope

The guidance does not meet this requirement. The requirement is impractical or out of scope.

SRG-OS-000213

CCI-001343

The operating system must invoke a system shutdown in the event of an audit failure, unless an alternative audit capability exists.

It is critical when an operating system is at risk of failing to process audit logs as required it takes action to mitigate the failure. If the system were to continue processing without auditing enabled, actions can be taken on the system that cannot be tracked and recorded for later forensic analysis. Audit processing failures include software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded.

Configure auditd admin_space_left Action on Low Disk Space

admin_space_left_action = ACTION

Possible values for ACTION are described in the auditd.conf man page. These include:

ignore
syslog
email
exec
suspend
single
halt

SRG-OS-000214

CCI-001274

The operating system must employ automated mechanisms to alert security personnel of any organization-defined inappropriate or unusual activities with security implications.

Successful incident response and auditing relies on timely, accurate system information and analysis in order to allow the organization to identify and respond to potential incidents in a proficient manner. Automated alarming mechanisms provide the appropriate personnel with the capability to immediately respond and react to events categorized as unusual or having security implications that could be detrimental to system and/or organizational security.

Configure auditd Rules for Comprehensive Auditing

Tracing of arbitrary system calls (identified by name or number) on entry or exit.
Filtering by PID, UID, call success, system call argument (with some limitations), etc.
Monitoring of specific files for modifications to the file’s contents or metadata.

# service auditd restart

SRG-OS-000215

CCI-001348

The operating system must back up audit records on an organization-defined frequency onto a different system or media than the system being audited.

Protection of log data includes assuring the log data is not accidentally lost or deleted. Backing up audit records to a different system or onto separate media than the system being audited on an organizationally defined frequency helps to assure in the event of a catastrophic system failure, the audit records will be retained.

Ensure Logs Sent To Remote Host

*.* @loghost.example.com

To use TCP for log message delivery:

*.* @@loghost.example.com

To use RELP for log message delivery:

*.* :omrelp:loghost.example.com

SRG-OS-000216

CCI-001350

The operating system must use cryptographic mechanisms to protect the integrity of audit information.

Protection of audit records and audit data is of critical importance. Cryptographic mechanisms are the industry established standard used to protect the integrity of audit data.

Encrypting Partitions

part / --fstype=ext3 --size=100 --onpart=hda1 --encrypted --passphrase=yourpassphrase

SRG-OS-000217

CCI-001352

The operating system must protect the audit records resulting from non-local accesses to privileged accounts and the execution of privileged functions.

Protection of audit records and audit data is of critical importance. Care must be taken to ensure privileged users cannot circumvent audit protections put in place. Auditing might not be reliable when performed by an operating system which the user being audited has privileged access to. The privileged user could inhibit auditing or directly modify audit records. To prevent this from occurring, privileged access shall be further defined between audit-related privileges and other privileges, thus, limiting the users with audit-related privileges.

Ensure Logs Sent To Remote Host

*.* @loghost.example.com

To use TCP for log message delivery:

*.* @@loghost.example.com

To use RELP for log message delivery:

*.* :omrelp:loghost.example.com

Guidance Does Not Meet this Requirement Due to Impracticality or Scope

The guidance does not meet this requirement. The requirement is impractical or out of scope.

SRG-OS-000218

CCI-001353

The operating system must produce a system-wide (logical or physical) audit trail composed of audit records in a standardized format.

Audits records can be generated from various components within the operating system. The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records (i.e., auditable events).

Enable auditd Service

# chkconfig auditd on

SRG-OS-000219

CCI-001356

The operating system must monitor for atypical usage of operating system accounts.

Atypical account usage is behavior that is not part of normal usage cycles, e.g., accounts logging in after hours or on weekends.

Configure auditd Rules for Comprehensive Auditing

Tracing of arbitrary system calls (identified by name or number) on entry or exit.
Filtering by PID, UID, call success, system call argument (with some limitations), etc.
Monitoring of specific files for modifications to the file’s contents or metadata.

# service auditd restart

SRG-OS-000220

CCI-001362

The operating system must enforce an organization-defined Discretionary Access Control (DAC) policy that must allow users to specify and control sharing by named individuals or groups of individuals, or by both.

Product Meets this Requirement

Red Hat Enterprise Linux meets this requirement by design.

SRG-OS-000221

CCI-001368

The operating system must enforce approved authorizations for controlling the flow of information within the system in accordance with applicable policy.

Product Meets this Requirement

Red Hat Enterprise Linux meets this requirement by design.

SRG-OS-000222

CCI-001372

The operating system, when transferring information between different security domains, must implement policy filters constraining data structure and content to organization-defined information security policy requirements.

Guidance Does Not Meet this Requirement Due to Impracticality or Scope

The guidance does not meet this requirement. The requirement is impractical or out of scope.

SRG-OS-000223

CCI-001373

The operating system, when transferring information between different security domains, must detect unsanctioned information.

Guidance Does Not Meet this Requirement Due to Impracticality or Scope

The guidance does not meet this requirement. The requirement is impractical or out of scope.

SRG-OS-000224

CCI-001374

The operating system, when transferring information between different security domains, must prohibit the transfer of unsanctioned information in accordance with the security policy.

Information flow control regulates where information is allowed to travel within an operating system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to the information. Actions to support this requirement include but are not limited to: checking all transferred information for malware; implementing dirty word list searches on transferred information; and applying the same protection measures to metadata (e.g., security attributes) that is applied to the information payload.

Guidance Does Not Meet this Requirement Due to Impracticality or Scope

The guidance does not meet this requirement. The requirement is impractical or out of scope.

SRG-OS-000225

CCI-001376

The operating system must uniquely identify source domains for information transfer.

Guidance Does Not Meet this Requirement Due to Impracticality or Scope

The guidance does not meet this requirement. The requirement is impractical or out of scope.

SRG-OS-000226

CCI-001377

The operating system must uniquely authenticate source domains for information transfer.

Guidance Does Not Meet this Requirement Due to Impracticality or Scope

The guidance does not meet this requirement. The requirement is impractical or out of scope.

SRG-OS-000227

CCI-001383

The operating system must provide additional protection for mobile devices accessed via login by purging information from the device after organization-defined number of consecutive, unsuccessful login attempts to the mobile device.

Mobile devices present additional risks related to attempted unauthorized access. If they are lost, stolen or misplaced, attempts can be made to unlock the device by guessing the PIN. In order to address this risk, mobile devices shall provide additional protection enabling the device to automatically wipe itself clean and purge itself of any and all data. This requirement applies only to mobile devices for which a login occurs (e.g., personal digital assistants and smart phones) and not to mobile devices accessed without a login such as removable media. In certain situations, this requirement may not apply to mobile devices if the information on the device is encrypted with sufficiently strong encryption mechanisms, making purging unnecessary. The login is to the mobile device, not to any one account on the device. Therefore, a successful login to any account on the mobile device resets the unsuccessful login count to zero.

Guidance Does Not Meet this Requirement Due to Impracticality or Scope

The guidance does not meet this requirement. The requirement is impractical or out of scope.

SRG-OS-000228

CCI-001384

The operating system for publicly accessible systems must display the system use information when appropriate, before granting further access.

Requirement applies to publicly accessible systems. System use notification messages can be implemented in the form of warning banners displayed when individuals log in to the information system. System use notification is intended only for information system access including an interactive login interface with a human user and is not intended to require notification when an interactive interface does not exist.

Set GUI Warning Banner Text

To set the text shown by the GNOME Display Manager in the login screen, run the following command:

sudo -u gdm gconftool-2 \
  --type string \
  --set /apps/gdm/simple-greeter/banner_message_text \
  "Text of the warning banner here"

SRG-OS-000229

CCI-000370

The operating system must employ automated mechanisms to centrally manage configuration settings.

Configuration settings are the configurable security-related parameters of information technology products that are part of the information system. Security-related parameters are those parameters impacting the security state of the system including parameters related to meeting other security control requirements. Security-related parameters include, for example, registry settings; account, file, and directory settings (i.e., permissions); and settings for services, ports, protocols, and remote connections. Rather than visiting each system when making configuration changes, organizations must employ automated tools that can make changes across all systems. This greatly increases efficiency and manageability of applications in a large scale environment.

Guidance Does Not Meet this Requirement Due to Impracticality or Scope

The guidance does not meet this requirement. The requirement is impractical or out of scope.

SRG-OS-000230

CCI-001200

The operating system must employ cryptographic mechanisms to prevent unauthorized disclosure of information at rest unless otherwise protected by alternative physical measures.

Encrypting Partitions

part / --fstype=ext3 --size=100 --onpart=hda1 --encrypted --passphrase=yourpassphrase

SRG-OS-000231

CCI-000066

The operating system must enforce requirements for remote connections to the information system.

The organization will define the requirements for connection of remote connections. In order to ensure the connection provides adequate integrity and confidentiality of the connection, the operating system must enforce these requirements.

Iptables and Ip6tables

A host-based firewall called Netfilter is included as part of the Linux kernel distributed with the system. It is activated by default. This firewall is controlled by the program iptables, and the entire capability is frequently referred to by this name. An analogous program called ip6tables handles filtering for IPv6.

Unlike TCP Wrappers, which depends on the network server program to support and respect the rules written, Netfilter filtering occurs at the kernel level, before a program can even process the data from the network packet. As such, any program on the system is affected by the rules written.

This section provides basic information about strengthening the iptables and ip6tables configurations included with the system. For more complete information that may allow the construction of a sophisticated ruleset tailored to your environment, please consult the references at the end of this section.

Verify ip6tables Enabled

The ip6tables service can be enabled with the following command:

# chkconfig ip6tables on

Verify iptables Enabled

The iptables service can be enabled with the following command:

# chkconfig iptables on

Set Default Iptables Policy for Incoming Packets

To set the default policy to DROP (instead of ACCEPT) for the built-in INPUT chain which processes incoming packets, add or correct the following line in /etc/sysconfig/iptables:

:INPUT DROP [0:0]

SRG-OS-000232

CCI-001069

The operating system must employ automated mechanisms to detect the presence of unauthorized software on organizational information systems and notify designated organizational officials in accordance with the organization-defined frequency.

Malicious software can establish a base on individual desktops and servers. Employing an automated mechanism to detect this type of software will aide in elimination of the software from the operating system.

SRG-OS-000233

CCI-001391

The operating system must notify the user of the number of successful logins/accesses that occur during the organization-defined time period.

Users need to be aware of activity that occurs regarding their account. Providing users with information regarding the number of successful attempts made to login to their account allows the user to determine if any unauthorized activity has occurred and gives them an opportunity to notify administrators.

Protect Accounts by Configuring PAM PAM, or Pluggable Authentication Modules, is a system which implements modular authentication for Linux programs. PAM provides a flexible and configurable architecture for authentication, and it should be configured to minimize exposure to unnecessary risk. This section contains guidance on how to accomplish that.

PAM is implemented as a set of shared objects which are loaded and invoked whenever an application wishes to authenticate a user. Typically, the application must be running as root in order to take advantage of PAM, because PAM's modules often need to be able to access sensitive stores of account information, such as /etc/shadow. Traditional privileged network listeners (e.g. sshd) or SUID programs (e.g. sudo) already meet this requirement. An SUID root application, userhelper, is provided so that programs which are not SUID or privileged themselves can still take advantage of PAM.

PAM looks in the directory /etc/pam.d for application-specific configuration information. For instance, if the program login attempts to authenticate a user, then PAM's libraries follow the instructions in the file /etc/pam.d/login to determine what actions should be taken.

One very important file in /etc/pam.d is /etc/pam.d/system-auth. This file, which is included by many other PAM configuration files, defines 'default' system authentication measures. Modifying this file is a good way to make far-reaching authentication changes, for instance when implementing a centralized authentication service.

SRG-OS-000234

CCI-001392

The operating system must notify the user of the number of unsuccessful login/access attempts that occur during organization-defined time period.

Users need to be aware of activity that occurs regarding their account. Providing users with information regarding the number of unsuccessful attempts made to login to their account allows the user to determine if any unauthorized activity has occurred and gives them an opportunity to notify administrators.

SRG-OS-000235

CCI-001395

The operating system must notify the user of organization-defined security-related changes to the user’s account that occur during the organization-defined time period.

Some organizations may define certain security events as events requiring user notification. An organization may define an event such as a password change to a user's account occurring outside of normal business hours as a security related event that requires the user be notified. In those instances where organizations define such events, the operating system must notify the affected user or users.

Product Does Not Meet this Requirement Due to Impracticality or Scope

The product does not meet this requirement. The requirement is impractical or out of scope.

SRG-OS-000236

CCI-001399

The operating system must support and maintain the binding of organization-defined security attributes to information in storage.

Security attributes are abstractions representing the basic properties or characteristics of an entity (e.g., subjects, objects) with respect to safeguarding information. These attributes are typically associated with internal data structures (e.g., records, buffers, files) within the information system and are used to enable the implementation of access control and flow control policies, reflect special dissemination, handling or distribution instructions, or support other aspects of the information security policy. The term security label is often used to associate a set of security attributes with a specific information object as part of the data structure for that object (e.g., user access privileges, nationality, affiliation as contractor). These attributes may be assigned during data processing however these assignments also need to be maintained while the data is in storage.

Product Meets this Requirement

Red Hat Enterprise Linux meets this requirement by design.

SRG-OS-000237

CCI-001400

The operating system must support and maintain the binding of organization-defined security attributes to information in process.

Product Meets this Requirement

Red Hat Enterprise Linux meets this requirement by design.

SRG-OS-000238

CCI-001401

The operating system must support and maintain the binding of organization-defined security attributes to information in transmission.

Security attributes are abstractions representing the basic properties or characteristics of an entity (e.g., subjects, objects) with respect to safeguarding information. These attributes are typically associated with internal data structures (e.g., records, buffers, files) within the information system and are used to enable the implementation of access control and flow control policies, reflect special dissemination, handling or distribution instructions, or support other aspects of the information security policy. The term security label is used to associate a set of security attributes with a specific information object as part of the data structure for that object (e.g., user access privileges, nationality, affiliation as contractor). A security label is defined as the means used to associate a set of security attributes with a specific information object as part of the data structure for the object. In this case the security attributes are to be bound to the information in transmission.

Guidance Does Not Meet this Requirement Due to Impracticality or Scope

The guidance does not meet this requirement. The requirement is impractical or out of scope.

SRG-OS-000239

CCI-001403

The operating system must automatically audit account modification.

Once an attacker establishes initial access to a system, they often attempt to create a persistent method of re-establishing access. One way to accomplish this is for the attacker to simply modify an existing account. Auditing of account modification is one method and best practice for mitigating this risk. A comprehensive account management process will ensure an audit trail which documents the modification of user accounts and, as required, notifies appropriate individuals.

Record Events that Modify User/Group Information

Add the following to /etc/audit/audit.rules, in order to capture events that modify account changes:

# audit_account_changes
-w /etc/group -p wa -k audit_account_changes
-w /etc/passwd -p wa -k audit_account_changes
-w /etc/gshadow -p wa -k audit_account_changes
-w /etc/shadow -p wa -k audit_account_changes
-w /etc/security/opasswd -p wa -k audit_account_changes

SRG-OS-000240

CCI-001404

The operating system must automatically audit account disabling actions.

When accounts are disabled, user accessibility is affected. Accounts are utilized for identifying individual application users or for identifying processes themselves. In order to detect and respond to events affecting user accessibility and operating system processing, the operating system must audit account disabling actions and, as required, notify as required the appropriate individuals, so they can investigate the event. Such a capability greatly reduces the risk that accessibility will be negatively affected for extended periods of time and provides logging that can be used for forensic purposes.

Record Events that Modify User/Group Information

Add the following to /etc/audit/audit.rules, in order to capture events that modify account changes:

# audit_account_changes
-w /etc/group -p wa -k audit_account_changes
-w /etc/passwd -p wa -k audit_account_changes
-w /etc/gshadow -p wa -k audit_account_changes
-w /etc/shadow -p wa -k audit_account_changes
-w /etc/security/opasswd -p wa -k audit_account_changes

SRG-OS-000241

CCI-001405

The operating system must automatically audit account termination.

Accounts are utilized for identifying individual application users or for identifying the application processes themselves. When accounts are deleted, a Denial of Service could happen. The operating system must audit and notify, as required, to mitigate the Denial of Service risk.

Record Events that Modify User/Group Information

Add the following to /etc/audit/audit.rules, in order to capture events that modify account changes:

# audit_account_changes
-w /etc/group -p wa -k audit_account_changes
-w /etc/passwd -p wa -k audit_account_changes
-w /etc/gshadow -p wa -k audit_account_changes
-w /etc/shadow -p wa -k audit_account_changes
-w /etc/security/opasswd -p wa -k audit_account_changes

SRG-OS-000242

CCI-001414

The operating system must enforce approved authorizations for controlling the flow of information between interconnected systems in accordance with applicable policy.

Verify ip6tables Enabled

The ip6tables service can be enabled with the following command:

# chkconfig ip6tables on

Verify iptables Enabled

The iptables service can be enabled with the following command:

# chkconfig iptables on

Set Default Iptables Policy for Incoming Packets

To set the default policy to DROP (instead of ACCEPT) for the built-in INPUT chain which processes incoming packets, add or correct the following line in /etc/sysconfig/iptables:

:INPUT DROP [0:0]

SRG-OS-000243

CCI-001424

The operating system must dynamically reconfigure security attributes in accordance with an identified security policy as information is created and combined.

Security attributes are abstractions representing the basic properties or characteristics of an entity (e.g., subjects, objects) with respect to safeguarding information. These attributes are typically associated with internal data structures (e.g., data records, buffers, files) within the application and are used to enable the implementation of access control and flow control policies, reflect special dissemination, handling or distribution instructions, or support other aspects of the information security policy. The term security label is often used to associate a set of security attributes with a specific information object as part of the data structure for that object (e.g., user access privileges, nationality, affiliation as contractor). A security label is defined as the means used to associate a set of security attributes with a specific information object as part of the data structure for the object.

Enable SELinux

Edit the file /etc/selinux/config. Add or correct the following lines:

SELINUX=enforcing
SELINUXTYPE=targeted

Edit the file /etc/grub.conf. Ensure that the following arguments DO NOT appear on any kernel command line in the file:

selinux=0
enforcing=0

touch
/.autorelabel

SRG-OS-000244

CCI-001425

The operating system must only allow authorized entities to change security attributes.

Security attributes are abstractions representing the basic properties or characteristics of an entity (e.g., subjects, objects) with respect to safeguarding information. These attributes are typically associated with internal data structures (e.g., records, buffers, files, registry keys) within the system and are used to enable the implementation of access control and flow control policies, reflect special dissemination, handling or distribution instructions, or support other aspects of the information security policy. The term security label is often used to associate a set of security attributes with a specific information object as part of the data structure for that object (e.g., user access privileges, nationality, affiliation as contractor). A security label is defined as the means used to associate a set of security attributes with a specific information object as part of the data structure for the object.

Product Meets this Requirement

Red Hat Enterprise Linux meets this requirement by design.

SRG-OS-000245

CCI-001426

The operating system must maintain the binding of security attributes to information with sufficient assurance that the information--attribute association can be used as the basis for automated policy actions.

The term security label is often used to associate a set of security attributes with a specific information object as part of the data structure for that object (e.g., user access privileges, nationality, affiliation as contractor). A security label is defined as: the means used to associate a set of security attributes with a specific information object as part of the data structure for that object. Security attributes are abstractions representing the basic properties or characteristics of an entity (e.g., subjects, objects) with respect to safeguarding information. These attributes are typically associated with internal data structures (e.g., records, buffers, files) within the information system and are used to enable the implementation of access control and flow control policies, reflect special dissemination, handling or distribution instructions, or support other aspects of the information security policy. Examples of automated policy actions include automated access control decisions (e.g., Mandatory Access Control decisions), or decisions to release (or not release) information (e.g., information flows via cross domain systems).

Enable SELinux

Edit the file /etc/selinux/config. Add or correct the following lines:

SELINUX=enforcing
SELINUXTYPE=targeted

Edit the file /etc/grub.conf. Ensure that the following arguments DO NOT appear on any kernel command line in the file:

selinux=0
enforcing=0

touch
/.autorelabel

SRG-OS-000246

CCI-001427

The operating system must only allow authorized users to associate security attributes with information.

The term security label is often used to associate a set of security attributes with a specific information object as part of the data structure for that object (e.g., user access privileges, nationality, affiliation as contractor). A security label is defined as the means used to associate a set of security attributes with a specific information object as part of the data structure for that object. Security attributes are abstractions representing the basic properties or characteristics of an entity (e.g., subjects, objects) with respect to safeguarding information. These attributes are typically associated with internal data structures (e.g., records, buffers, files) within the information system and are used to enable the implementation of access control and flow control policies, reflect special dissemination, handling or distribution instructions, or support other aspects of the information security policy. Throughout the course of normal usage, authorized users of operating systems handling sensitive data will have the need to associate security attributes with information. Operating systems maintaining the binding of organization defined security attributes to data must ensure that authorized users can associate security attributes with information.

Product Meets this Requirement

Red Hat Enterprise Linux meets this requirement by design.

SRG-OS-000247

CCI-001428

The operating system must display security attributes in human-readable form on each object output from the system to system output devices to identify an organization-identified set of special dissemination, handling, or distribution instructions using organization-identified human readable, standard naming conventions.

Security attributes are abstractions representing the basic properties or characteristics of an entity (e.g., subjects, objects) with respect to safeguarding information. These attributes are typically associated with internal data structures (e.g., records, buffers, files, registry keys) within the information system and are used to enable the implementation of access control and flow control policies, reflect special dissemination, handling or distribution instructions, or support other aspects of the information security policy. The term security label is often used to associate a set of security attributes with a specific information object as part of the data structure for that object (e.g., user access privileges, nationality, affiliation as contractor). A security label is defined as the means used to associate a set of security attributes with a specific information object as part of the data structure for the object. Security attributes need to be displayed in human readable form in order to determine how the data should be disseminated, handled, and what distribution instructions apply to the data. When applications generate or output data, the associated security attributes need to be displayed.

Implementation of the Requirement is Unclear

It is unclear how to satisfy this requirement.

SRG-OS-000248

CCI-001436

The operating system must disable the use of organization-defined networking protocols within the operating system deemed to be nonsecure except for explicitly identified components in support of specific operational requirements.

Some networking protocols may not meet security requirements to protect data and components. The organization can either make a determination as to the relative security of the networking protocol or base the security decision on the assessment of other entities. Based on that assessment some may be deemed to be nonsecure except for explicitly identified components in support of specific operational requirements.

Disable telnet Service

The telnet service can be disabled with the following command:

# chkconfig telnet off

Disable rsh Service

The rsh service, which is available with the rsh-server package and runs as a service through xinetd, should be disabled. The rsh service can be disabled with the following command:

# chkconfig rsh off

Disable rlogin Service

The rlogin service, which is available with the rsh-server package and runs as a service through xinetd, should be disabled. The rlogin service can be disabled with the following command:

# chkconfig rlogin off

Disable tftp Service

The tftp service should be disabled. The tftp service can be disabled with the following command:

# chkconfig tftp off

Disable vsftpd Service

The vsftpd service can be disabled with the following command:

# chkconfig vsftpd off

SRG-OS-000249

CCI-001452

The operating system must enforce the organization-defined time period during which the limit of consecutive invalid access attempts by a user is counted.

By limiting the number of failed login attempts, the risk of unauthorized system access via user password guessing, otherwise known as brute forcing, is reduced. Limits are imposed by locking the account.

Set Deny For Failed Password Attempts

This requires further investigation.

SRG-OS-000250

CCI-001453

The operating system must use cryptography to protect the integrity of remote access sessions.

Remote access is any access to an organizational operating system by a user (or an information system) communicating through an external, non-organization-controlled network. If cryptography is not used to protect these sessions, then the session data traversing the remote connection could be intercepted and potentially modified. Cryptography provides a means to secure the remote connection to prevent unauthorized access to the data traversing the remote access connection, thereby providing a degree of integrity. The encryption strength of mechanism is selected based on the security categorization of the information traversing the remote connection.

Configure LDAP to Use TLS For All Transactions

Configure LDAP to enforce TLS use. First, edit the file /etc/pam_ldap.conf, and add or correct the following lines:

ssl start_tls

Then review the LDAP server and ensure TLS has been configured.

Configure Certificate Directives for LDAP Use of TLS

tls_cacertdir /etc/pki/tls/CA

tls_cacertfile /etc/pki/tls/CA/cacert.pem

Then review the LDAP server and ensure TLS has been configured.

SRG-OS-000251

CCI-001454

The operating system must ensure remote sessions for accessing an organization-defined list of security functions and security-relevant information are audited.

Remote access is any access to an organizational operating system by a user (or an information system) communicating through an external, non-organization-controlled network. Remote access to security functions (e.g., user management, audit log management, etc.) and security relevant information requires the activity be audited by the organization. Any operating system providing remote access must support organizational requirements to audit access or organization-defined security functions and security-relevant information.

Enable auditd Service

# chkconfig auditd on

Configure auditd Rules for Comprehensive Auditing

Tracing of arbitrary system calls (identified by name or number) on entry or exit.
Filtering by PID, UID, call success, system call argument (with some limitations), etc.
Monitoring of specific files for modifications to the file’s contents or metadata.

# service auditd restart

SRG-OS-000252

CCI-001462

The operating system must provide the capability to capture/record and log all content related to a user session.

Session auditing activities are developed, integrated, and used in consultation with legal counsel in accordance with applicable federal laws, Executive Orders, directives, policies, or regulations.

Enable auditd Service

# chkconfig auditd on

SRG-OS-000253

CCI-001694

The operating system must enforce a Discretionary Access Control (DAC) policy that includes or excludes access to the granularity of a single user.

Product Meets this Requirement

Red Hat Enterprise Linux meets this requirement by design.

SRG-OS-000254

CCI-001464

The operating system must initiate session audits at system start-up.

Session auditing activities are developed, integrated, and used in consultation with legal counsel in accordance with applicable federal laws, Executive Orders, directives, policies, or regulations.

Enable Auditing for Processes Which Start Prior to the Audit Daemon

To ensure that all processes can be audited, even those which start prior to the audit daemon, add the argument audit=1 to the kernel line in /etc/grub.conf, in the manner below:

kernel /vmlinuz-version ro vga=ext root=/dev/VolGroup00/LogVol00 rhgb quiet audit=1

SRG-OS-000255

CCI-001487

The operating system must produce audit records containing sufficient information to establish the identity of any user/subject associated with the event.

Enable auditd Service

# chkconfig auditd on

Configure auditd Rules for Comprehensive Auditing

Tracing of arbitrary system calls (identified by name or number) on entry or exit.
Filtering by PID, UID, call success, system call argument (with some limitations), etc.
Monitoring of specific files for modifications to the file’s contents or metadata.

# service auditd restart

Record attempts to alter time through adjtimex

On a 32-bit system, add the following to /etc/audit/audit.rules:

# audit_time_rules
-a always,exit -F arch=b32 -S adjtimex -k audit_time_rules

On a 64-bit system, add the following to /etc/audit/audit.rules:

# audit_time_rules
-a always,exit -F arch=b64 -S adjtimex -k audit_time_rules

-a always,exit -F arch=b64 -S adjtimex -S settimeofday -S clock_settime 
-k audit_time_rules

Record attempts to alter time through settimeofday

On a 32-bit system, add the following to /etc/audit/audit.rules:

# audit_time_rules
-a always,exit -F arch=b32 -S settimeofday -k audit_time_rules

On a 64-bit system, add the following to /etc/audit/audit.rules:

# audit_time_rules
-a always,exit -F arch=b64 -S settimeofday -k audit_time_rules

-a always,exit -F arch=b64 -S adjtimex -S settimeofday -S clock_settime 
-k audit_time_rules

Record Attempts to Alter Time Through stime

On a 32-bit system, add the following to /etc/audit/audit.rules:

# audit_time_rules
-a always,exit -F arch=b32 -S stime -k audit_time_rules

-a always,exit -F arch=b64 -S adjtimex -S settimeofday -S clock_settime 
-k audit_time_rules

Record Attempts to Alter Time Through clock_settime

On a 32-bit system, add the following to /etc/audit/audit.rules:

# audit_time_rules
-a always,exit -F arch=b32 -S clock_settime -k audit_time_rules

On a 64-bit system, add the following to /etc/audit/audit.rules:

# audit_time_rules
-a always,exit -F arch=b64 -S clock_settime -k audit_time_rules

-a always,exit -F arch=b64 -S adjtimex -S settimeofday -S clock_settime 
-k audit_time_rules

Record Attempts to Alter the localtime File

Add the following to /etc/audit/audit.rules:

-w /etc/localtime -p wa -k audit_time_rules

The -k option allows for the specification of a key in string form that can be used for better reporting capability through ausearch and aureport and should always be used.

SRG-OS-000256

CCI-001493

The operating system must protect audit tools from unauthorized access.

Protecting audit data also includes identifying and protecting the tools used to view and manipulate log data. Depending upon the log format and application, system and application log tools may provide the only means to manipulate and manage application and system log data. It is imperative that access to audit tools be controlled and protected from unauthorized access.

Product Meets this Requirement

Red Hat Enterprise Linux meets this requirement by design.

SRG-OS-000257

CCI-001494

The operating system must protect audit tools from unauthorized modification.

Protecting audit data also includes identifying and protecting the tools used to view and manipulate log data. Depending upon the log format and application, system and application log tools may provide the only means to manipulate and manage application and system log data. If the tools are compromised it could provide attackers with the capability to manipulate log data. It is imperative that audit tools be controlled and protected from unauthorized modification.

Product Meets this Requirement

Red Hat Enterprise Linux meets this requirement by design.

SRG-OS-000258

CCI-001495

The operating system must protect audit tools from unauthorized deletion.

Protecting audit data also includes identifying and protecting the tools used to view and manipulate log data. Depending upon the log format and application, system and application log tools may provide the only means to manipulate and manage application and system log data. If the tools are deleted, it would affect the administrator’s ability to access and review log data.

Product Meets this Requirement

Red Hat Enterprise Linux meets this requirement by design.

SRG-OS-000259

CCI-001499

The operating system must limit privileges to change software resident within software libraries (including privileged programs).

When dealing with change control issues, it should be noted that any changes to the hardware, software, and/or firmware components of the operating system can potentially have significant effects on the overall security of the system. Only qualified and authorized individuals must be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications.

Product Meets this Requirement

Red Hat Enterprise Linux meets this requirement by design.

SRG-OS-000260

CCI-001500

The operating system must automatically implement organization-defined safeguards and countermeasures if security functions (or mechanisms) are changed inappropriately.

Any changes to the hardware, software, and/or firmware components of the operating system can potentially have significant effects on the overall security of the system. Accordingly, only qualified and authorized individuals must be allowed to obtain access to operating system components for purposes of initiating changes, including upgrades and modifications. In order to ensure a prompt response to unauthorized changes to application security functions or security mechanisms, organizations may define countermeasures and safeguards the operating system must undertake in the event these types of operating system changes occur.

Implementation of the Requirement is Unclear

It is unclear how to satisfy this requirement.

SRG-OS-000261

CCI-001555

The operating system uniquely must identify destination domains for information transfer.

Guidance Does Not Meet this Requirement Due to Impracticality or Scope

The guidance does not meet this requirement. The requirement is impractical or out of scope.

SRG-OS-000262

CCI-001556

The operating system uniquely must authenticate destination domains for information transfer.

Guidance Does Not Meet this Requirement Due to Impracticality or Scope

The guidance does not meet this requirement. The requirement is impractical or out of scope.

SRG-OS-000263

CCI-001557

The operating system must track problems associated with the information transfer.

When an operating system transfers data, there is the chance an error or problem with the data transfer may occur. The operating system needs to track failures and any problems encountered when performing data transfers, so problems can be identified and remediated. Some potential issues with a failed or problematic data transfer include leaving sensitive data in a processing queue indefinitely, partial or incomplete data transfers, and corrupted data transfers. Tracking problems with data transfers also serves to create a forensic record that can be retained to assist in investigations regarding the flow of data.

Enable rsyslog Service

The rsyslog service provides syslog-style logging by default on RHEL 6. The rsyslog service can be enabled with the following command:

# chkconfig rsyslog on

SRG-OS-000264

CCI-001693

The operating system must enforce a Discretionary Access Control (DAC) policy that limits propagation of access rights.

Product Meets this Requirement

Red Hat Enterprise Linux meets this requirement by design.

SRG-OS-000265

CCI-001589

The operating system must ensure unauthorized, security-relevant configuration changes detected are tracked.

Configure auditd Rules for Comprehensive Auditing

Tracing of arbitrary system calls (identified by name or number) on entry or exit.
Filtering by PID, UID, call success, system call argument (with some limitations), etc.
Monitoring of specific files for modifications to the file’s contents or metadata.

# service auditd restart

SRG-OS-000266

CCI-001619

The operating system must enforce password complexity by the number of special characters used.

Password complexity, or strength, is a measure of the effectiveness of a password in resisting guessing and brute-force attacks. Password complexity is one factor in determining how long it takes to crack a password. The more complex the password is, the greater the number of possible combinations that need to be tested before the password is compromised. Use of a complex password helps to increase the time and resources required to compromise the password.

Set Password Strength Minimum Special Characters The pam_cracklib module's ocredit= parameter controls requirements for usage of special (or ``other'') characters in a password. When set to a negative number, any password will be required to contain that many special characters. When set to a positive number, pam_cracklib will grant +1 additional length credit for each special character.

SRG-OS-000267

CCI-001632

The operating system must protect non-local maintenance sessions by separating the maintenance session from other network sessions with the information system by either physically separated communications paths or logically separated communications paths.

This is a requirement that maintenance needs to be done on a separate interface or encrypted channel so as to segment maintenance activity from regular usage. When performing non-local maintenance, there is a possibility of the session being monitored and replayed to gain unauthorized access into a system.

SRG-OS-000268

CCI-001662

The operating system must take corrective actions, when unauthorized mobile code is identified.

Product Does Not Meet this Requirement Due to Impracticality or Scope

The product does not meet this requirement. The requirement is impractical or out of scope.

SRG-OS-000269

CCI-001665

The operating system must preserve organization-defined system state information in the event of a system failure.

Failure in a known state can address safety or security in accordance with the mission/business needs of the organization. Failure in a known secure state helps prevent a loss of confidentiality, integrity, or availability in the event of a failure of the operating system or a component of the system. Preserving operating system state information helps to facilitate system restart and return to the operational mode of the organization with less disruption of mission/business processes.

Product Meets this Requirement

Red Hat Enterprise Linux meets this requirement by design.

SRG-OS-000270

CCI-001668

The operating system must employ malicious code protection mechanisms at workstations, servers, or mobile computing devices on the network to detect and eradicate malicious code transported by electronic mail, electronic mail attachments, web accesses, removable media, or other common means.

In order to minimize potential negative impact to the organization that can be caused by malicious code, it is imperative that malicious code is identified and eradicated. Malicious code includes viruses, worms, Trojan horses, and spyware. The requirement states that malicious code protection mechanisms, such as anti-virus, must be used on workstations, servers, and mobile computing devices. For the operating system, this means an anti-virus application must be installed.

Install Virus Scanning Software

SRG-OS-000271

CCI-001670

The operating system must take organization-defined list of least disruptive actions to terminate suspicious events.

System availability is a key tenet of system security. Organizations need to have the flexibility to be able to define the automated actions taken in response to an identified incident. This includes being able to define a least disruptive action the operating system takes to terminate suspicious events. The least disruptive actions may include initiating a request for human response.

Product Meets this Requirement

Red Hat Enterprise Linux meets this requirement by design.

SRG-OS-000272

CCI-001674

The operating system must respond to security function anomalies in accordance with organization-defined responses and alternative action(s).

The need to verify security functionality applies to all security functions. For those security functions unable to execute automated self-tests the organization either implements compensating security controls or explicitly accepts the risk of not performing the verification as required. Information system transitional states include startup, restart, shutdown, and abort.

Product Meets this Requirement

Red Hat Enterprise Linux meets this requirement by design.

SRG-OS-000273

CCI-000086

The operating system must enforce requirements for the connection of mobile devices to operating systems.

Wireless access introduces security risks which must be addressed through implementation of strict controls and procedures such as authentication, encryption, and defining what resources that can be accessed. The organization will define the requirements for connection of mobile devices. In order to ensure that the connection provides adequate integrity and confidentiality of the connection, the operating system must enforce these requirements.

Iptables and Ip6tables

SRG-OS-000274

CCI-001683

The operating system must notify, as required, appropriate individuals when accounts are created.

Monitoring account creation is critical to ensure only appropriate personnel have access to the operating system. This reduces the possibility a rogue account will be created. In order to facilitate the monitoring, the operating system must notify designated personnel when an account is created.

Record Events that Modify User/Group Information

Add the following to /etc/audit/audit.rules, in order to capture events that modify account changes:

# audit_account_changes
-w /etc/group -p wa -k audit_account_changes
-w /etc/passwd -p wa -k audit_account_changes
-w /etc/gshadow -p wa -k audit_account_changes
-w /etc/shadow -p wa -k audit_account_changes
-w /etc/security/opasswd -p wa -k audit_account_changes

SRG-OS-000275

CCI-001684

The operating system must notify, as required, appropriate individuals when accounts are modified.

Monitoring account modification is critical to ensure only appropriate personnel have access to the operating system. This reduces the possibility that an account will be given more access than is intended. In order to facilitate the monitoring, the operating system must notify designated personnel when an account is modified.

Record Events that Modify User/Group Information

Add the following to /etc/audit/audit.rules, in order to capture events that modify account changes:

# audit_account_changes
-w /etc/group -p wa -k audit_account_changes
-w /etc/passwd -p wa -k audit_account_changes
-w /etc/gshadow -p wa -k audit_account_changes
-w /etc/shadow -p wa -k audit_account_changes
-w /etc/security/opasswd -p wa -k audit_account_changes

SRG-OS-000276

CCI-001685

The operating system must notify, as required, appropriate individuals when account is disabled.

Monitoring account disabling is critical to ensure a denial of service situation does not exist on the operating system. An unexpected account deletion can also be a sign of a rogue administrator account that may be deleting traces of activity. In order to facilitate the monitoring, the operating system must notify designated personnel when an account is disabled.

Record Events that Modify User/Group Information

Add the following to /etc/audit/audit.rules, in order to capture events that modify account changes:

# audit_account_changes
-w /etc/group -p wa -k audit_account_changes
-w /etc/passwd -p wa -k audit_account_changes
-w /etc/gshadow -p wa -k audit_account_changes
-w /etc/shadow -p wa -k audit_account_changes
-w /etc/security/opasswd -p wa -k audit_account_changes

SRG-OS-000277

CCI-001686

The operating system must notify, as required, appropriate individuals for account termination.

Monitoring account termination is critical to ensure a denial of service situation does not exist on the operating system. An unexpected account termination can also be a sign of a rogue administrator account that may be deleting traces of activity. In order to facilitate the monitoring, the operating system must notify designated personnel when an account is terminated.

Record Events that Modify User/Group Information

Add the following to /etc/audit/audit.rules, in order to capture events that modify account changes:

# audit_account_changes
-w /etc/group -p wa -k audit_account_changes
-w /etc/passwd -p wa -k audit_account_changes
-w /etc/gshadow -p wa -k audit_account_changes
-w /etc/shadow -p wa -k audit_account_changes
-w /etc/security/opasswd -p wa -k audit_account_changes

SRG-OS-000278

CCI-001496

The operating system must use cryptographic mechanisms to protect the integrity of audit tools.

Auditing and logging are key components of any security architecture. It is essential security personnel know what is being done, what attempted to be done, where it was done, when it was done, and by whom in order to compile an accurate risk assessment. Cryptographic mechanisms must be used to protect the integrity of the audit tools used for audit reduction and reporting.

Configure Periodic Execution of AIDE

AIDE should be executed on a periodic basis to check for changes. To implement a daily execution of AIDE at 4:05am using cron, add the following line to /etc/crontab:

05 4 * * * root /usr/sbin/aide --check

AIDE can be executed periodically through other means; this is merely one example.

Verify File Hashes with RPM

The RPM package management system can check the hashes of installed software packages, including many that are important to system security. Run the following command to list which files on the system have hashes that differ from what is expected by the RPM database:

# rpm -Va | grep '^..5'

A “c” in the second column indicates that a file is a configuration file, which may appropriately be expected to change.

SRG-OS-NA

CCI-000833

The operating system must employ automated mechanisms to assist in the tracking of security incidents.

This is not applicable for operating systems. This requirement is specific for monitoring applications or network devices that are purposed for this requirement.

SRG-OS-NA

CCI-000870

The operating system must check all media containing diagnostic and test programs for malicious code before the media can be used in the information system.

This is not applicable for operating systems. Operating systems require the use of malicious code protection. It is the requirement of that software to check media.

SRG-OS-NA

CCI-001119

The operating system must isolate organization-defined key information security tools, mechanisms, and support components from other internal information system components via physically separate subnets with managed interfaces to other portions of the system.

This is a physical separation requirement and is not applicable.

SRG-OS-NA

CCI-001249

The operating system must update malicious code protection mechanisms only when directed by a privileged user.

This is not applicable for operating systems. This requirement would be for the malicious code protection application.

SRG-OS-NA

CCI-001259

The organization must interconnect and configure individual intrusion detection tools into a system-wide intrusion detection system using common protocols.

This requirement concerns work connection of devices and is not applicable to operating systems.

SRG-OS-NA

CCI-001262

The operating system must monitor inbound and outbound communications for unusual or unauthorized activities or conditions.

This is not applicable for operating systems. This requirement would be for the IDS/IPS device or application.

SRG-OS-NA

CCI-001266

The operating system must notify an organization-defined list of incident response personnel (identified by name and/or by role) of suspicious events.

This is not applicable for operating systems. This requirement would be for the IDS/IPS device or application.

SRG-OS-NA

CCI-001272

The operating system must make provisions so encrypted traffic is visible to information system monitoring tools.

This requirement is a combination of the network placement and the applications being used and is not applicable for operating systems.

SRG-OS-NA

CCI-001273

The operating system must analyze outbound communications traffic at the external boundary of the system (i.e., system perimeter).

This is not applicable for the operating system. This is a network perimeter requirement.

SRG-OS-NA

CCI-001463

The operating system must provide the capability to remotely view/hear all content related to an established user session in real time.

If required at the operating system, this requirement will be fulfilled by an application. This requirement is not applicable for operating systems.

SRG-OS-NA

CCI-001167

The operating system must ensure the development of mobile code to be deployed in information systems meets organization-defined mobile code requirements.

This requirement is not applicable to operating systems as operating systems do not control the development of the code.

SRG-OS-NA

CCI-001178

The information system must provide additional data origin and integrity artifacts along with the authoritative data the system returns in response to name/address resolution queries.

This is a resolution issue and is not applicable for operating systems.

SRG-OS-NA

CCI-001574

The information system must reject or delay, as defined by the organization, network traffic generated above configurable traffic volume thresholds.

This is a network traffic requirement and is not applicable for operating systems.

SRG-OS-NA

CCI-001179

The operating system, when operating as part of a distributed, hierarchical namespace, must provide the means to indicate the security status of child subspaces and (if the child supports secure resolution services) enable verification of a chain of trust.

This is a resolution issue and is not applicable for operating systems.

SRG-OS-NA

CCI-001180

The information system must perform data origin authentication and data integrity verification on the name/address resolution responses the system receives from authoritative sources when requested by client systems.

This is a resolution issue and is not applicable for operating systems.

SRG-OS-NA

CCI-001181

The information system must perform data origin authentication and data integrity verification on all resolution responses received whether or not local client systems explicitly request this service.

This is a resolution issue and is not applicable for operating systems.

SRG-OS-NA

CCI-001182

The information systems that collectively provide name/address resolution service for an operating system must be fault-tolerant.

This is a resolution issue and is not applicable for operating systems.

SRG-OS-NA

CCI-001663

The information system, when operating as part of a distributed, hierarchical namespace, must provide the means to enable verification of a chain of trust among parent and child domains (if the child supports secure resolution services).

This is a resolution issue and is not applicable for operating systems.

SRG-OS-NA

CCI-001664

The operating system must recognize only system-generated session identifiers.

This requirement focuses on communications protection at the application session, versus network packet level and is not applicable for operating systems.

SRG-OS-NA

CCI-001183

The information systems collectively must provide name/address resolution service for an operating system implement internal/external role separation.

This is a resolution issue and is not applicable for operating systems.

SRG-OS-NA

CCI-001184

The operating system must provide mechanisms to protect the authenticity of communications sessions.

This control focuses on communications protection at the application session, versus packet level and is not applicable for operating systems.

SRG-OS-NA

CCI-001671

The operating system must analyze outbound communications traffic at selected interior points within the system (e.g., subnets, subsystems), as deemed necessary, to discover anomalies.

This is a networking component requirement and is not applicable to operating system.

SRG-OS-NA

CCI-001185

The operating system must invalidate session identifiers upon user logout or other session termination.

This requirement focuses on communications protection at the application session, versus network packet level and is not applicable for operating systems.

SRG-OS-NA

CCI-001672

The operating system must employ a wireless intrusion detection system to detect attack attempts to the information system.

This is a network monitoring traffic analysis requirement to deploy wireless intrusion detection system. This is not applicable for operating systems.

SRG-OS-NA

CCI-001186

The information system must provide a readily observable logout capability whenever authentication is used to gain access to web pages.

Since this requirement is specific for web pages, it is not applicable for operating systems.

SRG-OS-NA

CCI-001673

The operating system must employ a wireless intrusion detection system to detect potential compromises/breaches to the information system.

This is a network monitoring traffic analysis requirement to deploy wireless intrusion detection system. This is not applicable for operating systems.

SRG-OS-NA

CCI-001187

The operating system must generate a unique session identifier for each session.

This requirement focuses on communications protection at the application session, versus network packet level and is not applicable for operating systems.

SRG-OS-NA

CCI-001188

The operating system must generate unique session identifiers with organization-defined randomness requirements.

This requirement focuses on communications protection at the application session, versus network packet level and is not applicable for operating systems.

SRG-OS-NA

CCI-001677

The operating system must employ malicious code protection mechanisms at workstations, servers, or mobile computing devices on the network to detect and take action on unsolicited messages transported by electronic mail, electronic mail attachments, web access, ,removable media, or other common means.

This is not applicable for operating systems. This requirement would be for the malicious code protection application.

SRG-OS-NA

CCI-001196

The information system must include components proactively seeking to identify web-based malicious code.

This is an application specific requirement is not applicable for operating systems.

SRG-OS-NA

CCI-001305

The operating system must employ malicious code protection mechanisms at operating system entry and exit points to detect and take action on unsolicited messages transported by electronic mail, electronic mail attachments, web accesses, removable media or other common means.

This is not applicable for operating systems. This requirement would be for the malicious code protection application.

SRG-OS-NA

CCI-001306

The operating system must update spam protection mechanisms (including signature definitions) when new releases are available in accordance with organizational configuration management policy and procedures.

This is an email requirement and is not applicable to operating systems.

SRG-OS-NA

CCI-001308

The information system must automatically update spam protection mechanisms (including signature definitions).

This is an email requirement and is not applicable to operating system.

SRG-OS-NA

CCI-001240

The operating system must update malicious code protection mechanisms (including signature definitions) whenever new releases are available in accordance with organizational configuration management policy and procedures.

This is not applicable for operating systems. This requirement would be for the malicious code protection application.

SRG-OS-NA

CCI-001241

The operating system must configure malicious code protection mechanisms to perform periodic scans of the information system on an organization-defined frequency.

This is not applicable for operating systems. This requirement would be for the malicious code protection application.

SRG-OS-NA

CCI-001242

The operating system must configure malicious code protection mechanisms to perform real-time scans of files from external sources as the files are downloaded, opened, or executed in accordance with organizational security policy.

This is not applicable for operating systems. This requirement would be for the malicious code protection application.

SRG-OS-NA

CCI-001243

The operating system must configure malicious code protection mechanisms to perform organization-defined action(s) in response to malicious code detection.

This is not applicable for operating systems. This requirement would be for the malicious code protection application.

SRG-OS-NA

CCI-001245

The operating system must address the receipt of false positives during malicious code detection and eradication and the resulting potential impact on the availability of the information system.

This is not applicable for operating systems. This requirement would be for the malicious code protection application.

SRG-OS-NA

CCI-001247

The operating system must automatically update malicious code protection mechanisms, including signature definitions.

This is not applicable for operating systems. This requirement would be for the malicious code protection application.

SRG-OS-NA

CCI-000145

The information system must enforce configurable traffic volume thresholds representing auditing capacity for network traffic.

This is not applicable for operating systems as network traffic monitoring is outside the scope of the operating system monitoring.

SRG-OS-NA

CCI-000152

To support audit review, analysis, and reporting the operating system must integrate audit review, analysis, and reporting processes to support organizational processes for investigation and response to suspicious activities.

This is not applicable to operating systems. The data from the operating system will be used by an application which will meet the requirement.

SRG-OS-NA

CCI-001688

The operating system must ensure the acquisition of mobile code to be deployed in information systems meets organization-defined mobile code requirements.

This requirement is not applicable to operating systems as the acquisition of operating systems does not impact mobile code.

SRG-OS-NA

CCI-001443

The operating system must protect wireless access to the system using authentication.

This is a network element check and does not apply to operating systems.

SRG-OS-NA

CCI-001444

The operating system must protect wireless access to the system using encryption.

This is a network element check and does not apply to the operating system.

SRG-OS-NA

CCI-000069

The operating system must route all remote accesses through managed access control points.

This is a network control and is not applicable to operating systems.

SRG-OS-NA

CCI-000071

The operating system must monitor for unauthorized remote connections to the information system on an organization-defined frequency.

This is a network control and is not applicable to the operating system.

SRG-OS-NA

CCI-000417

The operating system must disable network access by components/devices or notifies designated organizational officials.

This is a network function and is not applicable to operating systems.

SRG-OS-NA

CCI-001121

The operating system must protect against unauthorized physical connections across the boundary protections implemented at an organization-defined list of managed interfaces.

This is a network boundary check and is not applicable to operating systems.

SRG-OS-NA

CCI-001687

The operating system must ensure the use of mobile code to be deployed in information systems meets organization-defined mobile code requirements.

This is an application requirement and does not apply to operating systems.