Cyber Trackr - Free Compliance Library
Cyber Trackr
The Free Compliance Library

VMware vRealize Automation 7.x SLES Security Technical Implementation Guide

  • Version/Release: V2R2
  • Published: 2023-09-22
  • Expand All:
  • Severity:
  • Sort:
Compare

Select any two versions of this STIG to compare the individual requirements

View

Select any old version/release of this STIG to view the previous requirements

This Security Technical Implementation Guide is published as a tool to improve the security of Department of Defense (DOD) information systems. The requirements are derived from the National Institute of Standards and Technology (NIST) 800-53 and related documents. Comments or proposed revisions to this document should be sent via email to the following address: disa.stig_spt@mail.mil.
b
The SLES for vRealize must automatically remove or disable temporary user accounts after 72 hours.
AC-2 - Medium - CCI-000016 - V-240344 - SV-240344r670773_rule
RMF Control
AC-2
Severity
Medium
CCI
CCI-000016
Version
VRAU-SL-000010
Vuln IDs
  • V-240344
  • V-89465
Rule IDs
  • SV-240344r670773_rule
  • SV-100115
If temporary user accounts remain active when no longer needed or for an excessive period, these accounts may be used to gain unauthorized access. To mitigate this risk, automated termination of all temporary accounts must be set upon account creation. Temporary accounts are established as part of normal account activation procedures when there is a need for short-term accounts without the demand for immediacy in account activation. If temporary accounts are used, the operating system must be configured to automatically terminate these types of accounts after a DoD-defined time period of 72 hours. To address access requirements, many operating systems may be integrated with enterprise-level authentication/access mechanisms that meet or exceed access control policy requirements.
Checks: C-43577r670771_chk

For every existing temporary account, run the following command to obtain its account expiration information: # chage -l system_account_name Verify each of these accounts has an expiration date set within "72" hours. If any temporary accounts have no expiration date set or do not expire within "72" hours, this is a finding.

Fix: F-43536r670772_fix

In the event temporary accounts are required, configure the system to terminate them after a 72-hour time period. For every temporary account, run the following command to set an expiration date on it, substituting "system_account_name" to the appropriate value: # chage -E `date -d "+3 days" +%Y-%m-%d` system_account_name `date -d "+3 days" +%Y-%m-%d` gets the "72" expiration date for the account at the time of running the command.

b
The SLES for vRealize must audit all account creations.
AC-2 - Medium - CCI-000018 - V-240345 - SV-240345r670776_rule
RMF Control
AC-2
Severity
Medium
CCI
CCI-000018
Version
VRAU-SL-000015
Vuln IDs
  • V-240345
  • V-89467
Rule IDs
  • SV-240345r670776_rule
  • SV-100117
Once an attacker establishes initial access to a system, the attacker often attempts to create a persistent method of reestablishing access. One way to accomplish this is for the attacker to simply create a new account. Auditing of account creation mitigates this risk. To address access requirements, many operating systems may be integrated with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements.
Checks: C-43578r670774_chk

Determine if execution of the useradd and groupadd executable are audited. # auditctl -l | egrep '(useradd|groupadd)' If either useradd or groupadd are not listed with a permissions filter of at least "x", this is a finding. Expected result: LIST_RULES: exit,always watch=/usr/sbin/useradd perm=x key=useradd LIST_RULES: exit,always watch=/usr/sbin/groupadd perm=x key=groupadd

Fix: F-43537r670775_fix

Configure execute auditing of the useradd and groupadd executables. Run the dodscript with the following command as root: # /etc/dodscript.sh OR Configure execute auditing of the useradd and groupadd executables. Add the following to /etc/audit/audit.rules: -w /usr/sbin/useradd -p x -k useradd -w /usr/sbin/groupadd -p x -k groupadd Restart the auditd service: # service auditd restart

b
In addition to auditing new user and group accounts, these watches will alert the system administrator(s) to any modifications. Any unexpected users, groups, or modifications must be investigated for legitimacy.
AC-2 - Medium - CCI-000018 - V-240346 - SV-240346r670779_rule
RMF Control
AC-2
Severity
Medium
CCI
CCI-000018
Version
VRAU-SL-000020
Vuln IDs
  • V-240346
  • V-89469
Rule IDs
  • SV-240346r670779_rule
  • SV-100119
Once an attacker establishes initial access to a system, the attacker often attempts to create a persistent method of reestablishing access. One way to accomplish this is for the attacker to simply create a new account. Auditing of account creation mitigates this risk. To address access requirements, many operating systems may be integrated with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements.
Checks: C-43579r670777_chk

Determine if /etc/passwd, /etc/shadow, /etc/group, and /etc/gshadow are audited for appending. # auditctl -l | egrep '(/etc/passwd|/etc/shadow|/etc/group|/etc/gshadow)' | grep perm=a If any of these are not listed with a permissions filter of at least "a", this is a finding. Expected result: LIST_RULES: exit,always watch=/etc/passwd perm=a key=passwd LIST_RULES: exit,always watch=/etc/shadow perm=a key=shadow LIST_RULES: exit,always watch=/etc/group perm=a key=group LIST_RULES: exit,always watch=/etc/gshadow perm=a key=gshadow

Fix: F-43538r670778_fix

Configure append auditing of the passwd, shadow, group, and gshadow files. Run the dodscript with the following command as root: # /etc/dodscript.sh # echo '-w /etc/gshadow -p a -k gshadow' >> /etc/audit/audit.rules Restart the auditd service. # service auditd restart OR Configure append auditing of the passwd, shadow, group, and gshadow files by running the following commands: # echo '-w /etc/passwd -p a -k passwd' >> /etc/audit/audit.rules # echo '-w /etc/shadow -p a -k shadow' >> /etc/audit/audit.rules # echo '-w /etc/group -p a -k group' >> /etc/audit/audit.rules # echo '-w /etc/gshadow -p a -k gshadow' >> /etc/audit/audit.rules Restart the auditd service: # service auditd restart

b
The SLES for vRealize must enforce the limit of three consecutive invalid logon attempts by a user during a 15-minute time period.
AC-7 - Medium - CCI-000044 - V-240347 - SV-240347r670782_rule
RMF Control
AC-7
Severity
Medium
CCI
CCI-000044
Version
VRAU-SL-000025
Vuln IDs
  • V-240347
  • V-89471
Rule IDs
  • SV-240347r670782_rule
  • SV-100121
By limiting the number of failed logon attempts, the risk of unauthorized system access via user password guessing, otherwise known as brute-force attacks, is reduced. Limits are imposed by locking the account.
Checks: C-43580r670780_chk

Run the following command to ensure that the operating system enforces the limit of three consecutive invalid logon attempts by a user: # grep pam_tally2.so /etc/pam.d/common-auth The output should contain "deny=3" in the returned line. If this is not the case, this is a finding. Expected Result: auth required pam_tally2.so deny=3 onerr=fail even_deny_root unlock_time=86400 root_unlock_time=300

Fix: F-43539r670781_fix

To configure the SLES for vRealize to enforce the limit of three consecutive invalid attempts using "pam_tally2.so", modify the content of the /etc/pam.d/common-auth-vmware.local by running the following command: # sed -i "/^[^#]*pam_tally2.so/ c\auth required pam_tally2.so deny=3 onerr=fail even_deny_root unlock_time=86400 root_unlock_time=300" /etc/pam.d/common-auth-vmware.local

b
The SLES for vRealize must display the Standard Mandatory DoD Notice and Consent Banner before granting access via SSH.
AC-8 - Medium - CCI-000048 - V-240348 - SV-240348r670785_rule
RMF Control
AC-8
Severity
Medium
CCI
CCI-000048
Version
VRAU-SL-000030
Vuln IDs
  • V-240348
  • V-89473
Rule IDs
  • SV-240348r670785_rule
  • SV-100123
Display of a standardized and approved use notification before granting access to the operating system ensures privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. System use notifications are required only for access via logon interfaces with human users and are not required when such human interfaces do not exist. The banner must be formatted in accordance with applicable DoD policy. Use the following verbiage for operating systems that can accommodate banners of 1300 characters: "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." Use the following verbiage for operating systems that have severe limitations on the number of characters that can be displayed in the banner: "I've read & consent to terms in IS user agreem't."
Checks: C-43581r670783_chk

Check that the SSH daemon is configured for logon warning banners: # grep -i banner /etc/ssh/sshd_config | grep -v '#' If the output does not contain "Banner /etc/issue", this is a finding.

Fix: F-43540r670784_fix

To configure the SSH daemon for the logon warning banners, modify /etc/ssh/sshd_config with the following command: # sed -i "/^[^#]*Banner/ c\Banner /etc/issue" /etc/ssh/sshd_config The SSH service will need to be restarted after the above change has been made to SSH. This can be done by running the following command: # service sshd restart

a
The SLES for vRealize must limit the number of concurrent sessions to 10 for all accounts and/or account types.
AC-10 - Low - CCI-000054 - V-240349 - SV-240349r877399_rule
RMF Control
AC-10
Severity
Low
CCI
CCI-000054
Version
VRAU-SL-000040
Vuln IDs
  • V-240349
  • V-89475
Rule IDs
  • SV-240349r877399_rule
  • SV-100125
Operating system management includes the ability to control the number of users and user sessions that utilize an operating system. Limiting the number of allowed users and sessions per user is helpful in reducing the risks related to DoS attacks. This requirement addresses concurrent sessions for information system accounts and does not address concurrent sessions by single users via multiple system accounts. The maximum number of concurrent sessions should be defined based upon mission needs and the operational environment for each system.
Checks: C-43582r670786_chk

Verify the SLES for vRealize limits the number of concurrent sessions to "10" for all accounts and/or account types with the following command: # grep maxlogins /etc/security/limits.conf | grep -v '#' The default maxlimits should be set to a max of "10" or a documented site defined number: * hard maxlogins 10 If no such line exists, this is a finding.

Fix: F-43541r670787_fix

Configure the SLES for vRealize to limit the number of concurrent sessions to "10" for all accounts and/or account types by using the following command. sed -i 's/\(^* *hard *maxlogins\).*/* hard maxlogins 10/g' /etc/security/limits.conf

b
The SLES for vRealize must initiate a session lock after a 15-minute period of inactivity for all connection types.
AC-11 - Medium - CCI-000057 - V-240350 - SV-240350r670791_rule
RMF Control
AC-11
Severity
Medium
CCI
CCI-000057
Version
VRAU-SL-000050
Vuln IDs
  • V-240350
  • V-89477
Rule IDs
  • SV-240350r670791_rule
  • SV-100127
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 information system but does not log out because of the temporary nature of the absence. Rather than relying on the user to manually lock their operating system session prior to vacating the vicinity, operating systems need to be able to identify when a user's session has idled and take action to initiate the session lock. The session lock is implemented at the point where session activity can be determined and/or controlled.
Checks: C-43583r670789_chk

Check for the existence of the /etc/profile.d/tmout.sh file: # ls -al /etc/profile.d/tmout.sh Check for the presence of the TMOUT variable: # grep TMOUT /etc/profile.d/tmout.sh The value of TMOUT should be set to "900" seconds (15 minutes). If the file does not exist, or the TMOUT variable is not set, this is a finding.

Fix: F-43542r670790_fix

Ensure the file exists and is owned by "root". If the file does not exist, use the following commands to create the file: # touch /etc/profile.d/tmout.sh # chown root:root /etc/profile.d/tmout.sh # chmod 644 /etc/profile.d/tmout.sh Edit the file "/etc/profile.d/tmout.sh" and add the following lines: TMOUT=900 readonly TMOUT export TMOUT mesg n 2>/dev/null

b
The SLES for vRealize must initiate a session lock after a 15-minute period of inactivity for an SSH connection.
AC-11 - Medium - CCI-000057 - V-240351 - SV-240351r670794_rule
RMF Control
AC-11
Severity
Medium
CCI
CCI-000057
Version
VRAU-SL-000055
Vuln IDs
  • V-240351
  • V-89479
Rule IDs
  • SV-240351r670794_rule
  • SV-100129
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 information system but does not log out because of the temporary nature of the absence. Rather than relying on the user to manually lock their operating system session prior to vacating the vicinity, operating systems need to be able to identify when a user's session has idled and take action to initiate the session lock. The session lock is implemented at the point where session activity can be determined and/or controlled.
Checks: C-43584r670792_chk

Verify the SLES for vRealize initiates a session lock after a 15-minute period of inactivity for SSH. Execute the following command: # grep ClientAliveInterval /etc/ssh/sshd_config; grep ClientAliveCountMax /etc/ssh/sshd_config Verify the following result: ClientAliveInterval 900 ClientAliveCountMax 0 If this is not set, this is a finding.

Fix: F-43543r670793_fix

Configure the SLES for vRealize to initiate a session lock after a 15-minute period of inactivity for SSH. Set the session lock after a 15-minute period by executing the following command: # sed -i 's/^.*\bClientAliveInterval\b.*$/ClientAliveInterval 900/' /etc/ssh/sshd_config; sed -i 's/^.*\bClientAliveCountMax\b.*$/ClientAliveCountMax 0/' /etc/ssh/sshd_config

b
The SLES for vRealize must monitor remote access methods - SSH Daemon.
AC-17 - Medium - CCI-000067 - V-240352 - SV-240352r670797_rule
RMF Control
AC-17
Severity
Medium
CCI
CCI-000067
Version
VRAU-SL-000070
Vuln IDs
  • V-240352
  • V-89481
Rule IDs
  • SV-240352r670797_rule
  • SV-100131
Remote access services, such as those providing remote access to network devices and information systems, which lack automated monitoring capabilities, increase risk and make remote user access management difficult at best. Remote access is access to DoD nonpublic information systems by an authorized user (or an information system) communicating through an external, non-organization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless. Automated monitoring of remote access sessions allows organizations to detect cyber attacks and also ensure ongoing compliance with remote access policies by auditing connection activities of remote access capabilities, such as Remote Desktop Protocol (RDP), on a variety of information system components (e.g., servers, workstations, notebook computers, smartphones, and tablets).
Checks: C-43585r670795_chk

Verify that SSH is configured to verbosely log connection attempts and failed logon attempts to the server by running the following command: # grep LogLevel /etc/ssh/sshd_config | grep -v '#' The output message must contain the following text: LogLevel VERBOSE If it is not set to "VERBOSE", this is a finding.

Fix: F-43544r670796_fix

To configure SSH to verbosely log connection attempts and failed logon attempts to the server, run the following command: # sed -i 's/^.*\bLogLevel\b.*$/LogLevel VERBOSE/' /etc/ssh/sshd_config The SSH service will need to be restarted after the above change has been made to SSH. This can be done by running the following command: # service sshd restart

b
The SLES for vRealize must implement DoD-approved encryption to protect the confidentiality of remote access sessions- SSH Daemon.
AC-17 - Medium - CCI-000068 - V-240353 - SV-240353r877398_rule
RMF Control
AC-17
Severity
Medium
CCI
CCI-000068
Version
VRAU-SL-000075
Vuln IDs
  • V-240353
  • V-89483
Rule IDs
  • SV-240353r877398_rule
  • SV-100133
Without confidentiality protection mechanisms, unauthorized individuals may gain access to sensitive information via a remote access session. Remote access is access to DoD nonpublic information systems by an authorized user (or an information system) communicating through an external, non-organization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless. Encryption provides a means to secure the remote connection to prevent unauthorized access to the data traversing the remote access connection (e.g., RDP), thereby providing a degree of confidentiality. The encryption strength of a mechanism is selected based on the security categorization of the information.
Checks: C-43586r670798_chk

Check the SSH daemon configuration for DoD-approved encryption to protect the confidentiality of SSH remote connections by performing the following commands: Check the "Ciphers" setting in the "sshd_config" file. # grep -i Ciphers /etc/ssh/sshd_config | grep -v '#' The output must contain either nothing or any number of the following algorithms: aes128-ctr, aes256-ctr. If the output contains an algorithm not listed above, this is a finding. Expected Output: Ciphers aes256-ctr,aes128-ctr

Fix: F-43545r670799_fix

Update the Ciphers directive with the following command: # sed -i "/^[^#]*Ciphers/ c\Ciphers aes256-ctr,aes128-ctr" /etc/ssh/sshd_config Save and close the file. Restart the sshd process: # service sshd restart

b
The SLES for vRealize must implement DoD-approved encryption to protect the confidentiality of remote access sessions - SSH Client.
AC-17 - Medium - CCI-000068 - V-240354 - SV-240354r877398_rule
RMF Control
AC-17
Severity
Medium
CCI
CCI-000068
Version
VRAU-SL-000080
Vuln IDs
  • V-240354
  • V-89485
Rule IDs
  • SV-240354r877398_rule
  • SV-100135
Without confidentiality protection mechanisms, unauthorized individuals may gain access to sensitive information via a remote access session. Remote access is access to DoD nonpublic information systems by an authorized user (or an information system) communicating through an external, non-organization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless. Encryption provides a means to secure the remote connection to prevent unauthorized access to the data traversing the remote access connection (e.g., RDP), thereby providing a degree of confidentiality. The encryption strength of a mechanism is selected based on the security categorization of the information.
Checks: C-43587r766908_chk

Check the SSH daemon configuration for DoD-approved encryption to protect the confidentiality of SSH remote connections by performing the following commands: Check the "Ciphers" setting in the "ssh_config" file. # grep -i Ciphers /etc/ssh/ssh_config | grep -v '#' The output must contain either nothing or any number of the following algorithms: aes256-ctr,aes128-ctr. If the output contains an algorithm not listed above, this is a finding. Expected Output: Ciphers aes256-ctr,aes128-ctr

Fix: F-43546r670802_fix

Update the "Ciphers" directive with the following command: # sed -i "/^[^#]*Ciphers/ c\Ciphers aes256-ctr,aes128-ctr" /etc/ssh/ssh_config Save and close the file.

b
The SLES for vRealize must produce audit records.
AU-3 - Medium - CCI-000130 - V-240355 - SV-240355r670806_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000130
Version
VRAU-SL-000085
Vuln IDs
  • V-240355
  • V-89487
Rule IDs
  • SV-240355r670806_rule
  • SV-100137
Without establishing what type of events occurred, it would be difficult to establish, correlate, and investigate the events leading up to an outage or attack. Audit record content that may be necessary to satisfy this requirement includes, 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. Associating event types with detected events in the operating system audit logs provides a means of investigating an attack; recognizing resource utilization or capacity thresholds; or identifying an improperly configured operating system.
Checks: C-43588r670804_chk

Verify the SLES for vRealize produces audit records by running the following command to determine the current status of the "auditd" service: # service auditd status If the service is enabled, the returned message must contain the following text: Checking for service auditd running If the service is not running, this is a finding.

Fix: F-43547r670805_fix

Enable the "auditd" service by performing the following commands: # chkconfig auditd on # service auditd start

b
The SLES for vRealize must alert the ISSO and SA (at a minimum) in the event of an audit processing failure.
AU-5 - Medium - CCI-000139 - V-240356 - SV-240356r670809_rule
RMF Control
AU-5
Severity
Medium
CCI
CCI-000139
Version
VRAU-SL-000125
Vuln IDs
  • V-240356
  • V-89489
Rule IDs
  • SV-240356r670809_rule
  • SV-100139
It is critical for the appropriate personnel to be aware if a system is at risk of failing to process audit logs as required. Without this notification, the security personnel may be unaware of an impending failure of the audit capability, and system operation may be adversely affected. Audit processing failures include software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded. This requirement applies to each audit data storage repository (i.e., distinct information system component where audit records are stored), the centralized audit storage capacity of organizations (i.e., all audit data storage repositories combined), or both.
Checks: C-43589r670807_chk

Check /etc/audit/auditd.conf for the space_left_action with the following command: # cat /etc/audit/auditd.conf | grep space_left_action If the "space_left_action" parameter is missing; is set to "ignore", "suspend", "single", or "halt"; or is blank, this is a finding. Expected Result: space_left_action = SYSLOG NOTES: If the "space_left_action" is set to "exec", the system executes a designated script. If this script informs the SA of the event, this is not a finding. If the "space_left_action" is set to "email" and the "action_mail_acct" parameter is not set to the email address of the system administrator, this is a finding. The "action_mail_acct" parameter, if missing, defaults to "root". Note that if the email address of the system administrator is on a remote system, "sendmail" must be available.

Fix: F-43548r670808_fix

Set the space_left_action parameter to the valid setting "SYSLOG" by running the following command: # sed -i "/^[^#]*space_left_action/ c\space_left_action = SYSLOG" /etc/audit/auditd.conf Restart the audit service: # service auditd restart

b
The SLES for vRealize must shut down by default upon audit failure (unless availability is an overriding concern).
AU-5 - Medium - CCI-000140 - V-240357 - SV-240357r670812_rule
RMF Control
AU-5
Severity
Medium
CCI
CCI-000140
Version
VRAU-SL-000130
Vuln IDs
  • V-240357
  • V-89491
Rule IDs
  • SV-240357r670812_rule
  • SV-100141
It is critical that when the operating system is at risk of failing to process audit logs as required, it 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. Responses to audit failure depend upon the nature of the failure mode. When availability is an overriding concern, other approved actions in response to an audit failure are as follows: 1) If the failure was caused by the lack of audit record storage capacity, the operating system must continue generating audit records if possible (automatically restarting the audit service if necessary), overwriting the oldest audit records in a first-in-first-out manner. 2) If audit records are sent to a centralized collection server and communication with this server is lost or the server fails, the operating system must queue audit records locally until communication is restored or until the audit records are retrieved manually. Upon restoration of the connection to the centralized collection server, action should be taken to synchronize the local audit data with the collection server.
Checks: C-43590r670810_chk

Verify the /etc/audit/auditd.conf has the "disk_full_action", "disk_error_action", and "admin_disk_space_left" parameters set. # grep disk_full_action /etc/audit/auditd.conf If the "disk_full_action" parameter is missing or set to "suspend" or "ignore" this is a finding. # grep disk_error_action /etc/audit/auditd.conf If the "disk_error_action" parameter is missing or set to "suspend" or "ignore" this is a finding. # grep admin_space_left_action /etc/audit/auditd.conf If the "admin_space_left_action" parameter is missing or set to "suspend" or "ignore" this is a finding.

Fix: F-43549r670811_fix

Edit /etc/audit/auditd.conf and set the "disk_full_action", "disk_error_action", and "admin_space_left_action" parameters to "syslog" with the following commands: # sed -i "/^[^#]*disk_full_action/ c\disk_full_action = SYSLOG" /etc/audit/auditd.conf # sed -i "/^[^#]*disk_error_action/ c\disk_error_action = SYSLOG" /etc/audit/auditd.conf # sed -i "/^[^#]*admin_space_left_action/ c\admin_space_left_action = SYSLOG" /etc/audit/auditd.conf For certain systems, the need for availability outweighs the need to log all actions, and a different setting should be determined.

b
The SLES for vRealize must protect audit information from unauthorized read access - ownership.
AU-9 - Medium - CCI-000162 - V-240358 - SV-240358r670815_rule
RMF Control
AU-9
Severity
Medium
CCI
CCI-000162
Version
VRAU-SL-000150
Vuln IDs
  • V-240358
  • V-89493
Rule IDs
  • SV-240358r670815_rule
  • SV-100143
Unauthorized disclosure of audit records can reveal system and configuration data to attackers, thus compromising its confidentiality. Audit information includes all information (e.g., audit records, audit settings, audit reports) needed to successfully audit operating system activity.
Checks: C-43591r670813_chk

Verify that the system audit logs are owned by "root": # (audit_log_file=$(grep "^log_file" /etc/audit/auditd.conf|sed s/^[^\/]*//) && if [ -f "${audit_log_file}" ] ; then printf "Log(s) found in "${audit_log_file%/*}":\n"; ls -l ${audit_log_file%/*}; else printf "audit log file(s) not found\n"; fi) If any audit log file is not owned by "root", this is a finding.

Fix: F-43550r670814_fix

Change the ownership of the audit log file(s). Procedure: # chown root <audit log file> # chown root /var/log/audit/audit.log

b
The SLES for vRealize must protect audit information from unauthorized read access - group-ownership.
AU-9 - Medium - CCI-000162 - V-240359 - SV-240359r670818_rule
RMF Control
AU-9
Severity
Medium
CCI
CCI-000162
Version
VRAU-SL-000155
Vuln IDs
  • V-240359
  • V-89495
Rule IDs
  • SV-240359r670818_rule
  • SV-100145
Unauthorized disclosure of audit records can reveal system and configuration data to attackers, thus compromising its confidentiality. Audit information includes all information (e.g., audit records, audit settings, audit reports) needed to successfully audit operating system activity.
Checks: C-43592r670816_chk

Verify that the system audit logs are group-owned by "root": # (audit_log_file=$(grep "^log_file" /etc/audit/auditd.conf|sed s/^[^\/]*//) &amp;&amp; if [ -f "${audit_log_file}" ] ; then printf "Log(s) found in "${audit_log_file%/*}":\n"; ls -l ${audit_log_file%/*}; else printf "audit log file(s) not found\n"; fi) If any audit log file is not group-owned by "root" or "admin", this is a finding.

Fix: F-43551r670817_fix

Change the group-ownership of the audit log file(s). Procedure: # chgrp root <audit log file> # chgrp root /var/log/audit/audit.log

b
The SLES for vRealize must protect audit information from unauthorized modification.
AU-9 - Medium - CCI-000163 - V-240360 - SV-240360r670821_rule
RMF Control
AU-9
Severity
Medium
CCI
CCI-000163
Version
VRAU-SL-000160
Vuln IDs
  • V-240360
  • V-89497
Rule IDs
  • SV-240360r670821_rule
  • SV-100147
If audit information were to become compromised, then forensic analysis and discovery of the true source of potentially malicious system activity is impossible to achieve. To ensure the veracity of audit information, 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.
Checks: C-43593r670819_chk

Verify that the system audit logs with the following command: # (audit_log_file=$(grep "^log_file" /etc/audit/auditd.conf|sed s/^[^\/]*//) &amp;&amp; if [ -f "${audit_log_file}" ] ; then printf "Log(s) found in "${audit_log_file%/*}":\n"; ls -l ${audit_log_file%/*}; else printf "audit log file(s) not found\n"; fi) If any audit log file has a mode more permissive than "0640", this is a finding.

Fix: F-43552r670820_fix

Change the mode of the audit log file(s): # chmod 0640 <audit log file>

b
The SLES for vRealize must protect audit information from unauthorized deletion.
AU-9 - Medium - CCI-000164 - V-240361 - SV-240361r670824_rule
RMF Control
AU-9
Severity
Medium
CCI
CCI-000164
Version
VRAU-SL-000165
Vuln IDs
  • V-240361
  • V-89499
Rule IDs
  • SV-240361r670824_rule
  • SV-100149
If audit information were to become compromised, then forensic analysis and discovery of the true source of potentially malicious system activity is impossible to achieve. To ensure the veracity of audit information, 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.
Checks: C-43594r670822_chk

Verify that the system audit logs with the following command: # (audit_log_file=$(grep "^log_file" /etc/audit/auditd.conf|sed s/^[^\/]*//) &amp;&amp; if [ -f "${audit_log_file}" ] ; then printf "Log(s) found in "${audit_log_file%/*}":\n"; ls -l ${audit_log_file%/*}; else printf "audit log file(s) not found\n"; fi) If any audit log file has a mode more permissive than "0640", this is a finding.

Fix: F-43553r670823_fix

Change the mode of the audit log file(s): # chmod 0640 <audit log file>

b
The SLES for vRealize must protect audit information from unauthorized deletion - log directories.
AU-9 - Medium - CCI-000164 - V-240362 - SV-240362r670827_rule
RMF Control
AU-9
Severity
Medium
CCI
CCI-000164
Version
VRAU-SL-000170
Vuln IDs
  • V-240362
  • V-89501
Rule IDs
  • SV-240362r670827_rule
  • SV-100151
If audit information were to become compromised, then forensic analysis and discovery of the true source of potentially malicious system activity is impossible to achieve. To ensure the veracity of audit information, 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.
Checks: C-43595r670825_chk

Run the following command to check the mode of the system audit directories: # grep "^log_file" /etc/audit/auditd.conf|sed 's/^[^/]*//; s/[^/]*$//'|xargs stat -c %a:%n Audit directories must be mode "0700". If any are more permissive, this is a finding.

Fix: F-43554r670826_fix

Change the mode of the audit log directories with the following command: # chmod 700 <audit log directory>

b
The SLES for vRealize must allow only the ISSM (or individuals or roles appointed by the ISSM) to select which auditable events are to be audited - Permissions.
AU-12 - Medium - CCI-000171 - V-240376 - SV-240376r670869_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000171
Version
VRAU-SL-000240
Vuln IDs
  • V-240376
  • V-89529
Rule IDs
  • SV-240376r670869_rule
  • SV-100179
Without the capability to restrict which roles and individuals can select which events are audited, unauthorized personnel may be able to prevent the auditing of critical events. Misconfigured audits may degrade the system's performance by overwhelming the audit log. Misconfigured audits may also make it more difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Checks: C-43609r670867_chk

Check the permissions of the rules files in /etc/audit: # ls -l /etc/audit/ NOTE: If /etc/audit/audit.rules is a symblic link to /etc/audit/audit.rules.STIG, then the check is only applicable to /etc/audit/audit.rules.STIG. If the permissions of the file is not set to "640", this is a finding.

Fix: F-43568r670868_fix

Change the permissions of the /etc/audit/audit.rules.STIG, the /etc/audit/audit.rules.ORIG, and the /etc/audit/audit.rules files (if not a symblic link): # chmod 640 /etc/audit/audit.rules.STIG # chmod 640 /etc/audit/audit.rules.ORIG # if [ -f /etc/audit/audit.rules ]; then chmod 640 /etc/audit/audit.rules; fi Or run the following command to implement all logging requirements: # /etc/dodscript.sh

b
The SLES for vRealize must allow only the ISSM (or individuals or roles appointed by the ISSM) to select which auditable events are to be audited - ownership.
AU-12 - Medium - CCI-000171 - V-240377 - SV-240377r670872_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000171
Version
VRAU-SL-000245
Vuln IDs
  • V-240377
  • V-89531
Rule IDs
  • SV-240377r670872_rule
  • SV-100181
Without the capability to restrict which roles and individuals can select which events are audited, unauthorized personnel may be able to prevent the auditing of critical events. Misconfigured audits may degrade the system's performance by overwhelming the audit log. Misconfigured audits may also make it more difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Checks: C-43610r670870_chk

Check the permissions of the rules files in /etc/audit: # ls -l /etc/audit/ NOTE: If /etc/audit/audit.rules is a symblic link to /etc/audit/audit.rules.STIG, then the check is only applicable to /etc/audit/audit.rules.STIG If the ownership is not set to "root", this is a finding.

Fix: F-43569r670871_fix

Change the ownership of the /etc/audit/audit.rules.STIG, the /etc/audit/audit.rules.ORIG, and the /etc/audit/audit.rules files (if not a symblic link): # chown root /etc/audit/audit.rules.STIG # chown root /etc/audit/audit.rules.ORIG # if [ -f /etc/audit/audit.rules ]; then chown root /etc/audit/audit.rules; fi Or run the following command to implement all logging requirements: # /etc/dodscript.sh

b
The SLES for vRealize must allow only the ISSM (or individuals or roles appointed by the ISSM) to select which auditable events are to be audited - group-ownership.
AU-12 - Medium - CCI-000171 - V-240378 - SV-240378r670875_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000171
Version
VRAU-SL-000250
Vuln IDs
  • V-240378
  • V-89533
Rule IDs
  • SV-240378r670875_rule
  • SV-100183
Without the capability to restrict which roles and individuals can select which events are audited, unauthorized personnel may be able to prevent the auditing of critical events. Misconfigured audits may degrade the system's performance by overwhelming the audit log. Misconfigured audits may also make it more difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Checks: C-43611r670873_chk

Check the permissions of the rules files in /etc/audit: # ls -l /etc/audit/ NOTE: If /etc/audit/audit.rules is a symblic link to /etc/audit/audit.rules.STIG, then the check is only applicable to /etc/audit/audit.rules.STIG. If the group-owner is not set to "root", this is a finding.

Fix: F-43570r670874_fix

Change the group-ownership of the /etc/audit/audit.rules.STIG, the /etc/audit/audit.rules.ORIG, and the /etc/audit/audit.rules files (if not a symblic link): # chgrp root /etc/audit/audit.rules.STIG # chgrp root /etc/audit/audit.rules.ORIG # if [ -f /etc/audit/audit.rules ]; then chgrp root /etc/audit/audit.rules; fi Or run the following command to implement all logging requirements: # /etc/dodscript.sh

