CCIs from Operating System Security Requirements Guide Mapped to 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.
Guidance Does Not Meet this Requirement Due to Impracticality or Scope This requirement is NA. No fix is required.
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 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/default/useradd, substituting NUM_DAYS appropriately:
INACTIVE=
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.
Assign Expiration Date to Temporary Accounts In the event temporary or emergency accounts are required, configure the system to terminate them after a documented time period. For every temporary and emergency account, run the following command to set an expiration date on it, substituting USER and YYYY-MM-DD appropriately:
$ sudo chage -E YYYY-MM-DD USER
YYYY-MM-DD indicates the documented expiration date for the account.
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 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/default/useradd, substituting NUM_DAYS appropriately:
INACTIVE=
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-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_rules_usergroup_modification
-w /etc/group -p wa -k audit_rules_usergroup_modification
-w /etc/passwd -p wa -k audit_rules_usergroup_modification
-w /etc/gshadow -p wa -k audit_rules_usergroup_modification
-w /etc/shadow -p wa -k audit_rules_usergroup_modification
-w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification
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 Not Supported This requirement is a permanent finding and cannot be fixed. An appropriate mitigation for the system must be implemented but this finding cannot be considered fixed.
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 This requirement is NA. No fix is required.
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 Not Disabled in /etc/grub.conf SELinux can be disabled at boot time by an argument in /etc/grub.conf. Remove any instances of selinux=0 from the kernel arguments in that file to prevent SELinux from being disabled at boot.
Ensure SELinux State is Enforcing The SELinux state should be set to at system boot time. In the file /etc/selinux/config, add or correct the following line to configure the system to boot into enforcing mode:
SELINUX=
Configure SELinux Policy The SELinux targeted policy is appropriate for general-purpose desktops and servers, as well as systems in many other roles. To configure the system to use this policy, add or correct the following line in /etc/selinux/config:
SELINUXTYPE=
Other policies, such as mls, provide additional security labeling and greater confinement but are not compatible with many general-purpose use cases.
Ensure No Device Files are Unknown to SELinux Device files, which are used for communication with important system resources, should be labeled with proper SELinux types. If any device files carry the SELinux type device_t, report the bug so that policy can be corrected. Supply information about what the device is and what programs use it.
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 This requirement is NA. No fix is required.
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 This requirement is NA. No fix is required.
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.
Ensure SELinux State is Enforcing The SELinux state should be set to at system boot time. In the file /etc/selinux/config, add or correct the following line to configure the system to boot into enforcing mode:
SELINUX=
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. 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. The operating system must enforce flow control decisions based upon changing conditions.
Guidance Does Not Meet this Requirement Due to Impracticality or Scope This requirement is NA. No fix is required.
SRG-OS-000012 CCI-000028 The operating system must prevent encrypted data from bypassing content checking mechanisms. 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. When data is encrypted, mechanisms designed to examine data content to detect attacks or malicious code are unable to accomplish this task unless they are capable of unencrypting the data.
Guidance Does Not Meet this Requirement Due to Impracticality or Scope This requirement is NA. No fix is required.
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 This requirement is NA. No fix is required.
SRG-OS-000014 CCI-000030 The operating system must enforce information flow control on metadata. 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. Metadata is defined as data providing information about one or more other pieces of data, such as, purpose of the data, author/creator of the data, network location of where data was created, and application specific data information.
Guidance Does Not Meet this Requirement Due to Impracticality or Scope This requirement is NA. No fix is required.
SRG-OS-000015 CCI-000031 The operating system must support organization-defined one-way flows using hardware mechanisms. 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. The operating system must be able to support the hardware mechanisms associated with one way data flows.
Implementation of the Requirement is Not Supported This requirement is a permanent finding and cannot be fixed. An appropriate mitigation for the system must be implemented but this finding cannot be considered fixed.
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. 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. Organization-defined security policy filters may include, dirty word filters, file type checking filters, structured data filters, unstructured data filters, metadata content filters, and hidden content filters.
Ensure SELinux Not Disabled in /etc/grub.conf SELinux can be disabled at boot time by an argument in /etc/grub.conf. Remove any instances of selinux=0 from the kernel arguments in that file to prevent SELinux from being disabled at boot.
Ensure SELinux State is Enforcing The SELinux state should be set to at system boot time. In the file /etc/selinux/config, add or correct the following line to configure the system to boot into enforcing mode:
SELINUX=
Configure SELinux Policy The SELinux targeted policy is appropriate for general-purpose desktops and servers, as well as systems in many other roles. To configure the system to use this policy, add or correct the following line in /etc/selinux/config:
SELINUXTYPE=
Other policies, such as mls, provide additional security labeling and greater confinement but are not compatible with many general-purpose use cases.
Ensure No Device Files are Unknown to SELinux Device files, which are used for communication with important system resources, should be labeled with proper SELinux types. If any device files carry the SELinux type device_t, report the bug so that policy can be corrected. Supply information about what the device is and what programs use it.
Verify ip6tables Enabled if Using IPv6 The ip6tables service can be enabled with the following command:
$ sudo chkconfig --level 2345 ip6tables on
Verify iptables Enabled The iptables service can be enabled with the following command:
$ sudo chkconfig --level 2345 iptables on
SRG-OS-000017 CCI-000034 The operating system must provide the capability for a privileged administrator to enable/disable organization-defined security policy filters. 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. Organization-defined security policy filters may include, dirty word filters, file type checking filters, metadata content filters, and hidden content filters. In order to effectively manage these filters, the operating system must provide the mechanism to enable/disable these filters.
Product Meets this Requirement This requirement is a permanent not a finding. No fix is required.
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. 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. Organization-defined security policy filters may include, dirty word filters, file type checking filters, metadata content filters, and hidden content filters. In order to effectively manage these filters, the operating system must provide the mechanism to configure these filters.
Product Meets this Requirement This requirement is a permanent not a finding. No fix is required.
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 This requirement is NA. No fix is required.
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 / setgid programs, run the following command for each local partition PART:
$ sudo find PART -xdev -type f -perm -4000 -o -type f -perm -2000 2>/dev/null
Then, for each setuid / setgid 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 / setgid 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 To configure the system to lock out accounts after a number of incorrect login attempts using pam_faillock.so, modify the content of both /etc/pam.d/system-auth and /etc/pam.d/password-auth as follows:

  • Add the following line immediately before the pam_unix.so statement in the AUTH section:
    auth required pam_faillock.so preauth silent deny= unlock_time= fail_interval=
  • Add the following line immediately after the pam_unix.so statement in the AUTH section:
    auth [default=die] pam_faillock.so authfail deny= unlock_time= fail_interval=
  • Add the following line immediately before the pam_unix.so statement in the ACCOUNT section:
    account required pam_faillock.so
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 Lockout Time For Failed Password Attempts To configure the system to lock out accounts after a number of incorrect login attempts and require an administrator to unlock the account using pam_faillock.so, modify the content of both /etc/pam.d/system-auth and /etc/pam.d/password-auth as follows:

  • Add the following line immediately before the pam_unix.so statement in the AUTH section:
    auth required pam_faillock.so preauth silent deny= unlock_time= fail_interval=
  • Add the following line immediately after the pam_unix.so statement in the AUTH section:
    auth [default=die] pam_faillock.so authfail deny= unlock_time= fail_interval=
  • Add the following line immediately before the pam_unix.so statement in the ACCOUNT section:
    account required pam_faillock.so
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 To configure the system login banner:

Edit /etc/issue. Replace the default text with a message compliant with the local site policy or a legal disclaimer. The DoD required text is either:

You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions:
-The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.
-At any time, the USG may inspect and seize data stored on this IS.
-Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.
-This IS includes security measures (e.g., authentication and access controls) to protect USG interests -- not for your personal benefit or privacy.
-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details.


OR:

Use of this or any other DoD interest computer system constitutes consent to monitoring at all times.
This is a DoD interest computer system. All DoD interest computer systems and related equipment are intended for the communication, transmission, processing, and storage of official U.S. Government or other authorized information only. All DoD interest computer systems are subject to monitoring at all times to ensure proper functioning of equipment and systems including security devices and systems, to prevent unauthorized use and violations of statutes and security regulations, to deter criminal activity, and for other similar purposes. Any user of a DoD interest computer system should be aware that any information placed in the system is subject to monitoring and is not subject to any expectation of privacy.
If monitoring of this or any other DoD interest computer system reveals possible evidence of violation of criminal statutes, this evidence and any other related information, including identification information about the user, may be provided to law enforcement officials. If monitoring of this or any other DoD interest computer systems reveals violations of security regulations or unauthorized use, employees who violate security regulations or make unauthorized use of DoD interest computer systems are subject to appropriate disciplinary action.
Use of this or any other DoD interest computer system constitutes consent to monitoring at all times.


OR:

I've read & consent to terms in IS user agreem't.
Enable GUI Warning Banner To enable displaying a login warning banner in the GNOME Display Manager's login screen, run the following command:
$ sudo gconftool-2 --direct \
  --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory \
  --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 gconftool-2 --direct \
  --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory \
  --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 either to the /etc/gconf/gconf.xml.mandatory/%gconf-tree.xml if it exists or to the file /etc/gconf/gconf.xml.mandatory/apps/gdm/simple-greeter/%gconf.xml. Either of these files 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 gconftool-2 --direct \
  --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory \
  --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.