b
The SLES for vRealize must generate audit records when successful/unsuccessful attempts to access privileges occur. The SLES for vRealize must generate audit records for all discretionary access control permission modifications using chmod.
AU-12 - Medium - CCI-000172 - V-240379 - SV-240379r670878_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
VRAU-SL-000255
Vuln IDs
  • V-240379
  • V-89535
Rule IDs
  • SV-240379r670878_rule
  • SV-100185
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter).
Checks: C-43612r670876_chk

To determine if the system is configured to audit calls to the "chmod" system call, run the following command: # auditctl -l | grep syscall | grep chmod If the system is configured to audit this activity, it will return several lines, such as: LIST_RULES: exit,always arch=3221225534 (0xc000003e) auid=0 syscall=chmod,fchmod,chown,fchown,fchownat,fchmodat LIST_RULES: exit,always arch=3221225534 (0xc000003e) auid&gt;=500 (0x1f4) auid!=-1 (0xffffffff) syscall=chmod,fchmod,chown,fchown,fchownat,fchmodat If no lines are returned, this is a finding.

Fix: F-43571r670877_fix

At a minimum, the audit system should collect file permission changes for all users and "root". Add the following to "/etc/audit/audit.rules": -a always,exit -F arch=b64 -S chmod -F auid=0 -a always,exit -F arch=b64 -S chmod -F auid>=500 -F auid!=4294967295 Or run the following command to implement all logging requirements: # /etc/dodscript.sh

b
The SLES for vRealize must generate audit records when successful/unsuccessful attempts to access privileges occur. The SLES for vRealize must generate audit records for all discretionary access control permission modifications using chown.
AU-12 - Medium - CCI-000172 - V-240380 - SV-240380r670881_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
VRAU-SL-000260
Vuln IDs
  • V-240380
  • V-89537
Rule IDs
  • SV-240380r670881_rule
  • SV-100187
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter).
Checks: C-43613r670879_chk

To determine if the system is configured to audit calls to the "chown" system call, run the following command: # auditctl -l | grep syscall | grep chown If the system is configured to audit this activity, it will return several lines, such as: LIST_RULES: exit,always arch=3221225534 (0xc000003e) auid=0 syscall=chmod,fchmod,chown,fchown,fchownat,fchmodat LIST_RULES: exit,always arch=3221225534 (0xc000003e) auid&gt;=500 (0x1f4) auid!=-1 (0xffffffff) syscall=chmod,fchmod,chown,fchown,fchownat,fchmodat If no lines are returned, this is a finding.

Fix: F-43572r670880_fix

At a minimum, the audit system should collect file permission changes for all users and "root". Add the following to "/etc/audit/audit.rules": -a always,exit -F arch=b64 -S chown -F auid=0 -a always,exit -F arch=b64 -S chown -F auid>=500 -F auid!=4294967295 Or run the following command to implement all logging requirements: # /etc/dodscript.sh

b
The SLES for vRealize must generate audit records when successful/unsuccessful attempts to access privileges occur. The SLES for vRealize must generate audit records for all discretionary access control permission modifications using fchmod.
AU-12 - Medium - CCI-000172 - V-240381 - SV-240381r670884_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
VRAU-SL-000265
Vuln IDs
  • V-240381
  • V-89539
Rule IDs
  • SV-240381r670884_rule
  • SV-100189
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter).
Checks: C-43614r670882_chk

To determine if the system is configured to audit calls to the "fchmod" system call, run the following command: # auditctl -l | grep syscall | grep fchmod If the system is configured to audit this activity, it will return several lines, such as: LIST_RULES: exit,always arch=3221225534 (0xc000003e) auid=0 syscall=chmod,fchmod,chown,fchown,fchownat,fchmodat LIST_RULES: exit,always arch=3221225534 (0xc000003e) auid&gt;=500 (0x1f4) auid!=-1 (0xffffffff) syscall=chmod,fchmod,chown,fchown,fchownat,fchmodat If no lines are returned, this is a finding.

Fix: F-43573r670883_fix

At a minimum, the SLES for vRealize audit system should collect file permission changes for all users and "root". Add the following to "/etc/audit/audit.rules": -a always,exit -F arch=b64 -S fchmod -F auid=0 -a always,exit -F arch=b64 -S fchmod -F auid>=500 -F auid!=4294967295 Or run the following command to implement all logging requirements: # /etc/dodscript.sh

b
The SLES for vRealize must generate audit records when successful/unsuccessful attempts to access privileges occur. The SLES for vRealize must generate audit records for all discretionary access control permission modifications using fchmodat.
AU-12 - Medium - CCI-000172 - V-240382 - SV-240382r670887_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
VRAU-SL-000270
Vuln IDs
  • V-240382
  • V-89541
Rule IDs
  • SV-240382r670887_rule
  • SV-100191
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter).
Checks: C-43615r670885_chk

To determine if the system is configured to audit calls to the "fchmodat" system call, run the following command: # auditctl -l | grep syscall | grep fchmodat If the system is configured to audit this activity, it will return several lines, such as: LIST_RULES: exit,always arch=3221225534 (0xc000003e) auid=0 syscall=chmod,fchmod,chown,fchown,fchownat,fchmodat LIST_RULES: exit,always arch=3221225534 (0xc000003e) auid&gt;=500 (0x1f4) auid!=-1 (0xffffffff) syscall=chmod,fchmod,chown,fchown,fchownat,fchmodat If no lines are returned, this is a finding.

Fix: F-43574r670886_fix

At a minimum, the SLES for vRealize audit system should collect file permission changes for all users and "root". Add the following to "/etc/audit/audit.rules": -a always,exit -F arch=b64 -S fchmodat -F auid=0 -a always,exit -F arch=b64 -S fchmodat -F auid>=500 -F auid!=4294967295 Or run the following command to implement all logging requirements: # /etc/dodscript.sh

b
The SLES for vRealize must generate audit records when successful/unsuccessful attempts to access privileges occur. The SLES for vRealize must generate audit records for all discretionary access control permission modifications using fchown.
AU-12 - Medium - CCI-000172 - V-240383 - SV-240383r670890_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
VRAU-SL-000275
Vuln IDs
  • V-240383
  • V-89543
Rule IDs
  • SV-240383r670890_rule
  • SV-100193
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter).
Checks: C-43616r670888_chk

To determine if the system is configured to audit calls to the "fchown" system call, run the following command: # auditctl -l | grep syscall | grep fchown If the system is configured to audit this activity, it will return several lines, such as: LIST_RULES: exit,always arch=3221225534 (0xc000003e) auid=0 syscall=chmod,fchmod,chown,fchown,fchownat,fchmodat LIST_RULES: exit,always arch=3221225534 (0xc000003e) auid&gt;=500 (0x1f4) auid!=-1 (0xffffffff) syscall=chmod,fchmod,chown,fchown,fchownat,fchmodat If no lines are returned, this is a finding.

Fix: F-43575r670889_fix

At a minimum, the SLES for vRealize audit system should collect file permission changes for all users and "root". Add the following to "/etc/audit/audit.rules": -a always,exit -F arch=b64 -S fchown -F auid=0 -a always,exit -F arch=b64 -S fchown -F auid>=500 -F auid!=4294967295 -a always,exit -F arch=b32 -S fchown -a always,exit -F arch=b32 -S fchown32 Or run the following command to implement all logging requirements: # /etc/dodscript.sh

b
The SLES for vRealize must generate audit records when successful/unsuccessful attempts to access privileges occur. The SLES for vRealize must generate audit records for all discretionary access control permission modifications using fchownat.
AU-12 - Medium - CCI-000172 - V-240384 - SV-240384r670893_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
VRAU-SL-000280
Vuln IDs
  • V-240384
  • V-89545
Rule IDs
  • SV-240384r670893_rule
  • SV-100195
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter).
Checks: C-43617r670891_chk

To determine if the system is configured to audit calls to the "fchownat" system call, run the following command: # auditctl -l | grep syscall | grep fchownat If the system is configured to audit this activity, it will return several lines, such as: LIST_RULES: exit,always arch=3221225534 (0xc000003e) auid=0 syscall=chmod,fchmod,chown,fchown,fchownat,fchmodat LIST_RULES: exit,always arch=3221225534 (0xc000003e) auid&gt;=500 (0x1f4) auid!=-1 (0xffffffff) syscall=chmod,fchmod,chown,fchown,fchownat,fchmodat If no lines are returned, this is a finding.

Fix: F-43576r670892_fix

At a minimum, the SLES for vRealize audit system should collect file permission changes for all users and "root". Add the following to "/etc/audit/audit.rules": -a always,exit -F arch=b64 -S fchownat -F auid=0 -a always,exit -F arch=b64 -S fchownat -F auid>=500 -F auid!=4294967295 Or run the following command to implement all logging requirements: # /etc/dodscript.sh

b
The SLES for vRealize must generate audit records when successful/unsuccessful attempts to access privileges occur. The SLES for vRealize must generate audit records for all discretionary access control permission modifications using fremovexattr.
AU-12 - Medium - CCI-000172 - V-240385 - SV-240385r670896_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
VRAU-SL-000285
Vuln IDs
  • V-240385
  • V-89547
Rule IDs
  • SV-240385r670896_rule
  • SV-100197
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter).
Checks: C-43618r670894_chk

To determine if the system is configured to audit calls to the "fremovexattr" system call, run the following command: # auditctl -l | grep syscall | grep fremovexattr If the system is configured to audit this activity, it will return several lines, such as: LIST_RULES: exit,always arch=3221225534 (0xc000003e) syscall=lchown,sethostname,init_module,delete_module,setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr,clock_settime If no lines are returned, this is a finding.

Fix: F-43577r670895_fix

At a minimum, the SLES for vRealize audit system should collect file permission changes for all users and "root". Add the following to "/etc/audit/audit.rules": -a always,exit -F arch=b64 -S fremovexattr Or run the following command to implement all logging requirements: # /etc/dodscript.sh

b
The SLES for vRealize must generate audit records when successful/unsuccessful attempts to access privileges occur. The SLES for vRealize must generate audit records for all discretionary access control permission modifications using fsetxattr.
AU-12 - Medium - CCI-000172 - V-240386 - SV-240386r670899_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
VRAU-SL-000290
Vuln IDs
  • V-240386
  • V-89549
Rule IDs
  • SV-240386r670899_rule
  • SV-100199
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter).
Checks: C-43619r670897_chk

To determine if the system is configured to audit calls to the "fsetxattr" system call, run the following command: # auditctl -l | grep syscall | grep fsetxattr If the system is configured to audit this activity, it will return several lines, such as: LIST_RULES: exit,always arch=3221225534 (0xc000003e) syscall=lchown,sethostname,init_module,delete_module,setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr,clock_settime If no lines are returned, this is a finding.

Fix: F-43578r670898_fix

At a minimum, the SLES for vRealize audit system should collect file permission changes for all users and "root". Add the following to "/etc/audit/audit.rules": -a always,exit -F arch=b64 -S fsetxattr Or run the following command to implement all logging requirements: # /etc/dodscript.sh

b
The SLES for vRealize must generate audit records when successful/unsuccessful attempts to access privileges occur. The SLES for vRealize must generate audit records for all discretionary access control permission modifications using lchown.
AU-12 - Medium - CCI-000172 - V-240387 - SV-240387r670902_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
VRAU-SL-000295
Vuln IDs
  • V-240387
  • V-89551
Rule IDs
  • SV-240387r670902_rule
  • SV-100201
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter).
Checks: C-43620r670900_chk

To determine if the system is configured to audit calls to the "lchown" system call, run the following command: # auditctl -l | grep syscall | grep lchown If the system is configured to audit this activity, it will return several lines, such as: LIST_RULES: exit,always arch=3221225534 (0xc000003e) syscall=lchown,sethostname,init_module,delete_module,setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr,clock_settime If no lines are returned, this is a finding.

Fix: F-43579r670901_fix

At a minimum, the SLES for vRealize audit system should collect file permission changes for all users and "root". Add the following to "/etc/audit/audit.rules": -a always,exit -F arch=b64 -S lchown Or run the following command to implement all logging requirements: # /etc/dodscript.sh

b
The SLES for vRealize must generate audit records when successful/unsuccessful attempts to access privileges occur. The SLES for vRealize must generate audit records for all discretionary access control permission modifications using lremovexattr.
AU-12 - Medium - CCI-000172 - V-240388 - SV-240388r670905_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
VRAU-SL-000300
Vuln IDs
  • V-240388
  • V-89553
Rule IDs
  • SV-240388r670905_rule
  • SV-100203
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter).
Checks: C-43621r670903_chk

To determine if the system is configured to audit calls to the "lremovexattr" system call, run the following command: # auditctl -l | grep syscall | grep lremovexattr If the system is configured to audit this activity, it will return several lines, such as: LIST_RULES: exit,always arch=3221225534 (0xc000003e) syscall=lchown,sethostname,init_module,delete_module,setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr,clock_settime If no lines are returned, this is a finding.

Fix: F-43580r670904_fix

At a minimum, the SLES for vRealize audit system should collect file permission changes for all users and "root". Add the following to "/etc/audit/audit.rules": -a always,exit -F arch=b64 -S lremovexattr Or run the following command to implement all logging requirements: # /etc/dodscript.sh

b
The SLES for vRealize must generate audit records when successful/unsuccessful attempts to access privileges occur. The SLES for vRealize must generate audit records for all discretionary access control permission modifications using lsetxattr.
AU-12 - Medium - CCI-000172 - V-240389 - SV-240389r670908_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
VRAU-SL-000305
Vuln IDs
  • V-240389
  • V-89555
Rule IDs
  • SV-240389r670908_rule
  • SV-100205
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter).
Checks: C-43622r670906_chk

To determine if the system is configured to audit calls to the "lsetxattr" system call, run the following command: # auditctl -l | grep syscall | grep lsetxattr If the system is configured to audit this activity, it will return several lines, such as: LIST_RULES: exit,always arch=3221225534 (0xc000003e) syscall=lchown,sethostname,init_module,delete_module,setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr,clock_settime If no lines are returned, this is a finding.

Fix: F-43581r670907_fix

At a minimum, the SLES for vRealize audit system should collect file permission changes for all users and "root". Add the following to "/etc/audit/audit.rules": -a always,exit -F arch=b64 -S lsetxattr Or run the following command to implement all logging requirements: # /etc/dodscript.sh

b
The SLES for vRealize must generate audit records when successful/unsuccessful attempts to access privileges occur. The SLES for vRealize must generate audit records for all discretionary access control permission modifications using removexattr.
AU-12 - Medium - CCI-000172 - V-240390 - SV-240390r670911_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
VRAU-SL-000310
Vuln IDs
  • V-240390
  • V-89557
Rule IDs
  • SV-240390r670911_rule
  • SV-100207
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter).
Checks: C-43623r670909_chk

To determine if the system is configured to audit calls to the "removexattr" system call, run the following command: # auditctl -l | grep syscall | grep removexattr If the system is configured to audit this activity, it will return several lines, such as: LIST_RULES: exit,always arch=3221225534 (0xc000003e) syscall=lchown,sethostname,init_module,delete_module,setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr,clock_settime If no lines are returned, this is a finding.

Fix: F-43582r670910_fix

At a minimum, the SLES for vRealize audit system should collect file permission changes for all users and "root". Add the following to "/etc/audit/audit.rules": -a always,exit -F arch=b64 -S removexattr Or run the following command to implement all logging requirements: # /etc/dodscript.sh

b
The SLES for vRealize must generate audit records when successful/unsuccessful attempts to access privileges occur. The SLES for vRealize must generate audit records for all discretionary access control permission modifications using setxattr.
AU-12 - Medium - CCI-000172 - V-240391 - SV-240391r670914_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
VRAU-SL-000315
Vuln IDs
  • V-240391
  • V-89559
Rule IDs
  • SV-240391r670914_rule
  • SV-100209
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter).
Checks: C-43624r670912_chk

To determine if the system is configured to audit calls to the "setxattr" system call, run the following command: # auditctl -l | grep syscall | grep setxattr If the system is configured to audit this activity, it will return several lines, such as: LIST_RULES: exit,always arch=3221225534 (0xc000003e) syscall=lchown,sethostname,init_module,delete_module,setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr,clock_settime If no lines are returned, this is a finding.

Fix: F-43583r670913_fix

At a minimum, the SLES for vRealize audit system should collect file permission changes for all users and "root". Add the following to "/etc/audit/audit.rules": -a always,exit -F arch=b64 -S setxattr Or run the following command to implement all logging requirements: # /etc/dodscript.sh

b
The SLES for vRealize must generate audit records when successful/unsuccessful attempts to access privileges occur. The SLES for vRealize must generate audit records for all failed attempts to access files and programs.
AU-12 - Medium - CCI-000172 - V-240392 - SV-240392r670917_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
VRAU-SL-000320
Vuln IDs
  • V-240392
  • V-89561
Rule IDs
  • SV-240392r670917_rule
  • SV-100211
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter).
Checks: C-43625r670915_chk

To check that the audit system collects unauthorized file accesses, run the following commands: # grep EACCES /etc/audit/audit.rules -a exit,always -F arch=b64 -S swapon -F exit=-EACCES -a exit,always -F arch=b64 -S creat -F exit=-EACCES -a exit,always -F arch=b64 -S open -F exit=-EACCES # grep EPERM /etc/audit/audit.rules -a exit,always -F arch=b64 -S swapon -F exit=-EPERM -a exit,always -F arch=b64 -S creat -F exit=-EPERM -a exit,always -F arch=b64 -S open -F exit=-EPERM If either command lacks output, this is a finding.

Fix: F-43584r670916_fix

Add the following to "/etc/audit/audit.rules": -a exit,always -F arch=b64 -S swapon -F exit=-EACCES -a exit,always -F arch=b64 -S creat -F exit=-EACCES -a exit,always -F arch=b64 -S open -F exit=-EACCES -a exit,always -F arch=b64 -S swapon -F exit=-EPERM -a exit,always -F arch=b64 -S creat -F exit=-EPERM -a exit,always -F arch=b64 -S open -F exit=-EPERM Or run the following command to implement all logging requirements: # /etc/dodscript.sh

b
The SLES for vRealize must enforce password complexity by requiring that at least one upper-case character be used.
IA-5 - Medium - CCI-000192 - V-240393 - SV-240393r670920_rule
RMF Control
IA-5
Severity
Medium
CCI
CCI-000192
Version
VRAU-SL-000340
Vuln IDs
  • V-240393
  • V-89563
Rule IDs
  • SV-240393r670920_rule
  • SV-100213
Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password complexity is one factor of several that determines how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.
Checks: C-43626r670918_chk

Check the SLES for vRealize enforces password complexity by requiring that at least one upper-case character be used by using the following command: # grep ucredit /etc/pam.d/common-password-vmware.local If "ucredit" is not set to "-1" or not at all, this is a finding. Expected Result: password requisite pam_cracklib.so dcredit=-1 ucredit=-1 lcredit=-1 ocredit=-1 minlen=14 difok=4 retry=3

Fix: F-43585r670919_fix

If "ucredit" was not set at all in /etc/pam.d/common-password-vmware.local then run the following command: # sed -i '/pam_cracklib.so/ s/$/ ucredit=-1/' /etc/pam.d/common-password-vmware.local If "ucredit" was set incorrectly then run the following command to set it to "-1": # sed -i '/pam_cracklib.so/ s/ucredit=../ucredit=-1/' /etc/pam.d/common-password-vmware.local

b
Global settings defined in common- {account,auth,password,session} must be applied in the pam.d definition files.
IA-5 - Medium - CCI-000192 - V-240394 - SV-240394r670923_rule
RMF Control
IA-5
Severity
Medium
CCI
CCI-000192
Version
VRAU-SL-000345
Vuln IDs
  • V-240394
  • V-89565
Rule IDs
  • SV-240394r670923_rule
  • SV-100215
Pam global requirements are generally defined in the common-account, common-auth, common- password and common-session files located in the /etc/pam.d directory. In order for the requirements to be applied the file(s) containing them must be included directly or indirectly in each program's definition file in /etc/pam.d
Checks: C-43627r670921_chk

Verify that common-{account,auth,password,session} settings are being applied. Verify that local customization has occurred in the common- {account,auth,password,session}-pc file(s) by some method other than the use of the pam-config utility. The files "/etc/pam.d/common-{account,auth,password,session} -pc " are auto-generated by "pam-config". Any manual changes made to them will be lost if "pam-config" is allowed to run. # ls -l /etc/pam.d/common-{account,auth,password,session} If the symlinks point to "/etc/pam.d/common- {account,auth,password,session}-pc" and manual updates have been made in these files, the updates cannot be protected if pam-config is enabled. # ls -l /usr/sbin/pam-config If the setting for "pam-config" is not "000", this is a finding.

Fix: F-43586r670922_fix

In the default distribution of SLES 11, "/etc/pam.d/common- {account,auth,password,session}" are symlinks to their respective "/etc/pam.d/common- {account,auth,password,session}-pc" files. These common- {account,auth,password,session}-pc files are auto-generated by the pam-config utility. Edit /usr/sbin/pam-config permissions to prevent its use: # chmod 000 /usr/sbin/pam-config

b
The SLES for vRealize must enforce password complexity by requiring that at least one lower-case character be used.
IA-5 - Medium - CCI-000193 - V-240395 - SV-240395r670926_rule
RMF Control
IA-5
Severity
Medium
CCI
CCI-000193
Version
VRAU-SL-000350
Vuln IDs
  • V-240395
  • V-89567
Rule IDs
  • SV-240395r670926_rule
  • SV-100217
Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password complexity is one factor of several that determines how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.
Checks: C-43628r670924_chk

Verify the SLES for vRealize enforces password complexity by requiring that at least one lower-case character be used by using the following command: # grep lcredit /etc/pam.d/common-password-vmware.local If "lcredit" is not set to "-1" or not at all, this is a finding. Expected Result: password requisite pam_cracklib.so dcredit=-1 ucredit=-1 lcredit=-1 ocredit=-1 minlen=14 difok=4 retry=3

Fix: F-43587r670925_fix

If "lcredit" was not set at all in /etc/pam.d/common-password-vmware.local then run the following command: # sed -i '/pam_cracklib.so/ s/$/ lcredit=-1/' /etc/pam.d/common-password-vmware.local If "lcredit" was set incorrectly then run the following command to set it to "-1": # sed -i '/pam_cracklib.so/ s/lcredit=../lcredit=-1/' /etc/pam.d/common-password-vmware.local

b
The SLES for vRealize must enforce password complexity by requiring that at least one numeric character be used.
IA-5 - Medium - CCI-000194 - V-240396 - SV-240396r670929_rule
RMF Control
IA-5
Severity
Medium
CCI
CCI-000194
Version
VRAU-SL-000355
Vuln IDs
  • V-240396
  • V-89569
Rule IDs
  • SV-240396r670929_rule
  • SV-100219
Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password complexity is one factor of several that determines how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.
Checks: C-43629r670927_chk

Check that the SLES for vRealize enforces password complexity by requiring that at least one numeric character be used by running the following command: # grep dcredit /etc/pam.d/common-password-vmware.local If "dcredit" is not set to "-1" or is not set at all, this is a finding. Expected Result: password requisite pam_cracklib.so dcredit=-1 ucredit=-1 lcredit=-1 ocredit=-1 minlen=14 difok=4 retry=3

Fix: F-43588r670928_fix

If "dcredit" was not set at all in /etc/pam.d/common-password-vmware.local, run the following command: # sed -i '/pam_cracklib.so/ s/$/ dcredit=-1/' /etc/pam.d/common-password-vmware.local If "dcredit" was set incorrectly, run the following command: # sed -i '/pam_cracklib.so/ s/dcredit=../dcredit=-1/' /etc/pam.d/common-password-vmware.local

c
The SLES for vRealize must require the change of at least eight of the total number of characters when passwords are changed.
IA-5 - High - CCI-000195 - V-240397 - SV-240397r670932_rule
RMF Control
IA-5
Severity
High
CCI
CCI-000195
Version
VRAU-SL-000360
Vuln IDs
  • V-240397
  • V-89571
Rule IDs
  • SV-240397r670932_rule
  • SV-100221
If the operating system allows the user to consecutively reuse extensive portions of passwords, this increases the chances of password compromise by increasing the window of opportunity for attempts at guessing and brute-force attacks. The number of changed characters refers to the number of changes required with respect to the total number of positions in the current password. In other words, characters may be the same within the two passwords; however, the positions of the like characters must be different.
Checks: C-43630r670930_chk

Check that at least eight characters need to be changed between old and new passwords during a password change by running the following command: # grep pam_cracklib /etc/pam.d/common-password-vmware.local The "difok" parameter indicates how many characters must be different. The DoD requires at least eight characters to be different during a password change. This would appear as "difok=8". If difok is not found or not set to at least "8", this is a finding. Expected Result: password requisite pam_cracklib.so dcredit=-1 ucredit=-1 lcredit=-1 ocredit=-1 minlen=14 difok=8 retry=3

Fix: F-43589r670931_fix

If "difok" was not set at all in /etc/pam.d/common-password-vmware.local then run the following command: # sed -i '/pam_cracklib.so/ s/$/ difok-8/' /etc/pam.d/common-password-vmware.local If "difok" was set incorrectly then run the following command to set it to "8": # sed -i '/pam_cracklib.so/ s/difok=./difok=8/' /etc/pam.d/common-password-vmware.local

c
The SLES for vRealize must store only encrypted representations of passwords.
IA-5 - High - CCI-000196 - V-240398 - SV-240398r877397_rule
RMF Control
IA-5
Severity
High
CCI
CCI-000196
Version
VRAU-SL-000365
Vuln IDs
  • V-240398
  • V-89573
Rule IDs
  • SV-240398r877397_rule
  • SV-100223
Passwords need to be protected at all times, and encryption is the standard method for protecting passwords. If passwords are not encrypted, they can be plainly read (i.e., clear text) and easily compromised.
Checks: C-43631r670933_chk

Check that the user account passwords are stored hashed using sha512 by running the following command: # more /etc/shadow If the password hash does not begins with "$6$" for user accounts such as "root" or "admin", this is a finding.

Fix: F-43590r670934_fix

Reset the user password using the following command: # passwd [user account]

c
The SLES for vRealize must store only encrypted representations of passwords.
IA-5 - High - CCI-000196 - V-240399 - SV-240399r877397_rule
RMF Control
IA-5
Severity
High
CCI
CCI-000196
Version
VRAU-SL-000370
Vuln IDs
  • V-240399
  • V-89575
Rule IDs
  • SV-240399r877397_rule
  • SV-100225
Passwords need to be protected at all times, and encryption is the standard method for protecting passwords. If passwords are not encrypted, they can be plainly read (i.e., clear text) and easily compromised.
Checks: C-43632r670936_chk

Check that the user account passwords are stored hashed using sha512 by running the following command: # cat /etc/default/passwd | grep CRYPT=sha512 If "CRYPT=sha512" is not listed, this is a finding.

Fix: F-43591r670937_fix

Ensure password are being encrypted with hash sha512 with the following command: # echo 'CRYPT=sha512'>>/etc/default/passwd

b
SLES for vRealize must enforce 24 hours/1 day as the minimum password lifetime.
IA-5 - Medium - CCI-000198 - V-240400 - SV-240400r670941_rule
RMF Control
IA-5
Severity
Medium
CCI
CCI-000198
Version
VRAU-SL-000380
Vuln IDs
  • V-240400
  • V-89577
Rule IDs
  • SV-240400r670941_rule
  • SV-100227
Enforcing a minimum password lifetime helps to prevent repeated password changes to defeat the password reuse or history enforcement requirement. If users are allowed to immediately and continually change their password, then the password could be repeatedly changed in a short period of time to defeat the organization's policy regarding password reuse.
Checks: C-43633r670939_chk

To check that the SLES for vRealize enforces 24 hours/1 day as the minimum password age, run the following command: # grep PASS_MIN_DAYS /etc/login.defs | grep -v '#' The DoD requirement is "1". If "PASS_MIN_DAYS" is not set to the required value, this is a finding.

Fix: F-43592r670940_fix

To configure the SLES for vRealize to enforce 24 hours/1 day as the minimum password age, edit the file "/etc/login.defs" with the following command: # sed -i "/^[^#]*PASS_MIN_DAYS/ c\PASS_MIN_DAYS 1" /etc/login.defs

b
Users must not be able to change passwords more than once every 24 hours.
IA-5 - Medium - CCI-000198 - V-240401 - SV-240401r670944_rule
RMF Control
IA-5
Severity
Medium
CCI
CCI-000198
Version
VRAU-SL-000385
Vuln IDs
  • V-240401
  • V-89579
Rule IDs
  • SV-240401r670944_rule
  • SV-100229
Enforcing a minimum password lifetime helps to prevent repeated password changes to defeat the password reuse or history enforcement requirement. If users are allowed to immediately and continually change their password, then the password could be repeatedly changed in a short period of time to defeat the organization's policy regarding password reuse.
Checks: C-43634r670942_chk

Check the minimum time period between password changes for each user account is 1 day. # cat /etc/shadow | cut -d ':' -f1,4 | grep -v 1 | grep -v ":$" If any results are returned, this is a finding.

Fix: F-43593r670943_fix

Change the minimum time period between password changes for each [USER] account to 1 day. The command in the check text will give you a list of users that need to be updated to be in compliance. # passwd -n 1 [USER]

b
SLES for vRealize must enforce a 60-day maximum password lifetime restriction.
IA-5 - Medium - CCI-000199 - V-240402 - SV-240402r670947_rule
RMF Control
IA-5
Severity
Medium
CCI
CCI-000199
Version
VRAU-SL-000390
Vuln IDs
  • V-240402
  • V-89581
Rule IDs
  • SV-240402r670947_rule
  • SV-100231
Any password, no matter how complex, can eventually be cracked. Therefore, passwords need to be changed periodically. If the operating system does not limit the lifetime of passwords and force users to change their passwords, there is the risk that the operating system passwords could be compromised.
Checks: C-43635r670945_chk

To check that the SLES for vRealize enforces a 60-days or less maximum password age, run the following command: # grep PASS_MAX_DAYS /etc/login.defs | grep -v "#" The DoD requirement is "60" days or less (greater than zero, as zero days will lock the account immediately). If "PASS_MAX_DAYS" is not set to the required value, this is a finding.

Fix: F-43594r670946_fix

To configure the SLES for vRealize to enforce a 60-day or less maximum password age, edit the file "/etc/login.defs" and add or correct the following line. Replace [DAYS] with the appropriate amount of days. # sed -i "/^[^#]*PASS_MAX_DAYS/ c\PASS_MAX_DAYS 60" /etc/login.defs The DoD requirement is "60" days or less (greater than zero, as zero days will lock the account immediately).

b
User passwords must be changed at least every 60 days.
IA-5 - Medium - CCI-000199 - V-240403 - SV-240403r670950_rule
RMF Control
IA-5
Severity
Medium
CCI
CCI-000199
Version
VRAU-SL-000395
Vuln IDs
  • V-240403
  • V-89583
Rule IDs
  • SV-240403r670950_rule
  • SV-100233
Any password, no matter how complex, can eventually be cracked. Therefore, passwords need to be changed periodically. If the operating system does not limit the lifetime of passwords and force users to change their passwords, there is the risk that the operating system passwords could be compromised.
Checks: C-43636r670948_chk

Check the max days field of /etc/shadow by running the following command: # cat /etc/shadow | cut -d':' -f1,5 | egrep -v "([0|60])" | grep -v ":$" If any results are returned, this is a finding.

Fix: F-43595r670949_fix

Set the maximum time period between password changes for each [USER] account to "60" days. The command in the check text will give you a list of users that need to be updated to be in compliance. # passwd -x 60 [USER] The DoD requirement is "60" days.

b
The SLES for vRealize must prohibit password reuse for a minimum of five generations.
IA-5 - Medium - CCI-000200 - V-240404 - SV-240404r670953_rule
RMF Control
IA-5
Severity
Medium
CCI
CCI-000200
Version
VRAU-SL-000400
Vuln IDs
  • V-240404
  • V-89585
Rule IDs
  • SV-240404r670953_rule
  • SV-100235
Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. If the information system or application allows the user to consecutively reuse their password when that password has exceeded its defined lifetime, the end result is a password that is not changed as per policy requirements.
Checks: C-43637r670951_chk