Implementation of the Requirement is Not Supported This requirement is a permanent finding and cannot be fixed. An appropriate mitigation for the system must be implemented but this finding cannot be considered fixed.
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.
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. The DoD requirement is 10. To set the number of concurrent sessions per user add the following line in /etc/security/limits.conf:
* hard maxlogins 
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 This requirement is a permanent not a finding. No fix is required.
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 Run the following command to set the idle time-out value for inactivity in the GNOME desktop to minutes:
$ sudo gconftool-2 \
  --direct \
  --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory \
  --type int \
  --set /desktop/gnome/session/idle_delay 
GNOME Desktop Screensaver Mandatory Use Run the following command to activate the screensaver in the GNOME desktop after a period of inactivity:
$ sudo 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 Run the following command to activate locking of the screensaver in the GNOME desktop when it is activated:
$ sudo 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 screen Package To enable console screen locking, install the screen package:
$ sudo yum install screen
Instruct users to begin new terminal sessions with the following command:
$ screen
The console can now be locked with the following key combination:
ctrl+a x
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 Screensaver Run the following command to set the screensaver mode in the GNOME desktop to a blank screen:
$ sudo 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:
$ sudo chkconfig --level 2345 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.
Disable telnet Service The telnet service can be disabled with the following command:
$ sudo chkconfig telnet off
Disable rexec Service The rexec service, which is available with the rsh-server package and runs as a service through xinetd, should be disabled. The rexec service can be disabled with the following command:
$ sudo chkconfig rexec 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:
$ sudo chkconfig rsh off
Use Only Approved MACs Limit the MACs to those hash algorithms which are FIPS-approved. The following line in /etc/ssh/sshd_config demonstrates use of FIPS-approved MACs:
MACs hmac-sha2-512,hmac-sha2-256,hmac-sha1
The man page sshd_config(5) contains a list of supported MACs.
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 To prevent USB storage devices from being used, configure the kernel module loading system to prevent automatic loading of the USB storage driver. To configure the system to prevent the usb-storage kernel module from being loaded, add the following line to a file in the directory /etc/modprobe.d:
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 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 may be possible to configure filesystem mounts statically by editing /etc/fstab rather than relying on the automounter.

The autofs service can be disabled with the following command:
$ sudo chkconfig autofs off
Disable WiFi or Bluetooth in 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 be used to determine whether wireless support 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:
$ sudo 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:
$ sudo rm /etc/sysconfig/network-scripts/ifcfg-interface
Disable Bluetooth Service The bluetooth service can be disabled with the following command:
$ sudo chkconfig bluetooth off
$ sudo service bluetooth stop
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 bluetooth /bin/true
Product Meets this Requirement This requirement is a permanent not a finding. No fix is required.
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. Preventing the direct execution of binaries from removable media (such as a USB key) provides a defense against malicious software that may be present on such untrusted media. Add the noexec option to the fourth column of /etc/fstab for the line which controls mounting of any removable media partitions.
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 This requirement is a permanent not a finding. No fix is required.
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 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:
$ sudo chkconfig --level 2345 auditd on
Enable Auditing for Processes Which Start Prior to the Audit Daemon To ensure 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
Product Meets this Requirement This requirement is a permanent not a finding. No fix is required.
SRG-OS-000038 CCI-000131 The operating system must produce audit records containing sufficient information to establish when (date and time) the 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. Without sufficient information establishing where the audit events occurred, investigation into the cause of events is severely hindered.
Product Meets this Requirement This requirement is a permanent not a finding. No fix is required.
SRG-OS-000039 CCI-000132 The operating system must produce audit records containing sufficient information to establish where the 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. Without sufficient information establishing where the audit events occurred, investigation into the cause of events is severely hindered.
Product Meets this Requirement This requirement is a permanent not a finding. No fix is required.
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 This requirement is a permanent not a finding. No fix is required.
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 This requirement is a permanent not a finding. No fix is required.
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.
Product Meets this Requirement This requirement is a permanent not a finding. No fix is required.
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
Configure auditd to use audispd's syslog plugin To configure the auditd service to use the syslog plug-in of the audispd audit event multiplexor, set the active line in /etc/audisp/plugins.d/syslog.conf to yes. Restart the auditd service:
$ sudo service auditd restart
SRG-OS-000044 CCI-000137 The operating system must allocate audit record storage capacity. 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. It is imperative the operating system configured, allocate storage capacity to contain audit records.
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. 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. Care must be taken to evaluate that the audit records being produced do not exceed the 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.
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 insufficient. 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. 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.
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 = 
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. Acceptable values also include suspend, single, and halt.
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
Set this value to single to cause the system to switch to single-user mode for corrective action. Acceptable values also include suspend and halt. For certain systems, the need for availability outweighs the need to log all actions, and a different setting should be determined. Details regarding all possible values for ACTION are described in the auditd.conf man page.
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. Acceptable values also include suspend, single, and 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 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 = 
Implementation of the Requirement is Not Supported This requirement is a permanent finding and cannot be fixed. An appropriate mitigation for the system must be implemented but this finding cannot be considered fixed.
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 This requirement is a permanent not a finding. No fix is required.
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 This requirement is a permanent not a finding. No fix is required.
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.
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:
$ sudo chkconfig --level 2345 auditd on
Product Meets this Requirement This requirement is a permanent not a finding. No fix is required.
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 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:
$ sudo chkconfig --level 2345 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 This requirement is a permanent not a finding. No fix is required.
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:
$ sudo chkconfig --level 2345 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 This requirement is a permanent not a finding. No fix is required.
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 This requirement is a permanent not a finding. No fix is required.
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 This requirement is a permanent not a finding. No fix is required.
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 This requirement is NA. No fix is required.
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 Audit Logs Must Have Mode 0640 or Less Permissive If log_group in /etc/audit/auditd.conf is set to a group other than the root group account, change the mode of the audit log files with the following command:
$ sudo chmod 0640 audit_file

Otherwise, change the mode of the audit log files with the following command:
$ sudo chmod 0600 audit_file
System Audit Logs Must Be Owned By Root To properly set the owner of /var/log, run the command:
$ sudo chown root /var/log 
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.
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 -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
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 -k audit_time_rules
Record Attempts to Alter Time Through stime Add the following line to /etc/audit/audit.rules for both 32-bit and 64-bit systems:
# audit_time_rules
-a always,exit -F arch=b32 -S stime -k audit_time_rules
Since the 64-bit version of the "stime" system call is not defined in the audit lookup table, the corresponding "-F arch=b64" form of this rule is not expected to be defined on 64-bit systems (the aforementioned "-F arch=b32" stime rule form itself is sufficient for both 32-bit and 64-bit systems). 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 -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:
# time-change
-a always,exit -F arch=b32 -S clock_settime -F a0=0x0 -F key=time-change
On a 64-bit system, add the following to /etc/audit/audit.rules:
# time-change
-a always,exit -F arch=b64 -S clock_settime -F a0=0x0 -F key=time-change
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 -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.
Product Meets this Requirement This requirement is a permanent not a finding. No fix is required.
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. 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 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:
$ sudo chkconfig --level 2345 auditd on
Product Meets this Requirement This requirement is a permanent not a finding. No fix is required.
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.
Product Meets this Requirement This requirement is a permanent not a finding. No fix is required.
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.
Product Meets this Requirement This requirement is a permanent not a finding. No fix is required.
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 This requirement is a permanent not a finding. No fix is required.
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.
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. Add ucredit=-1 after pam_cracklib.so to require use of an upper case character in passwords.
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. Add lcredit=-1 after pam_cracklib.so to require use of a lowercase character in passwords.
SRG-OS-000071 CCI-000194 The operating system must enforce password complexity by the number of numeric 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 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. Add dcredit=-1 after pam_cracklib.so to require use of a digit in passwords.
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. Add difok= after pam_cracklib.so to require differing characters when changing passwords. The DoD requirement is 4.
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 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.
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:
$ sudo 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:
PASS_MIN_DAYS 
A value of 1 day is considered for sufficient for many environments. The DoD requirement is 1.
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:
PASS_MAX_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 or pam_pwhistory PAM modules. In the file /etc/pam.d/system-auth, append remember= to the line which refers to the pam_unix.so or pam_pwhistory.somodule, as shown below:
  • for the pam_unix.so case:
    password sufficient pam_unix.so existing_options remember=
  • for the pam_pwhistory.so case:
    password requisite pam_pwhistory.so existing_options remember=
The DoD STIG requirement is 5 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 


The DoD requirement is 14. The FISMA requirement is 12. 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.
Set Password Minimum Length The pam_cracklib module's minlen parameter controls requirements for minimum characters required in a password. Add minlen= after pam_pwquality to set minimum password length 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 This requirement is a permanent not a finding. No fix is required.
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 the following command:
$ grub-crypt --sha-512
When 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
NOTE: To meet FISMA Moderate, the bootloader password MUST differ from the root password.
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
Disable Interactive Boot To disable the ability for users to perform interactive startups, perform both of the following:
  1. Edit the file /etc/sysconfig/init. Add or correct the line:
    PROMPT=no
  2. Inspect the kernel boot arguments (which follow the word kernel) in /etc/grub.conf and ensure the confirm argument is not present.
Both the PROMPT option of the /etc/sysconfig/init file and the confirm kernel boot argument of the /etc/grub.conf file allow the console user to perform an interactive system startup, in which it is possible to select the set of services which are started on boot.
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. 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. Flow control is based on the characteristics of the information and/or the information path. A security domain is defined as a domain that implements a security policy and is administered by a single authority. Data type specification and usage include using file naming to reflect type of data and limiting data transfer based on file type.
Guidance Does Not Meet this Requirement Due to Impracticality or Scope This requirement is NA. No fix is required.
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. 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 that information. Policy enforcement mechanisms include the filtering and/or sanitization rules that are applied to information prior to transfer to a different security domain. Parsing transfer files facilitates policy decisions on source, destination, certificates, classification, subject, attachments, and other information security-related component differentiators. Policy rules for cross domain transfers include, limitations on embedding components/information types within other components/information types, prohibiting more than two-levels of embedding, and prohibiting the transfer of archived information types.
Guidance Does Not Meet this Requirement Due to Impracticality or Scope This requirement is NA. No fix is required.
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 This requirement is NA. No fix is required.
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 This requirement is a permanent not a finding. No fix is required.
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 This requirement is a permanent not a finding. No fix is required.
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 This requirement is a permanent not a finding. No fix is required.
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 This requirement is a permanent not a finding. No fix is required.
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.
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:
$ sudo chkconfig --level 2345 auditd on
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 controls whether RPM packages' signatures are always checked prior to installation. To configure yum to check package signatures before installing them, ensure the following line appears in /etc/yum.conf in the [main] section:
gpgcheck=1
Ensure gpgcheck Enabled For All Yum Package Repositories To ensure 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 This requirement is NA. No fix is required.
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 This requirement is NA. No fix is required.
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 This requirement is NA. No fix is required.
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.
Build and Test AIDE Database Run the following command to generate a new database:
$ sudo /usr/sbin/aide --init
By default, the database will be written to the file /var/lib/aide/aide.db.new.gz. Storing the database, the configuration file /etc/aide.conf, and the binary /usr/sbin/aide (or hashes of these files), in a secure location (such as on read-only media) provides additional assurance about their integrity. The newly-generated database can be installed as follows:
$ sudo cp /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz
To initiate a manual check, run the following command:
$ sudo /usr/sbin/aide --check
If this check produces any unexpected output, investigate.
Configure Periodic Execution of AIDE 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-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.
Uninstall telnet-server Package The telnet-server package can be uninstalled with the following command:
$ sudo yum erase telnet-server
Uninstall rsh-server Package The rsh-server package can be uninstalled with the following command:
$ sudo yum erase rsh-server
Uninstall ypserv Package The ypserv package can be uninstalled with the following command:
$ sudo yum erase ypserv
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:
$ sudo chkconfig abrtd 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:
$ sudo chkconfig netconsole 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:
$ sudo chkconfig oddjobd 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:
$ sudo chkconfig atd off
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 DCCP Support The Datagram Congestion Control Protocol (DCCP) is a relatively new transport layer protocol, designed to support streaming media and telephony. To configure the system to prevent the dccp kernel module from being loaded, add the following line to a file in the directory /etc/modprobe.d:
install dccp /bin/true
Disable SCTP Support The Stream Control Transmission Protocol (SCTP) is a transport layer protocol, designed to support the idea of message-oriented communication, with several streams of messages within one connection. To configure the system to prevent the sctp kernel module from being loaded, add the following line to a file in the directory /etc/modprobe.d:
install sctp /bin/true
Disable RDS Support The Reliable Datagram Sockets (RDS) protocol is a transport layer protocol designed to provide reliable high- bandwidth, low-latency communications between nodes in a cluster. To configure the system to prevent the rds kernel module from being loaded, add the following line to a file in the directory /etc/modprobe.d:
install rds /bin/true
Disable TIPC Support The Transparent Inter-Process Communication (TIPC) protocol is designed to provide communications between nodes in a cluster. To configure the system to prevent the tipc kernel module from being loaded, add the following line to a file in the directory /etc/modprobe.d:
install tipc /bin/true
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:
$ sudo chkconfig ntpdate 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:
$ sudo chkconfig qpidd 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:
$ sudo 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:
$ sudo chkconfig rhnsd off
Disable Postfix Network Listening Edit the file /etc/postfix/main.cf to ensure that only the following inet_interfaces line appears:
inet_interfaces = localhost
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 This requirement is a permanent not a finding. No fix is required.
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.
Build and Test AIDE Database Run the following command to generate a new database:
$ sudo /usr/sbin/aide --init
By default, the database will be written to the file /var/lib/aide/aide.db.new.gz. Storing the database, the configuration file /etc/aide.conf, and the binary /usr/sbin/aide (or hashes of these files), in a secure location (such as on read-only media) provides additional assurance about their integrity. The newly-generated database can be installed as follows:
$ sudo cp /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz
To initiate a manual check, run the following command:
$ sudo /usr/sbin/aide --check
If this check produces any unexpected output, investigate.
Configure Periodic Execution of AIDE 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 This requirement is NA. No fix is required.
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 This requirement is NA. No fix is required.
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 This requirement is NA. No fix is required.
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.
Guidance Does Not Meet this Requirement Due to Impracticality or Scope This requirement is NA. No fix is required.
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 The gpgcheck option controls whether RPM packages' signatures are always checked prior to installation. To configure yum to check package signatures before installing them, ensure the following line appears in /etc/yum.conf in the [main] section:
gpgcheck=1
Ensure gpgcheck Enabled For All Yum Package Repositories To ensure 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. 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, or token); or (iii) something you are (e.g., biometric). A privileged account is defined as an operating system account with authorizations of a privileged user. Network access is defined as access to an operating system by a user (or a process acting on behalf of a user) communicating through a network.
Enable Smart Card Login To enable smart card authentication, consult the documentation at:
  • https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Managing_Smart_Cards/enabling-smart-card-login.html
For guidance on enabling SSH to authenticate against a Common Access Card (CAC), consult documentation at:
  • https://access.redhat.com/solutions/82273
Disable SSH Support for .rhosts Files SSH can emulate the behavior of the obsolete rsh command in allowing users to enable insecure access to their accounts via .rhosts files.

To ensure this behavior is disabled, add or correct the following line in /etc/ssh/sshd_config:
IgnoreRhosts yes
Disable Host-Based Authentication SSH's cryptographic host-based authentication is more secure than .rhosts authentication. However, it is not recommended that hosts unilaterally trust one another, even within an organization.

To disable host-based authentication, add or correct the following line in /etc/ssh/sshd_config:
HostbasedAuthentication no
Disable SSH Access via Empty Passwords To explicitly disallow remote login from accounts with empty passwords, add or correct the following line in /etc/ssh/sshd_config:
PermitEmptyPasswords no
Any accounts with empty passwords should be disabled immediately, and PAM configuration should prevent users from being able to assign themselves empty passwords.
SRG-OS-000106 CCI-000766 The operating system must use multifactor authentication for network access to non-privileged accounts. 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 non-privileged account is defined as an operating system account with authorizations of a regular or non-privileged user. Network access is defined as access to an information system by a user (or a process acting on behalf of a user) communicating through a network.
Enable Smart Card Login To enable smart card authentication, consult the documentation at:
  • https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Managing_Smart_Cards/enabling-smart-card-login.html
For guidance on enabling SSH to authenticate against a Common Access Card (CAC), consult documentation at:
  • https://access.redhat.com/solutions/82273
Disable SSH Support for .rhosts Files SSH can emulate the behavior of the obsolete rsh command in allowing users to enable insecure access to their accounts via .rhosts files.

To ensure this behavior is disabled, add or correct the following line in /etc/ssh/sshd_config:
IgnoreRhosts yes
Disable Host-Based Authentication SSH's cryptographic host-based authentication is more secure than .rhosts authentication. However, it is not recommended that hosts unilaterally trust one another, even within an organization.

To disable host-based authentication, add or correct the following line in /etc/ssh/sshd_config:
HostbasedAuthentication no
Disable SSH Access via Empty Passwords To explicitly disallow remote login from accounts with empty passwords, add or correct the following line in /etc/ssh/sshd_config:
PermitEmptyPasswords no
Any accounts with empty passwords should be disabled immediately, and PAM configuration should prevent users from being able to assign themselves empty passwords.
SRG-OS-000107 CCI-000767 The operating system must use multifactor authentication for local access to privileged accounts. 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 operating system account with authorizations of a privileged user. Local access is defined as access to an organizational information system by a user (or process acting on behalf of a user) communicating through a direct connection without the use of a network.
Enable Smart Card Login To enable smart card authentication, consult the documentation at:
  • https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Managing_Smart_Cards/enabling-smart-card-login.html
For guidance on enabling SSH to authenticate against a Common Access Card (CAC), consult documentation at:
  • https://access.redhat.com/solutions/82273
SRG-OS-000108 CCI-000768 The operating system must use multifactor authentication for local access to non-privileged accounts. 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 non-privileged account is defined as an operating system account with authorizations of a regular or non-privileged user. Local access is defined as access to an organizational information system by a user (or process acting on behalf of a user) communicating through a direct connection without the use of a network.
Enable Smart Card Login To enable smart card authentication, consult the documentation at:
  • https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Managing_Smart_Cards/enabling-smart-card-login.html
For guidance on enabling SSH to authenticate against a Common Access Card (CAC), consult documentation at:
  • https://access.redhat.com/solutions/82273
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 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
Ensure All Accounts on the System Have Unique Names Change usernames, or delete accounts, so each has a unique name.
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 in /etc/ssh/sshd_config:
PermitRootLogin no
Product Meets this Requirement This requirement is a permanent not a finding. No fix is required.
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.
Enable Smart Card Login To enable smart card authentication, consult the documentation at:
  • https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Managing_Smart_Cards/enabling-smart-card-login.html