Verify that the SLES for vRealize prohibits the reuse of a password for a minimum of five generations by running the following commands: # grep pam_pwhistory.so /etc/pam.d/common-password-vmware.local If the "remember" option in /etc/pam.d/common-password-vmware.local is not "5" or greater, this is a finding.

Fix: F-43596r670952_fix

Configure pam to use password history. If "remember" was not set at all in /etc/pam.d/common-password-vmware.local, run the following command: # sed -i '/pam_cracklib.so/ s/$/ remember=5/' /etc/pam.d/common-password-vmware.local If "remember" was set incorrectly, run the following command to set it to "5": # sed -i '/pam_cracklib.so/ s/remember=./remember=5/' /etc/pam.d/common-password-vmware.local

b
The SLES for vRealize must prohibit password reuse for a minimum of five generations - old passwords are being stored.
IA-5 - Medium - CCI-000200 - V-240405 - SV-240405r670956_rule
RMF Control
IA-5
Severity
Medium
CCI
CCI-000200
Version
VRAU-SL-000405
Vuln IDs
  • V-240405
  • V-89587
Rule IDs
  • SV-240405r670956_rule
  • SV-100237
Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. If the information system or application allows the user to consecutively reuse their password when that password has exceeded its defined lifetime, the end result is a password that is not changed as per policy requirements.
Checks: C-43638r670954_chk

Verify that the old password file "opasswd" exists, by running the following command: # ls /etc/security/opasswd If "/etc/security/opasswd" does not exist, this is a finding.

Fix: F-43597r670955_fix

Create the password history file. # touch /etc/security/opasswd # chown root:root /etc/security/opasswd # chmod 0600 /etc/security/opasswd

b
The SLES for vRealize must enforce a minimum 15-character password length.
IA-5 - Medium - CCI-000205 - V-240406 - SV-240406r670959_rule
RMF Control
IA-5
Severity
Medium
CCI
CCI-000205
Version
VRAU-SL-000410
Vuln IDs
  • V-240406
  • V-89589
Rule IDs
  • SV-240406r670959_rule
  • SV-100239
The shorter the password, the lower the number of possible combinations that need to be tested before the password is compromised. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at 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. Use of more characters in a password helps to exponentially increase the time and/or resources required to compromise the password.
Checks: C-43639r670957_chk

Verify that the SLES for vRealize enforces a minimum 15-character password length by running the following command: # grep pam_cracklib /etc/pam.d/common-password-vmware.local # grep pam_cracklib /etc/pam.d/common-password If "minlen" is not set to "15" or higher, this is a finding.

Fix: F-43598r670958_fix

If "minlen" was not set at all in /etc/pam.d/common-password-vmware.local, run the following command: # sed -i '/pam_cracklib.so/ s/$/ minlen=15/' /etc/pam.d/common-password-vmware.local If "minlen" was set incorrectly then run the following command to set it to "15": # sed -i '/pam_cracklib.so/ s/minlen=../minlen=15/' /etc/pam.d/common-password-vmware.local

b
The system must require root password authentication upon booting into single-user mode.
AC-3 - Medium - CCI-000213 - V-240407 - SV-240407r670962_rule
RMF Control
AC-3
Severity
Medium
CCI
CCI-000213
Version
VRAU-SL-000420
Vuln IDs
  • V-240407
  • V-89591
Rule IDs
  • SV-240407r670962_rule
  • SV-100241
To mitigate the risk of unauthorized access to sensitive information by entities that have been issued certificates by DoD-approved PKIs, all DoD systems (e.g., web servers and web portals) must be properly configured to incorporate access control methods that do not rely solely on the possession of a certificate for access. Successful authentication must not automatically give an entity access to an asset or security boundary. Authorization procedures and controls must be implemented to ensure each authenticated entity also has a validated and current authorization. Authorization is the process of determining whether an entity, once authenticated, is permitted to access a specific asset. Information systems use access control policies and enforcement mechanisms to implement this requirement. Access control policies include: identity-based policies, role-based policies, and attribute-based policies. Access enforcement mechanisms include: access control lists, access control matrices, and cryptography. These policies and mechanisms must be employed by the application to control access between users (or processes acting on behalf of users) and objects (e.g., devices, files, records, processes, programs, and domains) in the information system.
Checks: C-43640r670960_chk

Verify that root password is required for single user mode login with the following command: # grep sulogin /etc/inittab Expected result: ~~:S:respawn:/sbin/sulogin If the expected result is not displayed, this is a finding.

Fix: F-43599r670961_fix

Configure the system to require root password login with single user mode use the following command: # echo '~~:S:respawn:/sbin/sulogin' >> /etc/inittab

b
Bootloader authentication must be enabled to prevent users without privilege to gain access to restricted file system resources.
AC-3 - Medium - CCI-000213 - V-240408 - SV-240408r670965_rule
RMF Control
AC-3
Severity
Medium
CCI
CCI-000213
Version
VRAU-SL-000425
Vuln IDs
  • V-240408
  • V-89593
Rule IDs
  • SV-240408r670965_rule
  • SV-100243
To mitigate the risk of unauthorized access to sensitive information by entities that have been issued certificates by DoD-approved PKIs, all DoD systems (e.g., web servers and web portals) must be properly configured to incorporate access control methods that do not rely solely on the possession of a certificate for access. Successful authentication must not automatically give an entity access to an asset or security boundary. Authorization procedures and controls must be implemented to ensure each authenticated entity also has a validated and current authorization. Authorization is the process of determining whether an entity, once authenticated, is permitted to access a specific asset. Information systems use access control policies and enforcement mechanisms to implement this requirement. Access control policies include identity-based policies, role-based policies, and attribute-based policies. Access enforcement mechanisms include access control lists, access control matrices, and cryptography. These policies and mechanisms must be employed by the application to control access between users (or processes acting on behalf of users) and objects (e.g., devices, files, records, processes, programs, and domains) in the information system.
Checks: C-43641r670963_chk

To verify a boot password exists, in /boot/grub/menu.lst run the following command: # grep password /boot/grub/menu.lst The output should show the following: password --encrypted $1$[rest-of-the-password-hash] If it does not, this is a finding.

Fix: F-43600r670964_fix

Run the following command: # /usr/sbin/grub-md5-crypt An MD5 password is generated. After the password is supplied, the command supplies the md5 hash output. Append the password to the "menu.lst" file by running the following command: echo 'password --md5 <hash from grub-md5-crypt>' >> /boot/grub/menu.lst Or use yast2 to set the bootloader password. Open the Boot Loader Installation tab. Click "Boot Loader Options". Activate the Protect Boot Loader with Password option with a click and type in the password twice. Click "OK" twice to save the changes.

b
The system boot loader configuration file(s) must have mode 0600 or less permissive.
AC-3 - Medium - CCI-000213 - V-240409 - SV-240409r670968_rule
RMF Control
AC-3
Severity
Medium
CCI
CCI-000213
Version
VRAU-SL-000430
Vuln IDs
  • V-240409
  • V-89595
Rule IDs
  • SV-240409r670968_rule
  • SV-100245
File permissions more permissive than 0600 on boot loader configuration files could allow an unauthorized user to view or modify sensitive information pertaining to system boot instructions.
Checks: C-43642r670966_chk

Check the /boot/grub/menu.lst file: # stat /boot/grub/menu.lst If /boot/grub/menu.lst has a mode more permissive than "0600", this is a finding.

Fix: F-43601r670967_fix

Change the mode of the menu.lst file to "0600": # chmod 0600 /boot/grub/menu.lst

b
The system boot loader configuration files must be owned by root.
AC-3 - Medium - CCI-000213 - V-240410 - SV-240410r670971_rule
RMF Control
AC-3
Severity
Medium
CCI
CCI-000213
Version
VRAU-SL-000435
Vuln IDs
  • V-240410
  • V-89597
Rule IDs
  • SV-240410r670971_rule
  • SV-100247
The system's boot loader configuration files are critical to the integrity of the system and must be protected. Unauthorized modification of these files resulting from improper ownership could compromise the system's boot loader configuration.
Checks: C-43643r670969_chk

Check /boot/grub/menu.lst ownership: # stat /boot/grub/menu.lst If the owner of the file is not "root", this is a finding.

Fix: F-43602r670970_fix

Change the ownership of the file: # chown root /boot/grub/menu.lst

b
The system boot loader configuration file(s) must be group-owned by root, bin, sys, or system.
AC-3 - Medium - CCI-000213 - V-240411 - SV-240411r670974_rule
RMF Control
AC-3
Severity
Medium
CCI
CCI-000213
Version
VRAU-SL-000440
Vuln IDs
  • V-240411
  • V-89599
Rule IDs
  • SV-240411r670974_rule
  • SV-100249
The system's boot loader configuration files are critical to the integrity of the system and must be protected. Unauthorized modifications resulting from improper group-ownership may compromise the boot loader configuration.
Checks: C-43644r670972_chk

Check /boot/grub/menu.lst ownership: # stat /boot/grub/menu.lst If the group-owner of the file is not "root", "bin", "sys", or "system", this is a finding.

Fix: F-43603r670973_fix

Change the group-ownership of the file: # chgrp root /boot/grub/menu.lst

b
The Bluetooth protocol handler must be disabled or not installed.
CM-7 - Medium - CCI-000381 - V-240412 - SV-240412r670977_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000381
Version
VRAU-SL-000445
Vuln IDs
  • V-240412
  • V-89601
Rule IDs
  • SV-240412r670977_rule
  • SV-100251
Bluetooth is a personal area network (PAN) technology. Binding this protocol to the network stack increases the attack surface of the host. Unprivileged local processes may be able to cause the kernel to dynamically load a protocol handler by opening a socket using the protocol.
Checks: C-43645r670975_chk

Verify the Bluetooth protocol handler is prevented from dynamic loading: # grep "install bluetooth /bin/true" /etc/modprobe.conf /etc/modprobe.conf.local /etc/modprobe.d/* If no result is returned, this is a finding.

Fix: F-43604r670976_fix

Prevent the Bluetooth protocol handler for dynamic loading: # echo "install bluetooth /bin/true" >> /etc/modprobe.conf.local

b
The system must have USB Mass Storage disabled unless needed.
CM-7 - Medium - CCI-000381 - V-240413 - SV-240413r670980_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000381
Version
VRAU-SL-000450
Vuln IDs
  • V-240413
  • V-89603
Rule IDs
  • SV-240413r670980_rule
  • SV-100253
USB is a common computer peripheral interface. USB devices may include storage devices that could be used to install malicious software on a system or exfiltrate data.
Checks: C-43646r670978_chk

If the system needs USB storage, this vulnerability is not applicable. Check if "usb-storage" is prevented from loading: # grep "install usb-storage /bin/true" /etc/modprobe.conf /etc/modprobe.conf.local /etc/modprobe.d/* If no results are returned, this is a finding.

Fix: F-43605r670979_fix

Prevent the "usb-storage" module from loading: # echo "install usb-storage /bin/true" >> /etc/modprobe.conf.local

b
The system must have USB disabled unless needed.
CM-7 - Medium - CCI-000381 - V-240414 - SV-240414r670983_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000381
Version
VRAU-SL-000455
Vuln IDs
  • V-240414
  • V-89605
Rule IDs
  • SV-240414r670983_rule
  • SV-100255
USB is a common computer peripheral interface. USB devices may include storage devices that could be used to install malicious software on a system or exfiltrate data.
Checks: C-43647r670981_chk

If the system needs USB, this vulnerability is not applicable. Check if the directory /proc/bus/usb exists. If the directory /proc/bus/usb exists, this is a finding.

Fix: F-43606r670982_fix

Edit the grub bootloader file /boot/grub/menu.lst by appending the "nousb" parameter to the kernel boot line.

b
The telnet-server package must not be installed.
CM-7 - Medium - CCI-000381 - V-240415 - SV-240415r670986_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000381
Version
VRAU-SL-000460
Vuln IDs
  • V-240415
  • V-89607
Rule IDs
  • SV-240415r670986_rule
  • SV-100257
Removing the "telnet-server" package decreases the risk of the unencrypted telnet service's accidental (or intentional) activation.
Checks: C-43648r670984_chk

Check if "telnet-server" is installed: # rpm -q telnet-server If there is a "telnet-server" package listed, this is a finding.

Fix: F-43607r670985_fix

To remove the "telnet-server" package use the following command: rpm -e telnet-server

b
The rsh-server package must not be installed.
CM-7 - Medium - CCI-000381 - V-240416 - SV-240416r670989_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000381
Version
VRAU-SL-000465
Vuln IDs
  • V-240416
  • V-89609
Rule IDs
  • SV-240416r670989_rule
  • SV-100259
The "rsh-server" package provides several obsolete and insecure network services. Removing it decreases the risk of accidental (or intentional) activation of those services.
Checks: C-43649r670987_chk

Check if "rsh-server" is installed: # rpm -q rsh-server If an "rsh-server" package is listed, this is a finding.

Fix: F-43608r670988_fix

To remove the "telnet-server" package, use the following command: rpm -e rsh-server

b
The ypserv package must not be installed.
CM-7 - Medium - CCI-000381 - V-240417 - SV-240417r670992_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000381
Version
VRAU-SL-000470
Vuln IDs
  • V-240417
  • V-89611
Rule IDs
  • SV-240417r670992_rule
  • SV-100261
Removing the "ypserv" package decreases the risk of the accidental (or intentional) activation of NIS or NIS+ services.
Checks: C-43650r670990_chk

Check if "ypserv" is installed: # rpm -q ypserv If there is a "ypserv" package listed, this is a finding.

Fix: F-43609r670991_fix

To remove the "telnet-server" package use the following command: rpm -e ypserv

b
The yast2-tftp-server package must not be installed.
CM-7 - Medium - CCI-000381 - V-240418 - SV-240418r670995_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000381
Version
VRAU-SL-000475
Vuln IDs
  • V-240418
  • V-89613
Rule IDs
  • SV-240418r670995_rule
  • SV-100263
Removing the "yast2-tftp-server" package decreases the risk of the accidental (or intentional) activation of tftp services.
Checks: C-43651r670993_chk

Check if "yast2-tftp-server" is installed: # rpm -q yast2-tftp-server If a "yast2-tftp-server" package is listed, this is a finding.

Fix: F-43610r670994_fix

To remove the "yast2-tftp-server" package, use the following command: rpm -e yast2-tftp-server

b
The tftp package must not be installed.
CM-7 - Medium - CCI-000381 - V-240419 - SV-240419r670998_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000381
Version
VRAU-SL-000490
Vuln IDs
  • V-240419
  • V-89615
Rule IDs
  • SV-240419r670998_rule
  • SV-100265
The Trivial File Transfer Protocol (TFTP) is normally used only for booting diskless workstations and for getting or saving network component configuration files. Disabling the "tftp" protocol service ensures the system is not acting over tftp, which does not provide encryption or authentication.
Checks: C-43652r670996_chk

Check if "tftp" is installed: # rpm -q tftp If there is a "tftp" package listed, this is a finding.

Fix: F-43611r670997_fix

To remove the "tftp" package use the following command: rpm -e tftp

b
The Datagram Congestion Control Protocol (DCCP) must be disabled unless required.
CM-7 - Medium - CCI-000382 - V-240420 - SV-240420r671001_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000382
Version
VRAU-SL-000495
Vuln IDs
  • V-240420
  • V-89617
Rule IDs
  • SV-240420r671001_rule
  • SV-100267
The DCCP is a proposed transport layer protocol. This protocol is not yet widely used. Binding this protocol to the network stack increases the attack surface of the host. Unprivileged local processes may be able to cause the kernel to dynamically load a protocol handler by opening a socket using the protocol.
Checks: C-43653r670999_chk

Check that the DCCP protocol handler is prevented from dynamic loading: # grep "install dccp /bin/true" /etc/modprobe.conf /etc/modprobe.conf.local /etc/modprobe.d/* If no result is returned, this is a finding. # grep "install dccp_ipv4 /bin/true" /etc/modprobe.conf /etc/modprobe.conf.local /etc/modprobe.d/* If no result is returned, this is a finding. # grep "install dccp_ipv6" /etc/modprobe.conf /etc/modprobe.conf.local /etc/modprobe.d/* | grep ‘bin/true’ If no result is returned, this is a finding.

Fix: F-43612r671000_fix

Prevent the DCCP protocol handler for dynamic loading: # echo "install dccp /bin/true" >> /etc/modprobe.conf.local # echo "install dccp_ipv4 /bin/true" >> /etc/modprobe.conf.local # echo "install dccp_ipv6 /bin/true" >> /etc/modprobe.conf.local

b
The Stream Control Transmission Protocol (SCTP) must be disabled unless required.
CM-7 - Medium - CCI-000382 - V-240421 - SV-240421r671004_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000382
Version
VRAU-SL-000500
Vuln IDs
  • V-240421
  • V-89619
Rule IDs
  • SV-240421r671004_rule
  • SV-100269
The SCTP is an IETF-standardized transport layer protocol. This protocol is not yet widely used. Binding this protocol to the network stack increases the attack surface of the host. Unprivileged local processes may be able to cause the kernel to dynamically load a protocol handler by opening a socket using the protocol.
Checks: C-43654r671002_chk

Verify the SCTP protocol handler is prevented from dynamic loading: # grep "install sctp /bin/true" /etc/modprobe.conf /etc/modprobe.conf.local /etc/modprobe.d/* If no result is returned, this is a finding.

Fix: F-43613r671003_fix

Prevent the SCTP protocol handler for dynamic loading: # echo "install sctp /bin/true" >> /etc/modprobe.conf.local

b
The Reliable Datagram Sockets (RDS) protocol must be disabled or not installed unless required.
CM-7 - Medium - CCI-000382 - V-240422 - SV-240422r671007_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000382
Version
VRAU-SL-000505
Vuln IDs
  • V-240422
  • V-89621
Rule IDs
  • SV-240422r671007_rule
  • SV-100271
The RDS protocol is a relatively new protocol developed by Oracle for communication between the nodes of a cluster. Binding this protocol to the network stack increases the attack surface of the host. Unprivileged local processes may be able to cause the system to dynamically load a protocol handler by opening a socket using the protocol.
Checks: C-43655r671005_chk

Ask the SA if RDS is required by application software running on the system. If so, this is not applicable. Check that the RDS protocol handler is prevented from dynamic loading: # grep "install rds /bin/true" /etc/modprobe.conf /etc/modprobe.conf.local /etc/modprobe.d/* If no result is returned, this is a finding.

Fix: F-43614r671006_fix

Prevent the use of RDS protocol handler for dynamic loading: # echo "install rds /bin/true" >> /etc/modprobe.conf.local

b
The Transparent Inter-Process Communication (TIPC) must be disabled or not installed.
CM-7 - Medium - CCI-000382 - V-240423 - SV-240423r671010_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000382
Version
VRAU-SL-000510
Vuln IDs
  • V-240423
  • V-89623
Rule IDs
  • SV-240423r671010_rule
  • SV-100273
The Transparent Inter-Process Communication (TIPC) protocol is a relatively new cluster communications protocol developed by Ericsson. Binding this protocol to the network stack increases the attack surface of the host. Unprivileged local processes may be able to cause the kernel to dynamically load a protocol handler by opening a socket using the protocol.
Checks: C-43656r671008_chk

Verify the TIPC protocol handler is prevented from dynamic loading: # grep "install tipc /bin/true" /etc/modprobe.conf /etc/modprobe.conf.local /etc/modprobe.d/* If no result is returned, this is a finding.

Fix: F-43615r671009_fix

Prevent the TIPC protocol handler for dynamic loading: # echo "install tipc /bin/true" >> /etc/modprobe.conf.local

b
The xinetd service must be disabled if no network services using it are enabled.
CM-7 - Medium - CCI-000382 - V-240424 - SV-240424r671013_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000382
Version
VRAU-SL-000515
Vuln IDs
  • V-240424
  • V-89625
Rule IDs
  • SV-240424r671013_rule
  • SV-100275
The "xinetd" service provides a dedicated listener service for some programs, which is no longer necessary for commonly used network services. Disabling it ensures that these uncommon services are not running and also prevents attacks against "xinetd" itself.
Checks: C-43657r671011_chk

If network services are using the "xinetd" service, this is not applicable. To check that the "xinetd" service is disabled in system boot configuration, run the following command: # chkconfig "xinetd" --list Output should indicate the "xinetd" service has either not been installed or has been disabled at all run levels as shown in the example below: xinetd 0:off 1:off 2:off 3:off 4:off 5:off 6:off Run the following command to verify "xinetd" is disabled through current runtime configuration: # service xinetd status If the service is disabled, the command will return the following output: Checking for service xinetd: unused If the service is running, this is a finding.

Fix: F-43616r671012_fix

The "xinetd" service can be disabled with the following command: # chkconfig xinetd off

b
The xinetd.conf file, and the xinetd.d directory must be owned by root or bin.
CM-7 - Medium - CCI-000382 - V-240425 - SV-240425r671016_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000382
Version
VRAU-SL-000520
Vuln IDs
  • V-240425
  • V-89627
Rule IDs
  • SV-240425r671016_rule
  • SV-100277
Failure to give ownership of sensitive files or utilities to root provides the designated owner and unauthorized users with the potential to access sensitive information or change the system configuration, which could weaken the system's security posture.
Checks: C-43658r671014_chk

Check the owner of the "xinetd" configuration files: # ls -lL /etc/xinetd.conf # ls -laL /etc/xinetd.d This is a finding if any of the above files or directories are not owned by "root" or "bin".

Fix: F-43617r671015_fix

Change the owner of the "xinetd" configuration files: # chown root /etc/xinetd.conf /etc/xinetd.d/*

b
The inetd.conf file, xinetd.conf file, and xinetd.d directory must be group owned by root, bin, sys, or system.
CM-7 - Medium - CCI-000382 - V-240426 - SV-240426r671019_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000382
Version
VRAU-SL-000525
Vuln IDs
  • V-240426
  • V-89629
Rule IDs
  • SV-240426r671019_rule
  • SV-100279
Failure to give ownership of sensitive files or utilities to root provides the designated owner and unauthorized users with the potential to access sensitive information or change the system configuration, which could weaken the system's security posture.
Checks: C-43659r671017_chk

Check the group-ownership of the "xinetd" configuration files and directories: # ls -alL /etc/xinetd.conf /etc/xinetd.d If a file or directory is not group-owned by "root", "bin", "sys", or "system", this is a finding.

Fix: F-43618r671018_fix

Change the group-owner of the "xinetd" configuration files and directories: # chgrp -R root /etc/xinetd.conf /etc/xinetd.d

b
The xinetd.d directory must have mode 0755 or less permissive.
CM-7 - Medium - CCI-000382 - V-240427 - SV-240427r671022_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000382
Version
VRAU-SL-000530
Vuln IDs
  • V-240427
  • V-89631
Rule IDs
  • SV-240427r671022_rule
  • SV-100281
The Internet service daemon configuration files must be protected as malicious modification could cause denial of service or increase the attack surface of the system.
Checks: C-43660r671020_chk

Check the permissions of the "xinetd" configuration directories: # ls -dlL /etc/xinetd.d If the mode of the directory is more permissive than "0755", this is a finding.

Fix: F-43619r671021_fix

Change the mode of the directory: # chmod 0755 /etc/xinetd.d

b
Xinetd logging/tracing must be enabled.
CM-7 - Medium - CCI-000382 - V-240428 - SV-240428r671025_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000382
Version
VRAU-SL-000535
Vuln IDs
  • V-240428
  • V-89633
Rule IDs
  • SV-240428r671025_rule
  • SV-100283
Xinetd logging and tracing allows the system administrators to observe the IP addresses that are connecting to their machines and to observe what network services are being sought. This provides valuable information when trying to find the source of malicious users and potential malicious users.
Checks: C-43661r671023_chk

Examine the /etc/xinetd.conf file and each file in the /etc/xinetd.d directory file for the following: log_type = SYSLOG authpriv log_on_success = HOST PID USERID EXIT log_on_failure = HOST USERID If "xinetd" running and logging is not enabled, this is a finding.

Fix: F-43620r671024_fix

Edit each file in the /etc/xinetd.d directory and the /etc/xinetd.conf file to contain: log_type = SYSLOG authpriv log_on_success = HOST PID USERID EXIT log_on_failure = HOST USERID The /etc/xinetd.conf file contains default values that will hold true for all services unless individually modified in the service's "xinetd.d" file.

b
The ypbind service must not be running if no network services utilizing it are enabled.
CM-7 - Medium - CCI-000382 - V-240429 - SV-240429r671028_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000382
Version
VRAU-SL-000540
Vuln IDs
  • V-240429
  • V-89635
Rule IDs
  • SV-240429r671028_rule
  • SV-100285
Disabling the "ypbind" service ensures the system is not acting as a client in a NIS or NIS+ domain when not required.
Checks: C-43662r671026_chk

If network services are using the "ypbind" service, this is not applicable. To check that the "ypbind" service is disabled in system boot configuration, run the following command: # chkconfig "ypbind" --list Output should indicate the "ypbind" service has either not been installed, or has been disabled at all run levels, as shown in the example below: ypbind 0:off 1:off 2:off 3:off 4:off 5:off 6:off Run the following command to verify "ypbind" is disabled through current runtime configuration: # service ypbind status If the service is disabled the command will return the following output: Checking for service ypbind unused If the service is running, this is a finding.

Fix: F-43621r671027_fix

The "ypbind" service can be disabled with the following command: # chkconfig ypbind off

b
The system must not use UDP for NIS/NIS+.
CM-7 - Medium - CCI-000382 - V-240430 - SV-240430r671031_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000382
Version
VRAU-SL-000545
Vuln IDs
  • V-240430
  • V-89637
Rule IDs
  • SV-240430r671031_rule
  • SV-100287
Implementing NIS or NIS+ under UDP may make the system more susceptible to a denial-of-service attack and does not provide the same quality of service as TCP.
Checks: C-43663r671029_chk

If the SLES for vRealize does not use NIS or NIS+, this is not applicable. Check if NIS or NIS+ is implemented using UDP: # rpcinfo -p | grep yp | grep udp If NIS or NIS+ is implemented using UDP, this is a finding.

Fix: F-43622r671030_fix

Configure the SLES for vRealize to not use UDP for NIS and NIS+. Consult vendor documentation for the required procedure.

b
NIS maps must be protected through hard-to-guess domain names.
CM-7 - Medium - CCI-000382 - V-240431 - SV-240431r671034_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000382
Version
VRAU-SL-000550
Vuln IDs
  • V-240431
  • V-89639
Rule IDs
  • SV-240431r671034_rule
  • SV-100289
The use of hard-to-guess NIS domain names provides additional protection from unauthorized access to the NIS directory information.
Checks: C-43664r671032_chk

If the SLES for vRealize does not use NIS or NIS+, this is not applicable. Check the domain name for NIS maps: # domainname If the name returned is simple to guess, such as the organization name, building or room name, etc., this is a finding.

Fix: F-43623r671033_fix

Change the NIS domain name to a value difficult to guess. Consult vendor documentation for the required procedure.

b
Mail relaying must be restricted.
CM-7 - Medium - CCI-000382 - V-240432 - SV-240432r671037_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000382
Version
VRAU-SL-000555
Vuln IDs
  • V-240432
  • V-89641
Rule IDs
  • SV-240432r671037_rule
  • SV-100291
If unrestricted mail relaying is permitted, unauthorized senders could use this host as a mail relay for the purpose of sending spam or other unauthorized activity.
Checks: C-43665r671035_chk

Determine if Sendmail only binds to loopback addresses by examining the "DaemonPortOptions" configuration options. # grep -i "O DaemonPortOptions" /etc/sendmail.cf If there are uncommented DaemonPortOptions lines, and all such lines specify system loopback addresses, this is not a finding. Otherwise, determine if Sendmail is configured to allow open relay operation. # grep -i promiscuous_relay /etc/mail/sendmail.mc If the promiscuous relay feature is enabled, this is a finding.

Fix: F-43624r671036_fix

If the SLES for vRealize does not need to receive mail from external hosts, add one or more "DaemonPortOptions" lines referencing system loopback addresses (such as "O DaemonPortOptions=Addr=127.0.0.1,Port=smtp,Name=MTA") and remove lines containing non-loopback addresses. # sed -i "s/O DaemonPortOptions=Name=MTA/O DaemonPortOptions=Addr=127.0.0.1,Port=smtp,Name=MTA/" /etc/sendmail.cf Restart the sendmail service: # service sendmail restart

b
The alias files must be owned by root.
CM-7 - Medium - CCI-000382 - V-240433 - SV-240433r671040_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000382
Version
VRAU-SL-000560
Vuln IDs
  • V-240433
  • V-89643
Rule IDs
  • SV-240433r671040_rule
  • SV-100293
If the alias and aliases.db files are not owned by root, an unauthorized user may modify the file to add aliases to run malicious code or redirect email.
Checks: C-43666r671038_chk

Check the ownership of the alias file: # ls -lL /etc/aliases # ls -lL /etc/aliases.db If all the files are not owned by "root", this is a finding.

Fix: F-43625r671039_fix

Change the owner of the alias files to "root": # chown root /etc/aliases # chown root /etc/aliases.db

b
The alias files must be group-owned by root or a system group.
CM-7 - Medium - CCI-000382 - V-240434 - SV-240434r671043_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000382
Version
VRAU-SL-000565
Vuln IDs
  • V-240434
  • V-89645
Rule IDs
  • SV-240434r671043_rule
  • SV-100295
If the aliases and aliases.db file are not group owned by root or a system group, an unauthorized user may modify one or both of the files to add aliases to run malicious code or redirect email.
Checks: C-43667r671041_chk

Check the group-ownership of the alias files: # ls -lL /etc/aliases # ls -lL /etc/aliases.db If the files are not group-owned by "root", this is a finding.

Fix: F-43626r671042_fix

Change the group-owner of the alias files to "root": # chgrp root /etc/aliases # chgrp root /etc/aliases.db

b
The alias files must have mode 0644 or less permissive.
CM-7 - Medium - CCI-000382 - V-240435 - SV-240435r671046_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000382
Version
VRAU-SL-000570
Vuln IDs
  • V-240435
  • V-89647
Rule IDs
  • SV-240435r671046_rule
  • SV-100297
Excessive permissions on the alias files may permit unauthorized modification. If an alias file is modified by an unauthorized user, they may modify the file to run malicious code or redirect email.
Checks: C-43668r671044_chk

Check the permissions of the alias files: # ls -lL /etc/aliases # ls -lL /etc/aliases.db If the files have a mode more permissive than "0644", this is a finding.

Fix: F-43627r671045_fix

Change the mode of the alias files to "0644": # chmod 0644 /etc/aliases /etc/aliases.db

b
Files executed through a mail aliases file must be owned by root and must reside within a directory owned and writable only by root.
CM-7 - Medium - CCI-000382 - V-240436 - SV-240436r671049_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000382
Version
VRAU-SL-000575
Vuln IDs
  • V-240436
  • V-89649
Rule IDs
  • SV-240436r671049_rule
  • SV-100299
If a file executed through a mail aliases file is not owned and writable only by root, it may be subject to unauthorized modification. Unauthorized modification of files executed through aliases may allow unauthorized users to attain root privileges.
Checks: C-43669r671047_chk

Verify the ownership of files referenced within the sendmail aliases file: # more /etc/aliases Examine the aliases file for any directories or paths used: # ls -lL &lt;directory or file path&gt; Check the owner for any paths referenced. If the file or parent directory is not owned by "root", this is a finding.

Fix: F-43628r671048_fix

Edit the /etc/aliases file (alternatively, /usr/lib/sendmail.cf). Locate the entries executing a program. They will appear similar to the following line: Aliasname: : /usr/local/bin/ls (or some other program name) Ensure "root" owns the programs and the directory or directories they reside in by using the "chown" command to change owner to "root": # chown root <file or directory name>

b
Files executed through a mail aliases file must be group-owned by root, bin, sys, or system, and must reside within a directory group-owned by root, bin, sys, or system.
CM-7 - Medium - CCI-000382 - V-240437 - SV-240437r671052_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000382
Version
VRAU-SL-000580
Vuln IDs
  • V-240437
  • V-89651
Rule IDs
  • SV-240437r671052_rule
  • SV-100301
If a file executed through a mail aliases file is not group-owned by root or a system group, it may be subject to unauthorized modification. Unauthorized modification of files executed through aliases may allow unauthorized users to attain root privileges.
Checks: C-43670r671050_chk