For guidance on enabling SSH to authenticate against a Common Access Card (CAC), consult documentation at:
  • https://access.redhat.com/solutions/82273
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. 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 non-privileged account is defined as an information system account with authorizations of a regular or non-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.
Enable Smart Card Login To enable smart card authentication, consult the documentation at:
  • https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Managing_Smart_Cards/enabling-smart-card-login.html
For guidance on enabling SSH to authenticate against a Common Access Card (CAC), consult documentation at:
  • https://access.redhat.com/solutions/82273
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. 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
Configure LDAP Client 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 a trusted 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 that CA. First, edit the file /etc/pam_ldap.conf, and add or correct either of the following lines:
tls_cacertdir /etc/pki/tls/CA
or
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. 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.
Configure LDAP Client 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 a trusted 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 that CA. First, edit the file /etc/pam_ldap.conf, and add or correct either of the following lines:
tls_cacertdir /etc/pki/tls/CA
or
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.
Guidance Does Not Meet this Requirement Due to Impracticality or Scope This requirement is NA. No fix is required.
SRG-OS-000116 CCI-000780 The operating system must authenticate devices before establishing wireless 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.
Guidance Does Not Meet this Requirement Due to Impracticality or Scope This requirement is NA. No fix is required.
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.
Guidance Does Not Meet this Requirement Due to Impracticality or Scope This requirement is NA. No fix is required.
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 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/default/useradd, substituting NUM_DAYS appropriately:
INACTIVE=
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-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.
Product Meets this Requirement This requirement is a permanent not a finding. No fix is required.
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.
Set Password Hashing Algorithm in /etc/pam.d/system-auth In /etc/pam.d/system-auth, the password section of the file controls which PAM modules execute during a password change. Set the pam_unix.so module in the password section to include the argument sha512, as shown below:
password    sufficient    pam_unix.so sha512 other arguments...
This will help ensure when local users change their passwords, hashes for the new passwords will be generated using the SHA-512 algorithm. This is the default.
Set Password Hashing Algorithm in /etc/login.defs In /etc/login.defs, add or correct the following line to ensure the system will use SHA-512 as the hashing algorithm:
ENCRYPT_METHOD SHA512
Set Password Hashing Algorithm in /etc/libuser.conf In /etc/libuser.conf, add or correct the following line in its [defaults] section to ensure the system will use the SHA-512 algorithm for password hashing:
crypt_style = sha512
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:
Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc
The man page sshd_config(5) contains a list of supported ciphers.
Use Only Approved MACs Limit the MACs to those hash algorithms which are FIPS-approved. The following line in /etc/ssh/sshd_config demonstrates use of FIPS-approved MACs:
MACs hmac-sha2-512,hmac-sha2-256,hmac-sha1
The man page sshd_config(5) contains a list of supported MACs.
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.
Ensure All Accounts on the System Have Unique Names Change usernames, or delete accounts, so each has a unique name.
Product Meets this Requirement This requirement is a permanent not a finding. No fix is required.
Product Meets this Requirement This requirement is a permanent not a finding. No fix is required.
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 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:
$ sudo chkconfig --level 2345 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.
Assign Expiration Date to Temporary Accounts In the event temporary or emergency accounts are required, configure the system to terminate them after a documented time period. For every temporary and emergency account, run the following command to set an expiration date on it, substituting USER and YYYY-MM-DD appropriately:
$ sudo chage -E YYYY-MM-DD USER
YYYY-MM-DD indicates the documented expiration date for the account.
Guidance Does Not Meet this Requirement Due to Impracticality or Scope This requirement is NA. No fix is required.
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 This requirement is a permanent not a finding. No fix is required.
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.
Disable telnet Service The telnet service can be disabled with the following command:
$ sudo chkconfig telnet off
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 
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.
Set SSH Client Alive Count To ensure the SSH idle timeout occurs precisely when the ClientAliveCountMax is set, edit /etc/ssh/sshd_config as follows:
ClientAliveCountMax 0
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.
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:
$ sudo chkconfig --level 2345 auditd on
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).
Enable Smart Card Login To enable smart card authentication, consult the documentation at:
  • https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Managing_Smart_Cards/enabling-smart-card-login.html
For guidance on enabling SSH to authenticate against a Common Access Card (CAC), consult documentation at:
  • https://access.redhat.com/solutions/82273
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.
Disable telnet Service The telnet service can be disabled with the following command:
$ sudo chkconfig telnet off
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.
Guidance Does Not Meet this Requirement Due to Impracticality or Scope This requirement is NA. No fix is required.
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.
Encrypt 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 installation time.

For manual installations, select the Encrypt checkbox during partition creation 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 subsequently need to be entered manually every time the system boots.

For automated/unattended installations, it is possible to use Kickstart by adding the --encrypted and --passphrase= options to the definition of each partition to be encrypted. For example, the following line would encrypt the root partition:
part / --fstype=ext3 --size=100 --onpart=hda1 --encrypted --passphrase=PASSPHRASE
Any PASSPHRASE is stored in the Kickstart in plaintext, and the Kickstart must then be protected accordingly. Omitting the --passphrase= option from the partition definition will cause the installer to pause and interactively ask for the passphrase during installation.

Detailed information on encrypting partitions using LUKS can be found on the Red Hat Documentation web site:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/chap-Security_Guide-Encryption.html#sect-Security_Guide-LUKS_Disk_Encryption
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 This requirement is a permanent not a finding. No fix is required.
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 This requirement is a permanent not a finding. No fix is required.
SRG-OS-000134 CCI-001084 The operating system must isolate security functions from nonsecurity functions. 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 This requirement is a permanent not a finding. No fix is required.
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.
Product Meets this Requirement This requirement is a permanent not a finding. No fix is required.
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. 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. The operating system maintains a separate execution domain (e.g., address space) for each executing process.
Product Meets this Requirement This requirement is a permanent not a finding. No fix is required.
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. 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. The information system maintains a separate execution domain (e.g., address space) for each executing process.
Product Meets this Requirement This requirement is a permanent not a finding. No fix is required.
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.
Product Meets this Requirement This requirement is a permanent not a finding. No fix is required.
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.
Product Meets this Requirement This requirement is a permanent not a finding. No fix is required.
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 To configure the number of retry prompts that are permitted per-session:

Edit the pam_cracklib.so statement in /etc/pam.d/system-auth to show retry=, or a lower value if site policy is more restrictive.

The DoD requirement is a maximum of 3 prompts per session.
Configure Kernel Parameter to Use TCP Syncookies To set the runtime status of the net.ipv4.tcp_syncookies kernel parameter, run the following command:
$ sudo sysctl -w net.ipv4.tcp_syncookies=1
If this is not the system's default value, add the following line to /etc/sysctl.conf:
net.ipv4.tcp_syncookies = 1
Verify ip6tables Enabled if Using IPv6 The ip6tables service can be enabled with the following command:
$ sudo chkconfig --level 2345 ip6tables on
Verify iptables Enabled The iptables service can be enabled with the following command:
$ sudo chkconfig --level 2345 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 This requirement is NA. No fix is required.
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.
Configure Kernel Parameter to Use TCP Syncookies To set the runtime status of the net.ipv4.tcp_syncookies kernel parameter, run the following command:
$ sudo sysctl -w net.ipv4.tcp_syncookies=1
If this is not the system's default value, add the following line to /etc/sysctl.conf:
net.ipv4.tcp_syncookies = 1
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 This requirement is a permanent not a finding. No fix is required.
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 if Using IPv6 The ip6tables service can be enabled with the following command:
$ sudo chkconfig --level 2345 ip6tables on
Verify iptables Enabled The iptables service can be enabled with the following command:
$ sudo chkconfig --level 2345 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 if Using IPv6 The ip6tables service can be enabled with the following command:
$ sudo chkconfig --level 2345 ip6tables on
Verify iptables Enabled The iptables service can be enabled with the following command:
$ sudo chkconfig --level 2345 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 if Using IPv6 The ip6tables service can be enabled with the following command:
$ sudo chkconfig --level 2345 ip6tables on
Verify iptables Enabled The iptables service can be enabled with the following command:
$ sudo chkconfig --level 2345 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 ip6tables 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/ip6tables:
:INPUT DROP [0:0]
If changes were required, reload the ip6tables rules:
$ sudo service ip6tables reload
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.
Product Meets this Requirement This requirement is a permanent not a finding. No fix is required.
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 This requirement is NA. No fix is required.
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 if Using IPv6 The ip6tables service can be enabled with the following command:
$ sudo chkconfig --level 2345 ip6tables on
Verify iptables Enabled The iptables service can be enabled with the following command:
$ sudo chkconfig --level 2345 iptables on
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:
$ sudo chkconfig --level 2345 auditd on
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 if Using IPv6 The ip6tables service can be enabled with the following command:
$ sudo chkconfig --level 2345 ip6tables on
Verify iptables Enabled The iptables service can be enabled with the following command:
$ sudo chkconfig --level 2345 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 if Using IPv6 The ip6tables service can be enabled with the following command:
$ sudo chkconfig --level 2345 ip6tables on
Verify iptables Enabled The iptables service can be enabled with the following command:
$ sudo chkconfig --level 2345 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.
Guidance Does Not Meet this Requirement Due to Impracticality or Scope This requirement is NA. No fix is required.
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.
Guidance Does Not Meet this Requirement Due to Impracticality or Scope This requirement is NA. No fix is required.
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.
Guidance Does Not Meet this Requirement Due to Impracticality or Scope This requirement is NA. No fix is required.
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 This requirement is NA. No fix is required.
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.
Product Meets this Requirement This requirement is a permanent not a finding. No fix is required.
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.
Product Meets this Requirement This requirement is a permanent not a finding. No fix is required.
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.
Product Meets this Requirement This requirement is a permanent not a finding. No fix is required.
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.
Install openswan or libreswan Package The openswan and libreswan packages provide 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:
$ sudo yum install openswan
The libreswan package can be installed with the following command:
$ sudo yum install libreswan
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. 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.
Install openswan or libreswan Package The openswan and libreswan packages provide 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:
$ sudo yum install openswan
The libreswan package can be installed with the following command:
$ sudo yum install libreswan
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.
Guidance Does Not Meet this Requirement Due to Impracticality or Scope This requirement is NA. No fix is required.
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 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 
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.
Set SSH Client Alive Count To ensure the SSH idle timeout occurs precisely when the ClientAliveCountMax is set, edit /etc/ssh/sshd_config as follows:
ClientAliveCountMax 0
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).
Guidance Does Not Meet this Requirement Due to Impracticality or Scope This requirement is NA. No fix is required.
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.
Guidance Does Not Meet this Requirement Due to Impracticality or Scope This requirement is NA. No fix is required.
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. 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.
Guidance Does Not Meet this Requirement Due to Impracticality or Scope This requirement is NA. No fix is required.
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. 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.
Guidance Does Not Meet this Requirement Due to Impracticality or Scope This requirement is NA. No fix is required.
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. 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.
Guidance Does Not Meet this Requirement Due to Impracticality or Scope This requirement is NA. No fix is required.
Guidance Does Not Meet this Requirement Due to Impracticality or Scope This requirement is NA. No fix is required.
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 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:
Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc
The man page sshd_config(5) contains a list of supported ciphers.
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 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:
Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc
The man page sshd_config(5) contains a list of supported ciphers.
Guidance Does Not Meet this Requirement Due to Impracticality or Scope This requirement is NA. No fix is required.
SRG-OS-000171 CCI-001146 The operating system must employ NSA-approved cryptography to protect classified 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 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:
Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc
The man page sshd_config(5) contains a list of supported ciphers.
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. 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.
Guidance Does Not Meet this Requirement Due to Impracticality or Scope This requirement is NA. No fix is required.
SRG-OS-000173 CCI-001148 The operating system must employ FIPS-validate or NSA-approved cryptography to implement digital signatures. 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.
Guidance Does Not Meet this Requirement Due to Impracticality or Scope This requirement is NA. No fix is required.
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 This requirement is NA. No fix is required.
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 This requirement is NA. No fix is required.
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 ip6tables 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/ip6tables:
:INPUT DROP [0:0]
If changes were required, reload the ip6tables rules:
$ sudo service ip6tables reload
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 This requirement is NA. No fix is required.
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 Not Supported This requirement is a permanent finding and cannot be fixed. An appropriate mitigation for the system must be implemented but this finding cannot be considered fixed.
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.
Guidance Does Not Meet this Requirement Due to Impracticality or Scope This requirement is NA. No fix is required.
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.
Guidance Does Not Meet this Requirement Due to Impracticality or Scope This requirement is NA. No fix is required.
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.
SRG-OS-000182 CCI-001169 The operating system must prevent the download 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.
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. 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.
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 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:
$ sudo chkconfig --level 2345 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.
Encrypt 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 installation time.

For manual installations, select the Encrypt checkbox during partition creation 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 subsequently need to be entered manually every time the system boots.

For automated/unattended installations, it is possible to use Kickstart by adding the --encrypted and --passphrase= options to the definition of each partition to be encrypted. For example, the following line would encrypt the root partition:
part / --fstype=ext3 --size=100 --onpart=hda1 --encrypted --passphrase=PASSPHRASE
Any PASSPHRASE is stored in the Kickstart in plaintext, and the Kickstart must then be protected accordingly. Omitting the --passphrase= option from the partition definition will cause the installer to pause and interactively ask for the passphrase during installation.

Detailed information on encrypting partitions using LUKS can be found on the Red Hat Documentation web site:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/chap-Security_Guide-Encryption.html#sect-Security_Guide-LUKS_Disk_Encryption
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 This requirement is a permanent not a finding. No fix is required.
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 This requirement is NA. No fix is required.
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 This requirement is NA. No fix is required.
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 This requirement is a permanent not a finding. No fix is required.
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.
A process for prompt installation of OS updates must exist. Procedures to promptly apply software updates must be established and executed. The Red Hat operating system provides support for automating such a process, by running the yum program through a cron job or by managing the system and its packages through the Red Hat Network or a Satellite Server.
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.
Ensure Software Patches Installed If the system is joined to the Red Hat Network, a Red Hat Satellite Server, or a yum server, run the following command to install updates:
$ sudo yum update
If the system is not configured to use one of these sources, updates (in the form of RPM packages) can be manually downloaded from the Red Hat Network and installed using rpm.
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 This requirement is a permanent not a finding. No fix is required.
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 Install virus scanning software, which uses signatures to search for the presence of viruses on the filesystem. The McAfee VirusScan Enterprise for Linux virus scanning tool is provided for DoD systems. Ensure virus definition files are no older than 7 days, or their last release. Configure the virus scanning software to perform scans dynamically on all accessed files. If this is not possible, configure the system to scan all altered files on the system on a daily basis. If the system processes inbound SMTP mail, configure the virus scanner to scan all received mail.
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 This requirement is a permanent not a finding. No fix is required.
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 To prevent USB storage devices from being used, configure the kernel module loading system to prevent automatic loading of the USB storage driver. To configure the system to prevent the usb-storage kernel module from being loaded, add the following line to a file in the directory /etc/modprobe.d:
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 All USB support can be disabled by adding the nousb argument to the kernel's boot loader configuration. To do so, append "nousb" to the kernel line in /etc/grub.conf as shown:
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 configuration is infeasible for systems which require USB devices, which is common.
Disable Booting from USB Devices in Boot Firmware Configure the system boot firmware (historically called BIOS on PC systems) to disallow booting from USB drives.
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 may be possible to configure filesystem mounts statically by editing /etc/fstab rather than relying on the automounter.