Examine the contents of the /etc/aliases file: # more /etc/aliases Examine the aliases file for any directories or paths that may be utilized: # ls -lL &lt;file referenced from aliases&gt; Check the permissions for any paths referenced. If the group-owner of any file is not "root", "bin", "sys", or "system", this is a finding.

Fix: F-43629r671051_fix

Change the group-ownership of the file referenced from /etc/mail/aliases: # chgrp root <file referenced from aliases>

b
Files executed through a mail aliases file must have mode 0755 or less permissive.
CM-7 - Medium - CCI-000382 - V-240438 - SV-240438r671055_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000382
Version
VRAU-SL-000585
Vuln IDs
  • V-240438
  • V-89653
Rule IDs
  • SV-240438r671055_rule
  • SV-100303
If a file executed through a mail alias file has permissions greater than 0755, it can be modified by an unauthorized user and may contain malicious code or instructions that could compromise the system.
Checks: C-43671r671053_chk

Examine the contents of the /etc/aliases file: # more /etc/aliases Examine the aliases file for any directories or paths that may be used: # ls -lL &lt;file referenced from aliases&gt; Check the permissions for any paths referenced. If any file referenced from the aliases file has a mode more permissive than "0755", this is a finding.

Fix: F-43630r671054_fix

Use the "chmod" command to change the access permissions for files executed from the alias file: # chmod 0755 <file referenced from aliases>

b
Sendmail logging must not be set to less than nine in the sendmail.cf file.
CM-7 - Medium - CCI-000382 - V-240439 - SV-240439r671058_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000382
Version
VRAU-SL-000590
Vuln IDs
  • V-240439
  • V-89655
Rule IDs
  • SV-240439r671058_rule
  • SV-100305
If Sendmail is not configured to log at level 9, system logs may not contain the information necessary for tracking unauthorized use of the sendmail service.
Checks: C-43672r671056_chk

Check sendmail to determine if the logging level is set to level nine: # grep "O L" /etc/sendmail.cf OR # grep LogLevel /etc/sendmail.cf If logging is set to less than nine, this is a finding.

Fix: F-43631r671057_fix

Edit the sendmail.cf file, locate the "O L" or "LogLevel" entry and change it to "9".

b
The system syslog service must log informational and more severe SMTP service messages.
CM-7 - Medium - CCI-000382 - V-240440 - SV-240440r671061_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000382
Version
VRAU-SL-000595
Vuln IDs
  • V-240440
  • V-89657
Rule IDs
  • SV-240440r671061_rule
  • SV-100307
If informational and more severe SMTP service messages are not logged, malicious activity on the system may go unnoticed.
Checks: C-43673r671059_chk

Check the /etc/syslog-ng/syslog-ng.conf for the following log entries: filter f_mailinfo { level(info) and facility(mail); }; filter f_mailwarn { level(warn) and facility(mail); }; filter f_mailerr { level(err, crit) and facility(mail); }; filter f_mail { facility(mail); }; If present, this is not a finding.

Fix: F-43632r671060_fix

Edit the /etc/syslog-ng/syslog-ng.conf file and add the following log entries: filter f_mailinfo { level(info) and facility(mail); }; filter f_mailwarn { level(warn) and facility(mail); }; filter f_mailerr { level(err, crit) and facility(mail); }; filter f_mail { facility(mail); }; destination mailinfo { file("/var/log/mail.info"); }; log { source(src); filter(f_mailinfo); destination(mailinfo); }; destination mailwarn { file("/var/log/mail.warn"); }; log { source(src); filter(f_mailwarn); destination(mailwarn); }; destination mailerr { file("/var/log/mail.err" fsync(yes)); }; log { source(src); filter(f_mailerr); destination(mailerr); };

b
The SMTP service log files must be owned by root.
CM-7 - Medium - CCI-000382 - V-240441 - SV-240441r671064_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000382
Version
VRAU-SL-000600
Vuln IDs
  • V-240441
  • V-89659
Rule IDs
  • SV-240441r671064_rule
  • SV-100309
If the SMTP service log file is not owned by root, then unauthorized personnel may modify or delete the file to hide a system compromise.
Checks: C-43674r671062_chk

Check the permissions on the mail log files: # ls -la /var/log/mail # ls -la /var/log/mail.info # ls -la /var/log/mail.warn # ls -la /var/log/mail.err If any mail log file is not owned by "root", this is a finding.

Fix: F-43633r671063_fix

Change the ownership of the sendmail log files: # chown root <sendmail log file>

b
The SMTP service log file must have mode 0644 or less permissive.
CM-7 - Medium - CCI-000382 - V-240442 - SV-240442r671067_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000382
Version
VRAU-SL-000605
Vuln IDs
  • V-240442
  • V-89661
Rule IDs
  • SV-240442r671067_rule
  • SV-100311
If the SMTP service log file is more permissive than 0644, unauthorized users may be allowed to change the log file.
Checks: C-43675r671065_chk

Check the permissions on the mail log files: # ls -la /var/log/mail # ls -la /var/log/mail.info # ls -la /var/log/mail.warn # ls -la /var/log/mail.err If the log file permissions are greater than "0644", this is a finding.

Fix: F-43634r671066_fix

Change the mode of the sendmail log files: # chmod 0644 <sendmail log file>

b
The SMTP service HELP command must not be enabled.
CM-7 - Medium - CCI-000382 - V-240443 - SV-240443r671070_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000382
Version
VRAU-SL-000610
Vuln IDs
  • V-240443
  • V-89663
Rule IDs
  • SV-240443r671070_rule
  • SV-100313
The HELP command should be disabled to mask version information. The version of the SMTP service software could be used by attackers to target vulnerabilities present in specific software versions.
Checks: C-43676r671068_chk

Check the permissions of the sendmail helpfile: ls -al /usr/lib/sendmail.d/helpfile If the permissions are not "0000", this is a finding.

Fix: F-43635r671069_fix

Run the following command to disable the sendmail helpfile: # chmod 0000 /usr/lib/sendmail.d/helpfile

b
The SMTP service SMTP greeting must not provide version information.
CM-7 - Medium - CCI-000382 - V-240444 - SV-240444r671073_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000382
Version
VRAU-SL-000615
Vuln IDs
  • V-240444
  • V-89665
Rule IDs
  • SV-240444r671073_rule
  • SV-100315
The version of the SMTP service can be used by attackers to plan an attack based on vulnerabilities present in the specific version.
Checks: C-43677r671071_chk

To check for the sendmail version being displayed in the greeting: # more /etc/sendmail.cf | grep SmtpGreetingMessage If it returns the following: O SmtpGreetingMessage=$j Sendmail $v/$Z; $b Then sendmail is providing version information, and this is a finding.

Fix: F-43636r671072_fix

Change the "O SmtpGreetingMessage" line in the /etc/sendmail.cf file to: O SmtpGreetingMessage= Mail Server Ready ; $b

b
The SMTP service must not use .forward files.
CM-7 - Medium - CCI-000382 - V-240445 - SV-240445r671076_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000382
Version
VRAU-SL-000620
Vuln IDs
  • V-240445
  • V-89667
Rule IDs
  • SV-240445r671076_rule
  • SV-100317
The .forward file allows users to automatically forward mail to another system. Use of .forward files could allow the unauthorized forwarding of mail and could potentially create mail loops, which could degrade system performance.
Checks: C-43678r671074_chk

Check if forwarding from sendmail: # grep "0 ForwardPath" /etc/sendmail.cf If the entry contains a file path and is not commented out, this is a finding.

Fix: F-43637r671075_fix

Disable forwarding for sendmail and remove ".forward" files from the system: Remove all .forward files on the system: # find / -name .forward -delete Use the following command to disable forwarding: # sed -i "s/O ForwardPath/#O ForwardPath/" /etc/sendmail.cf Restart the sendmail service: # service sendmail restart

b
The SMTP service must not have the EXPN feature active.
CM-7 - Medium - CCI-000382 - V-240446 - SV-240446r671079_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000382
Version
VRAU-SL-000625
Vuln IDs
  • V-240446
  • V-89669
Rule IDs
  • SV-240446r671079_rule
  • SV-100319
The SMTP EXPN function allows an attacker to determine if an account exists on a system, providing significant assistance to a brute force attack on user accounts. EXPN may also provide additional information concerning users on the system, such as the full names of account owners.
Checks: C-43679r671077_chk

Use the following command to check if EXPN is disabled: # grep -v "^#" /etc/sendmail.cf |grep -i PrivacyOptions If "noexpn" is not returned, this is a finding.

Fix: F-43638r671078_fix

Add "noexpn" to the "PrivacyOptions" flag in /etc/sendmail.cf

b
The SMTP service must not have the VRFY feature active.
CM-7 - Medium - CCI-000382 - V-240447 - SV-240447r671082_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000382
Version
VRAU-SL-000630
Vuln IDs
  • V-240447
  • V-89671
Rule IDs
  • SV-240447r671082_rule
  • SV-100321
The VRFY (Verify) command allows an attacker to determine if an account exists on a system, providing significant assistance to a brute force attack on user accounts. VRFY may provide additional information about users on the system, such as the full names of account owners.
Checks: C-43680r671080_chk

Use the following command to check if VRFY is disabled: # grep -v "^#" /etc/sendmail.cf |grep -i PrivacyOptions If "novrfy" is not returned, this is a finding.

Fix: F-43639r671081_fix

Add "novrfy" to the "PrivacyOptions" flag in /etc/sendmail.cf

b
The Lightweight User Datagram Protocol (UDP-Lite) must be disabled unless required.
CM-7 - Medium - CCI-000382 - V-240448 - SV-240448r671085_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000382
Version
VRAU-SL-000635
Vuln IDs
  • V-240448
  • V-89673
Rule IDs
  • SV-240448r671085_rule
  • SV-100323
The Lightweight User Datagram Protocol (UDP-Lite) is a proposed transport layer protocol. This protocol is not yet widely used. Binding this protocol to the network stack increases the attack surface of the host. Unprivileged local processes may be able to cause the system to dynamically load a protocol handler by opening a socket using the protocol.
Checks: C-43681r671083_chk

Run the following command: iptables --list | grep "udplite" If no result is displayed, this is a finding.

Fix: F-43640r671084_fix

Configure the system to prevent the dynamic loading of the UDP-Lite protocol handler: Add the following rule to the iptables firewall ruleset: # iptables -A INPUT -p udplite -j DROP

b
The Internetwork Packet Exchange (IPX) protocol must be disabled or not installed.
CM-7 - Medium - CCI-000382 - V-240449 - SV-240449r671088_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000382
Version
VRAU-SL-000640
Vuln IDs
  • V-240449
  • V-89675
Rule IDs
  • SV-240449r671088_rule
  • SV-100325
The Internetwork Packet Exchange (IPX) protocol is a network-layer protocol that is no longer in common use. Binding this protocol to the network stack increases the attack surface of the host. Unprivileged local processes may be able to cause the system to dynamically load a protocol handler by opening a socket using the protocol.
Checks: C-43682r671086_chk

Check that the IPX protocol handler is prevented from dynamic loading: # grep "install ipx /bin/true" /etc/modprobe.conf /etc/modprobe.conf.local /etc/modprobe.d/* If no result is returned, this is a finding.

Fix: F-43641r671087_fix

Prevent the IPX protocol handler for dynamic loading: # echo "install ipx /bin/true" >> /etc/modprobe.conf.local

b
The AppleTalk protocol must be disabled or not installed.
CM-7 - Medium - CCI-000382 - V-240450 - SV-240450r671091_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000382
Version
VRAU-SL-000645
Vuln IDs
  • V-240450
  • V-89677
Rule IDs
  • SV-240450r671091_rule
  • SV-100327
The AppleTalk suite of protocols is no longer in common use. Binding this protocol to the network stack increases the attack surface of the host. Unprivileged local processes may be able to cause the system to dynamically load a protocol handler by opening a socket using the protocol.
Checks: C-43683r671089_chk

Verify the AppleTalk protocol handler is prevented from dynamic loading: # grep "install appletalk /bin/true" /etc/modprobe.conf /etc/modprobe.conf.local /etc/modprobe.d/* If no result is returned, this is a finding.

Fix: F-43642r671090_fix

Prevent the AppleTalk protocol handler for dynamic loading: # echo "install appletalk /bin/true" >> /etc/modprobe.conf.local

b
The DECnet protocol must be disabled or not installed.
CM-7 - Medium - CCI-000382 - V-240451 - SV-240451r671094_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000382
Version
VRAU-SL-000650
Vuln IDs
  • V-240451
  • V-89679
Rule IDs
  • SV-240451r671094_rule
  • SV-100329
The DECnet suite of protocols is no longer in common use. Binding this protocol to the network stack increases the attack surface of the host. Unprivileged local processes may be able to cause the system to dynamically load a protocol handler by opening a socket using the protocol.
Checks: C-43684r671092_chk

Check that the DECnet protocol handler is prevented from dynamic loading: # grep "install decnet /bin/true" /etc/modprobe.conf /etc/modprobe.conf.local /etc/modprobe.d/* If no result is returned, this is a finding.

Fix: F-43643r671093_fix

Prevent the DECnet protocol handler for dynamic loading: # echo "install decnet /bin/true" >> /etc/modprobe.conf.local

b
Proxy Neighbor Discovery Protocol (NDP) must not be enabled on the system.
CM-7 - Medium - CCI-000382 - V-240452 - SV-240452r671097_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000382
Version
VRAU-SL-000655
Vuln IDs
  • V-240452
  • V-89681
Rule IDs
  • SV-240452r671097_rule
  • SV-100331
Proxy Neighbor Discovery Protocol (NDP) allows a system to respond to NDP requests on one interface on behalf of hosts connected to another interface. If this function is enabled when not required, addressing information may be leaked between the attached network segments.
Checks: C-43685r671095_chk