The autofs service can be disabled with the following command:
$ sudo chkconfig autofs off
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.
Build and Test AIDE Database Run the following command to generate a new database:
$ sudo /usr/sbin/aide --init
By default, the database will be written to the file /var/lib/aide/aide.db.new.gz. Storing the database, the configuration file /etc/aide.conf, and the binary /usr/sbin/aide (or hashes of these files), in a secure location (such as on read-only media) provides additional assurance about their integrity. The newly-generated database can be installed as follows:
$ sudo cp /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz
To initiate a manual check, run the following command:
$ sudo /usr/sbin/aide --check
If this check produces any unexpected output, investigate.
Configure Periodic Execution of AIDE 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.
Install Intrusion Detection Software The base Red Hat platform already includes a sophisticated auditing system that can detect intruder activity, as well as SELinux, which provides host-based intrusion prevention capabilities by confining privileged programs and user sessions which may become compromised.
In DoD environments, supplemental intrusion detection tools, such as, the McAfee Host-based Security System, are available to integrate with existing infrastructure. When these supplemental tools interfere with the proper functioning of SELinux, SELinux takes precedence.
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:
$ sudo chkconfig --level 2345 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 This requirement is a permanent not a finding. No fix is required.
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 This requirement is a permanent not a finding. No fix is required.
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.
Product Meets this Requirement This requirement is a permanent not a finding. No fix is required.
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 Not Supported This requirement is a permanent finding and cannot be fixed. An appropriate mitigation for the system must be implemented but this finding cannot be considered fixed.
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 Not Supported This requirement is a permanent finding and cannot be fixed. An appropriate mitigation for the system must be implemented but this finding cannot be considered fixed.
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.
Build and Test AIDE Database Run the following command to generate a new database:
$ sudo /usr/sbin/aide --init
By default, the database will be written to the file /var/lib/aide/aide.db.new.gz. Storing the database, the configuration file /etc/aide.conf, and the binary /usr/sbin/aide (or hashes of these files), in a secure location (such as on read-only media) provides additional assurance about their integrity. The newly-generated database can be installed as follows:
$ sudo cp /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz
To initiate a manual check, run the following command:
$ sudo /usr/sbin/aide --check
If this check produces any unexpected output, investigate.
Configure Periodic Execution of AIDE 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-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 This requirement is a permanent not a finding. No fix is required.
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.
Ensure rsyslog is Installed Rsyslog is installed by default. The rsyslog package can be installed with the following command:
$ sudo yum install rsyslog
Enable rsyslog Service The rsyslog service provides syslog-style logging by default on Red Hat Enterprise Linux 6. The rsyslog service can be enabled with the following command:
$ sudo chkconfig --level 2345 rsyslog on
Product Meets this Requirement This requirement is a permanent not a finding. No fix is required.
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.
Ensure rsyslog is Installed Rsyslog is installed by default. The rsyslog package can be installed with the following command:
$ sudo yum install rsyslog
Enable rsyslog Service The rsyslog service provides syslog-style logging by default on Red Hat Enterprise Linux 6. The rsyslog service can be enabled with the following command:
$ sudo chkconfig --level 2345 rsyslog on
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:
$ sudo chkconfig --level 2345 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 Log Files Are Owned By Appropriate User The owner of all log files written by rsyslog should be root. 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 owner:
$ ls -l LOGFILE
If the owner is not root, run the following command to correct this:
$ sudo chown root LOGFILE
Ensure Log Files Are Owned By Appropriate Group The group-owner of all log files written by rsyslog should be root. 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 group owner:
$ ls -l LOGFILE
If the owner is not root, run the following command to correct this:
$ sudo chgrp root LOGFILE
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:
$ sudo chmod 0600 LOGFILE
Product Meets this Requirement This requirement is a permanent not a finding. No fix is required.
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 This requirement is a permanent not a finding. No fix is required.
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.
Product Meets this Requirement This requirement is a permanent not a finding. No fix is required.
SRG-OS-000209 CCI-001339 The operating system must validate the binding of the information producer’s identity to the information. 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.
Guidance Does Not Meet this Requirement Due to Impracticality or Scope This requirement is NA. No fix is required.
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 This requirement is NA. No fix is required.
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 This requirement is NA. No fix is required.
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 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
Set this value to single to cause the system to switch to single-user mode for corrective action. Acceptable values also include suspend and halt. For certain systems, the need for availability outweighs the need to log all actions, and a different setting should be determined. Details regarding all possible values for ACTION are described in the auditd.conf man page.
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.
Guidance Does Not Meet this Requirement Due to Impracticality or Scope This requirement is NA. No fix is required.
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 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-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.
Guidance Does Not Meet this Requirement Due to Impracticality or Scope This requirement is NA. No fix is required.
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.
Guidance Does Not Meet this Requirement Due to Impracticality or Scope This requirement is NA. No fix is required.
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 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:
$ sudo chkconfig --level 2345 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.
Guidance Does Not Meet this Requirement Due to Impracticality or Scope This requirement is NA. No fix is required.
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. 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) in the operating system.
Product Meets this Requirement This requirement is a permanent not a finding. No fix is required.
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. 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.
Product Meets this Requirement This requirement is a permanent not a finding. No fix is required.
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. 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 constraints include ensuring: (i) character data fields only contain printable ASCII; (ii) character data fields only contain alpha-numeric characters; (iii) character data fields do not contain special characters; and (iv) maximum field sizes and file lengths are enforced based upon organization-defined security policy.
Guidance Does Not Meet this Requirement Due to Impracticality or Scope This requirement is NA. No fix is required.
SRG-OS-000223 CCI-001373 The operating system, when transferring information between different security domains, must detect unsanctioned information. 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. 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 This requirement is NA. No fix is required.
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 This requirement is NA. No fix is required.
SRG-OS-000225 CCI-001376 The operating system must uniquely identify source domains for information transfer. 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. 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.
Guidance Does Not Meet this Requirement Due to Impracticality or Scope This requirement is NA. No fix is required.
SRG-OS-000226 CCI-001377 The operating system must uniquely authenticate source domains for information transfer. 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. 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.
Guidance Does Not Meet this Requirement Due to Impracticality or Scope This requirement is NA. No fix is required.
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 This requirement is NA. No fix is required.
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.
Modify the System Login Banner To configure the system login banner:

Edit /etc/issue. Replace the default text with a message compliant with the local site policy or a legal disclaimer. The DoD required text is either:

You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions:
-The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.
-At any time, the USG may inspect and seize data stored on this IS.
-Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.
-This IS includes security measures (e.g., authentication and access controls) to protect USG interests -- not for your personal benefit or privacy.
-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details.


OR:

Use of this or any other DoD interest computer system constitutes consent to monitoring at all times.
This is a DoD interest computer system. All DoD interest computer systems and related equipment are intended for the communication, transmission, processing, and storage of official U.S. Government or other authorized information only. All DoD interest computer systems are subject to monitoring at all times to ensure proper functioning of equipment and systems including security devices and systems, to prevent unauthorized use and violations of statutes and security regulations, to deter criminal activity, and for other similar purposes. Any user of a DoD interest computer system should be aware that any information placed in the system is subject to monitoring and is not subject to any expectation of privacy.
If monitoring of this or any other DoD interest computer system reveals possible evidence of violation of criminal statutes, this evidence and any other related information, including identification information about the user, may be provided to law enforcement officials. If monitoring of this or any other DoD interest computer systems reveals violations of security regulations or unauthorized use, employees who violate security regulations or make unauthorized use of DoD interest computer systems are subject to appropriate disciplinary action.
Use of this or any other DoD interest computer system constitutes consent to monitoring at all times.


OR:

I've read & consent to terms in IS user agreem't.
Modify the System Login Banner To configure the system login banner:

Edit /etc/issue. Replace the default text with a message compliant with the local site policy or a legal disclaimer. The DoD required text is either:

You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions:
-The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.
-At any time, the USG may inspect and seize data stored on this IS.
-Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.
-This IS includes security measures (e.g., authentication and access controls) to protect USG interests -- not for your personal benefit or privacy.
-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details.


OR:

Use of this or any other DoD interest computer system constitutes consent to monitoring at all times.
This is a DoD interest computer system. All DoD interest computer systems and related equipment are intended for the communication, transmission, processing, and storage of official U.S. Government or other authorized information only. All DoD interest computer systems are subject to monitoring at all times to ensure proper functioning of equipment and systems including security devices and systems, to prevent unauthorized use and violations of statutes and security regulations, to deter criminal activity, and for other similar purposes. Any user of a DoD interest computer system should be aware that any information placed in the system is subject to monitoring and is not subject to any expectation of privacy.
If monitoring of this or any other DoD interest computer system reveals possible evidence of violation of criminal statutes, this evidence and any other related information, including identification information about the user, may be provided to law enforcement officials. If monitoring of this or any other DoD interest computer systems reveals violations of security regulations or unauthorized use, employees who violate security regulations or make unauthorized use of DoD interest computer systems are subject to appropriate disciplinary action.
Use of this or any other DoD interest computer system constitutes consent to monitoring at all times.


OR:

I've read & consent to terms in IS user agreem't.
Modify the System Login Banner To configure the system login banner:

Edit /etc/issue. Replace the default text with a message compliant with the local site policy or a legal disclaimer. The DoD required text is either:

You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions:
-The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.
-At any time, the USG may inspect and seize data stored on this IS.
-Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.
-This IS includes security measures (e.g., authentication and access controls) to protect USG interests -- not for your personal benefit or privacy.
-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details.


OR:

Use of this or any other DoD interest computer system constitutes consent to monitoring at all times.
This is a DoD interest computer system. All DoD interest computer systems and related equipment are intended for the communication, transmission, processing, and storage of official U.S. Government or other authorized information only. All DoD interest computer systems are subject to monitoring at all times to ensure proper functioning of equipment and systems including security devices and systems, to prevent unauthorized use and violations of statutes and security regulations, to deter criminal activity, and for other similar purposes. Any user of a DoD interest computer system should be aware that any information placed in the system is subject to monitoring and is not subject to any expectation of privacy.
If monitoring of this or any other DoD interest computer system reveals possible evidence of violation of criminal statutes, this evidence and any other related information, including identification information about the user, may be provided to law enforcement officials. If monitoring of this or any other DoD interest computer systems reveals violations of security regulations or unauthorized use, employees who violate security regulations or make unauthorized use of DoD interest computer systems are subject to appropriate disciplinary action.
Use of this or any other DoD interest computer system constitutes consent to monitoring at all times.


OR:

I've read & consent to terms in IS user agreem't.
Modify the System Login Banner To configure the system login banner:

Edit /etc/issue. Replace the default text with a message compliant with the local site policy or a legal disclaimer. The DoD required text is either:

You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions:
-The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.
-At any time, the USG may inspect and seize data stored on this IS.
-Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.
-This IS includes security measures (e.g., authentication and access controls) to protect USG interests -- not for your personal benefit or privacy.
-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details.


OR:

Use of this or any other DoD interest computer system constitutes consent to monitoring at all times.
This is a DoD interest computer system. All DoD interest computer systems and related equipment are intended for the communication, transmission, processing, and storage of official U.S. Government or other authorized information only. All DoD interest computer systems are subject to monitoring at all times to ensure proper functioning of equipment and systems including security devices and systems, to prevent unauthorized use and violations of statutes and security regulations, to deter criminal activity, and for other similar purposes. Any user of a DoD interest computer system should be aware that any information placed in the system is subject to monitoring and is not subject to any expectation of privacy.
If monitoring of this or any other DoD interest computer system reveals possible evidence of violation of criminal statutes, this evidence and any other related information, including identification information about the user, may be provided to law enforcement officials. If monitoring of this or any other DoD interest computer systems reveals violations of security regulations or unauthorized use, employees who violate security regulations or make unauthorized use of DoD interest computer systems are subject to appropriate disciplinary action.
Use of this or any other DoD interest computer system constitutes consent to monitoring at all times.


OR:

I've read & consent to terms in IS user agreem't.
Modify the System Login Banner To configure the system login banner:

Edit /etc/issue. Replace the default text with a message compliant with the local site policy or a legal disclaimer. The DoD required text is either:

You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions:
-The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.
-At any time, the USG may inspect and seize data stored on this IS.
-Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.
-This IS includes security measures (e.g., authentication and access controls) to protect USG interests -- not for your personal benefit or privacy.
-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details.


OR:

Use of this or any other DoD interest computer system constitutes consent to monitoring at all times.
This is a DoD interest computer system. All DoD interest computer systems and related equipment are intended for the communication, transmission, processing, and storage of official U.S. Government or other authorized information only. All DoD interest computer systems are subject to monitoring at all times to ensure proper functioning of equipment and systems including security devices and systems, to prevent unauthorized use and violations of statutes and security regulations, to deter criminal activity, and for other similar purposes. Any user of a DoD interest computer system should be aware that any information placed in the system is subject to monitoring and is not subject to any expectation of privacy.
If monitoring of this or any other DoD interest computer system reveals possible evidence of violation of criminal statutes, this evidence and any other related information, including identification information about the user, may be provided to law enforcement officials. If monitoring of this or any other DoD interest computer systems reveals violations of security regulations or unauthorized use, employees who violate security regulations or make unauthorized use of DoD interest computer systems are subject to appropriate disciplinary action.
Use of this or any other DoD interest computer system constitutes consent to monitoring at all times.


OR:

I've read & consent to terms in IS user agreem't.
Set GUI Warning Banner Text To set the text shown by the GNOME Display Manager in the login screen, run the following command:
$ sudo gconftool-2 --direct \
  --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory \
  --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 either to the /etc/gconf/gconf.xml.mandatory/%gconf-tree.xml if it exists or to the file /etc/gconf/gconf.xml.mandatory/apps/gdm/simple-greeter/%gconf.xml. Either of these files can later be edited directly if necessary.
Set GUI Warning Banner Text To set the text shown by the GNOME Display Manager in the login screen, run the following command:
$ sudo gconftool-2 --direct \
  --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory \
  --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 either to the /etc/gconf/gconf.xml.mandatory/%gconf-tree.xml if it exists or to the file /etc/gconf/gconf.xml.mandatory/apps/gdm/simple-greeter/%gconf.xml. Either of these files can later be edited directly if necessary.
Set GUI Warning Banner Text To set the text shown by the GNOME Display Manager in the login screen, run the following command:
$ sudo gconftool-2 --direct \
  --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory \
  --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 either to the /etc/gconf/gconf.xml.mandatory/%gconf-tree.xml if it exists or to the file /etc/gconf/gconf.xml.mandatory/apps/gdm/simple-greeter/%gconf.xml. Either of these files can later be edited directly if necessary.
Set GUI Warning Banner Text To set the text shown by the GNOME Display Manager in the login screen, run the following command:
$ sudo gconftool-2 --direct \
  --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory \
  --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 either to the /etc/gconf/gconf.xml.mandatory/%gconf-tree.xml if it exists or to the file /etc/gconf/gconf.xml.mandatory/apps/gdm/simple-greeter/%gconf.xml. Either of these files can later be edited directly if necessary.
Set GUI Warning Banner Text To set the text shown by the GNOME Display Manager in the login screen, run the following command:
$ sudo gconftool-2 --direct \
  --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory \
  --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 either to the /etc/gconf/gconf.xml.mandatory/%gconf-tree.xml if it exists or to the file /etc/gconf/gconf.xml.mandatory/apps/gdm/simple-greeter/%gconf.xml. Either of these files can later be edited directly if necessary.
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 This requirement is NA. No fix is required.
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. 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) within an organizational information system.
Encrypt 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 installation time.

For manual installations, select the Encrypt checkbox during partition creation 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 subsequently need to be entered manually every time the system boots.

For automated/unattended installations, it is possible to use Kickstart by adding the --encrypted and --passphrase= options to the definition of each partition to be encrypted. For example, the following line would encrypt the root partition:
part / --fstype=ext3 --size=100 --onpart=hda1 --encrypted --passphrase=PASSPHRASE
Any PASSPHRASE is stored in the Kickstart in plaintext, and the Kickstart must then be protected accordingly. Omitting the --passphrase= option from the partition definition will cause the installer to pause and interactively ask for the passphrase during installation.