Note: For Appliance OS, proxy_ndp is disabled by default and this is not a finding. Determine if the system is configured for proxy NDP, and if it is enabled: more /proc/sys/net/ipv6/conf/*/proxy_ndp If the file is not found, the kernel is not configured for proxy NDP, and this is not a finding. If the file has a value of "0", proxy NDP is not enabled, and this is not a finding. If the file has a value of "1", proxy NDP is enabled, and this is a finding.

Fix: F-43644r671096_fix

Disable proxy NDP on the system.

b
The SLES for vRealize must not have 6to4 enabled.
CM-7 - Medium - CCI-000382 - V-240453 - SV-240453r671100_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000382
Version
VRAU-SL-000660
Vuln IDs
  • V-240453
  • V-89683
Rule IDs
  • SV-240453r671100_rule
  • SV-100333
6to4 is an IPv6 transition mechanism that involves tunneling IPv6 packets encapsulated in IPv4 packets on an ad-hoc basis. This is not a preferred transition strategy and increases the attack surface of the system.
Checks: C-43686r671098_chk

Check the SLES for vRealize for any active "6to4" tunnels without specific remote addresses: # ip tun list | grep "remote any" | grep "ipv6/ip" If any results are returned the "tunnel" is the first field. If any results are returned, this is a finding.

Fix: F-43645r671099_fix

Disable the active 6to4 tunnel: # ip link set <tunnel> down Add this command to a startup script, or remove the configuration creating the tunnel.

b
The SLES for vRealize must not have Teredo enabled.
CM-7 - Medium - CCI-000382 - V-240454 - SV-240454r671103_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000382
Version
VRAU-SL-000665
Vuln IDs
  • V-240454
  • V-89685
Rule IDs
  • SV-240454r671103_rule
  • SV-100335
Teredo is an IPv6 transition mechanism that involves tunneling IPv6 packets encapsulated in IPv4 packets. Unauthorized tunneling may circumvent network security.
Checks: C-43687r671101_chk

Verify the Teredo service is not running: ps ax | grep teredo | grep -v grep If the Teredo process is running, this is a finding.

Fix: F-43646r671102_fix

Kill the Teredo service. Edit startup scripts to prevent the service from running on startup. For Appliance OS, Teredo is not included by default, this is not a finding.

b
The DHCP client must be disabled if not needed.
CM-7 - Medium - CCI-000382 - V-240455 - SV-240455r671106_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000382
Version
VRAU-SL-000670
Vuln IDs
  • V-240455
  • V-89687
Rule IDs
  • SV-240455r671106_rule
  • SV-100337
DHCP allows for the unauthenticated configuration of network parameters on the system by exchanging information with a DHCP server.
Checks: C-43688r671104_chk

Check that no interface is configured to use DHCP: # grep -i bootproto=dhcp4 /etc/sysconfig/network/ifcfg-* If any configuration is found, this is a finding.

Fix: F-43647r671105_fix

Edit the /etc/sysconfig/network/ifcfg-* file(s) and change the "bootproto" setting to "static".

b
The SLES for vRealize must have IEEE 1394 (Firewire) disabled unless needed.
CM-7 - Medium - CCI-000382 - V-240456 - SV-240456r671109_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000382
Version
VRAU-SL-000675
Vuln IDs
  • V-240456
  • V-89689
Rule IDs
  • SV-240456r671109_rule
  • SV-100339
Firewire is a common computer peripheral interface. Firewire devices may include storage devices that could be used to install malicious software on a system or exfiltrate data.
Checks: C-43689r671107_chk

If the SLES for vRealize needs IEEE 1394 (Firewire), this is not applicable. Check if the firewire module is not disabled: # grep "install ieee1394 /bin/true" /etc/modprobe.conf /etc/modprobe.conf.local /etc/modprobe.d/* If no results are returned, this is a finding.

Fix: F-43648r671108_fix

Prevent the SLES for vRealize from loading the firewire module: # echo "install ieee1394 /bin/true" >> /etc/modprobe.conf.local

b
Duplicate User IDs (UIDs) must not exist for users within the organization.
IA-2 - Medium - CCI-000764 - V-240457 - SV-240457r671112_rule
RMF Control
IA-2
Severity
Medium
CCI
CCI-000764
Version
VRAU-SL-000680
Vuln IDs
  • V-240457
  • V-89691
Rule IDs
  • SV-240457r671112_rule
  • SV-100341
To assure accountability and prevent unauthenticated access, organizational users must be identified and authenticated to prevent potential misuse and compromise of the system. Organizational users include organizational employees or individuals the organization deems to have equivalent status of employees (e.g., contractors). Organizational users (and processes acting on behalf of users) must be uniquely identified and authenticated to all accesses, except for the following: 1) Accesses explicitly identified and documented by the organization. Organizations document specific user actions that can be performed on the information system without identification or authentication; and 2) Accesses that occur through authorized use of group authenticators without individual authentication. Organizations may require unique identification of individuals in group accounts (e.g., shared privilege accounts) or for detailed accountability of individual activity.
Checks: C-43690r671110_chk

Verify that the SLES for vRealize contains no duplicate UIDs for organizational users by running the following command: # awk -F ":" 'list[$3]++{print $1, $3}' /etc/passwd If output is produced, this is a finding.

Fix: F-43649r671111_fix

Edit the file /etc/passwd and provide each organizational user account that has a duplicate UID with a unique UID.

c
The SLES for vRealize must prevent direct logon into the root account.
IA-2 - High - CCI-000770 - V-240458 - SV-240458r671115_rule
RMF Control
IA-2
Severity
High
CCI
CCI-000770
Version
VRAU-SL-000705
Vuln IDs
  • V-240458
  • V-89693
Rule IDs
  • SV-240458r671115_rule
  • SV-100343
To assure individual accountability and prevent unauthorized access, organizational users must be individually identified and authenticated. A group authenticator is a generic account used by multiple individuals. Use of a group authenticator alone does not uniquely identify individual users. Examples of the group authenticator is the UNIX OS "root" user account, the Windows "Administrator" account, the "sa" account, or a "helpdesk" account. For example, the UNIX and Windows operating systems offer a 'switch user' capability allowing users to authenticate with their individual credentials and, when needed, 'switch' to the administrator role. This method provides for unique individual authentication prior to using a group authenticator. 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.
Checks: C-43691r671113_chk

Verify the SLES for vRealize prevents direct logons to the "root" account by running the following command: # grep root /etc/shadow | cut -d "":"" -f 2 If the returned message contains any text, this is a finding.

Fix: F-43650r671114_fix

Configure the SLES for vRealize to prevent direct logons to the "root" account by performing the following operations: Add this line to the /etc/group file: admin:x:[UNIQUE_NUMBER]:[USERNAME] USERNAME is the user to be added to the admin group. UNIQUE_NUMBER is a number entered into the ID field of an entry that is unique to all other IDs in the file. Comment out the following lines in /etc/sudoers file: Default targetpw ALL ALL=(ALL) ALL Under the line in the /etc/sudoers file: root ALL=(ALL) All Add the following line: %admin ALL=(ALL) ALL Run the following command: # passwd -d root

b
The SLES for vRealize must enforce SSHv2 for network access to privileged accounts.
IA-2 - Medium - CCI-001941 - V-240459 - SV-240459r852556_rule
RMF Control
IA-2
Severity
Medium
CCI
CCI-001941
Version
VRAU-SL-000710
Vuln IDs
  • V-240459
  • V-89695
Rule IDs
  • SV-240459r852556_rule
  • SV-100345
A replay attack may enable an unauthorized user to gain access to the operating system. Authentication sessions between the authenticator and the operating system validating the user credentials must not be vulnerable to a replay attack. An authentication process resists replay attacks if it is impractical to achieve a successful authentication by recording and replaying a previous authentication message. A privileged account is any information system account with authorizations of a privileged user. Techniques used to address this include protocols using nonces (e.g., numbers generated for a specific one-time use) or challenges (e.g., TLS, WS_Security). Additional techniques include time-synchronous or challenge-response one-time authenticators.
Checks: C-43692r671116_chk

Verify that the SLES for vRealize enforces SSHv2 for network access to privileged accounts by running the following command: Replace [ADDRESS] in the following command with the correct IP address based on the current system configuration. # ssh -1 [ADDRESS] An example of the command usage is as follows: # ssh -1 localhost The output must be the following: Protocol major versions differ: 1 vs. 2 If the output is not as listed above, this is a finding. OR Verify that the ssh is configured to enforce SSHv2 for network access to privileged accounts by running the following command: # grep Protocol /etc/ssh/sshd_config If the result is not "Protocol 2", this is a finding.

Fix: F-43651r671117_fix

Configure the SLES for vRealize to enforce SSHv2 for network access to privileged accounts by running the following commands: # sed -i 's/^.*\bProtocol\b.*$/Protocol 2/' /etc/ssh/sshd_config Restart the ssh service: # service sshd restart

b
The SLES for vRealize must enforce SSHv2 for network access to non-privileged accounts.
IA-2 - Medium - CCI-001942 - V-240460 - SV-240460r852557_rule
RMF Control
IA-2
Severity
Medium
CCI
CCI-001942
Version
VRAU-SL-000715
Vuln IDs
  • V-240460
  • V-89697
Rule IDs
  • SV-240460r852557_rule
  • SV-100347
A replay attack may enable an unauthorized user to gain access to the operating system. Authentication sessions between the authenticator and the operating system validating the user credentials must not be vulnerable to a replay attack. An authentication process resists replay attacks if it is impractical to achieve a successful authentication by recording and replaying a previous authentication message. A non-privileged account is any operating system account with authorizations of a non-privileged user. Techniques used to address this include protocols using nonces (e.g., numbers generated for a specific one-time use) or challenges (e.g., TLS, WS_Security). Additional techniques include time-synchronous or challenge-response one-time authenticators.
Checks: C-43693r671119_chk

Verify that the SLES for vRealize enforces SSHv2 for network access to privileged accounts by running the following command: Replace [ADDRESS] in the following command with the correct IP address based on the current system configuration. # ssh -1 [ADDRESS] An example of the command usage is as follows: # ssh -1 localhost The output must be one of the following items: Protocol major versions differ: 1 vs. 2 OR: Protocol 1 not allowed in the FIPS mode. If the output is not one of the above, this is a finding. OR Verify that the ssh is configured to enforce SSHv2 for network access to privileged accounts by running the following command: # grep Protocol /etc/ssh/sshd_config If the result is not "Protocol 2", this is a finding.

Fix: F-43652r671120_fix

Configure the SLES for vRealize to enforce SSHv2 for network access to non-privileged accounts by running the following commands: # sed -i 's/^.*\bProtocol\b.*$/Protocol 2/' /etc/ssh/sshd_config Restart the ssh service: # service sshd restart

b
The SLES for vRealize must disable account identifiers of individuals and roles (such as root) after 35 days of inactivity after password expiration.
IA-4 - Medium - CCI-000795 - V-240461 - SV-240461r671124_rule
RMF Control
IA-4
Severity
Medium
CCI
CCI-000795
Version
VRAU-SL-000725
Vuln IDs
  • V-240461
  • V-89699
Rule IDs
  • SV-240461r671124_rule
  • SV-100349
Inactive identifiers pose a risk to systems and applications because attackers may exploit an inactive identifier and potentially obtain undetected access to the system. Owners of inactive accounts will not notice if unauthorized access to their user account has been obtained. Operating systems need to track periods of inactivity and disable application identifiers after 35 days of inactivity.
Checks: C-43694r671122_chk

Verify the SLES for vRealize disables account identifiers after "35" days of inactivity after the password expiration, by performing the following commands: # grep "INACTIVE" /etc/default/useradd The output must indicate the "INACTIVE" configuration option is set to an appropriate integer as shown in the example below: grep "INACTIVE" /etc/default/useradd INACTIVE=35 If "INACTIVE" is not set to the value of "35" or less, this is a finding.

Fix: F-43653r671123_fix

Configure the SLES for vRealize to disable account identifiers after 35 days of inactivity after the password expiration. Run the following command to change the configuration for useradd: Replace [VALUE] in the command with any integer from the range 0<[VALUE]<= 35. # sed -i "s/^.*\bINACTIVE\b.*$/INACTIVE=[VALUE]/" /etc/default/useradd DoD recommendation is "35" days, but a lower value is acceptable. The value "-1" will disable this feature and "0" will disable the account immediately after the password expires.

b
The SLES for vRealize must use mechanisms meeting the requirements of applicable federal laws, Executive orders, directives, policies, regulations, standards, and guidance for authentication to a cryptographic module.
IA-7 - Medium - CCI-000803 - V-240462 - SV-240462r671127_rule
RMF Control
IA-7
Severity
Medium
CCI
CCI-000803
Version
VRAU-SL-000730
Vuln IDs
  • V-240462
  • V-89701
Rule IDs
  • SV-240462r671127_rule
  • SV-100351
Unapproved mechanisms that are used for authentication to the cryptographic module are not verified and therefore cannot be relied upon to provide confidentiality or integrity, and DoD data may be compromised. Operating systems utilizing encryption are required to use FIPS-compliant mechanisms for authenticating to cryptographic modules. FIPS 140-2 is the current standard for validating that mechanisms used to access cryptographic modules utilize authentication that meets DoD requirements. This allows for Security Levels 1, 2, 3, or 4 for use on a general purpose computing system.
Checks: C-43695r671125_chk

Check the /etc/default/passwd file: # grep CRYPT /etc/default/passwd If the "CRYPT" setting in /etc/default/passwd is not present, or not set to "SHA256" or "SHA512", this is a finding. If the "CRYPT_FILES" setting in /etc/default/passwd is not present, or not set to "SHA256" or "SHA512", this is a finding.

Fix: F-43654r671126_fix

Edit the /etc/default/passwd file and add or change the "CRYPT" variable setting so that it contains: CRYPT=sha256 OR CRYPT=sha512 Edit the /etc/default/passwd file and add or change the "CRYPT_FILES" variable setting so that it contains: CRYPT_FILES=sha256 OR CRYPT_FILES=sha512

b
The SLES for vRealize must uniquely identify and must authenticate non-organizational users (or processes acting on behalf of non-organizational users).
IA-8 - Medium - CCI-000804 - V-240463 - SV-240463r671130_rule
RMF Control
IA-8
Severity
Medium
CCI
CCI-000804
Version
VRAU-SL-000735
Vuln IDs
  • V-240463
  • V-89703
Rule IDs
  • SV-240463r671130_rule
  • SV-100353
Lack of authentication and identification enables non-organizational users to gain access to the application or possibly other information systems and provides an opportunity for intruders to compromise resources within the application or information system. Non-organizational users include all information system users other than organizational users, which include organizational employees or individuals the organization deems to have equivalent status of an employee (e.g., contractors and guest researchers). Non-organizational users must 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.
Checks: C-43696r671128_chk

Run the following command to check for duplicate account names: # pwck -rq If there are no duplicate names, no line will be returned. If a line is returned, this is a finding.

Fix: F-43655r671129_fix

Change usernames, or delete accounts, so each has a unique name.

b
All GIDs referenced in /etc/passwd must be defined in /etc/group.
IA-8 - Medium - CCI-000804 - V-240464 - SV-240464r671133_rule
RMF Control
IA-8
Severity
Medium
CCI
CCI-000804
Version
VRAU-SL-000740
Vuln IDs
  • V-240464
  • V-89705
Rule IDs
  • SV-240464r671133_rule
  • SV-100355
Inconsistency in GIDs between /etc/passwd and /etc/group could lead to a user having unintended rights.
Checks: C-43697r671131_chk

To ensure all GIDs referenced in /etc/passwd are defined in /etc/group, run the following command: # pwck -rq If a line is returned, this is a finding.

Fix: F-43656r671132_fix

Add a group to the system for each GID referenced without a corresponding group.

b
The SLES for vRealize must uniquely identify and must authenticate non-organizational users (or processes acting on behalf of non-organizational users).
IA-8 - Medium - CCI-000804 - V-240465 - SV-240465r671136_rule
RMF Control
IA-8
Severity
Medium
CCI
CCI-000804
Version
VRAU-SL-000745
Vuln IDs
  • V-240465
  • V-89707
Rule IDs
  • SV-240465r671136_rule
  • SV-100357
Lack of authentication and identification enables non-organizational users to gain access to the application or possibly other information systems and provides an opportunity for intruders to compromise resources within the application or information system. Non-organizational users include all information system users other than organizational users, which include organizational employees or individuals the organization deems to have equivalent status of an employee (e.g., contractors and guest researchers). Non-organizational users must 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.
Checks: C-43698r671134_chk

Verify the SLES for vRealize uniquely identifies and authenticates non-organizational users by running the following commands: # awk -F: '{print $3}' /etc/passwd | sort | uniq -d If the output is not blank, this is a finding.

Fix: F-43657r671135_fix

Configure the SLES for vRealize to uniquely identify and authenticate non-organizational users (or processes acting on behalf of non-organizational users). UNIQUE_USER_ID is a unique numerical value that must be non-negative. USERNAME is the username of the user whose user ID is to be changed. # usermod -u [UNIQUE_USER_ID] [USERNAME]

b
The SLES for vRealize must be configured such that emergency administrator accounts are never automatically removed or disabled.
AC-2 - Medium - CCI-001682 - V-240466 - SV-240466r671139_rule
RMF Control
AC-2
Severity
Medium
CCI
CCI-001682
Version
VRAU-SL-000755
Vuln IDs
  • V-240466
  • V-89709
Rule IDs
  • SV-240466r671139_rule
  • SV-100359
Emergency administrator accounts are privileged accounts that are established in response to crisis situations where the need for rapid account activation is required. Therefore, emergency account activation may bypass normal account authorization processes. If these accounts are automatically disabled, system maintenance during emergencies may not be possible, thus adversely affecting system availability. Emergency administrator accounts are different from infrequently used accounts (i.e., local logon accounts used by system administrators when network or normal logon/access is not available). Infrequently used accounts also remain available and are not subject to automatic termination dates. However, an emergency administrator account is normally a different account that is created for use by vendors or system maintainers. To address access requirements, many operating systems can be integrated with enterprise-level authentication/access mechanisms that meet or exceed access control policy requirements.
Checks: C-43699r671137_chk

For each emergency administrator account run the following command: chage -l [user] If the output shows an expiration date for the account, this is a finding.

Fix: F-43658r671138_fix

For each emergency administrator account run the following command to remove the expiration: chage -E -1 [user]

b
The SLES for vRealize must employ strong authenticators in the establishment of nonlocal maintenance and diagnostic sessions.
MA-4 - Medium - CCI-000877 - V-240467 - SV-240467r877395_rule
RMF Control
MA-4
Severity
Medium
CCI
CCI-000877
Version
VRAU-SL-000760
Vuln IDs
  • V-240467
  • V-89711
Rule IDs
  • SV-240467r877395_rule
  • SV-100361
If maintenance tools are used by unauthorized personnel, they may accidentally or intentionally damage or compromise the system. The act of managing systems and applications includes the ability to access sensitive application information, such as system configuration details, diagnostic information, user information, and potentially sensitive application data. Some maintenance and test tools are either standalone devices with their own operating systems or are applications bundled with an operating system. Nonlocal 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. Local maintenance and diagnostic activities are those activities carried out by individuals physically present at the information system or information system component and not communicating across a network connection. Typically, strong authentication requires authenticators that are resistant to replay attacks and employ multifactor authentication. Strong authenticators include, for example, PKI where certificates are stored on a token protected by a password, passphrase, or biometric.
Checks: C-43700r671140_chk

Check the SSH daemon configuration for DoD-approved encryption to protect the confidentiality of SSH remote connections by performing the following commands: Check the "Ciphers" setting in the "sshd_config" file. # grep -i Ciphers /etc/ssh/sshd_config | grep -v '#' The output must contain either nothing or any number of the following algorithms: aes128-ctr, aes256-ctr. If the output contains an algorithm not listed above, this is a finding. Expected Output: Ciphers aes256-ctr,aes128-ctr

Fix: F-43659r671141_fix

Update the "Ciphers" directive with the following command: # sed -i "/^[^#]*Ciphers/ c\Ciphers aes256-ctr,aes128-ctr" /etc/ssh/sshd_config Save and close the file. Restart the sshd process: # service sshd restart

b
The SLES for vRealize must terminate all sessions and network connections related to nonlocal maintenance when nonlocal maintenance is completed.
MA-4 - Medium - CCI-000879 - V-240468 - SV-240468r671145_rule
RMF Control
MA-4
Severity
Medium
CCI
CCI-000879
Version
VRAU-SL-000765
Vuln IDs
  • V-240468
  • V-89713
Rule IDs
  • SV-240468r671145_rule
  • SV-100363
If a maintenance session or connection remains open after maintenance is completed, it may be hijacked by an attacker and used to compromise or damage the system. Some maintenance and test tools are either standalone devices with their own operating systems or are applications bundled with an operating system. Nonlocal 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. Local maintenance and diagnostic activities are those activities carried out by individuals physically present at the information system or information system component and not communicating across a network connection.
Checks: C-43701r671143_chk

Check for the existence of the /etc/profile.d/tmout.sh file: # ls -al /etc/profile.d/tmout.sh Check for the presence of the "TMOUT" variable: # grep TMOUT /etc/profile.d/tmout.sh The value of "TMOUT" should be set to "900" seconds (15 minutes). If the file does not exist, or the "TMOUT" variable is not set to "900", this is a finding.

Fix: F-43660r671144_fix

Ensure the file exists and is owned by "root". If the files does not exist, use the following commands to create the file: # touch /etc/profile.d/tmout.sh # chown root:root /etc/profile.d/tmout.sh # chmod 644 /etc/profile.d/tmout.sh Edit the file /etc/profile.d/tmout.sh, and add the following lines: TMOUT=900 readonly TMOUT export TMOUT mesg n 2>/dev/null

b
The SLES for vRealize must manage excess capacity, bandwidth, or other redundancy to limit the effects of information flooding types of Denial of Service (DoS) attacks.
SC-5 - Medium - CCI-001095 - V-240469 - SV-240469r671148_rule
RMF Control
SC-5
Severity
Medium
CCI
CCI-001095
Version
VRAU-SL-000785
Vuln IDs
  • V-240469
  • V-89715
Rule IDs
  • SV-240469r671148_rule
  • SV-100365
DoS is a condition when a resource is not available for legitimate users. When this occurs, the organization either cannot accomplish its mission or must operate at degraded capacity. Managing excess capacity ensures that sufficient capacity is available to counter flooding attacks. Employing increased capacity and service redundancy may reduce the susceptibility to some DoS attacks. Managing excess capacity may include, for example, establishing selected usage priorities, quotas, or partitioning.
Checks: C-43702r671146_chk

Check that the SLES for vRealize configured to use TCP syncookies when experiencing a TCP SYN flood. # cat /proc/sys/net/ipv4/tcp_syncookies If the result is not "1", this is a finding.

Fix: F-43661r671147_fix

Configure the SLES for vRealize to use TCP syncookies when experiencing a TCP SYN flood. # sed -i 's/^.*\bnet.ipv4.tcp_syncookies\b.*$/net.ipv4.tcp_syncookies=1/' /etc/sysctl.conf Reload sysctl to verify the new change: # sysctl -p

b
The SLES for vRealize must manage excess capacity, bandwidth, or other redundancy to limit the effects of information flooding types of Denial of Service (DoS) attacks.
SC-5 - Medium - CCI-001095 - V-240470 - SV-240470r671151_rule
RMF Control
SC-5
Severity
Medium
CCI
CCI-001095
Version
VRAU-SL-000790
Vuln IDs
  • V-240470
  • V-89717
Rule IDs
  • SV-240470r671151_rule
  • SV-100367
DoS is a condition when a resource is not available for legitimate users. When this occurs, the organization either cannot accomplish its mission or must operate at degraded capacity. Managing excess capacity ensures that sufficient capacity is available to counter flooding attacks. Employing increased capacity and service redundancy may reduce the susceptibility to some DoS attacks. Managing excess capacity may include, for example, establishing selected usage priorities, quotas, or partitioning.
Checks: C-43703r671149_chk

Check that the SLES for vRealize has an appropriate TCP backlog queue size to mitigate against TCP SYN flood DOS attacks with the following command: # cat /proc/sys/net/ipv4/tcp_max_syn_backlog If the TCP backlog queue size is not set to at least the recommended default setting of "1280", this is a finding.

Fix: F-43662r671150_fix

Configure the TCP backlog queue size with the following command: # sed -i 's/^.*\bnet.ipv4.tcp_max_syn_backlog\b.*$/net.ipv4.tcp_max_syn_backlog=1280/' /etc/sysctl.conf Reload sysctl to verify the new change: # sysctl -p

b
The SLES for vRealize must terminate all network connections associated with a communications session at the end of the session, or as follows: for in-band management sessions (privileged sessions), the session must be terminated after 10 minutes of inactivity; and for user sessions (non-privileged session), the session must be terminated after 15 minutes of inactivity, except to fulfill documented and validated mission requirements.
SC-10 - Medium - CCI-001133 - V-240471 - SV-240471r671395_rule
RMF Control
SC-10
Severity
Medium
CCI
CCI-001133
Version
VRAU-SL-000795
Vuln IDs
  • V-240471
  • V-89719
Rule IDs
  • SV-240471r671395_rule
  • SV-100369
Terminating an idle session within a short time period reduces the window of opportunity for unauthorized personnel to take control of a management session enabled on the console or console port that has been left unattended. In addition, quickly terminating an idle session will also free up resources committed by the managed network element. Terminating network connections associated with communications sessions includes, for example, de-allocating associated TCP/IP address/port pairs at the operating system level, and de-allocating networking assignments at the application level if multiple application sessions are using a single operating system-level network connection. This does not mean that the operating system terminates all sessions or network access; it only ends the inactive session and releases the resources associated with that session.
Checks: C-43704r671152_chk

Check for the existence of the /etc/profile.d/tmout.sh file: # ls -al /etc/profile.d/tmout.sh Check for the presence of the "TMOUT" variable: # grep TMOUT /etc/profile.d/tmout.sh The value of "TMOUT" should be set to "900" seconds (15 minutes). If the file does not exist, or the "TMOUT" variable is not set to "900", this is a finding.

Fix: F-43663r671153_fix

Ensure the file exists and is owned by "root". If the files does not exist, use the following commands to create the file: # touch /etc/profile.d/tmout.sh # chown root:root /etc/profile.d/tmout.sh # chmod 644 /etc/profile.d/tmout.sh Edit the file /etc/profile.d/tmout.sh, and add the following lines: TMOUT=900 readonly TMOUT export TMOUT mesg n 2>/dev/null

b
The /var/log directory must be group-owned by root.
SI-11 - Medium - CCI-001314 - V-240472 - SV-240472r671157_rule
RMF Control
SI-11
Severity
Medium
CCI
CCI-001314
Version
VRAU-SL-000820
Vuln IDs
  • V-240472
  • V-89721
Rule IDs
  • SV-240472r671157_rule
  • SV-100371
Only authorized personnel should be aware of errors and the details of the errors. Error messages are an indicator of an organization's operational state or can identify the operating system or platform. Additionally, Personally Identifiable Information (PII) and operational information must not be revealed through error messages to unauthorized personnel or their designated representatives. The structure and content of error messages must be carefully considered by the organization and development team. The extent to which the information system is able to identify and handle error conditions is guided by organizational policy and operational requirements.
Checks: C-43705r671155_chk

Verify the /var/log directory is group-owned by "root" by running the following command: # ls -lad /var/log | cut -d' ' -f4 The output must look like the following example: ls -lad /var/log | cut -d' ' -f4 root If "root" is not returned as a result, this is a finding.

Fix: F-43664r671156_fix

Change the group of the directory /var/log to "root" by running the following command: # chgrp root /var/log

b
The /var/log directory must be owned by root.
SI-11 - Medium - CCI-001314 - V-240473 - SV-240473r671160_rule
RMF Control
SI-11
Severity
Medium
CCI
CCI-001314
Version
VRAU-SL-000825
Vuln IDs
  • V-240473
  • V-89723
Rule IDs
  • SV-240473r671160_rule
  • SV-100373
Only authorized personnel should be aware of errors and the details of the errors. Error messages are an indicator of an organization's operational state or can identify the operating system or platform. Additionally, Personally Identifiable Information (PII) and operational information must not be revealed through error messages to unauthorized personnel or their designated representatives. The structure and content of error messages must be carefully considered by the organization and development team. The extent to which the information system is able to identify and handle error conditions is guided by organizational policy and operational requirements.
Checks: C-43706r671158_chk

Verify that the /var/log directory is owned by "root" by running the following command: # ls -lad /var/log | cut -d' ' -f3 The output must look like the following example: ls -lad /var/log | cut -d' ' -f3 root If "root" is not returned as a result, this is a finding.

Fix: F-43665r671159_fix

Change the owner of the directory /var/log to "root" by running the following command: # chown root /var/log

b
The /var/log directory must have mode 0750 or less permissive.
SI-11 - Medium - CCI-001314 - V-240474 - SV-240474r671163_rule
RMF Control
SI-11
Severity
Medium
CCI
CCI-001314
Version
VRAU-SL-000830
Vuln IDs
  • V-240474
  • V-89725
Rule IDs
  • SV-240474r671163_rule
  • SV-100375
Only authorized personnel should be aware of errors and the details of the errors. Error messages are an indicator of an organization's operational state or can identify the operating system or platform. Additionally, Personally Identifiable Information (PII) and operational information must not be revealed through error messages to unauthorized personnel or their designated representatives. The structure and content of error messages must be carefully considered by the organization and development team. The extent to which the information system is able to identify and handle error conditions is guided by organizational policy and operational requirements.
Checks: C-43707r671161_chk

Verify that the /var/log directory has mode 0750 or less by running the following command: # ls -lad /var/log | cut -d' ' -f1 The output must look like the following example: ls -lad /var/log | cut -d' ' -f1 drwxr-x--- If "drwxr-x---" is not returned as a result, this is a finding.

Fix: F-43666r671162_fix

Change the permissions of the directory /var/log to "0750" by running the following command: # chmod 0750 /var/log

b
The /var/log/messages file must be group-owned by root.
SI-11 - Medium - CCI-001314 - V-240475 - SV-240475r671166_rule
RMF Control
SI-11
Severity
Medium
CCI
CCI-001314
Version
VRAU-SL-000835
Vuln IDs
  • V-240475
  • V-89727
Rule IDs
  • SV-240475r671166_rule
  • SV-100377
Only authorized personnel should be aware of errors and the details of the errors. Error messages are an indicator of an organization's operational state or can identify the operating system or platform. Additionally, Personally Identifiable Information (PII) and operational information must not be revealed through error messages to unauthorized personnel or their designated representatives. The structure and content of error messages must be carefully considered by the organization and development team. The extent to which the information system is able to identify and handle error conditions is guided by organizational policy and operational requirements.
Checks: C-43708r671164_chk

Verify that the /var/log/messages file is group-owned by "root" by running the following command: # ls -la /var/log/messages | cut -d' ' -f4 The output must look like the following example: ls -la /var/log/messages | cut -d' ' -f4 root If "root" is not returned as a result, this is a finding.

Fix: F-43667r671165_fix

Change the group of the file /var/log/messages to "root" by running the following command: # chgrp root /var/log/messages

b
The /var/log/messages file must be owned by root.
SI-11 - Medium - CCI-001314 - V-240476 - SV-240476r671169_rule
RMF Control
SI-11
Severity
Medium
CCI
CCI-001314
Version
VRAU-SL-000840
Vuln IDs
  • V-240476
  • V-89729
Rule IDs
  • SV-240476r671169_rule
  • SV-100379
Only authorized personnel should be aware of errors and the details of the errors. Error messages are an indicator of an organization's operational state or can identify the operating system or platform. Additionally, Personally Identifiable Information (PII) and operational information must not be revealed through error messages to unauthorized personnel or their designated representatives. The structure and content of error messages must be carefully considered by the organization and development team. The extent to which the information system is able to identify and handle error conditions is guided by organizational policy and operational requirements.
Checks: C-43709r671167_chk

Verify that the /var/log/messages file is owned by "root" by running the following command: # ls -la /var/log/messages | cut -d' ' -f3 The output must look like the following example: ls -la /var/log/messages | cut -d' ' -f3 root If "root" is not returned as a result, this is a finding.

Fix: F-43668r671168_fix

Change the owner of the file /var/log/messages to "root" by running the following command: # chown root /var/log/messages

b
The /var/log/messages file must have mode 0640 or less permissive.
SI-11 - Medium - CCI-001314 - V-240477 - SV-240477r671172_rule
RMF Control
SI-11
Severity
Medium
CCI
CCI-001314
Version
VRAU-SL-000845
Vuln IDs
  • V-240477
  • V-89731
Rule IDs
  • SV-240477r671172_rule
  • SV-100381
Only authorized personnel should be aware of errors and the details of the errors. Error messages are an indicator of an organization's operational state or can identify the operating system or platform. Additionally, Personally Identifiable Information (PII) and operational information must not be revealed through error messages to unauthorized personnel or their designated representatives. The structure and content of error messages must be carefully considered by the organization and development team. The extent to which the information system is able to identify and handle error conditions is guided by organizational policy and operational requirements.
Checks: C-43710r671170_chk

Verify that the /var/log/messages file has mode 0640 or less by running the following command: # ls -lad /var/log/messages | cut -d' ' -f1 The output must look like the following example: ls -lad /var/log/messages | cut -d' ' -f1 -rw-r----- If "-rw-r-----" is not returned as a result, this is a finding.

Fix: F-43669r671171_fix

Change the permissions of the file /var/log/messages to "0640" by running the following command: # chmod 0640 /var/log/messages

b
The SLES for vRealize must reveal error messages only to authorized users.
SI-11 - Medium - CCI-001314 - V-240478 - SV-240478r671175_rule
RMF Control
SI-11
Severity
Medium
CCI
CCI-001314
Version
VRAU-SL-000850
Vuln IDs
  • V-240478
  • V-89733
Rule IDs
  • SV-240478r671175_rule
  • SV-100383
Only authorized personnel should be aware of errors and the details of the errors. Error messages are an indicator of an organization's operational state or can identify the operating system or platform. Additionally, Personally Identifiable Information (PII) and operational information must not be revealed through error messages to unauthorized personnel or their designated representatives. The structure and content of error messages must be carefully considered by the organization and development team. The extent to which the information system is able to identify and handle error conditions is guided by organizational policy and operational requirements.
Checks: C-43711r671173_chk

Check the permissions of the syslog configuration file(s): # ls -lL /etc/syslog-ng/syslog-ng.conf If the mode of the file is more permissive than "0640", this is a finding.

Fix: F-43670r671174_fix

Change the permissions of the syslog configuration file(s): # chmod 640 /etc/syslog-ng/syslog-ng.conf

b
The SLES for vRealize must reveal error messages only to authorized users.
SI-11 - Medium - CCI-001314 - V-240479 - SV-240479r671178_rule
RMF Control
SI-11
Severity
Medium
CCI
CCI-001314
Version
VRAU-SL-000855
Vuln IDs
  • V-240479
  • V-89735
Rule IDs
  • SV-240479r671178_rule
  • SV-100385
Only authorized personnel should be aware of errors and the details of the errors. Error messages are an indicator of an organization's operational state or can identify the operating system or platform. Additionally, Personally Identifiable Information (PII) and operational information must not be revealed through error messages to unauthorized personnel or their designated representatives. The structure and content of error messages must be carefully considered by the organization and development team. The extent to which the information system is able to identify and handle error conditions is guided by organizational policy and operational requirements.
Checks: C-43712r671176_chk

Check the permissions of the syslog configuration file(s): # ls -lL /etc/syslog-ng/syslog-ng.conf If the file is not owned by "root", this is a finding.

Fix: F-43671r671177_fix

Use the chown command to set the owner to "root": # chown root /etc/syslog-ng/syslog-ng.conf

b
The SLES for vRealize must reveal error messages only to authorized users.
SI-11 - Medium - CCI-001314 - V-240480 - SV-240480r671181_rule
RMF Control
SI-11
Severity
Medium
CCI
CCI-001314
Version
VRAU-SL-000860
Vuln IDs
  • V-240480
  • V-89737
Rule IDs
  • SV-240480r671181_rule
  • SV-100387
Only authorized personnel should be aware of errors and the details of the errors. Error messages are an indicator of an organization's operational state or can identify the operating system or platform. Additionally, Personally Identifiable Information (PII) and operational information must not be revealed through error messages to unauthorized personnel or their designated representatives. The structure and content of error messages must be carefully considered by the organization and development team. The extent to which the information system is able to identify and handle error conditions is guided by organizational policy and operational requirements.
Checks: C-43713r671179_chk

Check the permissions of the syslog configuration file(s): # ls -lL /etc/syslog-ng/syslog-ng.conf If the file is not group-owned by "root", this is a finding.

Fix: F-43672r671180_fix

Change the group-owner of the /etc/rsyslog.conf file to "root": # chgrp root /etc/syslog-ng/syslog-ng.conf

b
The SLES for vRealize must audit all account modifications.
AC-2 - Medium - CCI-001403 - V-240482 - SV-240482r671187_rule
RMF Control
AC-2
Severity
Medium
CCI
CCI-001403
Version
VRAU-SL-000870
Vuln IDs
  • V-240482
  • V-89741
Rule IDs
  • SV-240482r671187_rule
  • SV-100391
Once an attacker establishes initial access to a system, the attacker often attempts to create a persistent method of reestablishing access. One way to accomplish this is for the attacker to simply modify an existing account. Auditing of account modification is one method for mitigating this risk. To address access requirements, many operating systems can be integrated with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements.
Checks: C-43715r671185_chk

Determine if execution of the usermod and groupmod executable are audited. # auditctl -l | egrep '(usermod|groupmod)' | grep perm=x If either usermod or groupmod are not listed with a permissions filter of at least 'x', this is a finding.

Fix: F-43674r671186_fix

Configure execute auditing of the usermod and groupmod executables run the dodscript with the following command as root: # /etc/dodscript.sh OR.... Configure execute auditing of the usermod and groupmod executables. Add the following to the audit.rules file: -w /usr/sbin/usermod -p x -k usermod -w /usr/sbin/groupmod -p x -k groupmod Restart the auditd service. # service auditd restart

b
The SLES for vRealize must audit all account modifications.
AC-2 - Medium - CCI-001403 - V-240483 - SV-240483r671190_rule
RMF Control
AC-2
Severity
Medium
CCI
CCI-001403
Version
VRAU-SL-000875
Vuln IDs
  • V-240483
  • V-89743
Rule IDs
  • SV-240483r671190_rule
  • SV-100393
Once an attacker establishes initial access to a system, the attacker often attempts to create a persistent method of reestablishing access. One way to accomplish this is for the attacker to simply modify an existing account. Auditing of account modification is one method for mitigating this risk. To address access requirements, many operating systems can be integrated with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements.
Checks: C-43716r671188_chk

Determine if /etc/passwd, /etc/shadow, /etc/group, and /etc/gshadow are audited for writing. # auditctl -l | egrep '(/etc/passwd|/etc/shadow|/etc/group|/etc/gshadow)' | grep perm=w If any of these are not listed with a permissions filter of at least "w", this is a finding.

Fix: F-43675r671189_fix

Configure append auditing of the "passwd", "shadow", "group", and "gshadow" files run "dodscript" with the following command as "root": # /etc/dodscript.sh OR Configure auditing of the "passwd", "shadow", "group", and "gshadow" files. Add the following to the audit.rules file: -w /etc/passwd -p w -k passwd -w /etc/shadow -p w -k shadow -w /etc/group -p w -k group -w /etc/gshadow -p w -k gshadow Restart the auditd service: # service auditd restart

b
The SLES for vRealize must audit all account disabling actions.
AC-2 - Medium - CCI-001404 - V-240484 - SV-240484r671193_rule
RMF Control
AC-2
Severity
Medium
CCI
CCI-001404
Version
VRAU-SL-000880
Vuln IDs
  • V-240484
  • V-89745
Rule IDs
  • SV-240484r671193_rule
  • SV-100395
When operating system accounts are disabled, user accessibility is affected. Accounts are utilized for identifying individual users or for identifying the operating system processes themselves. In order to detect and respond to events affecting user accessibility and system processing, operating systems must audit account disabling actions and, as required, notify the appropriate individuals so they can investigate the event. Such a capability greatly reduces the risk that operating system accessibility will be negatively affected for extended periods of time and provides logging that can be used for forensic purposes. To address access requirements, many operating systems can be integrated with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements.
Checks: C-43717r671191_chk

Determine if execution of the "passwd" executable is audited: # auditctl -l | grep watch=/usr/bin/passwd If /usr/bin/passwd is not listed with a permissions filter of at least "x", this is a finding.

Fix: F-43676r671192_fix

Configure the SLES for vRealize to automatically audit account disabling actions by running the following command: # /etc/dodscript.sh OR # echo '-w /usr/bin/passwd -p x -k passwd' >> /etc/audit/audit.rules Restart the auditd service: # service auditd restart

b
The SLES for vRealize must audit all account removal actions.
AC-2 - Medium - CCI-001405 - V-240485 - SV-240485r671196_rule
RMF Control
AC-2
Severity
Medium
CCI
CCI-001405
Version
VRAU-SL-000885
Vuln IDs
  • V-240485
  • V-89747
Rule IDs
  • SV-240485r671196_rule
  • SV-100397
When operating system accounts are removed, user accessibility is affected. Accounts are utilized for identifying individual users or for identifying the operating system processes themselves. In order to detect and respond to events affecting user accessibility and system processing, operating systems must audit account removal actions and, as required, notify the appropriate individuals so they can investigate the event. Such a capability greatly reduces the risk that operating system accessibility will be negatively affected for extended periods of time and provides logging that can be used for forensic purposes. To address access requirements, many operating systems can be integrated with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements.
Checks: C-43718r671194_chk

Determine if execution of the "userdel" and "groupdel" executable are audited: # auditctl -l | egrep '(userdel|groupdel)' If either "userdel" or "groupdel" are not listed with a permissions filter of at least "x", this is a finding.

Fix: F-43677r671195_fix

Configure execute auditing of the "userdel" and "groupdel" executables. Add the following to the /etc/audit/audit.rules file: -w /usr/sbin/userdel -p x -k userdel -w /usr/sbin/groupdel -p x -k groupdel

b
The SLES for vRealize must implement cryptography to protect the integrity of remote access sessions.
AC-17 - Medium - CCI-001453 - V-240486 - SV-240486r877394_rule
RMF Control
AC-17
Severity
Medium
CCI
CCI-001453
Version
VRAU-SL-000890
Vuln IDs
  • V-240486
  • V-89749
Rule IDs
  • SV-240486r877394_rule
  • SV-100399
Without cryptographic integrity protections, information can be altered by unauthorized users without detection. Remote access (e.g., RDP) is access to DoD nonpublic information systems by an authorized user (or an information system) communicating through an external, non-organization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless. Cryptographic mechanisms used for protecting the integrity of information include, for example, signed hash functions using asymmetric cryptography enabling distribution of the public key to verify the hash information while maintaining the confidentiality of the secret key used to generate the hash.
Checks: C-43719r671197_chk

Check the SSH daemon configuration for DoD-approved encryption to protect the confidentiality of SSH remote connections by performing the following commands: Check the "Ciphers" setting in the "sshd_config" file. # grep -i Ciphers /etc/ssh/sshd_config | grep -v '#' The output must contain either nothing or any number of the following algorithms: aes128-ctr, aes256-ctr. If the output contains an algorithm not listed above, this is a finding. Expected Output: Ciphers aes256-ctr,aes128-ctr

Fix: F-43678r671198_fix

Update the "Ciphers" directive with the following command: # sed -i "/^[^#]*Ciphers/ c\Ciphers aes256-ctr,aes128-ctr" /etc/ssh/sshd_config Save and close the file. Restart the sshd process: # service sshd restart

b
The SLES for vRealize must initiate session audits at system start-up.
AU-14 - Medium - CCI-001464 - V-240487 - SV-240487r671202_rule
RMF Control
AU-14
Severity
Medium
CCI
CCI-001464
Version
VRAU-SL-000895
Vuln IDs
  • V-240487
  • V-89751
Rule IDs
  • SV-240487r671202_rule
  • SV-100401
If auditing is enabled late in the start-up process, the actions of some start-up processes may not be audited. Some audit systems also maintain state information only available if auditing is enabled before a given process is created.
Checks: C-43720r671200_chk

Check for the "audit=1" kernel parameter. # grep "audit=1" /proc/cmdline If no results are returned, this is a finding.

Fix: F-43679r671201_fix

Edit the grub bootloader file /boot/grub/menu.lst by appending the "audit=1" parameter to the kernel boot line. Reboot the system for the change to take effect.

b
The SLES for vRealize must produce audit records containing information to establish the identity of any individual or process associated with the event.
AU-3 - Medium - CCI-001487 - V-240488 - SV-240488r671205_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-001487
Version
VRAU-SL-000900
Vuln IDs
  • V-240488
  • V-89753
Rule IDs
  • SV-240488r671205_rule
  • SV-100403
Without information that establishes the identity of the subjects (i.e., users or processes acting on behalf of users) associated with the events, security personnel cannot determine responsibility for the potentially harmful event.
Checks: C-43721r671203_chk

Verify the SLES for vRealize produces audit records by running the following command to determine the current status of the "auditd" service: # service auditd status If the service is enabled, the returned message must contain the following text: Checking for service auditd running If the service is not "running", this is a finding.

Fix: F-43680r671204_fix

Enable the "auditd" service by performing the following commands: # chkconfig auditd on # service auditd start

b
The SLES for vRealize must protect audit tools from unauthorized access.
AU-9 - Medium - CCI-001493 - V-240489 - SV-240489r671208_rule
RMF Control
AU-9
Severity
Medium
CCI
CCI-001493
Version
VRAU-SL-000905
Vuln IDs
  • V-240489
  • V-89755
Rule IDs
  • SV-240489r671208_rule
  • SV-100405
Protecting audit information also includes identifying and protecting the tools used to view and manipulate log data. Therefore, protecting audit tools is necessary to prevent unauthorized operation on audit information. Operating systems providing tools to interface with audit information will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user enjoys in order to make access decisions regarding the access to audit tools. Audit tools include, but are not limited to, vendor-provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators.
Checks: C-43722r671206_chk

The following command will list which audit files on the system have permissions different from what is expected by the RPM database: # rpm -V audit | grep '^.M' If there is any output, for each file or directory found, compare the RPM-expected permissions with the permissions on the file or directory: # rpm -q --queryformat "[%{FILENAMES} %{FILEMODES:perms}\n]" audit | grep [filename] # ls -lL [filename] If the existing permissions are more permissive than those expected by RPM, this is a finding.

Fix: F-43681r671207_fix

Run the following command to reset audit permissions to the correct values: sudo rpm --setperms audit-1.8-0.34.26

b
The SLES for vRealize must protect audit tools from unauthorized modification.
AU-9 - Medium - CCI-001494 - V-240490 - SV-240490r671211_rule
RMF Control
AU-9
Severity
Medium
CCI
CCI-001494
Version
VRAU-SL-000910
Vuln IDs
  • V-240490
  • V-89757
Rule IDs
  • SV-240490r671211_rule
  • SV-100407
Protecting audit information also includes identifying and protecting the tools used to view and manipulate log data. Therefore, protecting audit tools is necessary to prevent unauthorized operation on audit information. Operating systems providing tools to interface with audit information will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user has in order to make access decisions regarding the modification of audit tools. Audit tools include, but are not limited to, vendor-provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators.
Checks: C-43723r671209_chk

The following command will list which audit files on the system where the group-ownership has been modified: # rpm -V audit | grep '^......G' If there is output, this is a finding.

Fix: F-43682r671210_fix

Run the following command to reset audit permissions to the correct values: sudo rpm --setperms audit-1.8-0.34.26

b
The SLES for vRealize must protect audit tools from unauthorized deletion.
AU-9 - Medium - CCI-001495 - V-240491 - SV-240491r671214_rule
RMF Control
AU-9
Severity
Medium
CCI
CCI-001495
Version
VRAU-SL-000915
Vuln IDs
  • V-240491
  • V-89759
Rule IDs
  • SV-240491r671214_rule
  • SV-100409
Protecting audit information also includes identifying and protecting the tools used to view and manipulate log data. Therefore, protecting audit tools is necessary to prevent unauthorized operation on audit information. Operating systems providing tools to interface with audit information will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user has in order to make access decisions regarding the deletion of audit tools. Audit tools include, but are not limited to, vendor-provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators.
Checks: C-43724r671212_chk

The following command will list which audit files on the system where the ownership has been modified: # rpm -V audit | grep '^.....U' If there is output, this is a finding.

Fix: F-43683r671213_fix

Run the following command to reset audit permissions to the correct values: sudo rpm --setperms audit-1.8-0.34.26

b
The shared library files must have restrictive permissions.
CM-5 - Medium - CCI-001499 - V-240492 - SV-240492r671217_rule
RMF Control
CM-5
Severity
Medium
CCI
CCI-001499
Version
VRAU-SL-000920
Vuln IDs
  • V-240492
  • V-89761
Rule IDs
  • SV-240492r671217_rule
  • SV-100411
If the operating system were to allow any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process. This requirement applies to operating systems with software libraries that are accessible and configurable, as in the case of interpreted languages. Software libraries also include privileged programs that execute with escalated privileges. Only qualified and authorized individuals must be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications.
Checks: C-43725r671215_chk

Verify that that system wide shared library files are not group-writable or world writable with the following command: ls -l /lib /lib64 /usr/lib /usr/lib64 /lib/modules If any library files are group-writable or world writable, this is a finding.

Fix: F-43684r671216_fix

For any shared library file that was a finding: sudo chmod go-w <filename>

b
Shared library files must have root ownership.
CM-5 - Medium - CCI-001499 - V-240493 - SV-240493r671220_rule
RMF Control
CM-5
Severity
Medium
CCI
CCI-001499
Version
VRAU-SL-000921
Vuln IDs
  • V-240493
  • V-89763
Rule IDs
  • SV-240493r671220_rule
  • SV-100413
If the operating system were to allow any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process. This requirement applies to operating systems with software libraries that are accessible and configurable, as in the case of interpreted languages. Software libraries also include privileged programs which execute with escalated privileges. Only qualified and authorized individuals must be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications.
Checks: C-43726r671218_chk

Verify that that system wide shared library files have root ownership with the following command: ls -l /lib /lib64 /usr/lib /usr/lib64 /lib/modules If any library files are not root owned, this is a finding.

Fix: F-43685r671219_fix

For any shared library file that was a finding: sudo chown root <filename>

b
System executables must have restrictive permissions.
CM-5 - Medium - CCI-001499 - V-240494 - SV-240494r671223_rule
RMF Control
CM-5
Severity
Medium
CCI
CCI-001499
Version
VRAU-SL-000922
Vuln IDs
  • V-240494
  • V-89765
Rule IDs
  • SV-240494r671223_rule
  • SV-100415
If the operating system were to allow any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process. This requirement applies to operating systems with software libraries that are accessible and configurable, as in the case of interpreted languages. Software libraries also include privileged programs which execute with escalated privileges. Only qualified and authorized individuals must be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications.
Checks: C-43727r671221_chk

Verify that that system executables are not group-writable or world writable with the following command: ls -l /bin /sbin /usr/bin /usr/libexec /usr/local/bin /usr/local/sbin /usr/sbin If any files are group-writable or world writable, this is a finding.

Fix: F-43686r671222_fix

For any file that was a finding: sudo chmod go-w <filename>

b
System executables must have root ownership.
CM-5 - Medium - CCI-001499 - V-240495 - SV-240495r671226_rule
RMF Control
CM-5
Severity
Medium
CCI
CCI-001499
Version
VRAU-SL-000923
Vuln IDs
  • V-240495
  • V-89767
Rule IDs
  • SV-240495r671226_rule
  • SV-100417
If the operating system were to allow any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process. This requirement applies to operating systems with software libraries that are accessible and configurable, as in the case of interpreted languages. Software libraries also include privileged programs which execute with escalated privileges. Only qualified and authorized individuals must be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications.
Checks: C-43728r671224_chk

Verify that that system executable files have root ownership with the following command: ls -l /bin /sbin /usr/bin /usr/libexec /usr/local/bin /usr/local/sbin /usr/sbin If any library files are not root owned, this is a finding.

Fix: F-43687r671225_fix

For any file that was a finding: sudo chown root <filename>

b
The SLES for vRealize must enforce password complexity by requiring that at least one special character be used.
IA-5 - Medium - CCI-001619 - V-240496 - SV-240496r671229_rule
RMF Control
IA-5
Severity
Medium
CCI
CCI-001619
Version
VRAU-SL-000925
Vuln IDs
  • V-240496
  • V-89769
Rule IDs
  • SV-240496r671229_rule
  • SV-100419
Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity or strength is a measure of the effectiveness of a password in resisting attempts at 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, the greater the number of possible combinations that need to be tested before the password is compromised. Special characters are those characters that are not alphanumeric. Examples include: ~ ! @ # $ % ^ *.
Checks: C-43729r671227_chk

Verify the SLES for vRealize enforces password complexity by requiring that at least one special character be used by using the following command: Check the password "ocredit" option: # grep pam_cracklib.so /etc/pam.d/common-password Confirm the "ocredit" option is set to "-1" as in the example: password requisite pam_cracklib.so ocredit=-1 There may be other options on the line. If no such line is found, or the "ocredit" is not "-1", this is a finding.

Fix: F-43688r671228_fix

Configure the SLES for vRealize to enforce password complexity by requiring that at least one special character be used: If "ocredit" was not set at all in /etc/pam.d/common-password-vmware.local then run the following command: # sed -i '/pam_cracklib.so/ s/$/ ocredit=-1/' /etc/pam.d/common-password-vmware.local If "ocredit" was set incorrectly then run the following command: # sed -i '/pam_cracklib.so/ s/ocredit=../ocredit=-1/' /etc/pam.d/common-password-vmware.local

b
The SLES for vRealize must automatically terminate a user session after inactivity time-outs have expired or at shutdown.
AC-12 - Medium - CCI-002361 - V-240497 - SV-240497r852558_rule
RMF Control
AC-12
Severity
Medium
CCI
CCI-002361
Version
VRAU-SL-000960
Vuln IDs
  • V-240497
  • V-89771
Rule IDs
  • SV-240497r852558_rule
  • SV-100421
Automatic session termination addresses the termination of user-initiated logical sessions in contrast to the termination of network connections that are associated with communications sessions (i.e., network disconnect). A logical session (for local, network, and remote access) is initiated whenever a user (or process acting on behalf of a user) accesses an organizational information system. Such user sessions can be terminated (and thus terminate user access) without terminating network sessions. Session termination terminates all processes associated with a user's logical session except those processes that are specifically created by the user (i.e., session owner) to continue after the session is terminated. Conditions or trigger events requiring automatic session termination can include, for example, organization-defined periods of user inactivity, targeted responses to certain types of incidents, and time-of-day restrictions on information system use. This capability is typically reserved for specific operating system functionality where the system owner, data owner, or organization requires additional assurance.
Checks: C-43730r671230_chk

Check for the existence of the /etc/profile.d/tmout.sh file: # ls -al /etc/profile.d/tmout.sh Check for the presence of the "TMOUT" variable: # grep TMOUT /etc/profile.d/tmout.sh The value of "TMOUT" should be set to "900" seconds (15 minutes). If the file does not exist, or the "TMOUT" variable is not set to "900", this is a finding.

Fix: F-43689r671231_fix

Ensure the file exists and is owned by "root". If the files does not exist, use the following commands to create the file: # touch /etc/profile.d/tmout.sh # chown root:root /etc/profile.d/tmout.sh # chmod 644 /etc/profile.d/tmout.sh Edit the file /etc/profile.d/tmout.sh, and add the following lines: TMOUT=900 readonly TMOUT export TMOUT mesg n 2>/dev/null

b
The SLES for vRealize must control remote access methods.
AC-17 - Medium - CCI-002314 - V-240498 - SV-240498r852559_rule
RMF Control
AC-17
Severity
Medium
CCI
CCI-002314
Version
VRAU-SL-000975
Vuln IDs
  • V-240498
  • V-89773
Rule IDs
  • SV-240498r852559_rule
  • SV-100423
Remote access services, such as those providing remote access to network devices and information systems, which lack automated control capabilities, increase risk and make remote user access management difficult at best. Remote access is access to DoD nonpublic information systems by an authorized user (or an information system) communicating through an external, non-organization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless. Operating system functionality (e.g., RDP) must be capable of taking enforcement action if the audit reveals unauthorized activity. Automated control of remote access sessions allows organizations to ensure ongoing compliance with remote access policies by enforcing connection rules of remote access applications on a variety of information system components (e.g., servers, workstations, notebook computers, smartphones, and tablets).
Checks: C-43731r671233_chk

Check the SSH daemon configuration for listening network addresses: # grep -i Listen /etc/ssh/sshd_config | grep -v '^#' If no configuration is returned, or if a returned "Listen" configuration contains addresses not designated for management traffic, this is a finding.

Fix: F-43690r671234_fix

Edit the SSH daemon configuration /etc/ssh/sshd_config to specify listening network addresses designated for management traffic with the following command: sed -i "/^ListenAddress/ c\ListenAddress x.x.x.x" /etc/ssh/sshd_config Note: Replace x.x.x.x with the desired remote access IP address.

b
The SLES for vRealize must audit all account enabling actions.
AC-2 - Medium - CCI-002130 - V-240499 - SV-240499r852560_rule
RMF Control
AC-2
Severity
Medium
CCI
CCI-002130
Version
VRAU-SL-000995
Vuln IDs
  • V-240499
  • V-89775
Rule IDs
  • SV-240499r852560_rule
  • SV-100425
Once an attacker establishes initial access to a system, the attacker often attempts to create a persistent method of reestablishing access. One way to accomplish this is for the attacker to simply enable a new or disabled account. Notification of account enabling is one method for mitigating this risk. A comprehensive account management process will ensure an audit trail, which documents the creation of operating system user accounts and notifies System Administrators and Information System Security Officers (ISSO) that it exists. Such a process greatly reduces the risk that accounts will be surreptitiously created and provides logging that can be used for forensic purposes. To address access requirements, many operating systems can be integrated with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements.
Checks: C-43732r671236_chk

Determine if execution of the "usermod" and "groupmod" executable are audited: # auditctl -l | egrep '(usermod|groupmod)' If either "usermod" or "groupmod" are not listed with a permissions filter of at least "x", this is a finding. Determine if execution of the "userdel" and "groupdel" executable are audited: # auditctl -l | egrep '(userdel|groupdel)' If either "userdel" or "groupdel" are not listed with a permissions filter of at least "x", this is a finding. Determine if execution of "useradd" and "groupadd" are audited: # auditctl -l | egrep '(useradd|groupadd)' If either "useradd" or "groupadd" are not listed with a permissions filter of at least "x", this is a finding. Determine if execution of the "passwd" executable is audited: # auditctl -l | grep “/usr/bin/passwd” If "/usr/bin/passwd" is not listed with a permissions filter of at least "x", this is a finding. Determine if /etc/passwd, /etc/shadow, /etc/group, and /etc/security/opasswd are audited for writing: # auditctl -l | egrep '(/etc/passwd|/etc/shadow|/etc/group|/etc/security/opasswd)' If any of these are not listed with a permissions filter of at least "w", this is a finding.

Fix: F-43691r671237_fix

Configure "execute" auditing of the "usermod" and "groupmod" executables. Add the following to the /etc/audit/audit.rules file: -w /usr/sbin/usermod -p x -k usermod -w /usr/sbin/groupmod -p x -k groupmod Configure "execute" auditing of the "userdel" and "groupdel" executables. Add the following to the /etc/audit/audit.rules file: -w /usr/sbin/userdel -p x -k userdel -w /usr/sbin/groupdel -p x -k groupdel Configure "execute" auditing of the "useradd" and "groupadd" executables. Add the following to audit.rules: -w /usr/sbin/useradd -p x -k useradd -w /usr/sbin/groupadd -p x -k groupadd Configure "execute" auditing of the "passwd" executable. Add the following to the aud.rules: -w /usr/bin/passwd -p x -k passwd Configure "write" auditing of the "passwd", "shadow", "group", and "opasswd" files. Add the following to the /etc/audit/audit.rules file: -w /etc/passwd -p wa -k passwd -w /etc/shadow -p wa -k shadow -w /etc/group -p wa -k group -w /etc/security/opasswd -p wa -k opasswd Restart the auditd service: # service auditd restart

b
The SLES for vRealize must notify System Administrators and Information System Security Officers when accounts are created, or enabled when previously disabled.
AC-2 - Medium - CCI-002132 - V-240500 - SV-240500r852561_rule
RMF Control
AC-2
Severity
Medium
CCI
CCI-002132
Version
VRAU-SL-001000
Vuln IDs
  • V-240500
  • V-89777
Rule IDs
  • SV-240500r852561_rule
  • SV-100427
Once an attacker establishes initial access to a system, the attacker often attempts to create a persistent method of reestablishing access. One way to accomplish this is for the attacker to simply enable a new or disabled account. Notification of account enabling is one method for mitigating this risk. A comprehensive account management process will ensure an audit trail, which documents the creation of operating system user accounts and notifies System Administrators and Information System Security Officers (ISSO) that it exists. Such a process greatly reduces the risk that accounts will be surreptitiously enabled and provides logging that can be used for forensic purposes. In order to detect and respond to events that affect user accessibility and application processing, operating systems must audit account enabling actions and, as required, notify the appropriate individuals so they can investigate the event. To address access requirements, many operating systems can be integrated with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements.
Checks: C-43733r671239_chk

Determine if execution of the "usermod" and "groupmod" executable are audited: # auditctl -l | egrep '(usermod|groupmod)' If either "usermod" or "groupmod" are not listed with a permissions filter of at least "x", this is a finding. Determine if execution of the "userdel" and "groupdel" executable are audited: # auditctl -l | egrep '(userdel|groupdel)' If either "userdel" or "groupdel" are not listed with a permissions filter of at least "x", this is a finding. Determine if execution of "useradd" and "groupadd" are audited: # auditctl -l | egrep '(useradd|groupadd)' If either "useradd" or "groupadd" are not listed with a permissions filter of at least "x", this is a finding. Determine if execution of the "passwd" executable is audited: # auditctl -l | grep “/usr/bin/passwd” If "/usr/bin/passwd" is not listed with a permissions filter of at least "x", this is a finding. Determine if /etc/passwd, /etc/shadow, /etc/group, and /etc/security/opasswd are audited for writing: # auditctl -l | egrep '(/etc/passwd|/etc/shadow|/etc/group|/etc/security/opasswd)' If any of these are not listed with a permissions filter of at least "w", this is a finding.

Fix: F-43692r671240_fix

Configure "execute" auditing of the "usermod" and "groupmod" executables. Add the following to the /etc/audit/audit.rules file: -w /usr/sbin/usermod -p x -k usermod -w /usr/sbin/groupmod -p x -k groupmod Configure "execute" auditing of the "userdel" and "groupdel" executables. Add the following to the /etc/audit/audit.rules file: -w /usr/sbin/userdel -p x -k userdel -w /usr/sbin/groupdel -p x -k groupdel Configure "execute" auditing of the "useradd" and "groupadd" executables. Add the following to audit.rules: -w /usr/sbin/useradd -p x -k useradd -w /usr/sbin/groupadd -p x -k groupadd Configure "execute" auditing of the "passwd" executable. Add the following to the aud.rules: -w /usr/bin/passwd -p x -k passwd Configure "write" auditing of the "passwd", "shadow", "group", and "opasswd" files. Add the following to the /etc/audit/audit.rules file: -w /etc/passwd -p wa -k passwd -w /etc/shadow -p wa -k shadow -w /etc/group -p wa -k group -w /etc/security/opasswd -p wa -k opasswd Restart the auditd service: # service auditd restart

a
The SLES for vRealize must audit the execution of privileged functions.
AC-6 - Low - CCI-002234 - V-240501 - SV-240501r852562_rule
RMF Control
AC-6
Severity
Low
CCI
CCI-002234
Version
VRAU-SL-001030
Vuln IDs
  • V-240501
  • V-89779
Rule IDs
  • SV-240501r852562_rule
  • SV-100429
Misuse of privileged functions, either intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised information system accounts, is a serious and ongoing concern and can have significant adverse impacts on organizations. Auditing the use of privileged functions is one way to detect such misuse and identify the risk from insider threats and the advanced persistent threat.
Checks: C-43734r671242_chk

To verify that auditing of privileged command use is configured, run the following command to find relevant setuid programs: # find / -xdev -type f -perm -4000 -o -perm -2000 2&gt;/dev/null Run the following command to verify entries in the audit rules for all programs found with the previous command: # grep path /etc/audit/audit.rules It should be the case that all relevant setuid programs have a line in the audit rules. If it is not the case, this is a finding.

Fix: F-43693r671243_fix

At a minimum, the audit system should collect the execution of privileged commands for all users and "root". To find the relevant setuid programs: # find / -xdev -type f -perm -4000 -o -perm -2000 2>/dev/null Then, for each setuid program on the system, add a line of the following form to "/etc/audit/audit.rules", where [SETUID_PROG_PATH] is the full path to each setuid program in the list: -a always,exit -F path=[SETUID_PROG_PATH] -F perm=x -F auid>=500 -k privileged OR # /etc/dodscript.sh

a
The SLES for vRealize must automatically lock an account until the locked account is released by an administrator when three unsuccessful logon attempts in 15 minutes occur.
AC-7 - Low - CCI-002238 - V-240502 - SV-240502r852563_rule
RMF Control
AC-7
Severity
Low
CCI
CCI-002238
Version
VRAU-SL-001035
Vuln IDs
  • V-240502
  • V-89781
Rule IDs
  • SV-240502r852563_rule
  • SV-100431
By limiting the number of failed logon 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.
Checks: C-43735r671245_chk

Check the "pam_tally2" configuration: # more /etc/pam.d/common-auth Confirm the following line is configured: auth required pam_tally2.so deny=3 onerr=fail even_deny_root unlock_time=86400 root_unlock_time=300 # more /etc/pam.d/common-account Confirm the following line is configured: account required pam_tally2.so If no such lines are found, this is a finding.

Fix: F-43694r671246_fix

Edit "/etc/pam.d/common-auth" and add the following line: auth required pam_tally2.so deny=3 onerr=fail even_deny_root unlock_time=86400 root_unlock_time=300 Edit "/etc/pam.d/common-account" and add the following line: account required pam_tally2.so

a
The SLES for vRealize must off-load audit records onto a different system or media from the system being audited.
AU-4 - Low - CCI-001851 - V-240503 - SV-240503r877390_rule
RMF Control
AU-4
Severity
Low
CCI
CCI-001851
Version
VRAU-SL-001060
Vuln IDs
  • V-240503
  • V-89783
Rule IDs
  • SV-240503r877390_rule
  • SV-100433
Information stored in one location is vulnerable to accidental or incidental deletion or alteration. Off-loading is a common process in information systems with limited audit storage capacity.
Checks: C-43736r671248_chk

Check the syslog configuration file for remote syslog servers: # cat /etc/syslog-ng/syslog-ng.conf | grep logserver If no line is returned, or "logserver" is commented out, this is a finding.

Fix: F-43695r671249_fix

Edit the syslog configuration file and add an appropriate remote syslog server: In the /etc/syslog-ng/syslog-ng.conf file, the remote logging entries must be uncommented and the IP address must be modified to point to the remote syslog server: # # Enable this and adopt IP to send log messages to a log server. # destination logserver { udp("x.x.x.x" port(514)); }; log { source(src); destination(logserver); }; Note: Replace x.x.x.x with the appropriate IP address.

b
The SLES for vRealize must immediately notify the SA and ISSO (at a minimum) when allocated audit record storage volume reaches 75% of the repository maximum audit record storage capacity.
AU-5 - Medium - CCI-001855 - V-240504 - SV-240504r877389_rule
RMF Control
AU-5
Severity
Medium
CCI
CCI-001855
Version
VRAU-SL-001065
Vuln IDs
  • V-240504
  • V-89785
Rule IDs
  • SV-240504r877389_rule
  • SV-100435
If security personnel are not notified immediately when storage volume reaches 75% utilization, they are unable to plan for audit record storage capacity expansion.
Checks: C-43737r671251_chk

Check "/etc/audit/auditd.conf" for the" space_left_action" with the following command: # cat /etc/audit/auditd.conf | grep space_left_action If the "space_left_action" parameter is missing, set to "ignore", set to "suspend", set to "single", set to "halt", or is blank, this is a finding. Expected Result: space_left_action = SYSLOG NOTES: If the space_left_action is set to "exec" the system executes a designated script. If this script informs the SA of the event, this is not a finding. If the space_left_action is set to "email" and the "action_mail_acct" parameter is not set to the email address of the system administrator, this is a finding. The "action_mail_acct parameter", if missing, defaults to "root". Note that if the email address of the system administrator is on a remote system "sendmail" must be available.

Fix: F-43696r671252_fix

Set the "space_left_action" parameter to the valid setting "SYSLOG", by running the following command: # sed -i "/^[^#]*space_left_action/ c\admin_space_left_action = SYSLOG" /etc/audit/auditd.conf Restart the audit service: # service auditd restart

b
The SLES for vRealize must provide an immediate real-time alert to the SA and ISSO, at a minimum, of all audit failure events requiring real-time alerts.
AU-5 - Medium - CCI-001858 - V-240505 - SV-240505r852566_rule
RMF Control
AU-5
Severity
Medium
CCI
CCI-001858
Version
VRAU-SL-001070
Vuln IDs
  • V-240505
  • V-89787
Rule IDs
  • SV-240505r852566_rule
  • SV-100437
It is critical for the appropriate personnel to be aware if a system is at risk of failing to process audit logs as required. Without a real-time alert, security personnel may be unaware of an impending failure of the audit capability and system operation may be adversely affected. Alerts provide organizations with urgent messages. Real-time alerts provide these messages immediately (i.e., the time from event detection to alert occurs in seconds or less).
Checks: C-43738r671254_chk

Check "/etc/audit/auditd.conf" for the "space_left_action" with the following command: # cat /etc/audit/auditd.conf | grep space_left_action If the "space_left_action" parameter is missing, set to "ignore", set to "suspend", set to "single", set to "halt", or is blank, this is a finding. Expected Result: space_left_action = SYSLOG NOTES: If the "space_left_action" is set to "exec" the system executes a designated script. If this script informs the SA of the event, this is not a finding. If the "space_left_action" is set to "email" and the "action_mail_acct" parameter is not set to the email address of the system administrator, this is a finding. The "action_mail_acct parameter", if missing, defaults to "root". Note that if the email address of the system administrator is on a remote system "sendmail" must be available.

Fix: F-43697r671255_fix

Set the "space_left_action" parameter to the valid setting "SYSLOG", by running the following command: # sed -i "/^[^#]*space_left_action/ c\admin_space_left_action = SYSLOG" /etc/audit/auditd.conf Restart the audit service: # service auditd restart

b
The SLES for vRealize must, for networked systems, compare internal information system clocks at least every 24 hours with a server which is synchronized to one of the redundant United States Naval Observatory (USNO) time servers, or a time server designated for the appropriate DoD network (NIPRNet/SIPRNet), and/or the Global Positioning System (GPS).
AU-8 - Medium - CCI-001891 - V-240506 - SV-240506r878118_rule
RMF Control
AU-8
Severity
Medium
CCI
CCI-001891
Version
VRAU-SL-001110
Vuln IDs
  • V-240506
  • V-89789
Rule IDs
  • SV-240506r878118_rule
  • SV-100439
Inaccurate time stamps make it more difficult to correlate events and can lead to an inaccurate analysis. Determining the correct time a particular event occurred on a system is critical when conducting forensic analysis and investigating system events. Sources outside the configured acceptable allowance (drift) may be inaccurate. Synchronizing internal information system clocks provides uniformity of time stamps for information systems with multiple system clocks and systems connected over a network. Organizations should consider endpoints that may not have regular access to the authoritative time server (e.g., mobile, teleworking, and tactical endpoints).
Checks: C-43739r671257_chk

A remote NTP server should be configured for time synchronization. To verify one is configured, open the following file: # cat /etc/ntp.conf | grep server | grep -v '^#' # cat /etc/ntp.conf | grep peer | grep -v '^#' # cat /etc/ntp.conf | grep multicastclient | grep -v '^#' Confirm the servers and peers or multicastclient (as applicable) are local or an authoritative U.S. DoD source. If a non-local/non-authoritative time-server is used, this is a finding.

Fix: F-43698r671258_fix

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" by using the following command: # echo "server [ntpserver]" >> /etc/ntp.conf Replace [ntpserver] with one of the USNO time servers. This instructs the NTP software to contact that remote server to obtain time data. Restart the service with: # service ntp restart

b
The time synchronization configuration file (such as /etc/ntp.conf) must be owned by root.
AU-8 - Medium - CCI-001891 - V-240507 - SV-240507r877038_rule
RMF Control
AU-8
Severity
Medium
CCI
CCI-001891
Version
VRAU-SL-001115
Vuln IDs
  • V-240507
  • V-89791
Rule IDs
  • SV-240507r877038_rule
  • SV-100441
A synchronized system clock is critical for the enforcement of time-based policies and the correlation of logs and audit records with other systems. If an illicit time source is used for synchronization, the integrity of system logs and the security of the system could be compromised. If the configuration files controlling time synchronization are not owned by a system account, unauthorized modifications could result in the failure of time synchronization.
Checks: C-43740r671260_chk

Check the ownership of the NTP configuration file: # ls -l /etc/ntp.conf If the owner is not "root", this is a finding.

Fix: F-43699r671261_fix

Change the owner of the NTP configuration file: # chown root /etc/ntp.conf

b
The time synchronization configuration file (such as /etc/ntp.conf) must be group-owned by root, bin, sys, or system.
AU-8 - Medium - CCI-001891 - V-240508 - SV-240508r877038_rule
RMF Control
AU-8
Severity
Medium
CCI
CCI-001891
Version
VRAU-SL-001120
Vuln IDs
  • V-240508
  • V-89793
Rule IDs
  • SV-240508r877038_rule
  • SV-100443
A synchronized system clock is critical for the enforcement of time-based policies and the correlation of logs and audit records with other systems. If an illicit time source is used for synchronization, the integrity of system logs and the security of the system could be compromised. If the configuration files controlling time synchronization are not owned by a system group, unauthorized modifications could result in the failure of time synchronization.
Checks: C-43741r671263_chk

Check the group-ownership of the NTP configuration file: # ls -lL /etc/ntp.conf If the group-owner is not "root", "bin", "sys", or "system", this is a finding.

Fix: F-43700r671264_fix

Change the group-owner of the NTP configuration file: # chgrp root /etc/ntp.conf

b
The time synchronization configuration file (such as /etc/ntp.conf) must have mode 0640 or less permissive.
AU-8 - Medium - CCI-001891 - V-240509 - SV-240509r877038_rule
RMF Control
AU-8
Severity
Medium
CCI
CCI-001891
Version
VRAU-SL-001125
Vuln IDs
  • V-240509
  • V-89795
Rule IDs
  • SV-240509r877038_rule
  • SV-100445
A synchronized system clock is critical for the enforcement of time-based policies and the correlation of logs and audit records with other systems. If an illicit time source is used for synchronization, the integrity of system logs and the security of the system could be compromised. If the configuration files controlling time synchronization are not protected, unauthorized modifications could result in the failure of time synchronization.
Checks: C-43742r671266_chk

Check that the mode for the NTP configuration file is not more permissive than "0640": # ls -l /etc/ntp.conf If the mode is more permissive than "0640", this is a finding.

Fix: F-43701r671267_fix

Change the mode of the NTP configuration file to "0640" or less permissive: # chmod 0640 /etc/ntp.conf

b
The SLES for vRealize must synchronize internal information system clocks to the authoritative time source when the time difference is greater than one second.
AU-8 - Medium - CCI-002046 - V-240510 - SV-240510r852571_rule
RMF Control
AU-8
Severity
Medium
CCI
CCI-002046
Version
VRAU-SL-001130
Vuln IDs
  • V-240510
  • V-89797
Rule IDs
  • SV-240510r852571_rule
  • SV-100447
Inaccurate time stamps make it more difficult to correlate events and can lead to an inaccurate analysis. Determining the correct time a particular event occurred on a system is critical when conducting forensic analysis and investigating system events. Synchronizing internal information system clocks provides uniformity of time stamps for information systems with multiple system clocks and systems connected over a network. Organizations should consider setting time periods for different types of systems (e.g., financial, legal, or mission-critical systems). Organizations should also consider endpoints that may not have regular access to the authoritative time server (e.g., mobile, teleworking, and tactical endpoints). This requirement is related to the comparison done every 24 hours in SRG-OS-000355 because a comparison must be done in order to determine the time difference.
Checks: C-43743r671269_chk

Run the following command to determine the current status of the "ntpd" service: # service ntp status If the service is configured, the command should show a list of the ntp servers and the status of the synchronization. If it does not, this is a finding.

Fix: F-43702r671270_fix

The "ntp" service can be enabled with the following command: # chkconfig ntp on # service ntp start Configure the time server for the authoritative time source with the following steps: 1. Edit /etc/ntp.conf and locate the "server" entry. 2. Replace the address with the address of the authoritative time source. 3. Save the /etc/ntp.conf file. 4. Restart the ntp daemon with /etc/init.d/ntp start.

b
The SLES for vRealize must audit the enforcement actions used to restrict access associated with changes to the system.
CM-5 - Medium - CCI-001814 - V-240511 - SV-240511r852572_rule
RMF Control
CM-5
Severity
Medium
CCI
CCI-001814
Version
VRAU-SL-001165
Vuln IDs
  • V-240511
  • V-89799
Rule IDs
  • SV-240511r852572_rule
  • SV-100449
Without auditing the enforcement of access restrictions against changes to the application configuration, it will be difficult to identify attempted attacks and an audit trail will not be available for forensic investigation for after-the-fact actions. Enforcement actions are the methods or mechanisms used to prevent unauthorized changes to configuration settings. Enforcement action methods may be as simple as denying access to a file based on the application of file permissions (access restriction). Audit items may consist of lists of actions blocked by access restrictions or changes identified after the fact.
Checks: C-43744r671272_chk

Verify the SLES for vRealize produces audit records by running the following command to determine the current status of the "auditd" service: # service auditd status If the service is enabled, the returned message must contain the following text: Checking for service auditd running If the service is not "running", this is a finding.

Fix: F-43703r671273_fix

Enable the "auditd" service by performing the following commands: # chkconfig auditd on # service auditd start

b
The RPM package management tool must cryptographically verify the authenticity of all software packages during installation.
CM-5 - Medium - CCI-001749 - V-240512 - SV-240512r877463_rule
RMF Control
CM-5
Severity
Medium
CCI
CCI-001749
Version
VRAU-SL-001170
Vuln IDs
  • V-240512
  • V-89801
Rule IDs
  • SV-240512r877463_rule
  • SV-100451
Changes to any software components can have significant effects on the overall security of the operating system. This requirement ensures the software has not been tampered with and that it has been provided by a trusted vendor. Accordingly, patches, service packs, device drivers, or operating system components must be signed with a certificate recognized and approved by the organization. Verifying the authenticity of the software prior to installation validates the integrity of the patch or upgrade received from a vendor. This ensures the software has not been tampered with and that it has been provided by a trusted vendor. Self-signed certificates are disallowed by this requirement. The operating system should not have to verify the software again. This requirement does not mandate DoD certificates for this purpose; however, the certificate used to verify the software must be from an approved CA.
Checks: C-43745r671275_chk

Verify RPM signature validation is not disabled: # grep nosignature /usr/lib/rpm/rpmrc ~root/.rpmrc The result should either respond with no such file or directory, or an empty return. If any configuration is found, this is a finding.

Fix: F-43704r671276_fix

Edit the RPM configuration files containing the "nosignature" option and remove the option.

b
The SLES for vRealize must audit all activities performed during nonlocal maintenance and diagnostic sessions.
MA-4 - Medium - CCI-002884 - V-240513 - SV-240513r852574_rule
RMF Control
MA-4
Severity
Medium
CCI
CCI-002884
Version
VRAU-SL-001245
Vuln IDs
  • V-240513
  • V-89803
Rule IDs
  • SV-240513r852574_rule
  • SV-100453
If events associated with nonlocal administrative access or diagnostic sessions are not logged, a major tool for assessing and investigating attacks would not be available. This requirement addresses auditing-related issues associated with maintenance tools used specifically for diagnostic and repair actions on organizational information systems. Nonlocal 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. Local maintenance and diagnostic activities are those activities carried out by individuals physically present at the information system or information system component and not communicating across a network connection. This requirement applies to hardware/software diagnostic test equipment or tools. This requirement does not cover hardware/software components that may support information system maintenance, yet are a part of the system, for example, the software implementing "ping," "ls," "ipconfig," or the hardware and software implementing the monitoring port of an Ethernet switch.
Checks: C-43746r671278_chk

Verify that all commands run by "root" are being audited with the following command: # cat /etc/audit/audit.rules | grep execve If the following lines are not displayed, this is a finding. -a exit,always -F arch=b64 -F euid=0 -S execve -a exit,always -F arch=b32 -F euid=0 -S execve

Fix: F-43705r671279_fix

Configure the system to log all commands run by "root" with the following command: # echo "-a exit,always -F arch=b64 -F euid=0 -S execve" >> /etc/audit/audit.rules # echo "-a exit,always -F arch=b32 -F euid=0 -S execve" >> /etc/audit/audit.rules Restart the audit service: # service auditd restart

b
The SLES for vRealize must implement cryptographic mechanisms to protect the integrity of nonlocal maintenance and diagnostic communications, when used for nonlocal maintenance sessions.
MA-4 - Medium - CCI-002890 - V-240514 - SV-240514r877382_rule
RMF Control
MA-4
Severity
Medium
CCI
CCI-002890
Version
VRAU-SL-001250
Vuln IDs
  • V-240514
  • V-89805
Rule IDs
  • SV-240514r877382_rule
  • SV-100455
Privileged access contains control and configuration information and is particularly sensitive, so additional protections are necessary. This is maintained by using cryptographic mechanisms, such as a hash function or digital signature, to protect integrity. Nonlocal 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. Local maintenance and diagnostic activities are those activities carried out by individuals physically present at the information system or information system component and not communicating across a network connection. The operating system can meet this requirement through leveraging a cryptographic module. This requirement does not cover hardware/software components that may support information system maintenance, yet are a part of the system (e.g., the software implementing "ping," "ls," "ipconfig," or the hardware and software implementing the monitoring port of an Ethernet switch).
Checks: C-43747r671281_chk

Check the SSH daemon configuration for DoD-approved encryption to protect the confidentiality of SSH remote connections by performing the following commands: Check the "Ciphers" setting in the "sshd_config" file. # grep -i Ciphers /etc/ssh/sshd_config | grep -v '#' The output must contain either nothing or any number of the following algorithms: aes128-ctr, aes256-ctr. If the output contains an algorithm not listed above, this is a finding. Expected Output: Ciphers aes256-ctr,aes128-ctr

Fix: F-43706r671282_fix

Update the "Ciphers" directive with the following command: # sed -i '/^[^#]*Ciphers/ c\Ciphers aes256-ctr,aes128-ctr' /etc/ssh/sshd_config Save and close the file. Restart the sshd process: # service sshd restart

b
The SLES for vRealize must implement cryptographic mechanisms to protect the confidentiality of nonlocal maintenance and diagnostic communications, when used for nonlocal maintenance sessions.
MA-4 - Medium - CCI-003123 - V-240515 - SV-240515r877381_rule
RMF Control
MA-4
Severity
Medium
CCI
CCI-003123
Version
VRAU-SL-001255
Vuln IDs
  • V-240515
  • V-89807
Rule IDs
  • SV-240515r877381_rule
  • SV-100457
Privileged access contains control and configuration information and is particularly sensitive, so additional protections are necessary. This is maintained by using cryptographic mechanisms such as encryption to protect confidentiality. Nonlocal 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. Local maintenance and diagnostic activities are those activities carried out by individuals physically present at the information system or information system component and not communicating across a network connection. This requirement applies to hardware/software diagnostic test equipment or tools. This requirement does not cover hardware/software components that may support information system maintenance, yet are a part of the system (e.g., the software implementing "ping," "ls," "ipconfig," or the hardware and software implementing the monitoring port of an Ethernet switch). The operating system can meet this requirement through leveraging a cryptographic module.
Checks: C-43748r671284_chk

Check the SSH daemon configuration for allowed MACs: # grep -i macs /etc/ssh/sshd_config | grep -v '^#' If no lines are returned, or the returned MACs list contains any MAC other than "hmac-sha1", this is a finding.

Fix: F-43707r671285_fix

Edit the SSH daemon configuration and remove any MACs other than "hmac-sha1". If necessary, add a "MACs" line. # sed -i "/^[^#]*MACs/ c\MACs hmac-sha1" /etc/ssh/sshd_config

c
The SLES for vRealize must implement NSA-approved cryptography to protect classified information in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards.
SC-13 - High - CCI-002450 - V-240516 - SV-240516r877380_rule
RMF Control
SC-13
Severity
High
CCI
CCI-002450
Version
VRAU-SL-001265
Vuln IDs
  • V-240516
  • V-89809
Rule IDs
  • SV-240516r877380_rule
  • SV-100459
Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. The operating system must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated.
Checks: C-43749r671287_chk

Check the SSH daemon configuration for DoD-approved encryption to protect the confidentiality of SSH remote connections by performing the following commands: Check the "Ciphers" setting in the "sshd_config" file. # grep -i Ciphers /etc/ssh/sshd_config | grep -v '#' The output must contain either nothing or any number of the following algorithms: aes128-ctr, aes256-ctr. If the output contains an algorithm not listed above, this is a finding. Expected Output: Ciphers aes256-ctr,aes128-ctr

Fix: F-43708r671288_fix

Update the "Ciphers" directive with the following command: # sed -i "/^[^#]*Ciphers/ c\Ciphers aes256-ctr,aes128-ctr" /etc/ssh/sshd_config Save and close the file. Restart the sshd process: # service sshd restart

c
The SLES for vRealize must protect against or limit the effects of Denial of Service (DoS) attacks by ensuring the SLES for vRealize is implementing rate-limiting measures on impacted network interfaces.
SC-5 - High - CCI-002385 - V-240517 - SV-240517r852578_rule
RMF Control
SC-5
Severity
High
CCI
CCI-002385
Version
VRAU-SL-001305
Vuln IDs
  • V-240517
  • V-89811
Rule IDs
  • SV-240517r852578_rule
  • SV-100461
DoS is a condition when a resource is not available for legitimate users. When this occurs, the organization either cannot accomplish its mission or must operate at degraded capacity. This requirement addresses the configuration of the operating system to mitigate the impact of DoS attacks that have occurred or are ongoing on system availability. For each system, known and potential DoS attacks must be identified and solutions for each type implemented. A variety of technologies exist to limit or, in some cases, eliminate the effects of DoS attacks (e.g., limiting processes or establishing memory partitions). Employing increased capacity and bandwidth, combined with service redundancy, may reduce the susceptibility to some DoS attacks.
Checks: C-43750r671290_chk

Check that the system configured to use TCP syncookies when experiencing a TCP SYN flood. # cat /proc/sys/net/ipv4/tcp_syncookies If the result is not "1", this is a finding.

Fix: F-43709r671291_fix

Configure the system to use TCP syncookies when experiencing a TCP SYN flood. Check for the presence of "net.ipv4.tcp_syncookies" in the /etc/sysctl.conf file: # grep "net.ipv4.tcp_syncookies" /etc/sysctl.conf If it exists, change the value to "1". If it does not exist, add a setting for tcp_syncookies: # echo "net.ipv4.tcp_syncookies=1" >> /etc/sysctl.conf Reload sysctl to verify the new change: # sysctl -p

c
The SLES for vRealize must protect the confidentiality and integrity of transmitted information.
SC-8 - High - CCI-002418 - V-240518 - SV-240518r916422_rule
RMF Control
SC-8
Severity
High
CCI
CCI-002418
Version
VRAU-SL-001310
Vuln IDs
  • V-240518
  • V-89813
Rule IDs
  • SV-240518r916422_rule
  • SV-100463
Without protection of the transmitted information, confidentiality and integrity may be compromised because unprotected communications can be intercepted and either read or altered. This requirement applies to both internal and external networks and all types of information system components from which information can be transmitted (e.g., servers, mobile devices, notebook computers, printers, copiers, scanners, and facsimile machines). Communication paths outside the physical protection of a controlled boundary are exposed to the possibility of interception and modification. Protecting the confidentiality and integrity of organizational information can be accomplished by physical means (e.g., employing physical distribution systems) or by logical means (e.g., employing cryptographic techniques). If physical means of protection are employed, then logical means (cryptography) do not have to be employed, and vice versa.
Checks: C-43751r671293_chk

Check the SSH daemon configuration for DoD-approved encryption to protect the confidentiality of SSH remote connections by performing the following commands: Check the "Ciphers" setting in the "sshd_config" file. # grep -i Ciphers /etc/ssh/sshd_config | grep -v '#' The output must contain either nothing or any number of the following algorithms: aes128-ctr, aes256-ctr. If the output contains an algorithm not listed above, this is a finding. Expected Output: Ciphers aes256-ctr,aes128-ctr

Fix: F-43710r671294_fix

Update the "Ciphers" directive with the following command: # sed -i "/^[^#]*Ciphers/ c\Ciphers aes256-ctr,aes128-ctr" /etc/ssh/sshd_config Save and close the file. Restart the sshd process: # service sshd restart

c
The SLES for vRealize must implement cryptographic mechanisms to prevent unauthorized disclosure of information and/or detect changes to information during transmission unless otherwise protected by alternative physical safeguards, such as, at a minimum, a Protected Distribution System (PDS).
SC-8 - High - CCI-002421 - V-240519 - SV-240519r878119_rule
RMF Control
SC-8
Severity
High
CCI
CCI-002421
Version
VRAU-SL-001315
Vuln IDs
  • V-240519
  • V-89815
Rule IDs
  • SV-240519r878119_rule
  • SV-100465
Encrypting information for transmission protects information from unauthorized disclosure and modification. Cryptographic mechanisms implemented to protect information integrity include, for example, cryptographic hash functions that have common application in digital signatures, checksums, and message authentication codes. Use of this requirement will be limited to situations where the data owner has a strict requirement for ensuring data integrity and confidentiality is maintained at every step of the data transfer and handling process. When transmitting data, operating systems need to leverage transmission protection mechanisms such as TLS, SSL VPNs, or IPsec. Alternative physical protection measures include PDS. PDSs are used to transmit unencrypted classified National Security Information (NSI) through an area of lesser classification or control. Since the classified NSI is unencrypted, the PDS must provide adequate electrical, electromagnetic, and physical safeguards to deter exploitation.
Checks: C-43752r671296_chk

Check the SSH daemon configuration for allowed MACs: # grep -i macs /etc/ssh/sshd_config | grep -v '^#' If no lines are returned, or the returned MACs list contains any MAC other than "hmac-sha1", this is a finding.

Fix: F-43711r671297_fix

Edit the SSH daemon configuration and remove any MACs other than "hmac-sha1". If necessary, add a "MACs" line.

b
The SLES for vRealize must implement non-executable data to protect its memory from unauthorized code execution.
SI-16 - Medium - CCI-002824 - V-240520 - SV-240520r852581_rule
RMF Control
SI-16
Severity
Medium
CCI
CCI-002824
Version
VRAU-SL-001335
Vuln IDs
  • V-240520
  • V-89817
Rule IDs
  • SV-240520r852581_rule
  • SV-100467
Some adversaries launch attacks with the intent of executing code in non-executable regions of memory or in memory locations that are prohibited. Security safeguards employed to protect memory include, for example, data execution prevention and address space layout randomization. Data execution prevention safeguards can either be hardware-enforced or software-enforced with hardware providing the greater strength of mechanism. Examples of attacks are buffer overflow attacks.
Checks: C-43753r671299_chk

The stock kernel has support for non-executable program stacks compiled in by default. Verify that the option was specified when the kernel was built: # grep -i "execute" /var/log/boot.msg The message: "NX (Execute Disable) protection: active" will be written in the boot log when compiled in the kernel. This is the default for x86_64. To activate this support, the “noexec=on” kernel parameter must be specified at boot time. Check for a message with the following command: # grep –i "noexec" /var/log/boot.msg The message: "Kernel command line: &lt;boot parameters&gt; noexec=on" will be written to the boot log when properly appended to the /boot/grub/menu.lst file. If non-executable program stacks have not been configured, this is a finding.

Fix: F-43712r671300_fix

Edit the /boot/grub/menu.lst file and add “noexec=on” to the end of each kernel line entry. A system restart is required to implement this change.

b
The SLES for vRealize must implement address space layout randomization to protect its memory from unauthorized code execution.
SI-16 - Medium - CCI-002824 - V-240521 - SV-240521r852582_rule
RMF Control
SI-16
Severity
Medium
CCI
CCI-002824
Version
VRAU-SL-001340
Vuln IDs
  • V-240521
  • V-89819
Rule IDs
  • SV-240521r852582_rule
  • SV-100469
Some adversaries launch attacks with the intent of executing code in non-executable regions of memory or in memory locations that are prohibited. Security safeguards employed to protect memory include, for example, data execution prevention and address space layout randomization. Data execution prevention safeguards can either be hardware-enforced or software-enforced with hardware providing the greater strength of mechanism. Examples of attacks are buffer overflow attacks.
Checks: C-43754r671302_chk

Verify "randomize_va_space" has not been changed from the default "1" setting. # sysctl kernel.randomize_va_space If the return value is not "kernel.randomize_va_space = 1", this is a finding.

Fix: F-43713r671303_fix

Run the following command: #sysctl kernel.randomize_va_space=1

b
The SLES for vRealize must verify correct operation of all security functions.
SI-6 - Medium - CCI-002696 - V-240522 - SV-240522r852583_rule
RMF Control
SI-6
Severity
Medium
CCI
CCI-002696
Version
VRAU-SL-001350
Vuln IDs
  • V-240522
  • V-89821
Rule IDs
  • SV-240522r852583_rule
  • SV-100471
Without verification of the security functions, security functions may not operate correctly and the failure may go unnoticed. Security function is defined as the hardware, software, and/or firmware of the information system responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based. Security functionality includes, but is not limited to, establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters. This requirement applies to operating systems performing security function verification/testing and/or systems and environments that require this functionality.
Checks: C-43755r671305_chk

Verify the SLES for vRealize produces audit records by running the following command to determine the current status of the "auditd" service: # service auditd status If the service is enabled, the returned message must contain the following text: Checking for service auditd running If the service is not "running", this is a finding.

Fix: F-43714r671306_fix

Enable the "auditd" service by performing the following commands: # chkconfig auditd on # service auditd start

b
The SLES for vRealize must generate audit records when successful/unsuccessful attempts to access security objects occur.
AU-12 - Medium - CCI-000172 - V-240523 - SV-240523r671310_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
VRAU-SL-001365
Vuln IDs
  • V-240523
  • V-89823
Rule IDs
  • SV-240523r671310_rule
  • SV-100473
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter).
Checks: C-43756r671308_chk

To verify that auditing is configured for system administrator actions, run the following command: # auditctl -l | grep "watch=/etc/sudoers" The result should return a rule for sudoers, such as: LIST_RULES: exit,always watch=/etc/sudoers perm=wa key=sudoers If there is no output, this is a finding.

Fix: F-43715r671309_fix

At a minimum, the audit system should collect administrator actions for all users and "root". Add the following to "/etc/audit/audit.rules": -w /etc/sudoers -p wa -k sudoers OR # /etc/dodscript.sh

b
The SLES for vRealize must generate audit records when successful/unsuccessful attempts to modify privileges occur.
AU-12 - Medium - CCI-000172 - V-240524 - SV-240524r671313_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
VRAU-SL-001375
Vuln IDs
  • V-240524
  • V-89825
Rule IDs
  • SV-240524r671313_rule
  • SV-100475
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter).
Checks: C-43757r671311_chk

To determine if the system is configured to audit calls to the "chmod" system call, run the following command: # auditctl -l | grep syscall | grep chmod If the system is configured to audit this activity, it will return several lines, such as: LIST_RULES: exit,always arch=3221225534 (0xc000003e) auid=0 syscall=chmod,fchmod,chown,fchown,fchownat,fchmodat LIST_RULES: exit,always arch=3221225534 (0xc000003e) auid&gt;=500 (0x1f4) auid!=-1 (0xffffffff) syscall=chmod,fchmod,chown,fchown,fchownat,fchmodat LIST_RULES: exit,always arch=1073741827 (0x40000003) syscall=chmod,lchown,sethostname,fchmod,fchown,adjtimex,init_module,delete_module,chown,lchown32,fchown32,chown32,setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr,clock_settime,fchownat,fchmodat If no lines are returned, this is a finding.

Fix: F-43716r671312_fix

At a minimum, the audit system should collect file permission changes for all users and "root". Add the following to "/etc/audit/audit.rules": -a always,exit -F arch=b64 -S chmod -F auid=0 -a always,exit -F arch=b64 -S chmod -F auid>=500 -F auid!=4294967295 -a always,exit -F arch=b32 -S chmod OR # /etc/dodscript.sh

b
The SLES for vRealize must generate audit records when successful/unsuccessful attempts to modify security objects occur.
AU-12 - Medium - CCI-000172 - V-240525 - SV-240525r671316_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
VRAU-SL-001380
Vuln IDs
  • V-240525
  • V-89827
Rule IDs
  • SV-240525r671316_rule
  • SV-100477
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter).
Checks: C-43758r671314_chk

To verify that auditing is configured for system administrator actions, run the following command: # auditctl -l | grep "watch=/etc/sudoers" The result should return a rule for sudoers, such as: LIST_RULES: exit,always watch=/etc/sudoers perm=wa key=sudoers If there is no output, this is a finding.

Fix: F-43717r671315_fix

At a minimum, the audit system should collect administrator actions for all users and "root". Add the following to "/etc/audit/audit.rules": -w /etc/sudoers -p wa -k sudoers OR # /etc/dodscript.sh

b
The SLES for vRealize must generate audit records when successful/unsuccessful attempts to delete privileges occur.
AU-12 - Medium - CCI-000172 - V-240526 - SV-240526r671319_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
VRAU-SL-001390
Vuln IDs
  • V-240526
  • V-89829
Rule IDs
  • SV-240526r671319_rule
  • SV-100479
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter).
Checks: C-43759r671317_chk

To determine if the system is configured to audit calls to the "chmod" system call, run the following command: # auditctl -l | grep syscall | grep chmod If the system is configured to audit this activity, it will return several lines, such as: LIST_RULES: exit,always arch=3221225534 (0xc000003e) auid=0 syscall=chmod,fchmod,chown,fchown,fchownat,fchmodat LIST_RULES: exit,always arch=3221225534 (0xc000003e) auid&gt;=500 (0x1f4) auid!=-1 (0xffffffff) syscall=chmod,fchmod,chown,fchown,fchownat,fchmodat LIST_RULES: exit,always arch=1073741827 (0x40000003) syscall=chmod,lchown,sethostname,fchmod,fchown,adjtimex,init_module,delete_module,chown,lchown32,fchown32,chown32,setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr,clock_settime,fchownat,fchmodat If no lines are returned, this is a finding.

Fix: F-43718r671318_fix

At a minimum, the audit system should collect file permission changes for all users and "root". Add the following to "/etc/audit/audit.rules": -a always,exit -F arch=b64 -S chmod -F auid=0 -a always,exit -F arch=b64 -S chmod -F auid>=500 -F auid!=4294967295 -a always,exit -F arch=b32 -S chmod OR # /etc/dodscript.sh

b
The SLES for vRealize must generate audit records when successful/unsuccessful attempts to delete security objects occur.
AU-12 - Medium - CCI-000172 - V-240527 - SV-240527r671322_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
VRAU-SL-001400
Vuln IDs
  • V-240527
  • V-89831
Rule IDs
  • SV-240527r671322_rule
  • SV-100481
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter).
Checks: C-43760r671320_chk

To verify that auditing is configured for system administrator actions, run the following command: # auditctl -l | grep "watch=/etc/sudoers" The result should return a rule for sudoers, such as: LIST_RULES: exit,always watch=/etc/sudoers perm=wa key=sudoers If there is no output, this is a finding.

Fix: F-43719r671321_fix

At a minimum, the audit system should collect administrator actions for all users and "root". Add the following to "/etc/audit/audit.rules": -w /etc/sudoers -p wa -k sudoers OR # /etc/dodscript.sh

b
The SLES for vRealize must generate audit records when successful/unsuccessful logon attempts occur.
AU-12 - Medium - CCI-000172 - V-240528 - SV-240528r671325_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
VRAU-SL-001405
Vuln IDs
  • V-240528
  • V-89833
Rule IDs
  • SV-240528r671325_rule
  • SV-100483
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter).
Checks: C-43761r671323_chk

The message types that are always recorded to /var/log/audit/audit.log include "LOGIN", "USER_LOGIN", "USER_START", "USER_END" among others and do not need to be added to audit.rules. The log files /var/log/faillog, /var/log/lastlog, and /var/log/tallylog must be protected from tampering of the logon records: # egrep "faillog|lastlog|tallylog" /etc/audit/audit.rules If /var/log/faillog, /var/log/lastlog, and /var/log/tallylog entries do not exist, this is a finding.

Fix: F-43720r671324_fix

Ensure the auditing of logons by modifying /etc/audit/audit.rules to contain: -w /var/log/faillog -p wa -w /var/log/lastlog -p wa -w /var/log/tallylog -p wa OR # /etc/dodscript.sh

b
The SLES for vRealize must generate audit records for privileged activities or other system-level access.
AU-12 - Medium - CCI-000172 - V-240529 - SV-240529r671328_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
VRAU-SL-001410
Vuln IDs
  • V-240529
  • V-89835
Rule IDs
  • SV-240529r671328_rule
  • SV-100485
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter).
Checks: C-43762r671326_chk

To verify that auditing of privileged command use is configured, run the following command to find relevant setuid programs: # find / -xdev -type f -perm -4000 -o -perm -2000 2&gt;/dev/null Run the following command to verify entries in the audit rules for all programs found with the previous command: # grep path /etc/audit/audit.rules It should be the case that all relevant setuid programs have a line in the audit rules. If it is not the case, this is a finding.

Fix: F-43721r671327_fix

At a minimum, the audit system should collect the execution of privileged commands for all users and root. To find the relevant setuid programs: # find / -xdev -type f -perm -4000 -o -perm -2000 2>/dev/null Then, for each setuid program on the system, add a line of the following form to "/etc/audit/audit.rules", where [SETUID_PROG_PATH] is the full path to each setuid program in the list: -a always,exit -F path=[SETUID_PROG_PATH] -F perm=x -F auid>=500 -k privileged OR # /etc/dodscript.sh

b
The SLES for vRealize audit system must be configured to audit the loading and unloading of dynamic kernel modules.
AU-12 - Medium - CCI-000172 - V-240530 - SV-240530r671331_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
VRAU-SL-001415
Vuln IDs
  • V-240530
  • V-89837
Rule IDs
  • SV-240530r671331_rule
  • SV-100487
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter).
Checks: C-43763r671329_chk

Determine if "/sbin/insmod" is audited: # cat /etc/audit/audit.rules | grep "/sbin/insmod" If the result does not start with "-w" and contain "-p x", this is a finding.

Fix: F-43722r671330_fix

Add the following to "/etc/audit/audit.rules" in order to capture kernel module loading and unloading events: -w /sbin/insmod -p x OR # /etc/dodscript.sh

b
The SLES for vRealize must generate audit records showing starting and ending time for user access to the system.
AU-12 - Medium - CCI-000172 - V-240531 - SV-240531r671334_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
VRAU-SL-001420
Vuln IDs
  • V-240531
  • V-89839
Rule IDs
  • SV-240531r671334_rule
  • SV-100489
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter).
Checks: C-43764r671332_chk

The message types that are always recorded to /var/log/audit/audit.log include "LOGIN", "USER_LOGIN", "USER_START", "USER_END" among others and do not need to be added to audit.rules. The log files /var/log/faillog, /var/log/lastlog, and /var/log/tallylog must be protected from tampering of the logon records: # egrep "faillog|lastlog|tallylog" /etc/audit/audit.rules If /var/log/faillog, /var/log/lastlog, and /var/log/tallylog entries do not exist, this is a finding.

Fix: F-43723r671333_fix

Ensure the auditing of logons by modifying /etc/audit/audit.rules to contain: -w /var/log/faillog -p wa -w /var/log/lastlog -p wa -w /var/log/tallylog -p wa OR... # /etc/dodscript.sh

b
The SLES for vRealize must generate audit records when concurrent logons to the same account occur from different sources.
AU-12 - Medium - CCI-000172 - V-240532 - SV-240532r671337_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
VRAU-SL-001425
Vuln IDs
  • V-240532
  • V-89841
Rule IDs
  • SV-240532r671337_rule
  • SV-100491
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter).
Checks: C-43765r671335_chk

The message types that are always recorded to /var/log/audit/audit.log include "LOGIN", "USER_LOGIN", "USER_START", "USER_END" among others and do not need to be added to audit.rules. The log files /var/log/faillog, /var/log/lastlog, and /var/log/tallylog must be protected from tampering of the logon records: # egrep "faillog|lastlog|tallylog" /etc/audit/audit.rules If /var/log/faillog, /var/log/lastlog, and /var/log/tallylog entries do not exist, this is a finding.

Fix: F-43724r671336_fix

Ensure the auditing of logons by modifying /etc/audit/audit.rules to contain: -w /var/log/faillog -p wa -w /var/log/lastlog -p wa -w /var/log/tallylog -p wa OR... # /etc/dodscript.sh

b
The SLES for vRealize must generate audit records when successful/unsuccessful accesses to objects occur.
AU-12 - Medium - CCI-000172 - V-240533 - SV-240533r671340_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
VRAU-SL-001430
Vuln IDs
  • V-240533
  • V-89843
Rule IDs
  • SV-240533r671340_rule
  • SV-100493
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter).
Checks: C-43766r671338_chk

Verify the SLES for vRealize produces audit records by running the following command to determine the current status of the "auditd" service: # service auditd status If the service is "enabled", the returned message must contain the following text: Checking for service auditd running If the service is not "running", this is a finding.

Fix: F-43725r671339_fix

Enable the "auditd" service by performing the following commands: # chkconfig auditd on # service auditd start

b
The SLES for vRealize audit system must be configured to audit failed attempts to access files and programs.
AU-12 - Medium - CCI-000172 - V-240534 - SV-240534r671343_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
VRAU-SL-001440
Vuln IDs
  • V-240534
  • V-89845
Rule IDs
  • SV-240534r671343_rule
  • SV-100495
Unsuccessful attempts to access files could be an indicator of malicious activity on a system. Auditing these events could serve as evidence of potential system compromise.
Checks: C-43767r671341_chk

Verify auditd is configured to audit failed file access attempts. There must be both an "-F exit=-EPERM" and "-F exit=-EACCES" for each access syscall: # cat /etc/audit.rules /etc/audit/audit.rules | grep -e "-a exit,always" | grep -e "-S open" | grep -e "-F exit=-EPERM" # cat /etc/audit.rules /etc/audit/audit.rules | grep -e "-a exit,always" | grep -e "-S open" | grep -e "-F exit=-EACCES" There must be both an "-F exit=-EPERM" and "-F exit=-EACCES" for each access syscall. If not, this is a finding.

Fix: F-43726r671342_fix

Edit the audit.rules file and add the following line(s) to enable auditing of failed attempts to access files and programs: -a exit,always -F arch=b64 -S open -F exit=-EPERM -a exit,always -F arch=b64 -S open -F exit=-EACCES -a exit,always -F arch=b32 -S open -F exit=-EPERM -a exit,always -F arch=b32 -S open -F exit=-EACCES

b
The SLES for vRealize audit system must be configured to audit failed attempts to access files and programs.
AU-12 - Medium - CCI-000172 - V-240535 - SV-240535r671346_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
VRAU-SL-001455
Vuln IDs
  • V-240535
  • V-89847
Rule IDs
  • SV-240535r671346_rule
  • SV-100497
Unsuccessful attempts to access files could be an indicator of malicious activity on a system. Auditing these events could serve as evidence of potential system compromise.
Checks: C-43768r671344_chk

Verify auditd is configured to audit failed file access attempts. # cat /etc/audit.rules /etc/audit/audit.rules | grep -e "-a exit,always" | grep -e "-S ftruncate" | grep -e "-F success=0" There must be an audit rule for each of the access syscalls logging all failed accesses (-F success=0). If not, this is a finding.

Fix: F-43727r671345_fix

Edit the audit.rules file and add the following line(s) to enable auditing of failed attempts to access files and programs: -a exit,always -F arch=b64 -S ftruncate -F success=0 -a exit,always -F arch=b32 -S ftruncate -F success=0

b
The SLES for vRealize audit system must be configured to audit user deletions of files and programs.
AU-12 - Medium - CCI-000172 - V-240536 - SV-240536r671349_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
VRAU-SL-001460
Vuln IDs
  • V-240536
  • V-89849
Rule IDs
  • SV-240536r671349_rule
  • SV-100499
Auditing file deletions will create an audit trail for files that are removed from the system. The audit trail could aid in system troubleshooting, as well as detecting malicious processes that attempt to delete log files to conceal their presence.
Checks: C-43769r671347_chk

To determine if the system is configured to audit calls to the "unlink" system call, run the following command: # auditctl -l | grep syscall | grep unlink | grep -v unlinkat If the system is configured to audit this activity, it will return several lines. If it does not, this is a finding. To determine if the system is configured to audit calls to the "unlinkat" system call, run the following command: # auditctl -l | grep syscall | grep unlinkat If the system is configured to audit this activity, it will return several lines. If it does not, this is a finding. To determine if the system is configured to audit calls to the "rename" system call, run the following command: # auditctl -l | grep syscall | grep rename | grep -v renameat If the system is configured to audit this activity, it will return several lines. If it does not, this is a finding. To determine if the system is configured to audit calls to the "renameat" system call, run the following command: # auditctl -l | grep syscall | grep renameat If the system is configured to audit this activity, it will return several lines. If it does not, this is a finding.

Fix: F-43728r671348_fix

Edit the audit.rules file and add the following line(s) to enable auditing of deletions of files and programs: -a always,exit -F arch=b64 -S unlink -S unlinkat -S rename -S renameat -F auid=0 -a always,exit -F arch=b64 -S unlink -S unlinkat -S rename -S renameat -F auid>=500 -F auid!=4294967295 -a always,exit -F arch=b32 -S unlink -S unlinkat -S rename -S renameat -F auid=0 -a always,exit -F arch=b32 -S unlink -S unlinkat -S rename -S renameat -F auid>=500 -F auid!=4294967295

b
The SLES for vRealize audit system must be configured to audit file deletions.
AU-12 - Medium - CCI-000172 - V-240537 - SV-240537r671352_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
VRAU-SL-001465
Vuln IDs
  • V-240537
  • V-89851
Rule IDs
  • SV-240537r671352_rule
  • SV-100501
If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise.
Checks: C-43770r671350_chk

Check the system audit configuration to determine if file and directory deletions are audited: # cat /etc/audit.rules /etc/audit/audit.rules | grep -e "-a exit,always" | grep -i "rmdir" If no results are returned, or the results do not contain "-S rmdir", this is a finding.

Fix: F-43729r671351_fix

Add the following to "/etc/audit/audit.rules" in order to capture file and directory deletion events: -a always,exit -F arch=b64 -S rmdir -S rm -a always,exit -F arch=b32 -S rmdir -S rm

b
SLES for vRealize audit logs must be rotated daily.
AU-12 - Medium - CCI-000172 - V-240538 - SV-240538r671355_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
VRAU-SL-001470
Vuln IDs
  • V-240538
  • V-89853
Rule IDs
  • SV-240538r671355_rule
  • SV-100503
Rotate audit logs daily to preserve audit file system space and to conform to the DISA requirement. If it is not rotated daily and moved to another location, then there is more of a chance for the compromise of audit data by malicious users.
Checks: C-43771r671353_chk

Check for a "logrotate" entry that rotates audit logs. # ls -l /etc/logrotate.d/audit If it exists, check for the presence of the "daily" rotate flag: # egrep "daily" /etc/logrotate.d/audit The command should produce a "daily" entry in the logrotate file for the audit daemon. If the "daily" entry is missing, this is a finding.

Fix: F-43730r671354_fix

Create or edit the /etc/logrotate.d/audit file and add the "daily" entry, such as: /var/log/audit/audit.log { compress dateext rotate 15 daily missingok notifempty create 600 root root sharedscripts postrotate /sbin/service auditd restart 2> /dev/null > /dev/null || true endscript }

b
The SLES for vRealize must generate audit records for all direct access to the information system.
AU-12 - Medium - CCI-000172 - V-240539 - SV-240539r671358_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
VRAU-SL-001475
Vuln IDs
  • V-240539
  • V-89855
Rule IDs
  • SV-240539r671358_rule
  • SV-100505
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter).
Checks: C-43772r671356_chk

The message types that are always recorded to /var/log/audit/audit.log include "LOGIN", "USER_LOGIN", "USER_START", "USER_END" among others and do not need to be added to audit.rules. The log files /var/log/faillog, /var/log/lastlog, and /var/log/tallylog must be protected from tampering of the login records: # egrep "faillog|lastlog|tallylog" /etc/audit/audit.rules If /var/log/faillog, /var/log/lastlog, and /var/log/tallylog entries do not exist, this is a finding.

Fix: F-43731r671357_fix

Ensure the auditing of logins by modifying /etc/audit/audit.rules to contain: -w /var/log/faillog -p wa -w /var/log/lastlog -p wa -w /var/log/tallylog -p wa OR # /etc/dodscript.sh

b
The SLES for vRealize must generate audit records for all account creations, modifications, disabling, and termination events.
AU-12 - Medium - CCI-000172 - V-240540 - SV-240540r671361_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
VRAU-SL-001480
Vuln IDs
  • V-240540
  • V-89857
Rule IDs
  • SV-240540r671361_rule
  • SV-100507
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter).
Checks: C-43773r671359_chk

Determine if execution of the "usermod" and "groupmod" executable are audited: # auditctl -l | egrep '(usermod|groupmod)' If either "usermod" or "groupmod" are not listed with a permissions filter of at least "x", this is a finding. Determine if execution of the "userdel" and "groupdel" executable are audited: # auditctl -l | egrep '(userdel|groupdel)' If either "userdel" or "groupdel" are not listed with a permissions filter of at least "x", this is a finding. Determine if execution of "useradd" and "groupadd" are audited: # auditctl -l | egrep '(useradd|groupadd)' If either "useradd" or "groupadd" are not listed with a permissions filter of at least "x", this is a finding. Determine if execution of the "passwd" executable is audited: # auditctl -l | grep “/usr/bin/passwd” If "/usr/bin/passwd" is not listed with a permissions filter of at least "x", this is a finding. Determine if /etc/passwd, /etc/shadow, /etc/group, and /etc/security/opasswd are audited for writing: # auditctl -l | egrep '(/etc/passwd|/etc/shadow|/etc/group|/etc/security/opasswd)' If any of these are not listed with a permissions filter of at least "w", this is a finding.

Fix: F-43732r671360_fix

Configure "execute" auditing of the "usermod" and "groupmod" executables. Add the following to the /etc/audit/audit.rules file: -w /usr/sbin/usermod -p x -k usermod -w /usr/sbin/groupmod -p x -k groupmod Configure "execute" auditing of the "userdel" and "groupdel" executables. Add the following to the /etc/audit/audit.rules file: -w /usr/sbin/userdel -p x -k userdel -w /usr/sbin/groupdel -p x -k groupdel Configure "execute" auditing of the "useradd" and "groupadd" executables. Add the following to audit.rules: -w /usr/sbin/useradd -p x -k useradd -w /usr/sbin/groupadd -p x -k groupadd Configure "execute" auditing of the "passwd" executable. Add the following to the aud.rules: -w /usr/bin/passwd -p x -k passwd Configure "write" auditing of the "passwd", "shadow", "group", and "opasswd" files. Add the following to the /etc/audit/audit.rules file: -w /etc/passwd -p wa -k passwd -w /etc/shadow -p wa -k shadow -w /etc/group -p wa -k group -w /etc/security/opasswd -p wa -k opasswd Restart the auditd service: # service auditd restart OR # /etc/dodscript.sh

b
The SLES for vRealize must generate audit records for all kernel module load, unload, and restart actions, and also for all program initiations.
AU-12 - Medium - CCI-000172 - V-240541 - SV-240541r671364_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
VRAU-SL-001485
Vuln IDs
  • V-240541
  • V-89859
Rule IDs
  • SV-240541r671364_rule
  • SV-100509
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter).
Checks: C-43774r671362_chk

Determine if "/sbin/insmod" is audited: # cat /etc/audit/audit.rules | grep "/sbin/insmod" If the result does not start with "-w" and contain "-p x", this is a finding.

Fix: F-43733r671363_fix

Add the following to "/etc/audit/audit.rules" in order to capture kernel module loading and unloading events: -w /sbin/insmod -p x OR # /etc/dodscript.sh

b
The SLES for vRealize must implement NIST FIPS-validated cryptography for the following: to provision digital signatures, to generate cryptographic hashes, and to protect unclassified information requiring confidentiality and cryptographic protection in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards.
SC-13 - Medium - CCI-002450 - V-240542 - SV-240542r878120_rule
RMF Control
SC-13
Severity
Medium
CCI
CCI-002450
Version
VRAU-SL-001490
Vuln IDs
  • V-240542
  • V-89861
Rule IDs
  • SV-240542r878120_rule
  • SV-100511
Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. The SLES for vRealize must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated.
Checks: C-43775r671365_chk

Check the SSH daemon configuration for allowed MACs: # grep -i macs /etc/ssh/sshd_config | grep -v '^#' If no lines are returned, or the returned MACs list contains any MAC other than "hmac-sha1", this is a finding.

Fix: F-43734r671366_fix

Edit the SSH daemon configuration and remove any MACs other than "hmac-sha1". If necessary, add a "MACs" line.

b
The SLES for vRealize must, at a minimum, off-load audit information on interconnected systems in real time and off-load standalone systems weekly.
AU-4 - Medium - CCI-001851 - V-240543 - SV-240543r852585_rule
RMF Control
AU-4
Severity
Medium
CCI
CCI-001851
Version
VRAU-SL-001495
Vuln IDs
  • V-240543
  • V-89863
Rule IDs
  • SV-240543r852585_rule
  • SV-100513
Information stored in one location is vulnerable to accidental or incidental deletion or alteration. Off-loading is a common process in information systems with limited audit storage capacity.
Checks: C-43776r671368_chk

Check the "syslog" configuration file for remote syslog servers: # cat /etc/syslog-ng/syslog-ng.conf | grep logserver If no line is returned, or "logserver" is commented out, this is a finding.

Fix: F-43735r671369_fix

Edit the syslog configuration file and add an appropriate remote syslog server: In the /etc/syslog-ng/syslog-ng.conf file, the remote logging entries must be uncommented and the IP address must be modified to point to the remote syslog server: # # Enable this and adopt IP to send log messages to a log server. # destination logserver { udp("10.10.10.10" port(514)); }; log { source(src); destination(logserver); };

b
The SLES for vRealize must prevent the use of dictionary words for passwords.
CM-6 - Medium - CCI-000366 - V-240544 - SV-240544r671373_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
VRAU-SL-001500
Vuln IDs
  • V-240544
  • V-89865
Rule IDs
  • SV-240544r671373_rule
  • SV-100515
If the operating system allows the user to select passwords based on dictionary words, this increases the chances of password compromise by increasing the opportunity for successful guesses and brute-force attacks.
Checks: C-43777r671371_chk

Check "/etc/pam.d/common-password" for "pam_cracklib" configuration: # grep pam_cracklib /etc/pam.d/common-password* If "pam_cracklib" is not present, this is a finding. Ensure the "passwd" command uses the "common-password" settings. # grep common-password /etc/pam.d/passwd If a line "password include common-password" is not found then the "password checks in common-password" will not be applied to new passwords, this is a finding.

Fix: F-43736r671372_fix

Edit "/etc/pam.d/common-password" and configure "pam_cracklib" by adding a line such as "password requisite pam_cracklib.so"

b
The SLES for vRealize must prevent the use of dictionary words for passwords.
CM-6 - Medium - CCI-000366 - V-240545 - SV-240545r671376_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
VRAU-SL-001505
Vuln IDs
  • V-240545
  • V-89867
Rule IDs
  • SV-240545r671376_rule
  • SV-100517
If the operating system allows the user to select passwords based on dictionary words, this increases the chances of password compromise by increasing the opportunity for successful guesses and brute-force attacks.
Checks: C-43778r671374_chk

Verify the module "pam_cracklib.so" is present. # ls /lib/security/ Confirm that "pam_cracklib.so" is present in the directory listing. If "pam_cracklib.so" is not present, this is a finding. Verify the file "/etc/pam.d/common-password" is configured. # grep pam_cracklib /etc/pam.d/common-password* If a line containing "password required pam_cracklib.so" is not present, this is a finding.

Fix: F-43737r671375_fix

Configure the SLES for vRealize to prevent the use of dictionary words for passwords. Edit the file "/etc/pam.d/common-password". Configure "common-password" by adding a line such as: password required pam_cracklib.so Save the changes made to the file "/etc/pam.d/common-password".

b
The SLES for vRealize must prevent the use of dictionary words for passwords.
CM-6 - Medium - CCI-000366 - V-240546 - SV-240546r671379_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
VRAU-SL-001510
Vuln IDs
  • V-240546
  • V-89869
Rule IDs
  • SV-240546r671379_rule
  • SV-100519
If the operating system allows the user to select passwords based on dictionary words, this increases the chances of password compromise by increasing the opportunity for successful guesses and brute-force attacks.
Checks: C-43779r671377_chk

Verify the "passwd" command uses the "common-password" settings. # grep common-password /etc/pam.d/passwd If a line "password include common-password" is not found then the "password checks in common-password" will not be applied to new passwords, and this is a finding.

Fix: F-43738r671378_fix

Configure the SLES for vRealize to prevent the use of dictionary words for passwords. Edit the file "/etc/pam.d/passwd". Configure "passwd" by adding a line such as: password include common-password Save the changes made to the file.

b
The SLES for vRealize must enforce a delay of at least 4 seconds between logon prompts following a failed logon attempt.
CM-6 - Medium - CCI-000366 - V-240547 - SV-240547r671382_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
VRAU-SL-001515
Vuln IDs
  • V-240547
  • V-89871
Rule IDs
  • SV-240547r671382_rule
  • SV-100521
Limiting the number of logon attempts over a certain time interval reduces the chances that an unauthorized user may gain access to an account.
Checks: C-43780r671380_chk

Check the value of the "FAIL_DELAY" variable and the ability to use it: # grep FAIL_DELAY /etc/login.defs The following result should be displayed: FAIL_DELAY 4 If the value does not exist, or is less than "4", this is a finding. Check for the use of "pam_faildelay": # grep pam_faildelay /etc/pam.d/common-auth* The following result should be displayed: /etc/pam.d/common-auth:auth optional pam_faildelay.so If the "pam_faildelay.so" module is not listed or is commented out, this is a finding.

Fix: F-43739r671381_fix

Add the "pam_faildelay" module and set the "FAIL_DELAY" variable. Edit "/etc/login.defs" and set the value of the "FAIL_DELAY" variable to "4" or more. Edit "/etc/pam.d/common-auth" and add a "pam_faildelay" entry if one does not exist, such as: auth optional pam_faildelay.so

b
The SLES for vRealize must enforce a delay of at least 4 seconds between logon prompts following a failed logon attempt.
CM-6 - Medium - CCI-000366 - V-240548 - SV-240548r671385_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
VRAU-SL-001520
Vuln IDs
  • V-240548
  • V-89873
Rule IDs
  • SV-240548r671385_rule
  • SV-100523
Limiting the number of logon attempts over a certain time interval reduces the chances that an unauthorized user may gain access to an account.
Checks: C-43781r671383_chk

Verify the SLES for vRealize enforces a delay of at least "4" seconds between logon prompts following a failed logon attempt. Review the file "/etc/login.defs" and verify the parameter "FAIL_DELAY" is a value of "4" or greater. # grep FAIL_DELAY /etc/login.defs The typical configuration looks something like this: FAIL_DELAY 4 If the parameter "FAIL_DELAY" does not exists, or is less than "4", this is a finding.

Fix: F-43740r671384_fix

Configure the SLES for vRealize to enforce a delay of at least "4" seconds between logon prompts following a failed logon attempt. Set the parameter "FAIL_DELAY" to a value of "4" or greater. Edit the file "/etc/login.defs". Set the parameter "FAIL_DELAY" to a value of "4" or greater. The typical configuration looks something like this: FAIL_DELAY 4 Save the changes made to the file.

b
The SLES for vRealize must enforce a delay of at least 4 seconds between logon prompts following a failed logon attempt.
CM-6 - Medium - CCI-000366 - V-240549 - SV-240549r671388_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
VRAU-SL-001525
Vuln IDs
  • V-240549
  • V-89875
Rule IDs
  • SV-240549r671388_rule
  • SV-100525
Limiting the number of logon attempts over a certain time interval reduces the chances that an unauthorized user may gain access to an account.
Checks: C-43782r671386_chk

Verify the SLES for vRealize enforces a delay of at least "4" seconds between logon prompts following a failed logon attempt. Verify the use of the "pam_faildelay" module. # grep pam_faildelay /etc/pam.d/common-auth* The typical configuration looks something like this: #delay is in micro seconds auth required pam_faildelay.so delay=4000000 If the line is not present, this is a finding.

Fix: F-43741r671387_fix

Configure the SLES for vRealize to enforce a delay of at least "4" seconds between logon prompts following a failed logon attempt with the following command: # sed -i "/^[^#]*pam_faildelay.so/ c\auth required pam_faildelay.so delay=4000000" /etc/pam.d/common-auth-vmware.local

b
The SLES for vRealize must be configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs.
CM-6 - Medium - CCI-000366 - V-240550 - SV-240550r671391_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
VRAU-SL-001530
Vuln IDs
  • V-240550
  • V-89877
Rule IDs
  • SV-240550r671391_rule
  • SV-100527
Configuring the operating system to implement organization-wide security implementation guides and security checklists ensures compliance with federal standards and establishes a common security baseline across DoD that reflects the most restrictive security posture consistent with operational requirements. Configuration settings are the set of parameters that can be changed in hardware, software, or firmware components of the system that affect the security posture and/or functionality of the system. Security-related parameters are those parameters impacting the security state of the system, including the parameters required to satisfy other security control requirements. Security-related parameters include, for example: registry settings; account, file, directory permission settings; and settings for functions, ports, protocols, services, and remote connections.
Checks: C-43783r671389_chk

Verify the SLES for vRealize is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding.

Fix: F-43742r671390_fix

Configure the SLES for vRealize in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs.

b
The SLES for vRealize must define default permissions for all authenticated users in such a way that the user can only read and modify their own files.
CM-6 - Medium - CCI-000366 - V-240551 - SV-240551r671394_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
VRAU-SL-001535
Vuln IDs
  • V-240551
  • V-89879
Rule IDs
  • SV-240551r671394_rule
  • SV-100529
Setting the most restrictive default permissions ensures that when new accounts are created they do not have unnecessary access.
Checks: C-43784r671392_chk

Check for the configured "umask" value in "login.defs" with the following command: # grep UMASK /etc/login.defs If the default "umask" is not "077", this a finding. Note: If the default umask is "000" or allows for the creation of world-writable files this becomes a Severity Code I finding.

Fix: F-43743r671393_fix

To configure the correct UMASK setting run the following command: # sed -i "/^[^#]*UMASK/ c\UMASK 077" /etc/login.defs

c
The version of vRealize Automation 7.x SLES running on the system must be a supported version.
CM-6 - High - CCI-000366 - V-258447 - SV-258447r928860_rule
RMF Control
CM-6
Severity
High
CCI
CCI-000366
Version
VRAU-SL-009999
Vuln IDs
  • V-258447
Rule IDs
  • SV-258447r928860_rule
Security flaws with software applications are discovered daily. 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, and hot fixes). Flaws discovered during security assessments, continuous monitoring, incident response activities, or information system error handling must also be addressed expeditiously. Organization-defined time periods for updating security-relevant software may vary based on a variety of factors including, for example, the security category of the information system or the criticality of the update (i.e., severity of the vulnerability related to the discovered flaw). This requirement will apply to software patch management solutions used to install patches across the enclave and to applications themselves that are not part of that patch management solution. For example, many browsers today provide the capability to install their own patch software. Patch criticality, as well as system criticality will vary. Therefore, the tactical situations regarding the patch management process will also vary. This means that the time period used must be a configurable parameter. Time frames for application of security-relevant software updates may be dependent upon the Information Assurance Vulnerability Management (IAVM) process. The application will be configured to check for and install security-relevant software updates within an identified time period from the availability of the update. The specific time period will be defined by an authoritative source (e.g., IAVM, CTOs, DTMs, and STIGs).
Checks: C-62187r928859_chk

vRealize Automation 7.x SLES is no longer supported by the vendor. If the system is running vRealize Automation 7.x SLES, this is a finding.

Fix: F-53958r798705_fix

Upgrade to a supported version.

b
Any publically accessible connection to the SLES for vRealize must display the Standard Mandatory DoD Notice and Consent Banner before granting access to the system.
AC-8 - Medium - CCI-001384 - V-258526 - SV-258526r929672_rule
RMF Control
AC-8
Severity
Medium
CCI
CCI-001384
Version
VRAU-SL-000865
Vuln IDs
  • V-258526
  • V-89739
Rule IDs
  • SV-258526r929672_rule
  • SV-100389
Display of a standardized and approved use notification before granting access to the publicly accessible operating system ensures privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. System use notifications are required only for access via logon interfaces with human users and are not required when such human interfaces do not exist. The banner must be formatted in accordance with applicable DoD policy. Use the following verbiage for operating systems that can accommodate banners of 1300 characters: "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." Use the following verbiage for operating systems that have severe limitations on the number of characters that can be displayed in the banner: "I've read & consent to terms in IS user agreem't."
Checks: C-62266r929670_chk

Check the issue file to verify that it contains one of the DoD required banners: # cat /etc/issue "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." Use the following verbiage for SLES for vRealize that have severe limitations on the number of characters that can be displayed in the banner: "I've read &amp; consent to terms in IS user agreem't." If it does not, this is a finding.

Fix: F-62175r929671_fix

To configure the system to display the Standard Mandatory DoD Notice and Consent Banner, run the dodscript with the following command as root: # /etc/dodscript.sh

b
The SLES for vRealize audit system must be configured to audit all administrative, privileged, and security actions.
AU-12 - Medium - CCI-000169 - V-258527 - SV-258527r929675_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000169
Version
VRAU-SL-000175
Vuln IDs
  • V-258527
  • V-89503
Rule IDs
  • SV-258527r929675_rule
  • SV-100153
Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). 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. DoD has defined the list of events for which the operating system will provide an audit record generation capability as the following: 1) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels); 2) Access actions, such as successful and unsuccessful logon attempts, privileged activities or other system-level access, starting and ending time for user access to the system, concurrent logons from different workstations, successful and unsuccessful accesses to objects, all program initiations, and all direct access to the information system; 3) All account creations, modifications, disabling, and terminations; and 4) All kernel module load, unload, and restart actions.
Checks: C-62267r929673_chk

Check the auditing configuration of the system: # cat /etc/audit/audit.rules | grep -i "auditd.conf" If no results are returned, or the line does not start with "-w", this is a finding. Expected Result: -w /etc/audit/auditd.conf

Fix: F-62176r929674_fix

Add the following lines to the audit.rules file to enable auditing of administrative, privileged, and security actions: echo '-w /etc/audit/auditd.conf' >> /etc/audit/audit.rules Or run the following command to implement all logging requirements: # /etc/dodscript.sh

b
The SLES for vRealize audit system must be configured to audit all attempts to alter system time through adjtimex.
AU-12 - Medium - CCI-000169 - V-258528 - SV-258528r929823_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000169
Version
VRAU-SL-000180
Vuln IDs
  • V-258528
  • V-89505
Rule IDs
  • SV-258528r929823_rule
  • SV-100155
Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). 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. DoD has defined the list of events for which the operating system will provide an audit record generation capability as the following: 1) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels); 2) Access actions, such as successful and unsuccessful logon attempts, privileged activities or other system-level access, starting and ending time for user access to the system, concurrent logons from different workstations, successful and unsuccessful accesses to objects, all program initiations, and all direct access to the information system; 3) All account creations, modifications, disabling, and terminations; and 4) All kernel module load, unload, and restart actions.
Checks: C-62268r929821_chk

Check if the system is configured to audit calls to the "adjtimex" system call by running the following command: # grep -w "adjtimex" /etc/audit/audit.rules If the system is configured to audit time changes, it will return at least two lines containing "-S adjtimex" that also contain "arch=b64". If no line is returned, this is a finding.

Fix: F-62177r929822_fix

Run the following command: echo '-a exit,always -F arch=b64 -S adjtimex -F auid=0' >> /etc/audit/audit.rules echo '-a exit,always -F arch=b64 -S adjtimex -F auid>=500 -F auid!=4294967295' >> /etc/audit/audit.rules Or run the following command to implement all logging requirements: # /etc/dodscript.sh

b
The SLES for vRealize audit system must be configured to audit all attempts to alter system time through settimeofday.
AU-12 - Medium - CCI-000169 - V-258529 - SV-258529r929826_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000169
Version
VRAU-SL-000185
Vuln IDs
  • V-258529
  • V-89507
Rule IDs
  • SV-258529r929826_rule
  • SV-100157
Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). 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. DoD has defined the list of events for which the operating system will provide an audit record generation capability as the following: 1) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels); 2) Access actions, such as successful and unsuccessful logon attempts, privileged activities or other system-level access, starting and ending time for user access to the system, concurrent logons from different workstations, successful and unsuccessful accesses to objects, all program initiations, and all direct access to the information system; 3) All account creations, modifications, disabling, and terminations; and 4) All kernel module load, unload, and restart actions.
Checks: C-62269r929824_chk

Check if the system is configured to audit calls to the "settimeofday" system call by running the following command: # grep -w "settimeofday" /etc/audit/audit.rules If the system is configured to audit this activity, it will return at least two lines containing "-S settimeofday" that also contain "arch=b64". If no line is returned, this is a finding.

Fix: F-62178r929825_fix

Run the following command: echo '-a exit,always -F arch=b64 -S settimeofday -F auid=0' >> /etc/audit/audit.rules echo '-a exit,always -F arch=b64 -S settimeofday -F auid>=500 -F auid!=4294967295' >> /etc/audit/audit.rules Or run the following command to implement all logging requirements: # /etc/dodscript.sh

b
The SLES for vRealize audit system must be configured to audit all attempts to alter system time through stime.
AU-12 - Medium - CCI-000169 - V-258530 - SV-258530r929829_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000169
Version
VRAU-SL-000190
Vuln IDs
  • V-258530
  • V-89509
Rule IDs
  • SV-258530r929829_rule
  • SV-100159
Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). 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. DoD has defined the list of events for which the operating system will provide an audit record generation capability as the following: 1) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels); 2) Access actions, such as successful and unsuccessful logon attempts, privileged activities or other system-level access, starting and ending time for user access to the system, concurrent logons from different workstations, successful and unsuccessful accesses to objects, all program initiations, and all direct access to the information system; 3) All account creations, modifications, disabling, and terminations; and 4) All kernel module load, unload, and restart actions.
Checks: C-62270r929827_chk

Check if the system is configured to audit calls to the "settimeofday" system call by running the following command: # grep -w "stime" /etc/audit/audit.rules If the system is configured to audit this activity, it will return at least two lines containing "-S settimeofday" that also contain "arch=b64". If no line is returned, this is a finding.

Fix: F-62179r929828_fix

Run the following command: echo '-a exit,always -F arch=b64 -S stime' >> /etc/audit/audit.rules Or run the following command to implement all logging requirements: # /etc/dodscript.sh

b
The SLES for vRealize audit system must be configured to audit all attempts to alter system time through clock_settime.
AU-12 - Medium - CCI-000169 - V-258531 - SV-258531r929832_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000169
Version
VRAU-SL-000195
Vuln IDs
  • V-258531
  • V-89511
Rule IDs
  • SV-258531r929832_rule
  • SV-100161
Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). 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. DoD has defined the list of events for which the operating system will provide an audit record generation capability as the following: 1) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels); 2) Access actions, such as successful and unsuccessful logon attempts, privileged activities or other system-level access, starting and ending time for user access to the system, concurrent logons from different workstations, successful and unsuccessful accesses to objects, all program initiations, and all direct access to the information system; 3) All account creations, modifications, disabling, and terminations; and 4) All kernel module load, unload, and restart actions.
Checks: C-62271r929830_chk

Check if the system is configured to audit calls to the "clock_settime" system call by running the following command: # grep -w "clock_settime" /etc/audit/audit.rules If the system is configured to audit this activity, it will return at least a line containing "-S clock_settime" that also contain "arch=b64". If no line is returned, this is a finding.

Fix: F-62180r929831_fix

Run the following command: echo '-a exit,always -F arch=b64 -S clock_settime' >> /etc/audit/audit.rules Or run the following command to implement all logging requirements: # /etc/dodscript.sh

b
The SLES for vRealize audit system must be configured to audit all attempts to alter system time through /etc/localtime.
AU-12 - Medium - CCI-000169 - V-258532 - SV-258532r929835_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000169
Version
VRAU-SL-000200
Vuln IDs
  • V-258532
  • V-89513
Rule IDs
  • SV-258532r929835_rule
  • SV-100163
Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). 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. DoD has defined the list of events for which the operating system will provide an audit record generation capability as the following: 1) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels); 2) Access actions, such as successful and unsuccessful logon attempts, privileged activities or other system-level access, starting and ending time for user access to the system, concurrent logons from different workstations, successful and unsuccessful accesses to objects, all program initiations, and all direct access to the information system; 3) All account creations, modifications, disabling, and terminations; and 4) All kernel module load, unload, and restart actions.
Checks: C-62272r929833_chk

To determine if the system is configured to audit attempts to alter time via the /etc/localtime file, run the following command: # auditctl -l | grep "watch=/etc/localtime" If the system is configured to audit this activity, it will return. LIST_RULES: exit,always watch=/etc/localtime perm=wa key=localtime If no line is returned, this is a finding.

Fix: F-62181r929834_fix

To configure the system to audit attempts to alter time via the /etc/localtime file, run the following command: echo '-w /etc/localtime -p wa -k localtime' >> /etc/audit/audit.rules Or run the following command to implement all logging requirements: # /etc/dodscript.sh

b
The SLES for vRealize audit system must be configured to audit all attempts to alter the system through sethostname.
AU-12 - Medium - CCI-000169 - V-258533 - SV-258533r929838_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000169
Version
VRAU-SL-000205
Vuln IDs
  • V-258533
  • V-89515
Rule IDs
  • SV-258533r929838_rule
  • SV-100165
Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). 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. DoD has defined the list of events for which the operating system will provide an audit record generation capability as the following: 1) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels); 2) Access actions, such as successful and unsuccessful logon attempts, privileged activities or other system-level access, starting and ending time for user access to the system, concurrent logons from different workstations, successful and unsuccessful accesses to objects, all program initiations, and all direct access to the information system; 3) All account creations, modifications, disabling, and terminations; and 4) All kernel module load, unload, and restart actions.
Checks: C-62273r929836_chk

Check if the system is configured to audit calls to the "sethostname" system call by running the following command: # grep -w "sethostname" /etc/audit/audit.rules If the system is configured to audit this activity, it will return at least one line. If no line is returned, this is a finding.

Fix: F-62182r929837_fix

Run the following command: # echo '-a exit,always -F arch=b64 -S sethostname' >> /etc/audit/audit.rules Or run the following command to implement all logging requirements: # /etc/dodscript.sh

b
The SLES for vRealize audit system must be configured to audit all attempts to alter the system through setdomainname.
AU-12 - Medium - CCI-000169 - V-258534 - SV-258534r929841_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000169
Version
VRAU-SL-000210
Vuln IDs
  • V-258534
  • V-89517
Rule IDs
  • SV-258534r929841_rule
  • SV-100167
Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). 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. DoD has defined the list of events for which the operating system will provide an audit record generation capability as the following: 1) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels); 2) Access actions, such as successful and unsuccessful logon attempts, privileged activities or other system-level access, starting and ending time for user access to the system, concurrent logons from different workstations, successful and unsuccessful accesses to objects, all program initiations, and all direct access to the information system; 3) All account creations, modifications, disabling, and terminations; and 4) All kernel module load, unload, and restart actions.
Checks: C-62274r929839_chk

Check if the system is configured to audit calls to the "sethostname" system call by running the following command: # grep -w "setdomainname" /etc/audit/audit.rules If the system is configured to audit this activity, it will return a line. If no line is returned, this is a finding.

Fix: F-62183r929840_fix

Run the following command: # echo '-a exit,always -F arch=b64 -S setdomainname' >> /etc/audit/audit.rules Or run the following command to implement all logging requirements: # /etc/dodscript.sh

b
The SLES for vRealize audit system must be configured to audit all attempts to alter the system through sched_setparam.
AU-12 - Medium - CCI-000169 - V-258535 - SV-258535r929844_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000169
Version
VRAU-SL-000215
Vuln IDs
  • V-258535
  • V-89519
Rule IDs
  • SV-258535r929844_rule
  • SV-100169
Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). 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. DoD has defined the list of events for which the operating system will provide an audit record generation capability as the following: 1) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels); 2) Access actions, such as successful and unsuccessful logon attempts, privileged activities or other system-level access, starting and ending time for user access to the system, concurrent logons from different workstations, successful and unsuccessful accesses to objects, all program initiations, and all direct access to the information system; 3) All account creations, modifications, disabling, and terminations; and 4) All kernel module load, unload, and restart actions.
Checks: C-62275r929842_chk

Check if the system is configured to audit calls to the "sethostname" system call by running the following command: # grep -w "sched_setparam" /etc/audit/audit.rules If the system is configured to audit this activity, it will return a line. If no line is returned, this is a finding.

Fix: F-62184r929843_fix

Run the following command: echo '-a exit,always -F arch=b64 -S sched_setparam' >> /etc/audit/audit.rules Or run the following command to implement all logging requirements: # /etc/dodscript.sh

b
The SLES for vRealize audit system must be configured to audit all attempts to alter the system through sched_setscheduler.
AU-12 - Medium - CCI-000169 - V-258536 - SV-258536r929847_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000169
Version
VRAU-SL-000220
Vuln IDs
  • V-258536
  • V-89521
Rule IDs
  • SV-258536r929847_rule
  • SV-100171
Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). 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. DoD has defined the list of events for which the operating system will provide an audit record generation capability as the following: 1) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels); 2) Access actions, such as successful and unsuccessful logon attempts, privileged activities or other system-level access, starting and ending time for user access to the system, concurrent logons from different workstations, successful and unsuccessful accesses to objects, all program initiations, and all direct access to the information system; 3) All account creations, modifications, disabling, and terminations; and 4) All kernel module load, unload, and restart actions.
Checks: C-62276r929845_chk

Check if the system is configured to audit calls to the "sethostname" system call by running the following command: # grep -w "sched_setscheduler" /etc/audit/audit.rules If the system is configured to audit this activity, it will return a line. If no line is returned, this is a finding.

Fix: F-62185r929846_fix

Run the following command: echo '-a exit,always -F arch=b64 -S sched_setscheduler' >> /etc/audit/audit.rules Or run the following command to implement all logging requirements: # /etc/dodscript.sh

b
The SLES for vRealize audit system must be configured to audit all attempts to alter /var/log/faillog.
AU-12 - Medium - CCI-000169 - V-258537 - SV-258537r929850_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000169
Version
VRAU-SL-000225
Vuln IDs
  • V-258537
  • V-89523
Rule IDs
  • SV-258537r929850_rule
  • SV-100173
Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). 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. DoD has defined the list of events for which the operating system will provide an audit record generation capability as the following: 1) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels); 2) Access actions, such as successful and unsuccessful logon attempts, privileged activities or other system-level access, starting and ending time for user access to the system, concurrent logons from different workstations, successful and unsuccessful accesses to objects, all program initiations, and all direct access to the information system; 3) All account creations, modifications, disabling, and terminations; and 4) All kernel module load, unload, and restart actions.
Checks: C-62277r929848_chk

Verify that attempts to alter the log files /var/log/faillog are audited: # egrep "faillog" /etc/audit/audit.rules If "-w /var/log/faillog -p wa" entry does not exist, this is a finding.

Fix: F-62186r929849_fix

Ensure attempts to alter /var/log/faillog are audited by modifying /etc/audit/audit.rules to contain -w /var/log/faillog -p wa with the following command: echo '-w /var/log/faillog -p wa' >> /etc/audit/audit.rules Or run the following command to implement all logging requirements: # /etc/dodscript.sh

b
The SLES for vRealize audit system must be configured to audit all attempts to alter /var/log/lastlog.
AU-12 - Medium - CCI-000169 - V-258538 - SV-258538r929853_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000169
Version
VRAU-SL-000230
Vuln IDs
  • V-258538
  • V-89525
Rule IDs
  • SV-258538r929853_rule
  • SV-100175
Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). 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. DoD has defined the list of events for which the operating system will provide an audit record generation capability as the following: 1) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels); 2) Access actions, such as successful and unsuccessful logon attempts, privileged activities or other system-level access, starting and ending time for user access to the system, concurrent logons from different workstations, successful and unsuccessful accesses to objects, all program initiations, and all direct access to the information system; 3) All account creations, modifications, disabling, and terminations; and 4) All kernel module load, unload, and restart actions.
Checks: C-62278r929851_chk

Verify that attempts to alter the log files /var/log/lastlog are audited: # egrep "lastlog" /etc/audit/audit.rules If "-w /var/log/lastlog -p wa" entry does not exist, this is a finding.

Fix: F-62187r929852_fix

Ensure attempts to alter /var/log/lastlog are audited by modifying /etc/audit/audit.rules to contain -w /var/log/lastlog -p wa with the following command: echo '-w /var/log/lastlog -p wa' >> /etc/audit/audit.rules Or run the following command to implement all logging requirements: # /etc/dodscript.sh

b
The SLES for vRealize audit system must be configured to audit all attempts to alter /var/log/tallylog.
AU-12 - Medium - CCI-000169 - V-258539 - SV-258539r929856_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000169
Version
VRAU-SL-000235
Vuln IDs
  • V-258539
  • V-89527
Rule IDs
  • SV-258539r929856_rule
  • SV-100177
Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). 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. DoD has defined the list of events for which the operating system will provide an audit record generation capability as the following: 1) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels); 2) Access actions, such as successful and unsuccessful logon attempts, privileged activities or other system-level access, starting and ending time for user access to the system, concurrent logons from different workstations, successful and unsuccessful accesses to objects, all program initiations, and all direct access to the information system; 3) All account creations, modifications, disabling, and terminations; and 4) All kernel module load, unload, and restart actions.
Checks: C-62279r929854_chk

Verify that attempts to alter the log files /var/log/tallylog are audited: # egrep "tallylog" /etc/audit/audit.rules If "-w /var/log/tallylog -p wa" entry does not exist, this is a finding.

Fix: F-62188r929855_fix

Ensure attempts to alter /var/log/tallylog are audited by modifying /etc/audit/audit.rules to contain "-w /var/log/tallylog -p wa" with the following command: echo '-w /var/log/tallylog -p wa' >> /etc/audit/audit.rules Or run the following command to implement all logging requirements: # /etc/dodscript.sh