Detailed information on encrypting partitions using LUKS can be found on the Red Hat Documentation web site:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/chap-Security_Guide-Encryption.html#sect-Security_Guide-LUKS_Disk_Encryption
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.
Verify ip6tables Enabled if Using IPv6 The ip6tables service can be enabled with the following command:
$ sudo chkconfig --level 2345 ip6tables on
Set Default ip6tables 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/ip6tables:
:INPUT DROP [0:0]
If changes were required, reload the ip6tables rules:
$ sudo service ip6tables reload
Verify iptables Enabled The iptables service can be enabled with the following command:
$ sudo chkconfig --level 2345 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]
Product Meets this Requirement This requirement is a permanent not a finding. No fix is required.
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.
Install AIDE Install the AIDE package with the command:
$ sudo yum install aide
Build and Test AIDE Database Run the following command to generate a new database:
$ sudo /usr/sbin/aide --init
By default, the database will be written to the file /var/lib/aide/aide.db.new.gz. Storing the database, the configuration file /etc/aide.conf, and the binary /usr/sbin/aide (or hashes of these files), in a secure location (such as on read-only media) provides additional assurance about their integrity. The newly-generated database can be installed as follows:
$ sudo cp /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz
To initiate a manual check, run the following command:
$ sudo /usr/sbin/aide --check
If this check produces any unexpected output, investigate.
Configure Periodic Execution of AIDE 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-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.
Guidance Does Not Meet this Requirement Due to Impracticality or Scope This requirement is NA. No fix is required.
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.
Guidance Does Not Meet this Requirement Due to Impracticality or Scope This requirement is NA. No fix is required.
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.
Guidance Does Not Meet this Requirement Due to Impracticality or Scope This requirement is NA. No fix is required.
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 This requirement is a permanent not a finding. No fix is required.
SRG-OS-000237 CCI-001400 The operating system must support and maintain the binding of organization-defined security attributes to information in process. 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). In this case the security attributes are to be bound to the information in process.
Product Meets this Requirement This requirement is a permanent not a finding. No fix is required.
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 This requirement is NA. No fix is required.
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_rules_usergroup_modification
-w /etc/group -p wa -k audit_rules_usergroup_modification
-w /etc/passwd -p wa -k audit_rules_usergroup_modification
-w /etc/gshadow -p wa -k audit_rules_usergroup_modification
-w /etc/shadow -p wa -k audit_rules_usergroup_modification
-w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification
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_rules_usergroup_modification
-w /etc/group -p wa -k audit_rules_usergroup_modification
-w /etc/passwd -p wa -k audit_rules_usergroup_modification
-w /etc/gshadow -p wa -k audit_rules_usergroup_modification
-w /etc/shadow -p wa -k audit_rules_usergroup_modification
-w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification
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_rules_usergroup_modification
-w /etc/group -p wa -k audit_rules_usergroup_modification
-w /etc/passwd -p wa -k audit_rules_usergroup_modification
-w /etc/gshadow -p wa -k audit_rules_usergroup_modification
-w /etc/shadow -p wa -k audit_rules_usergroup_modification
-w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification
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. 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. 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.
Verify ip6tables Enabled if Using IPv6 The ip6tables service can be enabled with the following command:
$ sudo chkconfig --level 2345 ip6tables on
Set Default ip6tables 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/ip6tables:
:INPUT DROP [0:0]
If changes were required, reload the ip6tables rules:
$ sudo service ip6tables reload
Verify iptables Enabled The iptables service can be enabled with the following command:
$ sudo chkconfig --level 2345 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]
Do Not Allow SSH Environment Options To ensure users are not able to present environment options to the SSH daemon, add or correct the following line in /etc/ssh/sshd_config:
PermitUserEnvironment no
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.
Product Meets this Requirement This requirement is a permanent not a finding. No fix is required.
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 This requirement is a permanent not a finding. No fix is required.
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).
Product Meets this Requirement This requirement is a permanent not a finding. No fix is required.
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 This requirement is a permanent not a finding. No fix is required.
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.
Product Meets this Requirement This requirement is a permanent not a finding. No fix is required.
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:
$ sudo chkconfig telnet off
Disable rexec Service The rexec service, which is available with the rsh-server package and runs as a service through xinetd, should be disabled. The rexec service can be disabled with the following command:
$ sudo chkconfig rexec 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:
$ sudo 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:
$ sudo chkconfig rlogin off
Remove Rsh Trust Files The files /etc/hosts.equiv and ~/.rhosts (in each user's home directory) list remote hosts and users that are trusted by the local system when using the rshd daemon. To remove these files, run the following command to delete them from any location:
$ sudo rm /etc/hosts.equiv
$ rm ~/.rhosts
Disable tftp Service The tftp service should be disabled. The tftp service can be disabled with the following command:
$ sudo chkconfig tftp off
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
Disable vsftpd Service The vsftpd service can be disabled with the following command:
$ sudo chkconfig vsftpd off
Uninstall vsftpd Package The vsftpd package can be removed with the following command:
$ sudo yum erase vsftpd
Disable Samba The smb service can be disabled with the following command:
$ sudo chkconfig smb 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 Interval For Counting Failed Password Attempts Utilizing pam_faillock.so, the fail_interval directive configures the system to lock out accounts after a number of incorrect login attempts. Modify the content of both /etc/pam.d/system-auth and /etc/pam.d/password-auth as follows:

  • Add the following line immediately before the pam_unix.so statement in the AUTH section:
    auth required pam_faillock.so preauth silent deny= unlock_time= fail_interval=
  • Add the following line immediately after the pam_unix.so statement in the AUTH section:
    auth [default=die] pam_faillock.so authfail deny= unlock_time= fail_interval=
  • Add the following line immediately before the pam_unix.so statement in the ACCOUNT section:
    account required pam_faillock.so
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.
Use Only Approved MACs Limit the MACs to those hash algorithms which are FIPS-approved. The following line in /etc/ssh/sshd_config demonstrates use of FIPS-approved MACs:
MACs hmac-sha2-512,hmac-sha2-256,hmac-sha1
The man page sshd_config(5) contains a list of supported MACs.
Configure LDAP Client 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 a trusted 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 that CA. First, edit the file /etc/pam_ldap.conf, and add or correct either of the following lines:
tls_cacertdir /etc/pki/tls/CA
or
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 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:
$ sudo chkconfig --level 2345 auditd on
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 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:
$ sudo chkconfig --level 2345 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. 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) in the operating system. This requirement mandates the granularity of the access is at the user level.
Product Meets this Requirement This requirement is a permanent not a finding. No fix is required.
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 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. 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 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:
$ sudo chkconfig --level 2345 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 -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
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 -k audit_time_rules
Record Attempts to Alter Time Through stime Add the following line to /etc/audit/audit.rules for both 32-bit and 64-bit systems:
# audit_time_rules
-a always,exit -F arch=b32 -S stime -k audit_time_rules
Since the 64-bit version of the "stime" system call is not defined in the audit lookup table, the corresponding "-F arch=b64" form of this rule is not expected to be defined on 64-bit systems (the aforementioned "-F arch=b32" stime rule form itself is sufficient for both 32-bit and 64-bit systems). 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 -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:
# time-change
-a always,exit -F arch=b32 -S clock_settime -F a0=0x0 -F key=time-change
On a 64-bit system, add the following to /etc/audit/audit.rules:
# time-change
-a always,exit -F arch=b64 -S clock_settime -F a0=0x0 -F key=time-change
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 -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.
Verify and Correct File Permissions with RPM The RPM package management system can check file access permissions of installed software packages, including many that are important to system security. After locating a file with incorrect permissions, run the following command to determine which package owns it:
$ rpm -qf FILENAME
Next, run the following command to reset its permissions to the correct values:
$ sudo rpm --setperms PACKAGENAME
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.
Verify and Correct File Permissions with RPM The RPM package management system can check file access permissions of installed software packages, including many that are important to system security. After locating a file with incorrect permissions, run the following command to determine which package owns it:
$ rpm -qf FILENAME
Next, run the following command to reset its permissions to the correct values:
$ sudo rpm --setperms PACKAGENAME
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.
Verify and Correct File Permissions with RPM The RPM package management system can check file access permissions of installed software packages, including many that are important to system security. After locating a file with incorrect permissions, run the following command to determine which package owns it:
$ rpm -qf FILENAME
Next, run the following command to reset its permissions to the correct values:
$ sudo rpm --setperms PACKAGENAME
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.
Verify that Shared Library Files Have Restrictive Permissions System-wide shared library files, which are linked to executables during process load time or run time, are stored in the following directories by default:
/lib
/lib64
/usr/lib
/usr/lib64
Kernel modules, which can be added to the kernel during runtime, are stored in /lib/modules. All files in these directories should not be group-writable or world-writable. If any file in these directories is found to be group-writable or world-writable, correct its permission with the following command:
$ sudo chmod go-w FILE
Verify that Shared Library Files Have Root Ownership System-wide shared library files, which are linked to executables during process load time or run time, are stored in the following directories by default:
/lib
/lib64
/usr/lib
/usr/lib64
Kernel modules, which can be added to the kernel during runtime, are also stored in /lib/modules. All files in these directories should be owned by the root user. If the directory, or any file in these directories, is found to be owned by a user other than root correct its ownership with the following command:
$ sudo chown root FILE
Verify that System Executables Have Restrictive Permissions System executables are stored in the following directories by default:
/bin
/sbin
/usr/bin
/usr/libexec
/usr/local/bin
/usr/local/sbin
/usr/sbin
All files in these directories should not be group-writable or world-writable. If any file FILE in these directories is found to be group-writable or world-writable, correct its permission with the following command:
$ sudo chmod go-w FILE
Verify that System Executables Have Root Ownership System executables are stored in the following directories by default:
/bin
/sbin
/usr/bin
/usr/libexec
/usr/local/bin
/usr/local/sbin
/usr/sbin
All files in these directories should be owned by the root user. If any file FILE in these directories is found to be owned by a user other than root, correct its ownership with the following command:
$ sudo chown root FILE
Product Meets this Requirement This requirement is a permanent not a finding. No fix is required.
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 Not Supported This requirement is a permanent finding and cannot be fixed. An appropriate mitigation for the system must be implemented but this finding cannot be considered fixed.
SRG-OS-000261 CCI-001555 The operating system uniquely must identify destination domains for information transfer. 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, 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.
Guidance Does Not Meet this Requirement Due to Impracticality or Scope This requirement is NA. No fix is required.
SRG-OS-000262 CCI-001556 The operating system uniquely must authenticate destination domains for information transfer. 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 that the information. 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. Means to enforce this enhancement include ensuring that the information system resolution labels distinguish between information systems and organizations, and between specific system components or individuals involved in preparing, sending, receiving, or disseminating information.
Guidance Does Not Meet this Requirement Due to Impracticality or Scope This requirement is NA. No fix is required.
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 Red Hat Enterprise Linux 6. The rsyslog service can be enabled with the following command:
$ sudo chkconfig --level 2345 rsyslog on
SRG-OS-000264 CCI-001693 The operating system must enforce a Discretionary Access Control (DAC) policy that limits propagation of access rights. 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) in the operating system.
Product Meets this Requirement This requirement is a permanent not a finding. No fix is required.
SRG-OS-000265 CCI-001589 The operating system must ensure unauthorized, security-relevant configuration changes detected are tracked. 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 registry settings; account, file, and directory settings (i.e., permissions); and settings for services, ports, protocols, and remote connections.
Build and Test AIDE Database Run the following command to generate a new database:
$ sudo /usr/sbin/aide --init
By default, the database will be written to the file /var/lib/aide/aide.db.new.gz. Storing the database, the configuration file /etc/aide.conf, and the binary /usr/sbin/aide (or hashes of these files), in a secure location (such as on read-only media) provides additional assurance about their integrity. The newly-generated database can be installed as follows:
$ sudo cp /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz
To initiate a manual check, run the following command:
$ sudo /usr/sbin/aide --check
If this check produces any unexpected output, investigate.
Configure Periodic Execution of AIDE 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 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:
$ sudo chkconfig --level 2345 auditd on
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. Add ocredit= after pam_cracklib.so to require use of a special character in passwords.
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.
Product Meets this Requirement This requirement is a permanent not a finding. No fix is required.
SRG-OS-000268 CCI-001662 The operating system must take corrective actions, when unauthorized mobile code is identified. 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.
Guidance Does Not Meet this Requirement Due to Impracticality or Scope This requirement is NA. No fix is required.
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 This requirement is a permanent not a finding. No fix is required.
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 Install virus scanning software, which uses signatures to search for the presence of viruses on the filesystem. The McAfee VirusScan Enterprise for Linux virus scanning tool is provided for DoD systems. Ensure virus definition files are no older than 7 days, or their last release. Configure the virus scanning software to perform scans dynamically on all accessed files. If this is not possible, configure the system to scan all altered files on the system on a daily basis. If the system processes inbound SMTP mail, configure the virus scanner to scan all received mail.
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 This requirement is a permanent not a finding. No fix is required.
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 This requirement is a permanent not a finding. No fix is required.
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.
Product Meets this Requirement This requirement is a permanent not a finding. No fix is required.
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_rules_usergroup_modification
-w /etc/group -p wa -k audit_rules_usergroup_modification
-w /etc/passwd -p wa -k audit_rules_usergroup_modification
-w /etc/gshadow -p wa -k audit_rules_usergroup_modification
-w /etc/shadow -p wa -k audit_rules_usergroup_modification
-w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification
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_rules_usergroup_modification
-w /etc/group -p wa -k audit_rules_usergroup_modification
-w /etc/passwd -p wa -k audit_rules_usergroup_modification
-w /etc/gshadow -p wa -k audit_rules_usergroup_modification
-w /etc/shadow -p wa -k audit_rules_usergroup_modification
-w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification
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_rules_usergroup_modification
-w /etc/group -p wa -k audit_rules_usergroup_modification
-w /etc/passwd -p wa -k audit_rules_usergroup_modification
-w /etc/gshadow -p wa -k audit_rules_usergroup_modification
-w /etc/shadow -p wa -k audit_rules_usergroup_modification
-w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification
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_rules_usergroup_modification
-w /etc/group -p wa -k audit_rules_usergroup_modification
-w /etc/passwd -p wa -k audit_rules_usergroup_modification
-w /etc/gshadow -p wa -k audit_rules_usergroup_modification
-w /etc/shadow -p wa -k audit_rules_usergroup_modification
-w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification
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.
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. If the file was not expected to change, investigate the cause of the change using audit logs or other means. The package can then be reinstalled to restore the file. Run the following command to determine which package owns the file:
$ rpm -qf FILENAME
The package can be reinstalled from a yum repository using the command:
$ sudo yum reinstall PACKAGENAME
Alternatively, the package can be reinstalled from trusted media using the command:
$ sudo rpm -Uvh PACKAGENAME
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.