{"stig":{"title":"VMware vRealize Operations Manager 6.x SLES Security Technical Implementation Guide","version":"2","release":"2"},"checks":[{"vulnId":"V-239441","ruleId":"SV-239441r661774_rule","severity":"medium","ruleTitle":"The SLES for vRealize must provide automated mechanisms for supporting account management functions.","description":"Enterprise environments make account management challenging and complex. A manual process for account management functions adds the risk of a potential oversight or other errors.\n\nA comprehensive account management process that includes automation helps to ensure accounts designated as requiring attention are consistently and promptly addressed. Examples include, but are not limited to, using automation to take action on multiple accounts designated as inactive, suspended, or terminated, or by disabling accounts located in non-centralized account stores such as multiple servers. This requirement applies to all account types, including individual/user, shared, group, system, guest/anonymous, emergency, developer/manufacturer/vendor, temporary, and service.\n\nThe automated mechanisms may reside within the SLES for vRealize itself or may be offered by other infrastructure providing automated account management capabilities. Automated mechanisms may be composed of differing technologies that, when placed together, contain an overall automated mechanism supporting an organization's automated account management requirements.\n\nAccount management functions include: assigning group or role membership; identifying account type; specifying user access authorizations (i.e., privileges); account removal, update, or termination; and administrative alerts. The use of automated mechanisms can include, for example: using email or text messaging to automatically notify account managers when users are terminated or transferred; using the information system to monitor account usage; and using automated telephonic notification to report atypical system account usage.","checkContent":"Interview the server admin to determine if there is automated mechanisms for managing user accounts. If there is not, this is a finding.","fixText":"Implement an automated system for managing user accounts that minimizes the risk of errors, either intentional or deliberate. If possible, this system should integrate with an existing enterprise user management system, such as, one based Active Directory or Kerberos.","ccis":["CCI-000015"]},{"vulnId":"V-239442","ruleId":"SV-239442r661777_rule","severity":"medium","ruleTitle":"The SLES for vRealize must automatically remove or disable temporary user accounts after 72 hours.","description":"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.\n\nTemporary 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.\n\nIf temporary accounts are used, the SLES for vRealize must be configured to automatically terminate these types of accounts after a DoD-defined time period of 72 hours.\n\nTo address access requirements, many SLES for vRealize operating systems may be integrated with enterprise-level authentication/access mechanisms that meet or exceed access control policy requirements.","checkContent":"For every existing temporary account, run the following command to obtain its account expiration information.\n\n# chage -l system_account_name\n\nVerify each of these accounts has an expiration date set within \"72\" hours. \n\nIf any temporary accounts have no expiration date set or do not expire within \"72\" hours, this is a finding.","fixText":"In the event temporary accounts are required, configure the system to terminate them after \"72\" hours. For every temporary account, run the following command to set an expiration date on it, substituting \"system_account_name\" for the appropriate value.\n\n# chage -E `date -d \"+3 days\" +%Y-%m-%d` system_account_name\n\n`date -d \"+3 days\" +%Y-%m-%d` gets the expiration date for the account at the time of running the command.","ccis":["CCI-000016"]},{"vulnId":"V-239443","ruleId":"SV-239443r661780_rule","severity":"medium","ruleTitle":"The SLES for vRealize must audit all account creations.","description":"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.\n\nTo address access requirements, many SLES for vRealize operating systems may be integrated with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements.","checkContent":"Determine if execution of the useradd and groupadd executable are audited.\n\n# auditctl -l | egrep '(useradd|groupadd)'\n\nIf either \"useradd\" or \"groupadd\" are not listed with a permissions filter of at least \"x\", this is a finding.\n\nExpected result:\nLIST_RULES: exit,always watch=/usr/sbin/useradd perm=x key=useradd\nLIST_RULES: exit,always watch=/usr/sbin/groupadd perm=x key=groupadd","fixText":"Configure execute auditing of the \"useradd\" and \"groupadd\" executables run the DoD.script with the following command as root:\n\n# /etc/dodscript.sh\n\nOR\n\nConfigure execute auditing of the \"useradd\" and \"groupadd\" executables. \n\nAdd the following to /etc/audit/audit.rules:\n-w /usr/sbin/useradd -p x -k useradd\n-w /usr/sbin/groupadd -p x -k groupadd\n\nRestart the auditd service. \n\n# service auditd restart","ccis":["CCI-000018"]},{"vulnId":"V-239444","ruleId":"SV-239444r661783_rule","severity":"medium","ruleTitle":"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.","description":"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.\n\nTo address access requirements, many SLES for vRealize operating systems may be integrated with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements.","checkContent":"Determine if /etc/passwd, /etc/shadow, /etc/group, and /etc/gshadow are audited for appending.\n\n# auditctl -l | egrep '(/etc/passwd|/etc/shadow|/etc/group|/etc/gshadow)' | grep perm=a\n\nIf the \"passwd\", \"shadow\", \"group\", and \"gshadow\" files are not listed with a permissions filter of at least \"a\", this is a finding.\n\nExpected result:\nLIST_RULES: exit,always watch=/etc/passwd perm=a key=passwd\nLIST_RULES: exit,always watch=/etc/shadow perm=a key=shadow\nLIST_RULES: exit,always watch=/etc/group perm=a key=group\nLIST_RULES: exit,always watch=/etc/gshadow perm=a key=gshadow","fixText":"Configure append auditing of the \"passwd\", \"shadow\", \"group\", and \"gshadow\" files run the DoD.script with the following command as root:\n\n# /etc/dodscript.sh\n# echo '-w /etc/gshadow -p a -k gshadow' >> /etc/audit/audit.rules\n\nRestart the auditd service.\n# service auditd restart\n\nOR\n\nConfigure append auditing of the passwd, shadow, group, and gshadow files by running the following commands:\n\n# echo '-w /etc/passwd -p a -k passwd' >> /etc/audit/audit.rules\n# echo '-w /etc/shadow -p a -k shadow' >> /etc/audit/audit.rules\n# echo '-w /etc/group -p a -k group' >> /etc/audit/audit.rules\n# echo '-w /etc/gshadow -p a -k gshadow' >> /etc/audit/audit.rules\n\nRestart the auditd service. \n\n# service auditd restart","ccis":["CCI-000018"]},{"vulnId":"V-239445","ruleId":"SV-239445r661786_rule","severity":"medium","ruleTitle":"The SLES for vRealize must enforce the limit of three consecutive invalid logon attempts by a user during a 15-minute time period.","description":"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.","checkContent":"Run the following command to ensure that the SLES for vRealize enforces the limit of \"3\" consecutive invalid logon attempts by a user:\n\n# grep pam_tally2.so /etc/pam.d/common-auth\n\nThe output should contain \"deny=3\" in the returned line. \n\nIf the output does not contain \"deny=3\", this is a finding.\n\nExpected Result:\nauth    required       pam_tally2.so deny=3 onerr=fail even_deny_root unlock_time=86400 root_unlock_time=300","fixText":"To configure the SLES for vRealize to enforce the limit of \"3\" consecutive invalid attempts using \"pam_tally2.so\", modify the content of the /etc/pam.d/common-auth-vmware.local by running the following command:\n\n# 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","ccis":["CCI-000044"]},{"vulnId":"V-239446","ruleId":"SV-239446r661789_rule","severity":"medium","ruleTitle":"The SLES for vRealize must display the Standard Mandatory DoD Notice and Consent Banner before granting access via SSH.","description":"Display of a standardized and approved use notification before granting access to the SLES for vRealize ensures privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance.\n\nSystem use notifications are required only for access via logon interfaces with human users and are not required when such human interfaces do not exist.\n\nThe banner must be formatted in accordance with applicable DoD policy. Use the following verbiage for SLES for vRealize systems that can accommodate banners of 1300 characters:\n\n\"You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only.\n\nBy using this IS (which includes any device attached to this IS), you consent to the following conditions:\n\n-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.\n\n-At any time, the USG may inspect and seize data stored on this IS.\n\n-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.\n\n-This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy.\n\n-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.\"\n\nUse the following verbiage for SLES for vRealize systems that have severe limitations on the number of characters that can be displayed in the banner:\n\n\"I've read & consent to terms in IS user agreem't.\"","checkContent":"Check that the SSH daemon is configured for logon warning banners:\n\n# grep -i banner /etc/ssh/sshd_config | grep -v '#'\n\nThe output should contain \"Banner /etc/issue\".\n\nIf the output does not contain \"Banner /etc/issue\", this is a finding.","fixText":"To configure the SSH daemon with the logon warning banners, modify /etc/ssh/sshd_config execute the following command:\n\n# sed -i \"/^[^#]*Banner/ c\\Banner /etc/issue\" /etc/ssh/sshd_config\n\nThe 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:\n\n# service sshd restart","ccis":["CCI-000048"]},{"vulnId":"V-239447","ruleId":"SV-239447r877399_rule","severity":"low","ruleTitle":"The SLES for vRealize must limit the number of concurrent sessions to ten for all accounts and/or account types.","description":"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.\n\nThis 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.","checkContent":"Verify the SLES for vRealize limits the number of concurrent sessions to \"10\" for all accounts and/or account types with the following command:\n\n# grep maxlogins /etc/security/limits.conf  | grep -v '#' \n\nThe default maxlimits should be set to a max of \"10\" or a documented site defined number:\n\n* hard    maxlogins      10\n\nIf the default maxlimits is not set to \"10\" or the documented site defined number, this is a finding.","fixText":"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:\n\nsed -i 's/\\(^* *hard *maxlogins\\).*/*              hard    maxlogins      10/g' /etc/security/limits.conf","ccis":["CCI-000054"]},{"vulnId":"V-239448","ruleId":"SV-239448r661795_rule","severity":"medium","ruleTitle":"The SLES for vRealize must initiate a session lock after a 15-minute period of inactivity for all connection types.","description":"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, SLES for vRealize needs to be able to identify when a user's session has idled and take action to initiate the session lock.\n\nThe session lock is implemented at the point where session activity can be determined and/or controlled.","checkContent":"Check for the existence of the /etc/profile.d/tmout.sh file:\n\n# ls -al /etc/profile.d/tmout.sh\n\nCheck for the presence of the \"TMOUT\" variable:\n\n# grep TMOUT /etc/profile.d/tmout.sh\n\nThe value of \"TMOUT\" should be set to 900 seconds (15 minutes).\n\nIf the file does not exist, or the \"TMOUT\" variable is not set, this is a finding.","fixText":"Ensure the file exists and is owned by root. If the files does not exist, use the following commands to create the file:\n\n# touch /etc/profile.d/tmout.sh\n# chown root:root /etc/profile.d/tmout.sh\n# chmod 644 /etc/profile.d/tmout.sh\n\nEdit the file \"/etc/profile.d/tmout.sh\", and add the following lines: \n\nTMOUT=900\nreadonly TMOUT\nexport TMOUT\nmesg n 2>/dev/null","ccis":["CCI-000057"]},{"vulnId":"V-239449","ruleId":"SV-239449r661798_rule","severity":"medium","ruleTitle":"The SLES for vRealize must initiate a session lock after a 15-minute period of inactivity for an SSH connection.","description":"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, SLES for vRealize needs to be able to identify when a user's session has idled and take action to initiate the session lock.\n\nThe session lock is implemented at the point where session activity can be determined and/or controlled.","checkContent":"Verify SLES for vRealize initiates a session lock after a 15-minute period of inactivity for SSH. \n\nExecute the following command:\n\n# grep ClientAliveInterval /etc/ssh/sshd_config; grep  ClientAliveCountMax /etc/ssh/sshd_config\n\nVerify the following result:\n\nClientAliveInterval 900 \nClientAliveCountMax 0\n\nIf the session lock is not set to a 15-minute period, this is a finding.","fixText":"Configure SLES for vRealize to initiate a session lock after a 15-minute period of inactivity for SSH.\n\nSet the session lock after a 15-minute period by executing the following command:\n\n# sed -i 's/^.*\\bClientAliveInterval\\b.*$/ClientAliveInterval 900/' /etc/ssh/sshd_config; sed -i 's/^.*\\bClientAliveCountMax\\b.*$/ClientAliveCountMax 0/' /etc/ssh/sshd_config","ccis":["CCI-000057"]},{"vulnId":"V-239450","ruleId":"SV-239450r661801_rule","severity":"medium","ruleTitle":"The SLES for vRealize must monitor remote access methods - SSH Daemon.","description":"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.\n\nRemote 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.\n\nAutomated 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).","checkContent":"Verify that SSH is configured to verbosely log connection attempts and failed logon attempts to the server by running the following command:\n\n# grep LogLevel /etc/ssh/sshd_config  | grep -v '#' \n\nThe output message must contain the following text:\n\nLogLevel VERBOSE\n\nIf it is not set to \"VERBOSE\", this is a finding.","fixText":"To configure SSH to verbosely log connection attempts and failed logon attempts to the server, run the following command:\n\n# sed -i 's/^.*\\bLogLevel\\b.*$/LogLevel VERBOSE/' /etc/ssh/sshd_config\n\nThe 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:\n\n# service sshd restart","ccis":["CCI-000067"]},{"vulnId":"V-239451","ruleId":"SV-239451r877398_rule","severity":"medium","ruleTitle":"The SLES for vRealize must implement DoD-approved encryption to protect the confidentiality of remote access sessions - SSH Daemon.","description":"Without confidentiality protection mechanisms, unauthorized individuals may gain access to sensitive information via a remote access session.\n\nRemote 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.\n\nEncryption 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.","checkContent":"Check the SSH daemon configuration for DoD-approved encryption to protect the confidentiality of SSH remote connections by performing the following commands:\n\nCheck the Cipher setting in the sshd_config file.\n\n# grep -i Ciphers /etc/ssh/sshd_config  | grep -v '#' \n\nThe output must contain either none or any number of the following algorithms:\n\naes128-ctr, aes256-ctr.\n\nIf the output contains an algorithm not listed above, this is a finding.\n\nExpected Output:\nCiphers aes256-ctr,aes128-ctr","fixText":"Update the Ciphers directive with the following command: \n\n# sed -i \"/^[^#]*Ciphers/ c\\Ciphers aes256-ctr,aes128-ctr\" /etc/ssh/sshd_config\n\nSave and close the file. Restart the sshd process: \n\n# service sshd restart","ccis":["CCI-000068"]},{"vulnId":"V-239452","ruleId":"SV-239452r877398_rule","severity":"medium","ruleTitle":"The SLES for vRealize must implement DoD-approved encryption to protect the confidentiality of remote access sessions - SSH Client.","description":"Without confidentiality protection mechanisms, unauthorized individuals may gain access to sensitive information via a remote access session.\n\nRemote 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.\n\nEncryption 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.","checkContent":"Check the SSH daemon configuration for DoD-approved encryption to protect the confidentiality of SSH remote connections by performing the following commands:\n\nCheck the Cipher setting in the ssh_config file.\n# grep -i Ciphers /etc/ssh/ssh_config  | grep -v '#' \n\nThe output must contain either none or any number of the following algorithms:\naes256-ctr,aes128-ctr.\n\nIf the output contains an algorithm not listed above, this is a finding.\n\nExpected Output:\nCiphers aes256-ctr,aes128-ctr","fixText":"Update the Ciphers directive with the following command: \n\n# sed -i \"/^[^#]*Ciphers/ c\\Ciphers aes256-ctr,aes128-ctr\" /etc/ssh/ssh_config\n\nSave and close the file.","ccis":["CCI-000068"]},{"vulnId":"V-239453","ruleId":"SV-239453r661810_rule","severity":"medium","ruleTitle":"The SLES for vRealize must produce audit records.","description":"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.\n\nAudit 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.\n\nAssociating event types with detected events in the SLES for vRealize audit logs provides a means of investigating an attack; recognizing resource utilization or capacity thresholds; or identifying an improperly configured operating system.","checkContent":"Verify SLES for vRealize produces audit records by running the following command to determine the current status of the \"auditd\" service:\n\n# service auditd status\n\nIf the service is enabled, the returned message must contain the following text:\n\nChecking for: \n\nservice   auditd   running\n\nIf the service is not running, this is a finding.","fixText":"Enable the \"auditd\" service by performing the following commands:\n\n# chkconfig auditd on\n# service auditd start","ccis":["CCI-000130"]},{"vulnId":"V-239454","ruleId":"SV-239454r661813_rule","severity":"medium","ruleTitle":"The SLES for vRealize must alert the ISSO and SA (at a minimum) in the event of an audit processing failure.","description":"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.\n\nAudit processing failures include software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded.\n\nThis 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.","checkContent":"Check /etc/audit/auditd.conf for the \"space_left_action\" with the following command:\n\n# cat /etc/audit/auditd.conf | grep space_left_action \n\nIf 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.\n\nExpected Result:\nspace_left_action = SYSLOG\n\nNotes: \nIf 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.\n\nIf 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. \n\nThe \"action_mail_acct\" parameter, if missing, defaults to \"root\".\n\nNote:  If the email address of the system administrator is on a remote system \"sendmail\" must be available.","fixText":"Set the \"space_left_action\" parameter to the valid setting \"SYSLOG\", by running the following command:\n\n# sed -i \"/^[^#]*space_left_action/ c\\space_left_action = SYSLOG\" /etc/audit/auditd.conf\n\nRestart the audit service: \n\n# service auditd restart","ccis":["CCI-000139"]},{"vulnId":"V-239455","ruleId":"SV-239455r661816_rule","severity":"medium","ruleTitle":"The SLES for vRealize must shut down by default upon audit failure (unless availability is an overriding concern).","description":"It is critical that when the SLES for vRealize 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.\n\nWhen availability is an overriding concern, other approved actions in response to an audit failure are as follows: \n\n1) 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.\n\n2) If audit records are sent to a centralized collection server and communication with this server is lost or the server fails, SLES for vRealize  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.","checkContent":"Verify the /etc/audit/auditd.conf has the \"disk_full_action\", \"disk_error_action\", and \"admin_disk_space_left\" parameters set.\n\n# grep disk_full_action /etc/audit/auditd.conf\n\nIf the \"disk_full_action\" parameter is missing or set to \"suspend\" or \"ignore\", this is a finding.\n\n# grep disk_error_action /etc/audit/auditd.conf\n\nIf the \"disk_error_action\" parameter is missing or set to \"suspend\" or \"ignore\", this is a finding.\n\n# grep admin_space_left_action /etc/audit/auditd.conf\n\nIf the \"admin_space_left_action\" parameter is missing or set to \"suspend\" or \"ignore\", this is a finding.","fixText":"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: \n\n# sed -i \"/^[^#]*disk_full_action/ c\\disk_full_action = SYSLOG\" /etc/audit/auditd.conf\n# sed -i \"/^[^#]*disk_error_action/ c\\disk_error_action = SYSLOG\" /etc/audit/auditd.conf\n# sed -i \"/^[^#]*admin_space_left_action/ c\\admin_space_left_action = SYSLOG\" /etc/audit/auditd.conf\n\nFor certain systems, the need for availability outweighs the need to log all actions, and a different setting should be determined.","ccis":["CCI-000140"]},{"vulnId":"V-239456","ruleId":"SV-239456r661819_rule","severity":"medium","ruleTitle":"The SLES for vRealize must protect audit information from unauthorized read access - ownership.","description":"Unauthorized disclosure of audit records can reveal system and configuration data to attackers, thus compromising its confidentiality.\n\nAudit information includes all information (e.g., audit records, audit settings, audit reports) needed to successfully audit SLES for vRealize activity.","checkContent":"Verify that the SLES for vRealize audit logs are owned by \"root\".\n\n# (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)\n\nIf any audit log file is not owned by \"root\" or \"admin\", this is a finding.","fixText":"Change the ownership of the audit log file(s).\n\nProcedure:\n# chown root <audit log file>\n\n# chown root /var/log/audit/audit.log","ccis":["CCI-000162"]},{"vulnId":"V-239457","ruleId":"SV-239457r661822_rule","severity":"medium","ruleTitle":"The SLES for vRealize must protect audit information from unauthorized read access - group ownership.","description":"Unauthorized disclosure of audit records can reveal system and configuration data to attackers, thus compromising its confidentiality.\n\nAudit information includes all information (e.g., audit records, audit settings, audit reports) needed to successfully audit SLES for vRealize activity.","checkContent":"Verify that the SLES for vRealize audit logs are group-owned by \"root\".\n\n# (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)\n\nIf any audit log file is not group-owned by \"root\" or \"admin\", this is a finding.","fixText":"Change the group ownership of the audit log file(s).\n\nProcedure:\n# chgrp root <audit log file>\n\n# chgrp root /var/log/audit/audit.log","ccis":["CCI-000162"]},{"vulnId":"V-239458","ruleId":"SV-239458r661825_rule","severity":"medium","ruleTitle":"The SLES for vRealize must protect audit information from unauthorized modification.","description":"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.\n\nTo ensure the veracity of audit information, the SLES for vRealize must protect audit information from unauthorized modification.\n\nAudit information includes all information (e.g., audit records, audit settings, audit reports) needed to successfully audit information system activity.","checkContent":"Check that the SLES for vRealize audit logs with the following command:\n\n# (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)\n\nIf any audit log file has a mode more permissive than \"0640\", this is a finding.","fixText":"Change the mode of the audit log file(s):\n\n# chmod 0640 <audit log file>","ccis":["CCI-000163"]},{"vulnId":"V-239459","ruleId":"SV-239459r661828_rule","severity":"medium","ruleTitle":"The SLES for vRealize must protect audit information from unauthorized deletion.","description":"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.\n\nTo ensure the veracity of audit information, the SLES for vRealize must protect audit information from unauthorized deletion. This requirement can be achieved through multiple methods, which will depend upon system architecture and design.\n\nAudit information includes all information (e.g., audit records, audit settings, audit reports) needed to successfully audit information system activity.","checkContent":"Check that the SLES for vRealize audit logs with the following command:\n\n# (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)\n\nIf any audit log file has a mode more permissive than \"0640\", this is a finding.","fixText":"Change the mode of the audit log file(s):\n\n# chmod 0640 <audit log file>","ccis":["CCI-000164"]},{"vulnId":"V-239460","ruleId":"SV-239460r661831_rule","severity":"medium","ruleTitle":"The SLES for vRealize must protect audit information from unauthorized deletion - log directories.","description":"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.\n\nTo ensure the veracity of audit information, the SLES for vRealize must protect audit information from unauthorized deletion. This requirement can be achieved through multiple methods, which will depend upon system architecture and design.\n\nAudit information includes all information (e.g., audit records, audit settings, audit reports) needed to successfully audit information system activity.","checkContent":"Run the following command to check the mode of the system audit directories: \n\n# grep \"^log_file\" /etc/audit/auditd.conf|sed 's/^[^/]*//; s/[^/]*$//'|xargs stat -c %a:%n\n\nAudit directories must be mode \"0700\". \n\nIf the audit directories is not set to mode \"0700\", this is a finding.","fixText":"Change the mode of the audit log directories with the following command: \n\n# chmod 700 <audit log directory>","ccis":["CCI-000164"]},{"vulnId":"V-239474","ruleId":"SV-239474r661873_rule","severity":"medium","ruleTitle":"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.","description":"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.","checkContent":"Check the permissions of the rules files in /etc/audit:\n\n# ls -l /etc/audit/\n\nNote: If /etc/audit/audit.rules is a symbolic link to /etc/audit/audit.rules.STIG, then the check is only applicable to /etc/audit/audit.rules.STIG.\n\nIf the permissions of the file is not set to \"640\", this is a finding.","fixText":"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 symbolic link):\n\n# chmod 640 /etc/audit/audit.rules.STIG\n# chmod 640 /etc/audit/audit.rules.ORIG\n# if [ -f /etc/audit/audit.rules ]; then chmod 640 /etc/audit/audit.rules; fi\n\nOr run the following command to implement all logging requirements:\n\n# /etc/dodscript.sh","ccis":["CCI-000171"]},{"vulnId":"V-239475","ruleId":"SV-239475r661876_rule","severity":"medium","ruleTitle":"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.","description":"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.","checkContent":"Check the permissions of the rules files in /etc/audit:\n\n# ls -l /etc/audit/\n\nNote: If /etc/audit/audit.rules is a symbolic link to /etc/audit/audit.rules.STIG, then the check is only applicable to /etc/audit/audit.rules.STIG.\n\nIf the ownership is not set to \"root\", this is a finding.","fixText":"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 symbolic link):\n\n# chown root /etc/audit/audit.rules.STIG\n# chown root /etc/audit/audit.rules.ORIG\n# if [ -f /etc/audit/audit.rules ]; then chown root /etc/audit/audit.rules; fi\n\nOr run the following command to implement all logging requirements:\n\n# /etc/dodscript.sh","ccis":["CCI-000171"]},{"vulnId":"V-239476","ruleId":"SV-239476r661879_rule","severity":"medium","ruleTitle":"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.","description":"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.","checkContent":"Check the permissions of the rules files in /etc/audit:\n\n# ls -l /etc/audit/\n\nNote: If /etc/audit/audit.rules is a symbolic link to /etc/audit/audit.rules.STIG, then the check is only applicable to /etc/audit/audit.rules.STIG.\n\nIf the group owner is not set to \"root\", this is a finding.","fixText":"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 symbolic link):\n\n# chgrp root /etc/audit/audit.rules.STIG\n# chgrp root /etc/audit/audit.rules.ORIG\n# if [ -f /etc/audit/audit.rules ]; then chgrp root /etc/audit/audit.rules; fi\n\nOr run the following command to implement all logging requirements:\n\n# /etc/dodscript.sh","ccis":["CCI-000171"]},{"vulnId":"V-239477","ruleId":"SV-239477r661882_rule","severity":"medium","ruleTitle":"The SLES for vRealize must generate audit records when successful/unsuccessful attempts to access privileges occur. The operating system must generate audit records for all discretionary access control permission modifications using chmod.","description":"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.\n\nAudit records can be generated from various components within the information system (e.g., module or policy filter).","checkContent":"To determine if the system is configured to audit calls to the \"chmod\" system call, run the following command: \n\n# auditctl -l | grep syscall | grep chmod\n\nIf the system is configured to audit this activity, it will return several lines, such as: \n\nLIST_RULES: exit,always arch=3221225534 (0xc000003e) auid=0 syscall=chmod,fchmod,chown,fchown,fchownat,fchmodat\nLIST_RULES: exit,always arch=3221225534 (0xc000003e) auid>=500 (0x1f4) auid!=-1 (0xffffffff) syscall=chmod,fchmod,chown,fchown,fchownat,fchmodat\n\nIf no lines are returned, this is a finding.","fixText":"At a minimum, the audit system should collect file permission changes for all users and root. Add the following to \"/etc/audit/audit.rules\": \n\n-a always,exit -F arch=b64 -S chmod -F auid=0\n-a always,exit -F arch=b64 -S chmod -F auid>=500 -F auid!=4294967295\n\nOr run the following command to implement all logging requirements:\n\n# /etc/dodscript.sh","ccis":["CCI-000172"]},{"vulnId":"V-239478","ruleId":"SV-239478r661885_rule","severity":"medium","ruleTitle":"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.","description":"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.\n\nAudit records can be generated from various components within the information system (e.g., module or policy filter).","checkContent":"To determine if the SLES for vRealize is configured to audit calls to the \"chown\" system call, run the following command: \n\n# auditctl -l | grep syscall | grep chown\n\nIf the SLES for vRealize is configured to audit this activity, it will return several lines, such as: \n\nLIST_RULES: exit,always arch=3221225534 (0xc000003e) auid=0 syscall=chmod,fchmod,chown,fchown,fchownat,fchmodat\nLIST_RULES: exit,always arch=3221225534 (0xc000003e) auid>=500 (0x1f4) auid!=-1 (0xffffffff) syscall=chmod,fchmod,chown,fchown,fchownat,fchmodat\n\nIf no lines are returned, this is a finding.","fixText":"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\": \n\n-a always,exit -F arch=b64 -S chown -F auid=0\n-a always,exit -F arch=b64 -S chown -F auid>=500 -F auid!=4294967295\n\nOr run the following command to implement all logging requirements:\n\n# /etc/dodscript.sh","ccis":["CCI-000172"]},{"vulnId":"V-239479","ruleId":"SV-239479r661888_rule","severity":"medium","ruleTitle":"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.","description":"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.\n\nAudit records can be generated from various components within the information system (e.g., module or policy filter).","checkContent":"To determine if SLES for vRealize is configured to audit calls to the \"fchmod\" system call, run the following command: \n\n# auditctl -l | grep syscall | grep fchmod\n\nIf SLES for vRealize is configured to audit this activity, it will return several lines, such as: \n\nLIST_RULES: exit,always arch=3221225534 (0xc000003e) auid=0 syscall=chmod,fchmod,chown,fchown,fchownat,fchmodat\nLIST_RULES: exit,always arch=3221225534 (0xc000003e) auid>=500 (0x1f4) auid!=-1 (0xffffffff) syscall=chmod,fchmod,chown,fchown,fchownat,fchmodat\n\nIf no lines are returned, this is a finding.","fixText":"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\": \n\n-a always,exit -F arch=b64 -S fchmod -F auid=0\n-a always,exit -F arch=b64 -S fchmod -F auid>=500 -F auid!=4294967295\n\nOr run the following command to implement all logging requirements:\n\n# /etc/dodscript.sh","ccis":["CCI-000172"]},{"vulnId":"V-239480","ruleId":"SV-239480r661891_rule","severity":"medium","ruleTitle":"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.","description":"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.\n\nAudit records can be generated from various components within the information system (e.g., module or policy filter).","checkContent":"To determine if SLES for vRealize is configured to audit calls to the \"fchmodat\" system call, run the following command: \n\n# auditctl -l | grep syscall | grep fchmodat\n\nIf SLES for vRealize is configured to audit this activity, it will return several lines, such as: \n\nLIST_RULES: exit,always arch=3221225534 (0xc000003e) auid=0 syscall=chmod,fchmod,chown,fchown,fchownat,fchmodat\nLIST_RULES: exit,always arch=3221225534 (0xc000003e) auid>=500 (0x1f4) auid!=-1 (0xffffffff) syscall=chmod,fchmod,chown,fchown,fchownat,fchmodat\n\nIf no lines are returned, this is a finding.","fixText":"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\": \n\n-a always,exit -F arch=b64 -S fchmodat -F auid=0\n-a always,exit -F arch=b64 -S fchmodat -F auid>=500 -F auid!=4294967295\n\nOr run the following command to implement all logging requirements:\n\n# /etc/dodscript.sh","ccis":["CCI-000172"]},{"vulnId":"V-239481","ruleId":"SV-239481r661894_rule","severity":"medium","ruleTitle":"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.","description":"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.\n\nAudit records can be generated from various components within the information system (e.g., module or policy filter).","checkContent":"To determine if SLES for vRealize is configured to audit calls to the \"fchown\" system call, run the following command: \n\n# auditctl -l | grep syscall | grep fchown\n\nIf SLES for vRealize is configured to audit this activity, it will return several lines, such as:\n\nLIST_RULES: exit,always arch=3221225534 (0xc000003e) auid=0 syscall=chmod,fchmod,chown,fchown,fchownat,fchmodat\nLIST_RULES: exit,always arch=3221225534 (0xc000003e) auid>=500 (0x1f4) auid!=-1 (0xffffffff) syscall=chmod,fchmod,chown,fchown,fchownat,fchmodat\n\nIf no lines are returned, this is a finding.","fixText":"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\": \n\n-a always,exit -F arch=b64 -S fchown -F auid=0\n-a always,exit -F arch=b64 -S fchown -F auid>=500 -F auid!=4294967295\n\nOr run the following command to implement all logging requirements:\n\n# /etc/dodscript.sh","ccis":["CCI-000172"]},{"vulnId":"V-239482","ruleId":"SV-239482r661897_rule","severity":"medium","ruleTitle":"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.","description":"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.\n\nAudit records can be generated from various components within the information system (e.g., module or policy filter).","checkContent":"To determine if SLES for vRealize is configured to audit calls to the \"fchownat\" system call, run the following command: \n\n# auditctl -l | grep syscall | grep fchownat\n\nIf SLES for vRealize is configured to audit this activity, it will return several lines, such as:\n\nLIST_RULES: exit,always arch=3221225534 (0xc000003e) auid=0 syscall=chmod,fchmod,chown,fchown,fchownat,fchmodat\nLIST_RULES: exit,always arch=3221225534 (0xc000003e) auid>=500 (0x1f4) auid!=-1 (0xffffffff) syscall=chmod,fchmod,chown,fchown,fchownat,fchmodat\n\nIf no lines are returned, this is a finding.","fixText":"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\": \n\n-a always,exit -F arch=b64 -S fchownat -F auid=0\n-a always,exit -F arch=b64 -S fchownat -F auid>=500 -F auid!=4294967295\n\nOr run the following command to implement all logging requirements:\n\n# /etc/dodscript.sh","ccis":["CCI-000172"]},{"vulnId":"V-239483","ruleId":"SV-239483r661900_rule","severity":"medium","ruleTitle":"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.","description":"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.\n\nAudit records can be generated from various components within the information system (e.g., module or policy filter).","checkContent":"To determine if SLES for vRealize is configured to audit calls to the \"fremovexattr\" system call, run the following command: \n\n# auditctl -l | grep syscall | grep fremovexattr\n\nIf SLES for vRealize is configured to audit this activity, it will return several lines, such as: \n\nLIST_RULES: exit,always arch=3221225534 (0xc000003e) syscall=lchown,sethostname,init_module,delete_module,setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr,clock_settime\n\nIf no lines are returned, this is a finding.","fixText":"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\": \n\n-a always,exit -F arch=b64 -S fremovexattr\n\nOr run the following command to implement all logging requirements:\n\n# /etc/dodscript.sh","ccis":["CCI-000172"]},{"vulnId":"V-239484","ruleId":"SV-239484r661903_rule","severity":"medium","ruleTitle":"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.","description":"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.\n\nAudit records can be generated from various components within the information system (e.g., module or policy filter).","checkContent":"To determine if SLES for vRealize is configured to audit calls to the \"fsetxattr\" system call, run the following command: \n\n# auditctl -l | grep syscall | grep fsetxattr\n\nIf SLES for vRealize is configured to audit this activity, it will return several lines, such as:\n\nLIST_RULES: exit,always arch=3221225534 (0xc000003e) syscall=lchown,sethostname,init_module,delete_module,setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr,clock_settime\n\nIf no lines are returned, this is a finding.","fixText":"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\": \n\n-a always,exit -F arch=b64 -S fsetxattr\n\nOr run the following command to implement all logging requirements:\n\n# /etc/dodscript.sh","ccis":["CCI-000172"]},{"vulnId":"V-239485","ruleId":"SV-239485r661906_rule","severity":"medium","ruleTitle":"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.","description":"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.\n\nAudit records can be generated from various components within the information system (e.g., module or policy filter).","checkContent":"To determine if SLES for vRealize is configured to audit calls to the \"lchown\" system call, run the following command: \n\n# auditctl -l | grep syscall | grep lchown\n\nIf SLES for vRealize is configured to audit this activity, it will return several lines, such as:\n\nLIST_RULES: exit,always arch=3221225534 (0xc000003e) syscall=lchown,sethostname,init_module,delete_module,setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr,clock_settime\n\nIf no lines are returned, this is a finding.","fixText":"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\": \n\n-a always,exit -F arch=b64 -S lchown\n\nOr run the following command to implement all logging requirements:\n\n# /etc/dodscript.sh","ccis":["CCI-000172"]},{"vulnId":"V-239486","ruleId":"SV-239486r661909_rule","severity":"medium","ruleTitle":"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.","description":"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.\n\nAudit records can be generated from various components within the information system (e.g., module or policy filter).","checkContent":"To determine if SLES for vRealize is configured to audit calls to the \"lremovexattr\" system call, run the following command: \n\n# auditctl -l | grep syscall | grep lremovexattr\n\nIf SLES for vRealize is configured to audit this activity, it will return several lines, such as:\n\nLIST_RULES: exit,always arch=3221225534 (0xc000003e) syscall=lchown,sethostname,init_module,delete_module,setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr,clock_settime\n\nIf no lines are returned, this is a finding.","fixText":"At a minimum, the SLES for vRealize audit system should collect file permission changes for all users and \"root\".\n\nAdd the following to \"/etc/audit/audit.rules\": \n\n-a always,exit -F arch=b64 -S lremovexattr\n\nOr run the following command to implement all logging requirements:\n\n# /etc/dodscript.sh","ccis":["CCI-000172"]},{"vulnId":"V-239487","ruleId":"SV-239487r661912_rule","severity":"medium","ruleTitle":"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.","description":"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.\n\nAudit records can be generated from various components within the information system (e.g., module or policy filter).","checkContent":"To determine if SLES for vRealize is configured to audit calls to the \"lsetxattr\" system call, run the following command: \n\n# auditctl -l | grep syscall | grep lsetxattr\n\nIf SLES for vRealize is configured to audit this activity, it will return several lines, such as:\n\nLIST_RULES: exit,always arch=3221225534 (0xc000003e) syscall=lchown,sethostname,init_module,delete_module,setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr,clock_settime\n\nIf no lines are returned, this is a finding.","fixText":"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\": \n\n-a always,exit -F arch=b64 -S lsetxattr\n\nOr run the following command to implement all logging requirements:\n\n# /etc/dodscript.sh","ccis":["CCI-000172"]},{"vulnId":"V-239488","ruleId":"SV-239488r661915_rule","severity":"medium","ruleTitle":"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.","description":"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.\n\nAudit records can be generated from various components within the information system (e.g., module or policy filter).","checkContent":"To determine if SLES for vRealize is configured to audit calls to the \"removexattr\" system call, run the following command: \n\n# auditctl -l | grep syscall | grep removexattr\n\nIf SLES for vRealize is configured to audit this activity, it will return several lines, such as:\n\nLIST_RULES: exit,always arch=3221225534 (0xc000003e) syscall=lchown,sethostname,init_module,delete_module,setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr,clock_settime\n\nIf no lines are returned, this is a finding.","fixText":"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\": \n\n-a always,exit -F arch=b64 -S removexattr\n\nOr run the following command to implement all logging requirements:\n\n# /etc/dodscript.sh","ccis":["CCI-000172"]},{"vulnId":"V-239489","ruleId":"SV-239489r661918_rule","severity":"medium","ruleTitle":"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.","description":"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.\n\nAudit records can be generated from various components within the information system (e.g., module or policy filter).","checkContent":"To determine if SLES for vRealize  is configured to audit calls to the \"setxattr\" system call, run the following command: \n\n# auditctl -l | grep syscall | grep setxattr\n\nIf SLES for vRealize is configured to audit this activity, it will return several lines, such as:\n\nLIST_RULES: exit,always arch=3221225534 (0xc000003e) syscall=lchown,sethostname,init_module,delete_module,setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr,clock_settime\n\nIf no lines are returned, this is a finding.","fixText":"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\": \n\n-a always,exit -F arch=b64 -S setxattr\n\nOr run the following command to implement all logging requirements:\n\n# /etc/dodscript.sh","ccis":["CCI-000172"]},{"vulnId":"V-239490","ruleId":"SV-239490r661921_rule","severity":"medium","ruleTitle":"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.","description":"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.\n\nAudit records can be generated from various components within the information system (e.g., module or policy filter).","checkContent":"To check that the SLES for vRealize audit system collects unauthorized file accesses, run the following commands:\n\n# grep EACCES /etc/audit/audit.rules\n\n-a exit,always -F arch=b64 -S swapon -F exit=-EACCES\n-a exit,always -F arch=b64 -S creat -F exit=-EACCES\n-a exit,always -F arch=b64 -S open -F exit=-EACCES\n\n# grep EPERM /etc/audit/audit.rules\n\n-a exit,always -F arch=b64 -S swapon -F exit=-EPERM\n-a exit,always -F arch=b64 -S creat -F exit=-EPERM\n-a exit,always -F arch=b64 -S open -F exit=-EPERM\n\nIf either command lacks output, this is a finding.","fixText":"Add the following to \"/etc/audit/audit.rules\": \n\n-a exit,always -F arch=b64 -S swapon -F exit=-EACCES\n-a exit,always -F arch=b64 -S creat -F exit=-EACCES\n-a exit,always -F arch=b64 -S open -F exit=-EACCES\n\n-a exit,always -F arch=b64 -S swapon -F exit=-EPERM\n-a exit,always -F arch=b64 -S creat -F exit=-EPERM\n-a exit,always -F arch=b64 -S open -F exit=-EPERM\n\nOr run the following command to implement all logging requirements:\n\n# /etc/dodscript.sh","ccis":["CCI-000172"]},{"vulnId":"V-239491","ruleId":"SV-239491r661924_rule","severity":"medium","ruleTitle":"The SLES for vRealize must enforce password complexity by requiring that at least one upper-case character be used.","description":"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.\n\nPassword 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.","checkContent":"Check SLES for vRealize enforces password complexity by requiring that at least one upper-case character be used by using the following command:\n\n# grep ucredit /etc/pam.d/common-password-vmware.local\n\nIf \"ucredit\" is not set to \"-1\" or not at all, this is a finding.\n\nExpected Result:\npassword requisite pam_cracklib.so dcredit=-1 ucredit=-1 lcredit=-1 ocredit=-1 minlen=14 difok=4 retry=3","fixText":"If ucredit was not set at all in \"/etc/pam.d/common-password-vmware.local\" file then run the following command:\n\n# sed -i '/pam_cracklib.so/ s/$/ ucredit=-1/' /etc/pam.d/common-password-vmware.local\n\nIf \"ucredit\" was set incorrectly, run the following command to set it to \"-1\":\n\n# sed -i '/pam_cracklib.so/ s/ucredit=../ucredit=-1/' /etc/pam.d/common-password-vmware.local","ccis":["CCI-000192"]},{"vulnId":"V-239492","ruleId":"SV-239492r661927_rule","severity":"medium","ruleTitle":"Global settings defined in common- {account,auth,password,session} must be applied in the pam.d definition files.","description":"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.","checkContent":"Verify that common-{account, auth, password, session} settings are being applied:\n\nVerify 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.\n\nThe files \"/etc/pam.d/common-{account,auth,password,session} -pc\" are autogenerated by \"pam-config\". Any manual changes made to them will be lost if \"pam-config\" is allowed to run.\n\n# ls -l /etc/pam.d/common-{account,auth,password,session}\n\nIf 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.\n\n# ls -l /usr/sbin/pam-config\n\nIf the setting for pam-config is not \"000\", this is a finding.","fixText":"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 autogenerated by the pam-config utility. \n\nEdit /usr/sbin/pam-config permissions to prevent its use:\n\n# chmod 000 /usr/sbin/pam-config","ccis":["CCI-000192"]},{"vulnId":"V-239493","ruleId":"SV-239493r661930_rule","severity":"medium","ruleTitle":"The SLES for vRealize must enforce password complexity by requiring that at least one lower-case character be used.","description":"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.\n\nPassword 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.","checkContent":"Verify SLES for vRealize enforces password complexity by requiring that at least one lower-case character be used by using the following command:\n\n# grep lcredit /etc/pam.d/common-password-vmware.local\n\nIf \"lcredit\" is not set to \"-1\" or not at all, this is a finding.\n\nExpected Result:\npassword requisite pam_cracklib.so dcredit=-1 ucredit=-1 lcredit=-1 ocredit=-1 minlen=14 difok=4 retry=3","fixText":"If lcredit was not set at all in \"/etc/pam.d/common-password-vmware.local\" then run the following command:\n\n# sed -i '/pam_cracklib.so/ s/$/ lcredit=-1/' /etc/pam.d/common-password-vmware.local\n\nIf \"lcredit\" was set incorrectly, run the following command to set it to \"-1\":\n\n# sed -i '/pam_cracklib.so/ s/lcredit=../lcredit=-1/' /etc/pam.d/common-password-vmware.local","ccis":["CCI-000193"]},{"vulnId":"V-239494","ruleId":"SV-239494r661933_rule","severity":"medium","ruleTitle":"The SLES for vRealize must enforce password complexity by requiring that at least one numeric character be used.","description":"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.\n\nPassword 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.","checkContent":"Check that SLES for vRealize enforces password complexity by requiring that at least one numeric character be used by running the following command:\n\n# grep dcredit /etc/pam.d/common-password-vmware.local\n\nIf \"dcredit\" is not set to \"-1\" or not at all, this is a finding.\n\nExpected Result:\npassword requisite pam_cracklib.so dcredit=-1 ucredit=-1 lcredit=-1 ocredit=-1 minlen=14 difok=4 retry=3","fixText":"If dcredit was not set at all in \"/etc/pam.d/common-password-vmware.local\" then run the following command:\n\n# sed -i '/pam_cracklib.so/ s/$/ dcredit=-1/' /etc/pam.d/common-password-vmware.local\n\nIf \"dcredit\" was set incorrectly, run the following command to set it to \"-1\":\n\n# sed -i '/pam_cracklib.so/ s/dcredit=../dcredit=-1/' /etc/pam.d/common-password-vmware.local","ccis":["CCI-000194"]},{"vulnId":"V-239495","ruleId":"SV-239495r661936_rule","severity":"medium","ruleTitle":"The SLES for vRealize must require the change of at least eight of the total number of characters when passwords are changed.","description":"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.\n\nThe 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.","checkContent":"Check that at least eight characters need to be changed between old and new passwords during a password change by running the following command:\n\n# grep pam_cracklib /etc/pam.d/common-password-vmware.local\n\nThe \"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\". \n\nIf \"difok\" is not found or not set to at least \"8\", this is a finding.\n\nExpected Result:\npassword requisite pam_cracklib.so dcredit=-1 ucredit=-1 lcredit=-1 ocredit=-1 minlen=14 difok=8 retry=3","fixText":"If \"difok\" was not set at all in \"/etc/pam.d/common-password-vmware.local\" then run the following command:\n\n# sed -i '/pam_cracklib.so/ s/$/ difok-8/' /etc/pam.d/common-password-vmware.local\n\nIf \"difok\" was set incorrectly, run the following command to set it to \"8\":\n\n# sed -i '/pam_cracklib.so/ s/difok=./difok=8/' /etc/pam.d/common-password-vmware.local","ccis":["CCI-000195"]},{"vulnId":"V-239496","ruleId":"SV-239496r877397_rule","severity":"high","ruleTitle":"The SLES for vRealize must store only encrypted representations of passwords.","description":"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.","checkContent":"Check that the user account passwords are stored hashed using sha512 by running the following command:\n\n# cat /etc/default/passwd | grep CRYPT=sha512\n\nIf \"CRYPT=sha512\" is not listed, this is a finding.","fixText":"Ensure password are being encrypted with hash sha512 with the following command:\n\n# echo 'CRYPT=sha512'>>/etc/default/passwd","ccis":["CCI-000196"]},{"vulnId":"V-239497","ruleId":"SV-239497r661942_rule","severity":"medium","ruleTitle":"SLES for vRealize must enforce 24 hours/1 day as the minimum password lifetime.","description":"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.","checkContent":"To check that SLES for vRealize enforces 24 hours/1 day as the minimum password age, run the following command:\n\n# grep PASS_MIN_DAYS /etc/login.defs | grep -v '#'\n\nThe DoD requirement is \"1\".\n\nIf \"PASS_MIN_DAYS\" is not set to the required value, this is a finding.","fixText":"To configure SLES for vRealize to enforce 24 hours/1 day as the minimum password age, edit the file \"/etc/login.defs\" with the following command:\n\n# sed -i \"/^[^#]*PASS_MIN_DAYS/ c\\PASS_MIN_DAYS 1\" /etc/login.defs","ccis":["CCI-000198"]},{"vulnId":"V-239498","ruleId":"SV-239498r661945_rule","severity":"medium","ruleTitle":"Users must not be able to change passwords more than once every 24 hours.","description":"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.","checkContent":"Check the minimum time period between password changes for each user account is \"1\" day.\n\n# cat /etc/shadow | cut -d ':' -f1,4 | grep -v 1 | grep -v \":$\"\n\nIf any results are returned, this is a finding.","fixText":"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.\n\n# passwd -n 1 [USER]","ccis":["CCI-000198"]},{"vulnId":"V-239499","ruleId":"SV-239499r661948_rule","severity":"medium","ruleTitle":"SLES for vRealize must enforce a 60-day maximum password lifetime restriction.","description":"Any password, no matter how complex, can eventually be cracked. Therefore, passwords need to be changed periodically. If SLES for vRealize does not limit the lifetime of passwords and force users to change their passwords, there is the risk that SLES for vRealize passwords could be compromised.","checkContent":"To check that SLES for vRealize enforces a \"60\" days or less maximum password age, run the following command:\n\n# grep PASS_MAX_DAYS /etc/login.defs | grep -v \"#\"\n\nThe DoD requirement is \"60\" days or less (Greater than zero, as zero days will lock the account immediately). \n\nIf \"PASS_MAX_DAYS\" is not set to the required value, this is a finding.","fixText":"To configure 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.\n\n# sed -i \"/^[^#]*PASS_MAX_DAYS/ c\\PASS_MAX_DAYS 60\" /etc/login.defs\n\nThe DoD requirement is \"60\" days or less (Greater than zero, as zero days will lock the account immediately).","ccis":["CCI-000199"]},{"vulnId":"V-239500","ruleId":"SV-239500r661951_rule","severity":"medium","ruleTitle":"User passwords must be changed at least every 60 days.","description":"Any password, no matter how complex, can eventually be cracked. Therefore, passwords need to be changed periodically. If SLES for vRealize does not limit the lifetime of passwords and force users to change their passwords, there is the risk that SLES for vRealize passwords could be compromised.","checkContent":"Check the max days field of \"/etc/shadow\" by running the following command:\n\n# cat /etc/shadow | cut -d':' -f1,5 | egrep -v \"([0|60])\" | grep -v \":$\"\n\nIf any results are returned, this is a finding.","fixText":"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.\n\n# passwd -x 60 [USER]\n\nThe DoD requirement is \"60\" days.","ccis":["CCI-000199"]},{"vulnId":"V-239501","ruleId":"SV-239501r661954_rule","severity":"medium","ruleTitle":"The SLES for vRealize must prohibit password reuse for a minimum of five generations.","description":"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.","checkContent":"Verify that SLES for vRealize prohibits the reuse of a password for a minimum of five generations, by running the following commands:\n\n# grep pam_pwhistory.so /etc/pam.d/common-password-vmware.local \n\nIf the \"remember\" option in \"/etc/pam.d/common-password-vmware.local\" file is not \"5\" or greater, this is a finding.","fixText":"Configure pam to use password history. \n\nIf the \"remember\" option was not set at all in \"/etc/pam.d/common-password-vmware.local\" file then run the following command:\n\n# sed -i '/pam_cracklib.so/ s/$/ remember=5/' /etc/pam.d/common-password-vmware.local\n\nIf \"remember\" option was set incorrectly, run the following command to set it to \"5\":\n\n# sed -i '/pam_cracklib.so/ s/remember=./remember=5/' /etc/pam.d/common-password-vmware.local","ccis":["CCI-000200"]},{"vulnId":"V-239502","ruleId":"SV-239502r661957_rule","severity":"medium","ruleTitle":"The SLES for vRealize must prohibit password reuse for a minimum of five generations. Ensure the old passwords are being stored.","description":"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.","checkContent":"Verify that the old password file, \"opasswd\", exists, by running the following command:\n\n# ls /etc/security/opasswd\n\nIf \"/etc/security/opasswd\" file does not exist, this is a finding.","fixText":"Create the password history file. \n\n# touch /etc/security/opasswd\n# chown root:root /etc/security/opasswd\n# chmod 0600 /etc/security/opasswd","ccis":["CCI-000200"]},{"vulnId":"V-239503","ruleId":"SV-239503r661960_rule","severity":"medium","ruleTitle":"The SLES for vRealize must enforce a minimum 15-character password length.","description":"The shorter the password, the lower the number of possible combinations that need to be tested before the password is compromised.\n\nPassword 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.","checkContent":"Verify that SLES for vRealize enforces a minimum 15-character password length, by running the following command:\n\n# grep pam_cracklib /etc/pam.d/common-password-vmware.local\n\n# grep pam_cracklib /etc/pam.d/common-password\n\nIf the result does not contain \"minlen=15\" or higher, this is a finding.","fixText":"If \"minlen\" was not set at all in \"/etc/pam.d/common-password-vmware.local\" file then run the following command:\n\n# sed -i '/pam_cracklib.so/ s/$/ minlen=15/' /etc/pam.d/common-password-vmware.local\n\nIf \"minlen\" was set incorrectly, run the following command to set it to \"15\":\n\n# sed -i '/pam_cracklib.so/ s/minlen=../minlen=15/' /etc/pam.d/common-password-vmware.local","ccis":["CCI-000205"]},{"vulnId":"V-239504","ruleId":"SV-239504r661963_rule","severity":"medium","ruleTitle":"The SLES for vRealize must require root password authentication upon booting into single-user mode.","description":"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.\n\nAccess 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.","checkContent":"Verify that root password is required for single user mode logon with the following command:\n\n# grep sulogin /etc/inittab\n\nExpected result:\n~~:S:respawn:/sbin/sulogin\n\nIf the expected result is not displayed, this is a finding.","fixText":"Configure SLES for vRealize to require root password login with single user mode use the following command:\n\n# echo '~~:S:respawn:/sbin/sulogin' >> /etc/inittab","ccis":["CCI-000213"]},{"vulnId":"V-239505","ruleId":"SV-239505r661966_rule","severity":"medium","ruleTitle":"Bootloader authentication must be enabled to prevent users without privilege to gain access restricted file system resources.","description":"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.\n\nAccess 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.","checkContent":"To verify a boot password exists. In \"/boot/grub/menu.lst\" run the following command:\n\n# grep password /boot/grub/menu.lst\n\nThe output should show the following: \n\npassword --encrypted $1$[rest-of-the-password-hash]\n\nIf it does not, this is a finding.","fixText":"Run the following command: \n\n# /usr/sbin/grub-md5-crypt \n\nAn MD5 password is generated. After the password is supplied, the command supplies the md5 hash output.\n\nAppend the password to the menu.lst file by running the following command:\n\necho 'password --md5 <hash from grub-md5-crypt>' >> /boot/grub/menu.lst\n\nOr use \"yast2\" to set the bootloader password:\n\nOpen the Boot Loader Installation tab.\nClick Boot Loader Options.\nActivate the Protect Boot Loader with Password option with a click and type in your Password twice.\n\nClick \"OK\" twice to save the changes.","ccis":["CCI-000213"]},{"vulnId":"V-239506","ruleId":"SV-239506r661969_rule","severity":"medium","ruleTitle":"The SLES for the vRealize boot loader configuration file(s) must have mode 0600 or less permissive.","description":"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.","checkContent":"Check the /boot/grub/menu.lst file:\n\n# stat /boot/grub/menu.lst\n\nIf \"/boot/grub/menu.lst\" has a mode more permissive than \"0600\", this is a finding.","fixText":"Change the mode of the \"/boot/grub/menu.lst\" file to \"0600\":\n\n# chmod 0600 /boot/grub/menu.lst","ccis":["CCI-000213"]},{"vulnId":"V-239507","ruleId":"SV-239507r661972_rule","severity":"medium","ruleTitle":"The SLES for the vRealize boot loader configuration files must be owned by root.","description":"The SLES for vRealize’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.","checkContent":"Check \"/boot/grub/menu.lst\" file ownership:\n\n# stat /boot/grub/menu.lst\n\nIf the owner of the file is not \"root\", this is a finding.","fixText":"Change the ownership of the \"/boot/grub/menu.lst\" file:\n\n# chown root /boot/grub/menu.lst","ccis":["CCI-000213"]},{"vulnId":"V-239508","ruleId":"SV-239508r661975_rule","severity":"medium","ruleTitle":"The SLES for the vRealize boot loader configuration file(s) must be group-owned by root, bin, sys, or system.","description":"The SLES for vRealize’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.","checkContent":"Check \"/boot/grub/menu.lst\" file ownership:\n\n# stat /boot/grub/menu.lst\n\nIf the group-owner of the file is not \"root\", \"bin\", \"sys\", or \"system\", this is a finding.","fixText":"Change the group-ownership of the \"/boot/grub/menu.lst\" file:\n\n# chgrp root /boot/grub/menu.lst","ccis":["CCI-000213"]},{"vulnId":"V-239509","ruleId":"SV-239509r661978_rule","severity":"medium","ruleTitle":"The Bluetooth protocol handler must be disabled or not installed.","description":"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.","checkContent":"Verify the Bluetooth protocol handler is prevented from dynamic loading:\n\n# grep \"install bluetooth /bin/true\" /etc/modprobe.conf /etc/modprobe.conf.local /etc/modprobe.d/*\n\nIf no result is returned, this is a finding.","fixText":"Prevent the Bluetooth protocol handler for dynamic loading:\n\n# echo \"install bluetooth /bin/true\" >> /etc/modprobe.conf.local","ccis":["CCI-000381"]},{"vulnId":"V-239510","ruleId":"SV-239510r661981_rule","severity":"medium","ruleTitle":"The SLES for vRealize must have USB Mass Storage disabled unless needed.","description":"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.","checkContent":"If SLES for vRealize needs USB storage, this vulnerability is not applicable.\n\nCheck if the \"usb-storage\" module is prevented from loading:\n\n# grep \"install usb-storage /bin/true\" /etc/modprobe.conf /etc/modprobe.conf.local /etc/modprobe.d/*\n\nIf no results are returned, this is a finding.","fixText":"Prevent the \"usb-storage\" module from loading:\n\n# echo \"install usb-storage /bin/true\" >> /etc/modprobe.conf.local","ccis":["CCI-000381"]},{"vulnId":"V-239511","ruleId":"SV-239511r661984_rule","severity":"medium","ruleTitle":"The SLES for vRealize must have USB disabled unless needed.","description":"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.","checkContent":"If SLES for vRealize needs USB, this vulnerability is not applicable.\n\nCheck if the directory \"/proc/bus/usb exists\". \n\nIf the directory \"/proc/bus/usb exists\", this is a finding.","fixText":"Edit the grub bootloader file, \"/boot/grub/menu.lst\" file, by appending the \"nousb\" parameter to the kernel boot line.","ccis":["CCI-000381"]},{"vulnId":"V-239512","ruleId":"SV-239512r661987_rule","severity":"medium","ruleTitle":"The telnet-server package must not be installed.","description":"Removing the \"telnet-server\" package decreases the risk of the unencrypted telnet service's accidental (or intentional) activation.","checkContent":"Check if \"telnet-server\" package is installed:\n\n# rpm -q telnet-server\n\nIf there is a \"telnet-server\" package listed, this is a finding.","fixText":"To remove the \"telnet-server\" package use the following command:\n\nrpm -e telnet-server","ccis":["CCI-000381"]},{"vulnId":"V-239513","ruleId":"SV-239513r661990_rule","severity":"medium","ruleTitle":"The rsh-server package must not be installed.","description":"The \"rsh-server\" package provides several obsolete and insecure network services. Removing it decreases the risk of those services' accidental (or intentional) activation.","checkContent":"Check if \"rsh-server\" package is installed:\n\n# rpm -q rsh-server\n\nIf there is a \"rsh-server\" package listed, this is a finding.","fixText":"To remove the \"telnet-server\" package use the following command:\n\nrpm -e rsh-server","ccis":["CCI-000381"]},{"vulnId":"V-239514","ruleId":"SV-239514r661993_rule","severity":"medium","ruleTitle":"The ypserv package must not be installed.","description":"Removing the \"ypserv\" package decreases the risk of the accidental (or intentional) activation of NIS or NIS+ services.","checkContent":"Check if \"ypserv\" package is installed:\n\n# rpm -q ypserv\n\nIf there is a \"ypserv\" package listed, this is a finding.","fixText":"To remove the \"ypserv\" package use the following command:\n\nrpm -e ypserv","ccis":["CCI-000381"]},{"vulnId":"V-239515","ruleId":"SV-239515r661996_rule","severity":"medium","ruleTitle":"The yast2-tftp-server package must not be installed.","description":"Removing the \"yast2-tftp-server\" package decreases the risk of the accidental (or intentional) activation of tftp services.","checkContent":"Check if \"yast2-tftp-server\" package is installed:\n\n# rpm -q yast2-tftp-server\n\nIf there is a \"yast2-tftp-server\" package listed, this is a finding.","fixText":"To remove the \"yast2-tftp-server\" package use the following command:\n\nrpm -e yast2-tftp-server","ccis":["CCI-000381"]},{"vulnId":"V-239516","ruleId":"SV-239516r661999_rule","severity":"medium","ruleTitle":"The Datagram Congestion Control Protocol (DCCP) must be disabled unless required.","description":"The Datagram Congestion Control Protocol (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.","checkContent":"Check that the DCCP protocol handler is prevented from dynamic loading:\n\n# grep \"install dccp /bin/true\" /etc/modprobe.conf /etc/modprobe.conf.local /etc/modprobe.d/* \n\nIf no result is returned, this is a finding.\n\n# grep \"install dccp_ipv4 /bin/true\" /etc/modprobe.conf /etc/modprobe.conf.local /etc/modprobe.d/* \n\nIf no result is returned, this is a finding.\n\n# grep \"install dccp_ipv6\" /etc/modprobe.conf /etc/modprobe.conf.local /etc/modprobe.d/* | grep ‘bin/true’\n\nIf no result is returned, this is a finding.","fixText":"Prevent the DCCP protocol handler for dynamic loading:\n\n# echo \"install dccp /bin/true\" >> /etc/modprobe.conf.local\n# echo \"install dccp_ipv4 /bin/true\" >> /etc/modprobe.conf.local\n# echo \"install dccp_ipv6 /bin/true\" >> /etc/modprobe.conf.local","ccis":["CCI-000382"]},{"vulnId":"V-239517","ruleId":"SV-239517r662002_rule","severity":"medium","ruleTitle":"The Stream Control Transmission Protocol (SCTP) must be disabled unless required.","description":"The Stream Control Transmission Protocol (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.","checkContent":"Verify the SCTP protocol handler is prevented from dynamic loading:\n\n# grep \"install sctp /bin/true\" /etc/modprobe.conf /etc/modprobe.conf.local /etc/modprobe.d/*\n\nIf no result is returned, this is a finding.","fixText":"Prevent the SCTP protocol handler from dynamic loading:\n\n# echo \"install sctp /bin/true\" >> /etc/modprobe.conf.local","ccis":["CCI-000382"]},{"vulnId":"V-239518","ruleId":"SV-239518r662005_rule","severity":"medium","ruleTitle":"The Reliable Datagram Sockets (RDS) protocol must be disabled or not installed unless required.","description":"The Reliable Datagram Sockets (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.","checkContent":"Ask the SA if RDS is required by application software running on the system. If so, this is not applicable.\n\nCheck that the RDS protocol handler is prevented from dynamic loading:\n\n# grep \"install rds /bin/true\" /etc/modprobe.conf /etc/modprobe.conf.local /etc/modprobe.d/*\n\nIf no result is returned, this is a finding.","fixText":"Prevent the RDS protocol handler from dynamic loading:\n\n# echo \"install rds /bin/true\" >> /etc/modprobe.conf.local","ccis":["CCI-000382"]},{"vulnId":"V-239519","ruleId":"SV-239519r662008_rule","severity":"medium","ruleTitle":"The Transparent Inter-Process Communication (TIPC) must be disabled or not installed.","description":"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.","checkContent":"Verify the TIPC protocol handler is prevented from dynamic loading:\n\n# grep \"install tipc /bin/true\" /etc/modprobe.conf /etc/modprobe.conf.local /etc/modprobe.d/* \n\nIf no result is returned, this is a finding.","fixText":"Prevent the TIPC protocol handler from dynamic loading:\n\n# echo \"install tipc /bin/true\" >> /etc/modprobe.conf.local","ccis":["CCI-000382"]},{"vulnId":"V-239520","ruleId":"SV-239520r662011_rule","severity":"medium","ruleTitle":"The xinetd service must be disabled if no network services utilizing it are enabled.","description":"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.","checkContent":"If network services are using the \"xinetd\" service, this is not applicable.\n\nTo check that the \"xinetd\" service is disabled in system boot configuration, run the following command: \n\n# chkconfig \"xinetd\" --list\n\nOutput should indicate the \"xinetd\" service has either not been installed, or has been disabled at all run levels, as shown in the example below: \n\nxinetd 0:off 1:off 2:off 3:off 4:off 5:off 6:off\n\nRun the following command to verify \"xinetd\" is disabled through current runtime configuration: \n\n# service xinetd status\n\nIf the \"xinetd\" service is disabled the command will return the following output: \n\nChecking for service xinetd: unused\n\nIf the \"xinetd\" service is running, this is a finding.","fixText":"The \"xinetd\" service can be disabled with the following command: \n\n# chkconfig xinetd off","ccis":["CCI-000382"]},{"vulnId":"V-239521","ruleId":"SV-239521r662014_rule","severity":"medium","ruleTitle":"The ypbind service must not be running if no network services utilizing it are enabled.","description":"Disabling the \"ypbind\" service ensures the SLES for vRealize is not acting as a client in a NIS or NIS+ domain when not required.","checkContent":"If network services are using the \"ypbind\" service, this is not applicable.\n\nTo check that the \"ypbind\" service is disabled in system boot configuration, run the following command: \n\n# chkconfig \"ypbind\" --list\n\nOutput should indicate the \"ypbind\" service has either not been installed, or has been disabled at all runlevels, as shown in the example below: \n\nypbind 0:off 1:off 2:off 3:off 4:off 5:off 6:off\n\nRun the following command to verify \"ypbind\" is disabled through current runtime configuration: \n\n# service ypbind status\n\nIf the \"ypbind\" service is disabled the command will return the following output: \n\nChecking for service ypbind unused\n\nIf the \"ypbind\" service is running, this is a finding.","fixText":"The \"ypbind\" service can be disabled with the following command: \n\n# chkconfig ypbind off","ccis":["CCI-000382"]},{"vulnId":"V-239522","ruleId":"SV-239522r662017_rule","severity":"medium","ruleTitle":"NIS/NIS+/yp files must be owned by root, sys, or bin.","description":"NIS/NIS+/yp files are part of the system's identification and authentication processes and are, therefore, critical to system security. Failure to give ownership of sensitive files or utilities to root or bin 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.","checkContent":"Perform the following to check NIS file ownership:\n\n# ls -la /var/yp/*\n\nIf the NIS file ownership is not \"root\", sys, or bin, this is a finding.","fixText":"Change the ownership of NIS/NIS+/yp files to \"root\", \"sys\", \"bin\", or \"system\". Consult vendor documentation to determine the location of the files:\n\n# chown root <filename>","ccis":["CCI-000382"]},{"vulnId":"V-239523","ruleId":"SV-239523r662020_rule","severity":"medium","ruleTitle":"The NIS/NIS+/yp command files must have mode 0755 or less permissive.","description":"NIS/NIS+/yp files are part of the system's identification and authentication processes and are, therefore, critical to system security. Unauthorized modification of these files could compromise these processes and SLES for vRealize.","checkContent":"Perform the following to check NIS file ownership:\n\n# ls -la /var/yp/*\n\nIf the NIS file's mode is more permissive than \"0755\", this is a finding.","fixText":"Change the mode of NIS/NIS+/yp command files to \"0755\" or less permissive:\n\n# chmod 0755 <filename>","ccis":["CCI-000382"]},{"vulnId":"V-239524","ruleId":"SV-239524r662023_rule","severity":"medium","ruleTitle":"The SLES for vRealize must not use UDP for NIS/NIS+.","description":"Implementing NIS or NIS+ under UDP may make SLES for vRealize more susceptible to a denial of service attack and does not provide the same quality of service as TCP.","checkContent":"If SLES for vRealize does not use NIS or NIS+, this is not applicable.\n\nCheck if NIS or NIS+ is implemented using UDP:\n\n# rpcinfo -p | grep yp | grep udp\n\nIf NIS or NIS+ is implemented using UDP, this is a finding.","fixText":"Configure SLES for vRealize to not use UDP for NIS and NIS+. Consult vendor documentation for the required procedure.","ccis":["CCI-000382"]},{"vulnId":"V-239525","ruleId":"SV-239525r662026_rule","severity":"medium","ruleTitle":"NIS maps must be protected through hard-to-guess domain names.","description":"The use of hard-to-guess NIS domain names provides additional protection from unauthorized access to the NIS directory information.","checkContent":"If SLES for vRealize does not use NIS or NIS+, this is not applicable.\n\nCheck the domain name for NIS maps:\n\n# domainname\n\nIf the name returned is simple to guess, such as the organization name, building or room name, etc., this is a finding.","fixText":"Change the NIS domainname to a value difficult to guess. Consult vendor documentation for the required procedure.","ccis":["CCI-000382"]},{"vulnId":"V-239526","ruleId":"SV-239526r662029_rule","severity":"medium","ruleTitle":"Mail relaying must be restricted.","description":"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.","checkContent":"Determine if Sendmail only binds to loopback addresses by examining the \"DaemonPortOptions\" configuration options.\n\n# grep -i \"O DaemonPortOptions\" /etc/sendmail.cf\n\nIf there are uncommented \"DaemonPortOptions\" lines, and all such lines specify system loopback addresses, this is not a finding.\n\nOtherwise, determine if \"Sendmail\" is configured to allow open relay operation.\n\n# grep -i promiscuous_relay /etc/mail/sendmail.mc\n\nIf the promiscuous relay feature is enabled, this is a finding.","fixText":"If 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.\n\n# sed -i \"s/O DaemonPortOptions=Name=MTA/O DaemonPortOptions=Addr=127.0.0.1,Port=smtp,Name=MTA/\" /etc/sendmail.cf\n\nRestart the sendmail service:\n\n# service sendmail restart","ccis":["CCI-000382"]},{"vulnId":"V-239527","ruleId":"SV-239527r662032_rule","severity":"medium","ruleTitle":"The alias files must be owned by root.","description":"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.","checkContent":"Check the ownership of the alias file:\n\n# ls -lL /etc/aliases\n# ls -lL /etc/aliases.db\n\nIf all the files are not owned by \"root\", this is a finding.","fixText":"Change the owner of the alias files to \"root\":\n\n# chown root /etc/aliases\n# chown root /etc/aliases.db","ccis":["CCI-000382"]},{"vulnId":"V-239528","ruleId":"SV-239528r662035_rule","severity":"medium","ruleTitle":"The alias files must be group-owned by root, or a system group.","description":"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.","checkContent":"Check the group ownership of the alias files:\n\n# ls -lL /etc/aliases\n# ls -lL /etc/aliases.db\n\nIf the files are not group-owned by \"root\", this is a finding.","fixText":"Change the group owner of the alias files to \"root\":\n\n# chgrp root /etc/aliases\n# chgrp root /etc/aliases.db","ccis":["CCI-000382"]},{"vulnId":"V-239529","ruleId":"SV-239529r662038_rule","severity":"medium","ruleTitle":"The alias files must have mode 0644 or less permissive.","description":"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.","checkContent":"Check the permissions of the alias files:\n\n# ls -lL /etc/aliases\n# ls -lL /etc/aliases.db\n\nIf the alias files have a mode more permissive than \"0644\", this is a finding.","fixText":"Change the mode of the alias files to \"0644\":\n\n# chmod 0644 /etc/aliases /etc/aliases.db","ccis":["CCI-000382"]},{"vulnId":"V-239530","ruleId":"SV-239530r662041_rule","severity":"medium","ruleTitle":"Files executed through a mail aliases file must be owned by root and must reside within a directory owned and writable only by root.","description":"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.","checkContent":"Verify the ownership of files referenced within the sendmail aliases file:\n\n# more /etc/aliases\n\nExamine the aliases file for any utilized directories or paths:\n\n# ls -lL <directory or file path>\n\nCheck the owner for any paths referenced. Check if the file or parent directory is owned by root. \n\nIf the file or parent directory is not owned by \"root\", this is a finding.","fixText":"Edit the \"/etc/aliases\" file (alternatively, /usr/lib/sendmail.cf). Locate the entries executing a program. They will appear similar to the following line:\n\nAliasname: : /usr/local/bin/ls (or some other program name)\n\nEnsure \"root\" owns the programs and the directory(ies) they reside in by using the chown command to change owner to \"root\":\n\n# chown root <file or directory name>","ccis":["CCI-000382"]},{"vulnId":"V-239531","ruleId":"SV-239531r662044_rule","severity":"medium","ruleTitle":"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.","description":"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.","checkContent":"Examine the contents of the \"/etc/aliases\" file:\n\n# more /etc/aliases\n\nExamine the aliases file for any directories or paths that may be utilized:\n\n# ls -lL <file referenced from aliases>\n\nCheck the permissions for any paths referenced. \n\nIf the group owner of any file is not \"root\", \"bin\", \"sys\", or \"system\", this is a finding.","fixText":"Change the group ownership of the file referenced from \"/etc/mail/aliases\":\n\n# chgrp root <file referenced from aliases>","ccis":["CCI-000382"]},{"vulnId":"V-239532","ruleId":"SV-239532r662047_rule","severity":"medium","ruleTitle":"Files executed through a mail aliases file must have mode 0755 or less permissive.","description":"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.","checkContent":"Examine the contents of the \"/etc/aliases\" file:\n\n# more /etc/aliases\n\nExamine the aliases file for any directories or paths that may be utilized:\n\n# ls -lL <file referenced from aliases>\n\nCheck the permissions for any paths referenced. \n\nIf any file referenced from the aliases file has a mode more permissive than \"0755\", this is a finding.","fixText":"Use the chmod command to change the access permissions for files executed from the alias file:\n\n# chmod 0755 <file referenced from aliases>","ccis":["CCI-000382"]},{"vulnId":"V-239533","ruleId":"SV-239533r662050_rule","severity":"medium","ruleTitle":"Sendmail logging must not be set to less than nine in the sendmail.cf file.","description":"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.","checkContent":"Check sendmail to determine if the logging level is set to level \"9\":\n\n# grep \"O L\" /etc/sendmail.cf\nOR\n# grep LogLevel /etc/sendmail.cf\n\nIf logging is set to less than \"9\", this is a finding.","fixText":"Edit the \"sendmail.cf\" file, locate the \"O L\" or \"LogLevel\" entry, and change it to \"9\".","ccis":["CCI-000382"]},{"vulnId":"V-239534","ruleId":"SV-239534r662053_rule","severity":"medium","ruleTitle":"The system syslog service must log informational and more severe SMTP service messages.","description":"If informational and more severe SMTP service messages are not logged, malicious activity on the system may go unnoticed.","checkContent":"Check the \"/etc/syslog-ng/syslog-ng.conf\" file for the following log entries:\n\nfilter f_mailinfo { level(info) and facility(mail); };\nfilter f_mailwarn { level(warn) and facility(mail); };\nfilter f_mailerr { level(err, crit) and facility(mail); };\nfilter f_mail { facility(mail); };\n\nIf any of the above log entries are present, this is not a finding.","fixText":"Edit the \"/etc/syslog-ng/syslog-ng.conf\" file and add the following log entries:\n\nfilter f_mailinfo { level(info) and facility(mail); };\nfilter f_mailwarn { level(warn) and facility(mail); };\nfilter f_mailerr { level(err, crit) and facility(mail); };\nfilter f_mail { facility(mail); };\n\ndestination mailinfo { file(\"/var/log/mail.info\"); };\nlog { source(src); filter(f_mailinfo); destination(mailinfo); };\n\ndestination mailwarn { file(\"/var/log/mail.warn\"); };\nlog { source(src); filter(f_mailwarn); destination(mailwarn); };\n\ndestination mailerr { file(\"/var/log/mail.err\" fsync(yes)); };\nlog { source(src); filter(f_mailerr); destination(mailerr); };","ccis":["CCI-000382"]},{"vulnId":"V-239535","ruleId":"SV-239535r662056_rule","severity":"medium","ruleTitle":"The SMTP service log files must be owned by root.","description":"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.","checkContent":"Check the permissions on the mail log files:\n\n# ls -la /var/log/mail\n# ls -la /var/log/mail.info\n# ls -la /var/log/mail.warn\n# ls -la /var/log/mail.err\n\nIf any mail log file is not owned by \"root\", this is a finding.","fixText":"Change the ownership of the sendmail log files to \"root\":\n\n# chown root <sendmail log file>","ccis":["CCI-000382"]},{"vulnId":"V-239536","ruleId":"SV-239536r662059_rule","severity":"medium","ruleTitle":"The SMTP service log file must have mode 0644 or less permissive.","description":"If the SMTP service log file is more permissive than 0644, unauthorized users may be allowed to change the log file.","checkContent":"Check the permissions on the mail log files:\n\n# ls -la /var/log/mail\n# ls -la /var/log/mail.info\n# ls -la /var/log/mail.warn\n# ls -la /var/log/mail.err\n\nIf the log file permissions are greater than \"0644\", this is a finding.","fixText":"Change the mode of the sendmail log files to \"0644\":\n\n# chmod 0644 <sendmail log file>","ccis":["CCI-000382"]},{"vulnId":"V-239537","ruleId":"SV-239537r662062_rule","severity":"medium","ruleTitle":"The SMTP service HELP command must not be enabled.","description":"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.","checkContent":"Check the permissions of the sendmail helpfile:\n\nls -al /usr/lib/sendmail.d/helpfile\n\nIf the permissions are not \"0000\", this is a finding.","fixText":"Run the following command to disable the sendmail helpfile:\n\n# chmod 0000 /usr/lib/sendmail.d/helpfile","ccis":["CCI-000382"]},{"vulnId":"V-239538","ruleId":"SV-239538r662065_rule","severity":"medium","ruleTitle":"The SMTP services SMTP greeting must not provide version information.","description":"The version of the SMTP service can be used by attackers to plan an attack based on vulnerabilities present in the specific version.","checkContent":"To check for the sendmail version being displayed in the greeting:\n\n# more /etc/sendmail.cf | grep SmtpGreetingMessage\n\nIf it returns: \n\nO SmtpGreetingMessage=$j Sendmail $v/$Z; $b\n\nThen sendmail is providing version information, this is a finding.","fixText":"Change the \"O SmtpGreetingMessage\" line in the \"/etc/sendmail.cf\" file to:\n\nO SmtpGreetingMessage= Mail Server Ready ; $b","ccis":["CCI-000382"]},{"vulnId":"V-239539","ruleId":"SV-239539r662068_rule","severity":"medium","ruleTitle":"The SMTP service must not use .forward files.","description":"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 that could degrade system performance.","checkContent":"Check forwarding from sendmail:\n\n# grep \"0 ForwardPath\" /etc/sendmail.cf\n\nIf the entry contains a file path and is not commented out, this is a finding.","fixText":"Disable forwarding for sendmail and remove \".forward\" files from the system:\n\nRemove all \".forward\" files on the system.\n\n# find / -name .forward -delete\n\nUse the following command to disable forwarding:\n\n# sed -i \"s/O ForwardPath/#O ForwardPath/\" /etc/sendmail.cf\n\nRestart the sendmail service:\n\n# service sendmail restart","ccis":["CCI-000382"]},{"vulnId":"V-239540","ruleId":"SV-239540r662071_rule","severity":"medium","ruleTitle":"The SMTP service must not have the EXPN feature active.","description":"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.","checkContent":"Use the following command to check if EXPN is disabled:\n\n# grep -v \"^#\" /etc/sendmail.cf |grep -i PrivacyOptions\n\nIf \"noexpn\" is not returned, this is a finding.","fixText":"Add \"noexpn\" to the \"PrivacyOptions\" flag in the \"/etc/sendmail.cf\" file.","ccis":["CCI-000382"]},{"vulnId":"V-239541","ruleId":"SV-239541r662074_rule","severity":"medium","ruleTitle":"The SMTP service must not have the VRFY feature active.","description":"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.","checkContent":"Use the following command to check if VRFY is disabled:\n\n# grep -v \"^#\" /etc/sendmail.cf |grep -i PrivacyOptions\n\nIf \"novrfy\" is not returned, this is a finding.","fixText":"Add \"novrfy\" to the \"PrivacyOptions\" flag in the \"/etc/sendmail.cf\" file.","ccis":["CCI-000382"]},{"vulnId":"V-239542","ruleId":"SV-239542r662077_rule","severity":"medium","ruleTitle":"The Lightweight User Datagram Protocol (UDP-Lite) must be disabled unless required.","description":"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 SLES for vRealize  to dynamically load a protocol handler by opening a socket using the protocol.","checkContent":"Run the following command:\n\niptables --list | grep \"udplite\"\n\nIf no result is displayed, this is a finding.","fixText":"Configure SLES for vRealize to prevent the dynamic loading of the \"UDP-Lite\" protocol handler:\n\nAdd the following rule to the iptables firewall ruleset:\n\n# iptables -A INPUT -p udplite -j DROP","ccis":["CCI-000382"]},{"vulnId":"V-239543","ruleId":"SV-239543r662080_rule","severity":"medium","ruleTitle":"The Internetwork Packet Exchange (IPX) protocol must be disabled or not installed.","description":"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 SLES for vRealize to dynamically load a protocol handler by opening a socket using the protocol.","checkContent":"Check that the \"IPX\" protocol handler is prevented from dynamic loading:\n\n# grep \"install ipx /bin/true\" /etc/modprobe.conf /etc/modprobe.conf.local /etc/modprobe.d/* \n\nIf no result is returned, this is a finding.","fixText":"Prevent the \"IPX\" protocol handler from dynamic loading:\n\n# echo \"install ipx /bin/true\" >> /etc/modprobe.conf.local","ccis":["CCI-000382"]},{"vulnId":"V-239544","ruleId":"SV-239544r662083_rule","severity":"medium","ruleTitle":"The AppleTalk protocol must be disabled or not installed.","description":"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 SLES for vRealize to dynamically load a protocol handler by opening a socket using the protocol.","checkContent":"Verify the \"AppleTalk\" protocol handler is prevented from dynamic loading:\n\n# grep \"install appletalk /bin/true\" /etc/modprobe.conf /etc/modprobe.conf.local /etc/modprobe.d/* \n\nIf no result is returned, this is a finding.","fixText":"Prevent the \"AppleTalk\" protocol handler from dynamic loading:\n\n# echo \"install appletalk /bin/true\" >> /etc/modprobe.conf.local","ccis":["CCI-000382"]},{"vulnId":"V-239545","ruleId":"SV-239545r662086_rule","severity":"medium","ruleTitle":"The DECnet protocol must be disabled or not installed.","description":"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 SLES for vRealize to dynamically load a protocol handler by opening a socket using the protocol.","checkContent":"Check that the \"DECnet\" protocol handler is prevented from dynamic loading:\n\n# grep \"install decnet /bin/true\" /etc/modprobe.conf /etc/modprobe.conf.local /etc/modprobe.d/*\n\nIf no result is returned, this is a finding.","fixText":"Prevent the \"DECnet\" protocol handler from dynamic loading:\n\n# echo \"install decnet /bin/true\" >> /etc/modprobe.conf.local","ccis":["CCI-000382"]},{"vulnId":"V-239546","ruleId":"SV-239546r662089_rule","severity":"medium","ruleTitle":"Proxy Neighbor Discovery Protocol (NDP) must not be enabled on SLES for vRealize.","description":"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.","checkContent":"Determine if SLES for vRealize has proxy \"NDP\", and if it is enabled:\n\n# more /proc/sys/net/ipv6/conf/*/proxy_ndp\n\nIf the file is not found, the kernel does not have proxy \"NDP\", this is not a finding.\n\nIf the file has a value of \"0\", proxy \"NDP\" is not enabled, this is not a finding.\n\nIf the file has a value of \"1\", proxy NDP is enabled, this is a finding.","fixText":"Disable proxy \"NDP\" on the system.\n\nFor Appliance OS, \"proxy_ndp\" is disabled by default.","ccis":["CCI-000382"]},{"vulnId":"V-239547","ruleId":"SV-239547r662092_rule","severity":"medium","ruleTitle":"The SLES for vRealize must not have 6to4 enabled.","description":"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 SLES for vRealize.","checkContent":"Check SLES for vRealize for any active \"6to4\" tunnels without specific remote addresses:\n\n# ip tun list | grep \"remote any\" | grep \"ipv6/ip\"\n\nIf any results are returned the \"tunnel\" is the first field. \n\nIf any results are returned, this is a finding.","fixText":"Disable the active \"6to4\" tunnel:\n\n# ip link set <tunnel> down\n\nAdd this command to a startup script, or remove the configuration creating the tunnel.","ccis":["CCI-000382"]},{"vulnId":"V-239548","ruleId":"SV-239548r662095_rule","severity":"medium","ruleTitle":"The SLES for vRealize must not have Teredo enabled.","description":"Teredo is an IPv6 transition mechanism that involves tunneling IPv6 packets encapsulated in IPv4 packets. Unauthorized tunneling may circumvent network security.","checkContent":"Verify the \"Miredo\" service is not running:\n\n# ps ax | grep miredo | grep -v grep\n\nIf the Miredo process is running, this is a finding. \n\nNote: For Appliance OS, \"Miredo\" is not included by default, this is not a finding.","fixText":"Kill the \"Miredo\" service.\n\nEdit startup scripts to prevent the service from running on startup.","ccis":["CCI-000382"]},{"vulnId":"V-239549","ruleId":"SV-239549r662098_rule","severity":"medium","ruleTitle":"The DHCP client must be disabled if not needed.","description":"DHCP allows for the unauthenticated configuration of network parameters on SLES for vRealize  by exchanging information with a DHCP server.","checkContent":"Check that no interface is configured to use \"DHCP\":\n\n# grep -i bootproto=dhcp4 /etc/sysconfig/network/ifcfg-*\n\nIf any configuration is found, this is a finding.","fixText":"Edit the \"/etc/sysconfig/network/ifcfg-*\" file(s) and change the \"bootproto\" setting to \"static\".","ccis":["CCI-000382"]},{"vulnId":"V-239550","ruleId":"SV-239550r662101_rule","severity":"medium","ruleTitle":"The SLES for vRealize must have IEEE 1394 (Firewire) disabled unless needed.","description":"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.","checkContent":"If SLES for vRealize needs IEEE 1394 (Firewire), this is not applicable.\n\nCheck if the firewire module is not disabled:\n\n# grep \"install ieee1394 /bin/true\" /etc/modprobe.conf /etc/modprobe.conf.local /etc/modprobe.d/*\n\nIf no results are returned, this is a finding.","fixText":"Prevent SLES for vRealize from loading the firewire module:\n\n# echo \"install ieee1394 /bin/true\" >> /etc/modprobe.conf.local","ccis":["CCI-000382"]},{"vulnId":"V-239551","ruleId":"SV-239551r662104_rule","severity":"medium","ruleTitle":"Duplicate User IDs (UIDs) must not exist for users within the organization.","description":"To assure accountability and prevent unauthenticated access, organizational users must be identified and authenticated to prevent potential misuse and compromise of SLES for vRealize.\n\nOrganizational 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: \n\n1) 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\n\n2) 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.","checkContent":"Verify that SLES for vRealize contains no duplicate UIDs for organizational users by running the following command:\n\n# awk -F \":\" 'list[$3]++{print $1, $3}' /etc/passwd\n\nIf output is produced, this is a finding.","fixText":"Edit the file \"/etc/passwd\" and provide each organizational user account that has a duplicate UID with a unique UID.","ccis":["CCI-000764"]},{"vulnId":"V-239552","ruleId":"SV-239552r662107_rule","severity":"high","ruleTitle":"The SLES for vRealize must prevent direct logon into the root account.","description":"To assure individual accountability and prevent unauthorized access, organizational users must be individually identified and authenticated.\n\nA 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.\n\nFor 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.\n\nUsers (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.\n\nRequiring 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.","checkContent":"Verify SLES for vRealize prevents direct logons to the root account by running the following command:\n\n# grep root /etc/shadow | cut -d \"\":\"\" -f 2\n\nIf the returned message contains any text, this is a finding.","fixText":"Configure SLES for vRealize to prevent direct logins to the root account by performing the following operations:\n\nAdd this line to the \"/etc/group\" file:\n\nadmin:x:[UNIQUE_NUMBER]:[USERNAME]\n\nUSERNAME is the user you wish to add to the admin group.\nUNIQUE_NUMBER is a number entered into the ID field of an entry that is unique to all other IDs in the file.\n\nComment out the following lines in \"/etc/sudoers\" file: \n\nDefault targetpw\nALL  ALL=(ALL) ALL\n\nUnder the line in the \"/etc/sudoers\" file:\n\nroot ALL=(ALL) All\n\nAdd the following line:\n\n%admin ALL=(ALL) ALL\n\nRun the following command:\n\n# passwd -d root","ccis":["CCI-000770"]},{"vulnId":"V-239553","ruleId":"SV-239553r852586_rule","severity":"medium","ruleTitle":"The SLES for vRealize must enforce SSHv2 for network access to privileged accounts.","description":"A replay attack may enable an unauthorized user to gain access to SLES for vRealize. Authentication sessions between the authenticator and SLES for vRealize validating the user credentials must not be vulnerable to a replay attack.\n\nAn authentication process resists replay attacks if it is impractical to achieve a successful authentication by recording and replaying a previous authentication message.\n\nA privileged account is any information system account with authorizations of a privileged user.\n\nTechniques 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.","checkContent":"Verify that SLES for vRealize enforces SSHv2 for network access to privileged accounts by running the following command:\n\nReplace [ADDRESS] in the following command with the correct IP address based on the current system configuration. \n\n# ssh -1 [ADDRESS]\n\nAn example of the command usage is as follows:\n# ssh -1 localhost\n\nThe output must be the following:\n\nProtocol major versions differ: 1 vs. 2\n\nIf it is not, this is a finding.\n\nOR\n\nVerify that the ssh is configured to enforce SSHv2 for network access to privileged accounts by running the following command:\n\n# grep Protocol /etc/ssh/sshd_config\n\nIf the result is not \"Protocol 2\", this is a finding.","fixText":"Configure SLES for vRealize to enforce SSHv2 for network access to privileged accounts by running the following commands:\n\n# sed -i 's/^.*\\bProtocol\\b.*$/Protocol 2/' /etc/ssh/sshd_config\n\nRestart the ssh service. \n\n# service sshd restart","ccis":["CCI-001941"]},{"vulnId":"V-239554","ruleId":"SV-239554r852587_rule","severity":"medium","ruleTitle":"The SLES for vRealize must enforce SSHv2 for network access to non-privileged accounts.","description":"A replay attack may enable an unauthorized user to gain access to SLES for vRealize. Authentication sessions between the authenticator and SLES for vRealize validating the user credentials must not be vulnerable to a replay attack.\n\nAn authentication process resists replay attacks if it is impractical to achieve a successful authentication by recording and replaying a previous authentication message.\n\nA non-privileged account is any SLES for vRealize account with authorizations of a non-privileged user.\n\nTechniques 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.","checkContent":"Verify that SLES for vRealize enforces SSHv2 for network access to privileged accounts by running the following command:\n\nReplace [ADDRESS] in the following command with the correct IP address based on the current system configuration. \n\n# ssh -1 [ADDRESS]\n\nAn example of the command usage is as follows:\n# ssh -1 localhost\n\nThe output must be one of the following items:\n\nProtocol major versions differ: 1 vs. 2\n\nOR\n\nProtocol 1 not allowed in the FIPS mode.\n\nIf it does not, this is a finding.\n\nOR \n\nVerify that the ssh is configured to enforce SSHv2 for network access to privileged accounts by running the following command:\n\n# grep Protocol /etc/ssh/sshd_config\n\nIf the result is not \"Protocol 2\", this is a finding.","fixText":"Configure SLES for vRealize to enforce SSHv2 for network access to non-privileged accounts by running the following commands:\n\n# sed -i 's/^.*\\bProtocol\\b.*$/Protocol 2/' /etc/ssh/sshd_config\n\nRestart the ssh service. \n\n# service sshd restart","ccis":["CCI-001942"]},{"vulnId":"V-239555","ruleId":"SV-239555r662116_rule","severity":"medium","ruleTitle":"The SLES for vRealize must disable account identifiers of individuals and roles (such as root) after 35 days of inactivity after password expiration.","description":"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.\n\nSLES for vRealize need to track periods of inactivity and disable application identifiers after 35 days of inactivity.","checkContent":"Verify SLES for vRealize disables account identifiers after \"35\" days of inactivity after the password expiration, by performing the following commands:\n\n# grep \"INACTIVE\" /etc/default/useradd\n\nThe output must indicate the \"INACTIVE\" configuration option is set to an appropriate integer as shown in the example below: \n\ngrep \"INACTIVE\" /etc/default/useradd\nINACTIVE=35\n\nIf \"INACTIVE\" is not set to a value 0<[VALUE]<=35, this is a finding.","fixText":"Configure 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:\n\nReplace [VALUE] in the command with any integer from the range 0<[VALUE]<= 35. \n\n# sed -i \"s/^.*\\bINACTIVE\\b.*$/INACTIVE=[VALUE]/\" /etc/default/useradd\n\nDoD 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.","ccis":["CCI-000795"]},{"vulnId":"V-239556","ruleId":"SV-239556r662119_rule","severity":"medium","ruleTitle":"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.","description":"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.\n\nSLES for vRealize  utilizing encryption are required to use FIPS-compliant mechanisms for authenticating to cryptographic modules. \n\nFIPS 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.","checkContent":"Check the \"/etc/default/passwd\" file:\n\n# grep CRYPT /etc/default/passwd\n\nIf the \"CRYPT\" setting in the \"/etc/default/passwd\" file is not present, or not set to \"SHA256\" or \"SHA512\", this is a finding.\n\nIf the \"CRYPT_FILES\" setting in the \"/etc/default/passwd\" file is not present, or not set to \"SHA256\" or \"SHA512\", this is a finding.","fixText":"Edit the \"/etc/default/passwd\" file and add or change the \"CRYPT\" variable setting so that it contains:\n\nCRYPT=sha256 \nOR\nCRYPT=sha512 \n\nEdit the \"/etc/default/passwd\" file and add or change the \"CRYPT_FILES\" variable setting so that it contains:\n\nCRYPT_FILES=sha256 \nOR\nCRYPT_FILES=sha512","ccis":["CCI-000803"]},{"vulnId":"V-239557","ruleId":"SV-239557r662122_rule","severity":"medium","ruleTitle":"The SLES for vRealize must uniquely identify and must authenticate non-organizational users (or processes acting on behalf of non-organizational users).","description":"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.\n\nNon-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).\n\nNon-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.","checkContent":"Run the following command to check for duplicate account names: \n\n# pwck -rq\n\nIf there are no duplicate names, no line will be returned. \n\nIf a line is returned, this is a finding.","fixText":"Change usernames, or delete accounts, so each has a unique name.","ccis":["CCI-000804"]},{"vulnId":"V-239558","ruleId":"SV-239558r662125_rule","severity":"medium","ruleTitle":"The SLES for vRealize must uniquely identify and must authenticate non-organizational users (or processes acting on behalf of non-organizational users).","description":"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.\n\nNon-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).\n\nNon-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.","checkContent":"Verify the SLES for vRealize uniquely identifies and authenticates non-organizational users by running the following commands:\n\n# awk -F: '{print $3}' /etc/passwd | sort | uniq -d\n\nIf the output is not blank, this is a finding.","fixText":"Configure the SLES for vRealize to uniquely identify and authenticate non-organizational users (or processes acting on behalf of non-organizational users).\n\nUNIQUE_USER_ID is a unique numerical value that must be non-negative. \n\nUSERNAME is the username of the user whose user ID you wish to change. \n\n# usermod -u [UNIQUE_USER_ID] [USERNAME]","ccis":["CCI-000804"]},{"vulnId":"V-239559","ruleId":"SV-239559r662128_rule","severity":"medium","ruleTitle":"The SLES for vRealize must be configured such that emergency administrator accounts are never automatically removed or disabled.","description":"Emergency administrator accounts are privileged accounts which 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. \n\nEmergency 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.\n\nTo address access requirements, many operating systems can be integrated with enterprise-level authentication/access mechanisms that meet or exceed access control policy requirements.","checkContent":"For each emergency administrator account run the following command:\n\nchage -l [user]\n\nIf the output shows an expiration date for the account, this is a finding.","fixText":"For each emergency administrator account run the following command to remove the expiration date: \n\nchage -E -1 [user]","ccis":["CCI-001682"]},{"vulnId":"V-239560","ruleId":"SV-239560r877395_rule","severity":"medium","ruleTitle":"The SLES for vRealize must employ strong authenticators in the establishment of nonlocal maintenance and diagnostic sessions.","description":"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.\n\nSome maintenance and test tools are either standalone devices with their own operating systems or are applications bundled with an operating system. \n\nNonlocal 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.","checkContent":"Check the SSH daemon configuration for DoD-approved encryption to protect the confidentiality of SSH remote connections by performing the following commands:\n\nCheck the Cipher setting in the sshd_config file.\n\n# grep -i Ciphers /etc/ssh/sshd_config  | grep -v '#' \n\nThe output must contain either none or any number of the following algorithms:\n\naes128-ctr, aes256-ctr.\n\nIf the output contains an algorithm not listed above, this is a finding.\n\nExpected Output:\nCiphers aes256-ctr,aes128-ctr","fixText":"Update the Ciphers directive with the following command: \n\n# sed -i \"/^[^#]*Ciphers/ c\\Ciphers aes256-ctr,aes128-ctr\" /etc/ssh/sshd_config\n\nSave and close the file. Restart the sshd process: \n\n# service sshd restart","ccis":["CCI-000877"]},{"vulnId":"V-239561","ruleId":"SV-239561r662134_rule","severity":"medium","ruleTitle":"The SLES for vRealize must terminate all sessions and network connections related to nonlocal maintenance when nonlocal maintenance is completed.","description":"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.\n\nSome maintenance and test tools are either standalone devices with their own operating systems or are applications bundled with an operating system.\n\nNonlocal 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.","checkContent":"Check for the existence of the \"/etc/profile.d/tmout.sh\" file:\n\n# ls -al /etc/profile.d/tmout.sh\n\nCheck for the presence of the \"TMOUT\" variable:\n\n# grep TMOUT /etc/profile.d/tmout.sh\n\nThe value of \"TMOUT\" should be set to \"900\" seconds (15 minutes).\n\nIf the file does not exist, or the \"TMOUT\" variable is not set to \"900\", this is a finding.","fixText":"Ensure the file exists and is owned by \"root\". If the files does not exist, use the following commands to create the file:\n\n# touch /etc/profile.d/tmout.sh\n# chown root:root /etc/profile.d/tmout.sh\n# chmod 644 /etc/profile.d/tmout.sh\n\nEdit the file \"/etc/profile.d/tmout.sh\", and add the following lines: \n\nTMOUT=900\nreadonly TMOUT\nexport TMOUT\nmesg n 2>/dev/null","ccis":["CCI-000879"]},{"vulnId":"V-239562","ruleId":"SV-239562r662137_rule","severity":"medium","ruleTitle":"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.","description":"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. \n\nManaging 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.","checkContent":"Check that SLES for vRealize is configured to use TCP syncookies when experiencing a TCP SYN flood.\n\n# cat /proc/sys/net/ipv4/tcp_syncookies\n\nIf the result is not \"1\", this is a finding.","fixText":"Configure SLES for vRealize to use TCP syncookies when experiencing a TCP SYN flood.\n\n# sed -i 's/^.*\\bnet.ipv4.tcp_syncookies\\b.*$/net.ipv4.tcp_syncookies=1/' /etc/sysctl.conf\n\nReload sysctl to verify the new change:\n\n# sysctl -p","ccis":["CCI-001095"]},{"vulnId":"V-239563","ruleId":"SV-239563r662140_rule","severity":"medium","ruleTitle":"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.","description":"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. \n\nManaging 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.","checkContent":"Check that SLES for vRealize has an appropriate TCP backlog queue size to mitigate against TCP SYN flood DOS attacks with the following command:\n\n# cat /proc/sys/net/ipv4/tcp_max_syn_backlog\n\nThe recommended default setting is \"1280\". \n\nIf the TCP backlog queue size is not set to \"1280\", this is a finding.","fixText":"Configure the TCP backlog queue size with the following command:\n\n# sed -i 's/^.*\\bnet.ipv4.tcp_max_syn_backlog\\b.*$/net.ipv4.tcp_max_syn_backlog=1280/' /etc/sysctl.conf\n\nReload sysctl to verify the new change:\n\n# sysctl -p","ccis":["CCI-001095"]},{"vulnId":"V-239564","ruleId":"SV-239564r662405_rule","severity":"medium","ruleTitle":"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.","description":"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. \n\nTerminating 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 SLES for vRealize terminates all sessions or network access; it only ends the inactive session and releases the resources associated with that session.","checkContent":"Check for the existence of the \"/etc/profile.d/tmout.sh\" file:\n\n# ls -al /etc/profile.d/tmout.sh\n\nCheck for the presence of the \"TMOUT\" variable:\n\n# grep TMOUT /etc/profile.d/tmout.sh\n\nThe value of \"TMOUT\" should be set to \"900\" seconds (15 minutes).\n\nIf the file does not exist, or the \"TMOUT\" variable is not set to \"900\", this is a finding.","fixText":"Ensure the file exists and is owned by \"root\". If the files does not exist, use the following commands to create the file:\n\n# touch /etc/profile.d/tmout.sh\n# chown root:root /etc/profile.d/tmout.sh\n# chmod 644 /etc/profile.d/tmout.sh\n\nEdit the file \"/etc/profile.d/tmout.sh\", and add the following lines: \n\nTMOUT=900\nreadonly TMOUT\nexport TMOUT\nmesg n 2>/dev/null","ccis":["CCI-001133"]},{"vulnId":"V-239565","ruleId":"SV-239565r662146_rule","severity":"medium","ruleTitle":"The /var/log directory must be group-owned by root.","description":"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 SLES for vRealize 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.\n\nThe 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.","checkContent":"Verify the \"/var/log\" directory is group-owned by \"root\" by running the following command:\n\n# ls -lad /var/log | cut -d' ' -f4\n\nThe output must look like the following example:\n\nls -lad /var/log | cut -d' ' -f4\nroot\n\nIf \"root\" is not returned as a result, this is a finding.","fixText":"Change the group of the directory \"/var/log\" to \"root\" by running the following command:\n\n# chgrp root /var/log","ccis":["CCI-001314"]},{"vulnId":"V-239566","ruleId":"SV-239566r662149_rule","severity":"medium","ruleTitle":"The /var/log directory must be owned by root.","description":"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 SLES for vRealize 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.\n\nThe 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.","checkContent":"Verify that the \"/var/log\" directory is owned by \"root\" by running the following command:\n\n# ls -lad /var/log | cut -d' ' -f3\n\nThe output must look like the following example:\n\nls -lad /var/log | cut -d' ' -f3\nroot\n\nIf \"root\" is not returned as a result, this is a finding.","fixText":"Change the owner of the directory \"/var/log\" to \"root\" by running the following command:\n\n# chown root /var/log","ccis":["CCI-001314"]},{"vulnId":"V-239567","ruleId":"SV-239567r662152_rule","severity":"medium","ruleTitle":"The /var/log directory must have mode 0750 or less permissive.","description":"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 SLES for vRealize 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.\n\nThe 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.","checkContent":"Verify that the \"/var/log\" directory is the mode 0750 or less permissive by running the following command:\n\n# ls -lad /var/log | cut -d' ' -f1\n\nThe output must look like the following example:\n\nls -lad /var/log | cut -d' ' -f1\ndrwxr-x---\n\nIf \"drwxr-x---\" is not returned as a result, this is a finding.","fixText":"Change the permissions of the directory \"/var/log\" to \"0750\" by running the following command:\n\n# chmod 0750 /var/log","ccis":["CCI-001314"]},{"vulnId":"V-239568","ruleId":"SV-239568r662155_rule","severity":"medium","ruleTitle":"The /var/log/messages file must be group-owned by root.","description":"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 SLES for vRealize 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.\n\nThe 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.","checkContent":"Verify that the \"/var/log/messages\" file is group-owned by \"root\" by running the following command:\n\n# ls -la /var/log/messages | cut -d' ' -f4\n\nThe output must look like the following example:\n\nls -la /var/log/messages | cut -d' ' -f4\nroot\n\nIf \"root\" is not returned as a result, this is a finding.","fixText":"Change the group of the file \"/var/log/messages\" to \"root\" by running the following command:\n\n# chgrp root /var/log/messages","ccis":["CCI-001314"]},{"vulnId":"V-239569","ruleId":"SV-239569r662158_rule","severity":"medium","ruleTitle":"The /var/log/messages file must be owned by root.","description":"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 SLES for vRealize 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.\n\nThe 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.","checkContent":"Verify that the \"/var/log/messages\" file is owned by \"root\" by running the following command:\n\n# ls -la /var/log/messages | cut -d' ' -f3\n\nThe output must look like the following example:\n\nls -la /var/log/messages | cut -d' ' -f3\nroot\n\nIf \"root\" is not returned as a result, this is a finding.","fixText":"Change the owner of the file \"/var/log/messages\" to \"root\" by running the following command:\n\n# chown root /var/log/messages","ccis":["CCI-001314"]},{"vulnId":"V-239570","ruleId":"SV-239570r662161_rule","severity":"medium","ruleTitle":"The /var/log/messages file must have mode 0640 or less permissive.","description":"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 SLES for vRealize 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.\n\nThe 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.","checkContent":"Verify that the \"/var/log/messages\" file is 0640 or less permissive by running the following command:\n\n# ls -lad /var/log/messages | cut -d' ' -f1\n\nThe output must look like the following example:\n\nls -lad /var/log/messages | cut -d' ' -f1\n-rw-r-----\n\nIf \"-rw-r-----\" is not returned as a result, this is a finding.","fixText":"Change the permissions of the file \"/var/log/messages\" to \"0640\" by running the following command:\n\n# chmod 0640 /var/log/messages","ccis":["CCI-001314"]},{"vulnId":"V-239571","ruleId":"SV-239571r662164_rule","severity":"medium","ruleTitle":"The SLES for vRealize must reveal error messages only to authorized users.","description":"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 SLES for vRealize 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.\n\nThe 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.","checkContent":"Check the permissions of the syslog configuration file(s):\n\n# ls -lL /etc/syslog-ng/syslog-ng.conf\n\nIf the mode of the file is more permissive than \"0640\", this is a finding.","fixText":"Change the permissions of the syslog configuration file(s):\n\n# chmod 640 /etc/syslog-ng/syslog-ng.conf","ccis":["CCI-001314"]},{"vulnId":"V-239572","ruleId":"SV-239572r662167_rule","severity":"medium","ruleTitle":"The SLES for vRealize must reveal error messages only to authorized users.","description":"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 SLES for vRealize 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.\n\nThe 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.","checkContent":"Check the permissions of the syslog configuration file(s):\n\n# ls -lL /etc/syslog-ng/syslog-ng.conf\n\nIf the file is not owned by \"root\", this is a finding.","fixText":"Use the chown command to set the owner to \"root\":\n\n# chown root /etc/syslog-ng/syslog-ng.conf","ccis":["CCI-001314"]},{"vulnId":"V-239573","ruleId":"SV-239573r662170_rule","severity":"medium","ruleTitle":"The SLES for vRealize must reveal error messages only to authorized users.","description":"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 SLES for vRealize 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.\n\nThe 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.","checkContent":"Check the permissions of the syslog configuration file(s):\n\n# ls -lL /etc/syslog-ng/syslog-ng.conf\n\nIf the file is not group owned by \"root\", this is a finding.","fixText":"Change the group-owner of the \"/etc/rsyslog.conf\" file to \"root\":\n\n# chgrp root /etc/syslog-ng/syslog-ng.conf","ccis":["CCI-001314"]},{"vulnId":"V-239575","ruleId":"SV-239575r662176_rule","severity":"medium","ruleTitle":"The SLES for vRealize must audit all account modifications.","description":"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.\n\nTo address access requirements, many SLES for vRealize systems can be integrated with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements.","checkContent":"Determine if execution of the \"usermod\" and \"groupmod\" executable are audited.\n\n# auditctl -l | egrep '(usermod|groupmod)' | grep perm=x\n\nIf either \"usermod\" or \"groupmod\" are not listed with a permissions filter of at least \"x\", this is a finding.","fixText":"Configure execute auditing of the \"usermod\" and \"groupmod\" executables run the DoD.script with the following command as \"root\":\n\n# /etc/dodscript.sh\n\nOR\n\nConfigure execute auditing of the \"usermod\" and \"groupmod\" executables. Add the following to the audit.rules file: \n\n-w /usr/sbin/usermod -p x -k usermod\n-w /usr/sbin/groupmod -p x -k groupmod\n\nRestart the auditd service. \n\n# service auditd restart","ccis":["CCI-001403"]},{"vulnId":"V-239576","ruleId":"SV-239576r662179_rule","severity":"medium","ruleTitle":"The SLES for vRealize must audit all account modifications.","description":"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.\n\nTo address access requirements, many SLES for vRealize systems can be integrated with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements.","checkContent":"Determine if \"/etc/passwd\", \"/etc/shadow\", \"/etc/group\", and \"/etc/gshadow\" are audited for writing.\n\n# auditctl -l | egrep '(/etc/passwd|/etc/shadow|/etc/group|/etc/gshadow)' | grep perm=w\n\nIf any of these are not listed with a permissions filter of at least \"w\", this is a finding.","fixText":"Configure append auditing of the \"passwd\", \"shadow\", \"group\", and \"gshadow\" files run the DoD.script with the following command as root:\n\n# /etc/dodscript.sh\n\nOR\n\nConfigure append auditing of the \"passwd\", \"shadow\", \"group\", and \"gshadow\" files. Add the following to the audit.rules file: \n\n-w /etc/passwd -p w -k passwd\n-w /etc/shadow -p w -k shadow\n-w /etc/group -p w -k group\n-w /etc/gshadow -p w -k gshadow\n\nRestart the auditd service. \n\n# service auditd restart","ccis":["CCI-001403"]},{"vulnId":"V-239577","ruleId":"SV-239577r662182_rule","severity":"medium","ruleTitle":"The SLES for vRealize must audit all account-disabling actions.","description":"When SLES for vRealize accounts are disabled, user accessibility is affected. Accounts are utilized for identifying individual users or for identifying the SLES for vRealize processes themselves. In order to detect and respond to events affecting user accessibility and system processing, SLES for vRealize 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 SLES for vRealize accessibility will be negatively affected for extended periods of time and provides logging that can be used for forensic purposes.\n\nTo address access requirements, many SLES for vRealize systems can be integrated with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements.","checkContent":"Determine if execution of the \"passwd\" executable is audited: \n\n# auditctl -l | grep watch=/usr/bin/passwd \n\nIf \"/usr/bin/passwd\" is not listed with a permissions filter of at least \"x\", this is a finding.","fixText":"Configure SLES for vRealize to automatically audit account-disabling actions by running the following command:\n\n# /etc/dodscript.sh\n\nOR\n\n# echo '-w /usr/bin/passwd -p x -k passwd' >> /etc/audit/audit.rules\n\nRestart the auditd service. \n\n# service auditd restart","ccis":["CCI-001404"]},{"vulnId":"V-239578","ruleId":"SV-239578r662185_rule","severity":"medium","ruleTitle":"The SLES for vRealize must audit all account removal actions.","description":"When SLES for vRealize accounts are removed, user accessibility is affected. Accounts are utilized for identifying individual users or for identifying the SLES for vRealize  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 SLES for vRealize accessibility will be negatively affected for extended periods of time and provides logging that can be used for forensic purposes.\n\nTo address access requirements, many SLES for vRealize systems can be integrated with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements.","checkContent":"Determine if execution of the \"userdel\" and \"groupdel\" executable are audited:\n\n# auditctl -l | egrep '(userdel|groupdel)'\n\nIf either \"userdel\" or \"groupdel\" are not listed with a permissions filter of at least \"x\", this is a finding.","fixText":"Configure execute auditing of the \"userdel\" and \"groupdel\" executables. Add the following to the \"/etc/audit/audit.rules\" file:\n\n-w /usr/sbin/userdel -p x -k userdel\n-w /usr/sbin/groupdel -p x -k groupdel","ccis":["CCI-001405"]},{"vulnId":"V-239579","ruleId":"SV-239579r877394_rule","severity":"medium","ruleTitle":"The SLES for vRealize must implement cryptography to protect the integrity of remote access sessions.","description":"Without cryptographic integrity protections, information can be altered by unauthorized users without detection.\n\nRemote 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.\n\nCryptographic 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.","checkContent":"Check the SSH daemon configuration for DoD-approved encryption to protect the confidentiality of SSH remote connections by performing the following commands:\n\nCheck the Cipher setting in the \"sshd_config\" file.\n\n# grep -i Ciphers /etc/ssh/sshd_config  | grep -v '#' \n\nThe output must contain either none or any number of the following algorithms:\n\naes128-ctr, aes256-ctr.\n\nIf the output contains an algorithm not listed above, this is a finding.\n\nExpected Output:\nCiphers aes256-ctr,aes128-ctr","fixText":"Update the Ciphers directive with the following command: \n\n# sed -i \"/^[^#]*Ciphers/ c\\Ciphers aes256-ctr,aes128-ctr\" /etc/ssh/sshd_config\n\nSave and close the file. Restart the sshd process: \n\n# service sshd restart","ccis":["CCI-001453"]},{"vulnId":"V-239580","ruleId":"SV-239580r662191_rule","severity":"medium","ruleTitle":"The SLES for vRealize must initiate session audits at system start-up.","description":"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.","checkContent":"Check for the \"audit=1\" kernel parameter.\n\n# grep \"audit=1\" /proc/cmdline\n\nIf no results are returned, this is a finding.","fixText":"Edit the grub bootloader file \"/boot/grub/menu.lst\" by appending the \"audit=1\" parameter to the kernel boot line.\n\nReboot the system for the change to take effect.","ccis":["CCI-001464"]},{"vulnId":"V-239581","ruleId":"SV-239581r662194_rule","severity":"medium","ruleTitle":"The SLES for vRealize must produce audit records containing information to establish the identity of any individual or process associated with the event.","description":"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.","checkContent":"Verify SLES for vRealize produces audit records by running the following command to determine the current status of the \"auditd\" service:\n\n# service auditd status\n\nIf the service is enabled, the returned message must contain the following text:\n\nChecking for service auditd                running\n\nIf the service is not running, this is a finding.","fixText":"Enable the \"auditd\" service by performing the following commands:\n\n# chkconfig auditd on\n# service auditd start","ccis":["CCI-001487"]},{"vulnId":"V-239582","ruleId":"SV-239582r662197_rule","severity":"medium","ruleTitle":"The SLES for vRealize must protect audit tools from unauthorized access.","description":"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.\n\nSLES for vRealize 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.\n\nAudit 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.","checkContent":"The following command will list which audit files on the system have permissions different from what is expected by the RPM database: \n\n# rpm -V audit | grep '^.M'\n\nIf there is any output, for each file or directory found, compare the RPM-expected permissions with the permissions on the file or directory:\n\n# rpm -q --queryformat \"[%{FILENAMES} %{FILEMODES:perms}\\n]\" audit | grep [filename]\n# ls -lL [filename]\n\nIf the existing permissions are more permissive than those expected by the RPM database, this is a finding.","fixText":"For each file that has permissions that are more permissive than those expected by the RPM database, alter the permission of the file with the following command:\n\n# chmod <permission> <filename>","ccis":["CCI-001493"]},{"vulnId":"V-239583","ruleId":"SV-239583r662200_rule","severity":"medium","ruleTitle":"The SLES for vRealize must protect audit tools from unauthorized modification.","description":"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.\n\nSLES for vRealize 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.\n\nAudit 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.","checkContent":"The following command will list which audit files on the system where the group ownership has been modified:\n\n# rpm -V audit | grep '^......G'\n\nIf there is output, this is a finding.","fixText":"For each file that has the incorrect group modification, alter the group ownership of the file with the following command:\n\n# chgrp <group> <filename>","ccis":["CCI-001494"]},{"vulnId":"V-239584","ruleId":"SV-239584r662203_rule","severity":"medium","ruleTitle":"The SLES for vRealize must protect audit tools from unauthorized deletion.","description":"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.\n\nSLES for vRealize 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.\n\nAudit 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.","checkContent":"The following command will list which audit files on the system where the ownership has been modified:\n\n# rpm -V audit | grep '^.....U'\n\nIf there is output, this is a finding.","fixText":"For each file that has the incorrect owner modification, alter the ownership of the file with the following command:\n\n# chown <owner> <filename>","ccis":["CCI-001495"]},{"vulnId":"V-239585","ruleId":"SV-239585r662206_rule","severity":"medium","ruleTitle":"The SLES for vRealize must enforce password complexity by requiring that at least one special character be used.","description":"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.\n\nPassword 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.\n\nSpecial characters are those characters that are not alphanumeric. Examples include: ~ ! @ # $ % ^ *.","checkContent":"Verify SLES for vRealize enforces password complexity by requiring that at least one special character be used by using the following command:\n\nCheck the password \"ocredit\" option:\n\n# grep pam_cracklib.so /etc/pam.d/common-password\n\nConfirm the \"ocredit\" option is set to \"-1\" as in the example: \n\npassword requisite pam_cracklib.so ocredit=-1\n\nThere may be other options on the line. \n\nIf no such line is found, or the \"ocredit\" is not \"-1\", this is a finding.","fixText":"Configure SLES for vRealize to enforce password complexity by requiring that at least one special character be used by running the following command:\n\nIf \"ocredit\" was not set at all in \"/etc/pam.d/common-password-vmware.local\" file then run the following command:\n\n# sed -i '/pam_cracklib.so/ s/$/ ocredit=-1/' /etc/pam.d/common-password-vmware.local\n\nIf \"ocredit\" was set incorrectly, run the following command:\n\n# sed -i '/pam_cracklib.so/ s/ocredit=../ocredit=-1/' /etc/pam.d/common-password-vmware.local","ccis":["CCI-001619"]},{"vulnId":"V-239586","ruleId":"SV-239586r662209_rule","severity":"low","ruleTitle":"The SLES for vRealize must notify System Administrators and Information Systems Security Officer when accounts are created.","description":"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. Notification of account creation is one method for mitigating this risk. A comprehensive account management process will ensure an audit trail, which documents the creation of SLES for vRealize 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.\n\nTo address access requirements, many SLES for vRealize systems can be integrated with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements.","checkContent":"Check the syslog configuration file for remote syslog servers:\n\n# cat /etc/syslog-ng/syslog-ng.conf | grep logserver\n\nIf no line is returned, or the \"logserver\" is commented out, this is a finding.","fixText":"Edit the syslog configuration file and add an appropriate remote syslog server:\n\nIn 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:\n\n# \n# Enable this and adopt IP to send log messages to a log server. \n# \n#destination logserver { udp(\"10.10.10.10\" port(514)); };\n#log { source(src); destination(logserver); };","ccis":["CCI-001683"]},{"vulnId":"V-239587","ruleId":"SV-239587r662212_rule","severity":"low","ruleTitle":"The SLES for vRealize must notify System Administrators and Information System Security Officers when accounts are modified.","description":"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. Notification of account modification is one method for mitigating this risk. A comprehensive account management process will ensure an audit trail, which documents the creation of SLES for vRealize 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.\n\nTo address access requirements, many SLES for vRealize systems can be integrated with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements.","checkContent":"Check the syslog configuration file for remote syslog servers:\n\n# cat /etc/syslog-ng/syslog-ng.conf | grep logserver\n\nIf no line is returned, or the \"logserver\" is commented out, this is a finding.","fixText":"Edit the syslog configuration file and add an appropriate remote syslog server:\n\nIn 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:\n\n# \n# Enable this and adopt IP to send log messages to a log server. \n# \n#destination logserver { udp(\"10.10.10.10\" port(514)); };\n#log { source(src); destination(logserver); };","ccis":["CCI-001684"]},{"vulnId":"V-239588","ruleId":"SV-239588r662215_rule","severity":"low","ruleTitle":"The SLES for vRealize must notify System Administrators and Information System Security Officers when accounts are disabled.","description":"When SLES for vRealize accounts are disabled, user accessibility is affected. Accounts are utilized for identifying individual SLES for vRealize users or for identifying the SLES for vRealize processes themselves.\n\nIn order to detect and respond to events that affect user accessibility and system processing, operating systems must audit account disabling actions and, as required, notify System Administrators and Information System Security Officers (ISSO) 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 also provides logging that can be used for forensic purposes.\n\nTo address access requirements, many SLES for vRealize systems can be integrated with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements.","checkContent":"Check the syslog configuration file for remote syslog servers:\n\n# cat /etc/syslog-ng/syslog-ng.conf | grep logserver\n\nIf no line is returned, or the \"logserver\" is commented out, this is a finding.","fixText":"Edit the syslog configuration file and add an appropriate remote syslog server:\n\nIn 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:\n\n# \n# Enable this and adopt IP to send log messages to a log server. \n# \n#destination logserver { udp(\"10.10.10.10\" port(514)); };\n#log { source(src); destination(logserver); };","ccis":["CCI-001685"]},{"vulnId":"V-239589","ruleId":"SV-239589r662218_rule","severity":"low","ruleTitle":"The SLES for vRealize must notify System Administrators and Information System Security Officers when accounts are removed.","description":"When SLES for vRealize accounts are removed, user accessibility is affected. Accounts are utilized for identifying individual SLES for vRealize users or for identifying the SLES for vRealize processes themselves.\n\nIn order to detect and respond to events that affect user accessibility and system processing, SLES for vRealize must audit account removal actions and, as required, notify System Administrators and Information System Security Officers (ISSO) 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 also provides logging that can be used for forensic purposes.\n\nTo address access requirements, many operating systems can be integrated with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements.","checkContent":"Check the syslog configuration file for remote syslog servers:\n\n# cat /etc/syslog-ng/syslog-ng.conf | grep logserver\n\nIf no line is returned, or the \"logserver\" is commented out, this is a finding.","fixText":"Edit the syslog configuration file and add an appropriate remote syslog server:\n\nIn 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:\n\n# \n# Enable this and adopt IP to send log messages to a log server. \n# \n#destination logserver { udp(\"10.10.10.10\" port(514)); };\n#log { source(src); destination(logserver); };","ccis":["CCI-001686"]},{"vulnId":"V-239590","ruleId":"SV-239590r877393_rule","severity":"medium","ruleTitle":"The SLES for vRealize must use cryptographic mechanisms to protect the integrity of audit tools.","description":"Protecting the integrity of the tools used for auditing purposes is a critical step toward ensuring the integrity of audit information. Audit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity.\n\nAudit 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.\n\nIt is not uncommon for attackers to replace the audit tools or inject code into the existing tools with the purpose of providing the capability to hide or erase system activity from the audit logs.\n\nTo address this risk, audit tools must be cryptographically signed in order to provide the capability to identify when the audit tools have been modified, manipulated, or replaced. An example is a checksum hash of the file or files.","checkContent":"The following command will list which audit files on the system have file hashes different from what is expected by the RPM database:\n\n# rpm -V audit | grep '$1 ~ /..5/ && $2 != \"c\"'\n\nIf there is output, this is a finding.","fixText":"The RPM package management system can check the hashes of audit system package files. Run the following command to list which audit files on the system have hashes that differ from what is expected by the RPM database: \n\n# rpm -V audit | grep '^..5'\n\nA \"c\" in the second column indicates that a file is a configuration file, which may appropriately be expected to change. If the file that has changed was not expected to, refresh from distribution media or online repositories. \n\nrpm -Uvh [affected_package]","ccis":["CCI-001496"]},{"vulnId":"V-239591","ruleId":"SV-239591r852588_rule","severity":"medium","ruleTitle":"The SLES for vRealize must automatically terminate a user session after inactivity time-outs have expired or at shutdown.","description":"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.\n\nSession 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.\n\nConditions 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.\n\nThis capability is typically reserved for specific operating system functionality where the system owner, data owner, or organization requires additional assurance.","checkContent":"Check for the existence of the \"/etc/profile.d/tmout.sh\" file:\n\n# ls -al /etc/profile.d/tmout.sh\n\nCheck for the presence of the \"TMOUT\" variable:\n\n# grep TMOUT /etc/profile.d/tmout.sh\n\nThe value of \"TMOUT\" should be set to \"900\" seconds (15 minutes).\n\nIf the file does not exist, or the \"TMOUT\" variable is not set to \"900\", this is a finding.","fixText":"Ensure the file exists and is owned by \"root\". If the files does not exist, use the following commands to create the file:\n\n# touch /etc/profile.d/tmout.sh\n# chown root:root /etc/profile.d/tmout.sh\n# chmod 644 /etc/profile.d/tmout.sh\n\nEdit the file \"/etc/profile.d/tmout.sh\", and add the following lines: \n\nTMOUT=900\nreadonly TMOUT\nexport TMOUT\nmesg n 2>/dev/null","ccis":["CCI-002361"]},{"vulnId":"V-239592","ruleId":"SV-239592r852589_rule","severity":"medium","ruleTitle":"The SLES for vRealize must control remote access methods.","description":"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.\n\nRemote 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.\n\nSLES for vRealize 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).","checkContent":"Check the SSH daemon configuration for listening network addresses:\n\n# grep -i Listen /etc/ssh/sshd_config | grep -v '^#'\n\nIf no configuration is returned, or if a returned \"Listen\" configuration contains addresses not designated for management traffic, this is a finding.","fixText":"Edit the SSH daemon configuration with the following command:\n\n# sed -i \"/^[^#]ListenAddress/ c\\ListenAddress = 0.0.0.0\" /etc/ssh/sshd_config\n\nReplace \"0.0.0.0\" with the listening network addresses designated for management traffic.","ccis":["CCI-002314"]},{"vulnId":"V-239593","ruleId":"SV-239593r852590_rule","severity":"medium","ruleTitle":"The SLES for vRealize must audit all account enabling actions.","description":"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 SLES for vRealize 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.\n\nTo address access requirements, many SLES for vRealize systems can be integrated with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements.","checkContent":"Determine if execution of the usermod and groupmod executable are audited:\n\n# auditctl -l | egrep '(usermod|groupmod)'\n\nIf either \"useradd\" or \"groupadd\" are not listed with a permissions filter of at least \"x\", this is a finding.\n\nDetermine if execution of the \"userdel\" and \"groupdel\" executable are audited:\n\n# auditctl -l | egrep '(userdel|groupdel)'\n\nIf either \"userdel\" or \"groupdel\" are not listed with a permissions filter of at least \"x\", this is a finding.\n\nDetermine if execution of \"useradd\" and \"groupadd\" are audited:\n\n# auditctl -l | egrep '(useradd|groupadd)'\n\nIf either \"useradd\" or \"groupadd\" are not listed with a permissions filter of at least \"x\", this is a finding.\n\nDetermine if execution of the passwd executable is audited: \n\n# auditctl -l | grep \"/usr/bin/passwd\" \n\nIf \"/usr/bin/passwd\" is not listed with a permissions filter of at least \"x\", this is a finding. \n\nDetermine if \"/etc/passwd\", \"/etc/shadow\", \"etc/group\", and \"etc/security/opasswd\" are audited for writing:\n\n# auditctl -l | egrep '(/etc/passwd|/etc/shadow|/etc/group|/etc/security/opasswd)'\n\nIf any of these are not listed with a permissions filter of at least \"w\", this is a finding.","fixText":"Configure execute auditing of the \"usermod\" and \"groupmod\" executables. Add the following to the \"/etc/audit/audit.rules\" file:\n\n-w /usr/sbin/usermod -p x -k usermod\n-w /usr/sbin/groupmod -p x -k groupmod\n\nConfigure execute auditing of the \"userdel\" and \"groupdel\" executables. Add the following to the \"/etc/audit/audit.rules\" file:\n\n-w /usr/sbin/userdel -p x -k userdel\n-w /usr/sbin/groupdel -p x -k groupdel\n\nConfigure execute auditing of the \"useradd\" and \"groupadd\" executables. Add the following to audit.rules:\n\n-w /usr/sbin/useradd -p x -k useradd\n-w /usr/sbin/groupadd -p x -k groupadd\n\nConfigure execute auditing of the \"passwd\" executable. Add the following to the aud.rules:\n\n-w /usr/bin/passwd -p x -k passwd\n\nConfigure write auditing of the \"passwd\", \"shadow\", \"group\", and \"opasswd\" files. Add the following to the \"/etc/audit/audit.rules\" file:\n\n-w /etc/passwd -p wa -k passwd\n-w /etc/shadow -p wa -k shadow\n-w /etc/group -p wa -k group\n-w /etc/security/opasswd -p wa -k opasswd\n\nRestart the auditd service:\n\n# service auditd restart","ccis":["CCI-002130"]},{"vulnId":"V-239594","ruleId":"SV-239594r852591_rule","severity":"medium","ruleTitle":"The SLES for vRealize must notify System Administrators and Information System Security Officers when accounts are created, or enabled when previously disabled.","description":"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 SLES for vRealize 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. \n\nIn order to detect and respond to events that affect user accessibility and application processing, SLES for vRealize systems must audit account enabling actions and, as required, notify the appropriate individuals so they can investigate the event. \n\nTo address access requirements, many operating systems can be integrated with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements.","checkContent":"Determine if execution of the \"usermod\" and \"groupmod\" executable are audited:\n\n# auditctl -l | egrep '(usermod|groupmod)'\n\nIf either \"useradd\" or \"groupadd\" are not listed with a permissions filter of at least \"x\", this is a finding.\n\nDetermine if execution of the \"userdel\" and \"groupdel\" executable are audited:\n\n# auditctl -l | egrep '(userdel|groupdel)'\n\nIf either \"userdel\" or \"groupdel\" are not listed with a permissions filter of at least \"x\", this is a finding.\n\nDetermine if execution of \"useradd\" and \"groupadd\" are audited:\n\n# auditctl -l | egrep '(useradd|groupadd)'\n\nIf either \"useradd\" or \"groupadd\" are not listed with a permissions filter of at least \"x\", this is a finding.\n\nDetermine if execution of the \"passwd\" executable is audited: \n\n# auditctl -l | grep \"/usr/bin/passwd\" \n\nIf \"/usr/bin/passwd\" is not listed with a permissions filter of at least \"x\", this is a finding. \n\nDetermine if \"/etc/passwd\", \"/etc/shadow\", \"/etc/group\", and \"/etc/security/opasswd\" are audited for writing:\n\n# auditctl -l | egrep '(/etc/passwd|/etc/shadow|/etc/group|/etc/security/opasswd)'\n\nIf any of these are not listed with a permissions filter of at least \"w\", this is a finding.","fixText":"Configure execute auditing of the \"usermod\" and \"groupmod\" executables. Add the following to the \"/etc/audit/audit.rules\" file:\n\n-w /usr/sbin/usermod -p x -k usermod\n-w /usr/sbin/groupmod -p x -k groupmod\n\nConfigure execute auditing of the \"userdel\" and \"groupdel\" executables. Add the following to the \"/etc/audit/audit.rules\" file:\n\n-w /usr/sbin/userdel -p x -k userdel\n-w /usr/sbin/groupdel -p x -k groupdel\n\nConfigure execute auditing of the \"useradd\" and \"groupadd\" executables. Add the following to audit.rules:\n\n-w /usr/sbin/useradd -p x -k useradd\n-w /usr/sbin/groupadd -p x -k groupadd\n\nConfigure execute auditing of the \"passwd\" executable. Add the following to the aud.rules:\n\n-w /usr/bin/passwd -p x -k passwd\n\nConfigure write auditing of the \"passwd\", \"shadow\", \"group\", and \"opasswd\" files. Add the following to the \"/etc/audit/audit.rules\" file:\n\n-w /etc/passwd -p wa -k passwd\n-w /etc/shadow -p wa -k shadow\n-w /etc/group -p wa -k group\n-w /etc/security/opasswd -p wa -k opasswd\n\nRestart the auditd service:\n\n# service auditd restart","ccis":["CCI-002132"]},{"vulnId":"V-239595","ruleId":"SV-239595r852592_rule","severity":"low","ruleTitle":"The SLES for vRealize must audit the execution of privileged functions.","description":"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.","checkContent":"To verify that auditing of privileged command use is configured, run the following command to find relevant setuid programs: \n\n# find / -xdev -type f -perm -4000 -o -perm -2000 2>/dev/null\n\nRun the following command to verify entries in the audit rules for all programs found with the previous command: \n\n# grep path /etc/audit/audit.rules\n\nIt 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.","fixText":"At a minimum, the audit system should collect the execution of privileged commands for all users and root. To find the relevant setuid programs: \n\n# find / -xdev -type f -perm -4000 -o -perm -2000 2>/dev/null\n\nThen, 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: \n\n-a always,exit -F path=[SETUID_PROG_PATH] -F perm=x -F auid>=500 -k privileged\n\nOR\n\n# /etc/dodscript.sh","ccis":["CCI-002234"]},{"vulnId":"V-239596","ruleId":"SV-239596r852593_rule","severity":"low","ruleTitle":"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.","description":"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.","checkContent":"Check the \"pam_tally2\" configuration:\n\n# more /etc/pam.d/common-auth\n\nConfirm the following line is configured:\n\nauth required pam_tally2.so deny=3 onerr=fail even_deny_root unlock_ti\nme=86400 root_unlock_time=300\n\n# more /etc/pam.d/common-account\n\nConfirm the following line is configured:\n\naccount required pam_tally2.so\n\nIf no such lines are found, this is a finding.","fixText":"Edit \"/etc/pam.d/common-auth\" file and add the following line:\n\nauth required pam_tally2.so deny=3 onerr=fail even_deny_root unlock_time=86400 root_unlock_time=300 \n\nEdit \"/etc/pam.d/common-account\" file and add the following line:\n\naccount required pam_tally2.so","ccis":["CCI-002238"]},{"vulnId":"V-239597","ruleId":"SV-239597r877390_rule","severity":"low","ruleTitle":"The SLES for vRealize must off-load audit records onto a different system or media from the system being audited.","description":"Information stored in one location is vulnerable to accidental or incidental deletion or alteration.\n\nOff-loading is a common process in information systems with limited audit storage capacity.","checkContent":"Check the syslog configuration file for remote syslog servers:\n\n# cat /etc/syslog-ng/syslog-ng.conf | grep logserver\n\nIf no line is returned, or the \"logserver\" is commented out, this is a finding.","fixText":"Edit the syslog configuration file and add an appropriate remote syslog server:\n\nIn 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:\n\n# \n# Enable this and adopt IP to send log messages to a log server. \n# \n#destination logserver { udp(\"10.10.10.10\" port(514)); };\n#log { source(src); destination(logserver); };","ccis":["CCI-001851"]},{"vulnId":"V-239598","ruleId":"SV-239598r877389_rule","severity":"medium","ruleTitle":"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.","description":"If security personnel are not notified immediately when storage volume reaches 75% utilization, they are unable to plan for audit record storage capacity expansion.","checkContent":"Check \"/etc/audit/auditd.conf\" file for the \"space_left_action\" parameter with the following command:\n\n# cat /etc/audit/auditd.conf | grep space_left_action \n\nIf 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\n\nExpected Result: \n\nspace_left_action = SYSLOG\n\nNotes: \nIf the \"space_left_action\" parameter is set to \"exec\" the system executes a designated script. \n\nIf this script informs the SA of the event, this is not a finding.\n\nIf the \"space_left_action\" parameter 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. \n\nThe \"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.","fixText":"Set the \"space_left_action\" parameter to the valid setting \"SYSLOG\", by running the following command:\n\n# sed -i \"/^[^#]*space_left_action/ c\\admin_space_left_action = SYSLOG\" /etc/audit/auditd.conf\n\nRestart the audit service: \n\n# service auditd restart","ccis":["CCI-001855"]},{"vulnId":"V-239599","ruleId":"SV-239599r852596_rule","severity":"medium","ruleTitle":"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.","description":"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.\n\nAlerts 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).","checkContent":"Check \"/etc/audit/auditd.conf\" file for the \"space_left_action\" parameter with the following command:\n\n# cat /etc/audit/auditd.conf | grep space_left_action \n\nIf 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\n\nExpected Result: \n\nspace_left_action = SYSLOG\n\nNotes: \nIf the \"space_left_action\" parameter is set to \"exec\" the system executes a designated script. \n\nIf this script informs the SA of the event, this is not a finding.\n\nIf the \"space_left_action\" parameter 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. \n\nThe \"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.","fixText":"Set the \"space_left_action\" parameter to the valid setting \"SYSLOG\", by running the following command:\n\n# sed -i \"/^[^#]*space_left_action/ c\\admin_space_left_action = SYSLOG\" /etc/audit/auditd.conf\n\nRestart the audit service: \n\n# service auditd restart","ccis":["CCI-001858"]},{"vulnId":"V-239600","ruleId":"SV-239600r878121_rule","severity":"medium","ruleTitle":"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).","description":"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.\n\nSynchronizing internal information system clocks provides uniformity of time stamps for information systems with multiple system clocks and systems connected over a network.\n\nOrganizations should consider endpoints that may not have regular access to the authoritative timeserver (e.g., mobile, teleworking, and tactical endpoints).","checkContent":"A remote NTP server should be configured for time synchronization. To verify one is configured, open the following files:\n\n# cat /etc/ntp.conf | grep server | grep -v '^#' \n# cat /etc/ntp.conf | grep peer | grep -v '^#' \n# cat /etc/ntp.conf | grep multicastclient | grep -v '^#' \n\nConfirm the servers and peers or multicastclient (as applicable) are local or an authoritative U.S. DoD source.\n\nIf a non-local/non-authoritative time-server is used, this is a finding.","fixText":"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:\n\n# echo \"server [ntpserver]\" >> /etc/ntp.conf\n\nReplace [ntpserver] with one of the USNO time servers. This instructs the NTP software to contact that remote server to obtain time data.\n\nRestart the service with: \n\n# service ntp restart","ccis":["CCI-001891"]},{"vulnId":"V-239601","ruleId":"SV-239601r877038_rule","severity":"medium","ruleTitle":"The time synchronization configuration file (such as /etc/ntp.conf) must be owned by root.","description":"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.","checkContent":"Check the ownership of the NTP configuration file:\n\n# ls -l /etc/ntp.conf\n\nIf the owner is not \"root\", this is a finding.","fixText":"Change the owner of the NTP configuration file to \"root\":\n\n# chown root /etc/ntp.conf","ccis":["CCI-001891"]},{"vulnId":"V-239602","ruleId":"SV-239602r877038_rule","severity":"medium","ruleTitle":"The time synchronization configuration file (such as /etc/ntp.conf) must be group-owned by root, bin, sys, or system.","description":"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.","checkContent":"Check the group ownership of the NTP configuration file:\n\n# ls -lL /etc/ntp.conf\n\nIf the group-owner is not \"root\", \"bin\", \"sys\", or \"system\", this is a finding.","fixText":"Change the group-owner of the NTP configuration file:\n\n# chgrp root /etc/ntp.conf","ccis":["CCI-001891"]},{"vulnId":"V-239603","ruleId":"SV-239603r877038_rule","severity":"medium","ruleTitle":"The time synchronization configuration file (such as /etc/ntp.conf) must have mode 0640 or less permissive.","description":"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.","checkContent":"Check that the mode for the NTP configuration file is not more permissive than \"0640\":\n\n# ls -l /etc/ntp.conf\n\nIf the mode is more permissive than \"0640\", this is a finding.","fixText":"Change the mode of the NTP configuration file to \"0640\" or less permissive:\n\n# chmod 0640 /etc/ntp.conf","ccis":["CCI-001891"]},{"vulnId":"V-239604","ruleId":"SV-239604r852601_rule","severity":"medium","ruleTitle":"The SLES for vRealize must synchronize internal information system clocks to the authoritative time source when the time difference is greater than one second.","description":"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.\n\nSynchronizing 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).\n\nOrganizations should also consider endpoints that may not have regular access to the authoritative timeserver (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.","checkContent":"Run the following command to determine the current status of the \"ntpd\" service: \n\n# service ntp status\n\nIf the service is configured, the command should show a list of the ntp servers and the status of the synchronization. \n\nIf nothing is returned, this is a finding.\n\nIf the service is configured, but does not show a status of \"on\", this is a finding.","fixText":"The \"ntp\" service can be enabled with the following command: \n\n# chkconfig ntp on \n# service ntp start","ccis":["CCI-002046"]},{"vulnId":"V-239605","ruleId":"SV-239605r852602_rule","severity":"medium","ruleTitle":"The SLES for vRealize must notify designated personnel if baseline configurations are changed in an unauthorized manner.","description":"Unauthorized changes to the baseline configuration could make the system vulnerable to various attacks or allow unauthorized access to the operating system. Changes to operating system configurations can have unintended side effects, some of which may be relevant to security.\n\nDetecting such changes and providing an automated response can help avoid unintended, negative consequences that could ultimately affect the security state of the SLES for vRealize. SLES for vRealize’s IMO/ISSO and SAs must be notified via email and/or monitoring system trap when there is an unauthorized modification of a configuration item.","checkContent":"Verify SLES for vRealize produces audit records by running the following command to determine the current status of the \"auditd\" service:\n\n# service auditd status\n\nIf the service is enabled, the returned message must contain the following text:\n\nChecking for service auditd                running\n\nIf the service is not running, this is a finding.","fixText":"Enable the \"auditd\" service by performing the following commands:\n\n# chkconfig auditd on\n# service auditd start","ccis":["CCI-001744"]},{"vulnId":"V-239606","ruleId":"SV-239606r852603_rule","severity":"medium","ruleTitle":"The SLES for vRealize must audit the enforcement actions used to restrict access associated with changes to the system.","description":"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.\n\nEnforcement 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.","checkContent":"Verify SLES for vRealize produces audit records by running the following command to determine the current status of the \"auditd\" service:\n\n# service auditd status\n\nIf the service is enabled, the returned message must contain the following text:\n\nChecking for service auditd                running\n\nIf the service is not running, this is a finding.","fixText":"Enable the \"auditd\" service by performing the following commands:\n\n# chkconfig auditd on\n# service auditd start","ccis":["CCI-001814"]},{"vulnId":"V-239607","ruleId":"SV-239607r877463_rule","severity":"medium","ruleTitle":"The RPM package management tool must cryptographically verify the authenticity of all software packages during installation.","description":"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.\n\nAccordingly, patches, service packs, device drivers, or SLES for vRealize components must be signed with a certificate recognized and approved by the organization.\n\nVerifying 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. SLES for vRealize 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.","checkContent":"Verify RPM signature validation is not disabled:\n\n# grep nosignature /usr/lib/rpm/rpmrc ~root/.rpmrc\n\nThe result should either respond with no such file or directory, or an empty return.\n\nIf any configuration is found, this is a finding.","fixText":"Edit the RPM configuration files containing the \"nosignature\" option and remove the option.","ccis":["CCI-001749"]},{"vulnId":"V-239608","ruleId":"SV-239608r852605_rule","severity":"medium","ruleTitle":"The SLES for vRealize must audit all activities performed during nonlocal maintenance and diagnostic sessions.","description":"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.\n\nThis requirement addresses auditing-related issues associated with maintenance tools used specifically for diagnostic and repair actions on organizational information systems.\n\nNonlocal 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.\n\nThis 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.","checkContent":"Verify that all commands run by \"root\" are being audited with the following command:\n\n# cat /etc/audit/audit.rules | grep execve\n\nIf the following lines are not displayed, this is a finding.\n\n-a exit,always -F arch=b64 -F euid=0 -S execve\n-a exit,always -F arch=b32 -F euid=0 -S execve","fixText":"Configure SLES for vRealize to log all commands run by \"root\" with the following command:\n\n# echo \"-a exit,always -F arch=b64 -F euid=0 -S execve\" >> /etc/audit/audit.rules\n\n# echo \"-a exit,always -F arch=b32 -F euid=0 -S execve\" >> /etc/audit/audit.rules\n\nRestart the audit service: \n\n# service auditd restart","ccis":["CCI-002884"]},{"vulnId":"V-239609","ruleId":"SV-239609r877382_rule","severity":"medium","ruleTitle":"The SLES for vRealize must implement cryptographic mechanisms to protect the integrity of nonlocal maintenance and diagnostic communications, when used for nonlocal maintenance sessions.","description":"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. \n\nNonlocal 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. \n\nThe SLES for vRealize 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).","checkContent":"Check the SSH daemon configuration for DoD-approved encryption to protect the confidentiality of SSH remote connections by performing the following commands:\n\nCheck the Cipher setting in the \"sshd_config\" file.\n\n# grep -i Ciphers /etc/ssh/sshd_config  | grep -v '#' \n\nThe output must contain either none or any number of the following algorithms:\n\naes128-ctr, aes256-ctr.\n\nIf the output contains an algorithm not listed above, this is a finding.\n\nExpected Output:\nCiphers aes256-ctr,aes128-ctr","fixText":"Update the Ciphers directive with the following command: \n\n# sed -i '/^[^#]*Ciphers/ c\\Ciphers aes256-ctr,aes128-ctr' /etc/ssh/sshd_config\n\nSave and close the file. Restart the sshd process: \n\n# service sshd restart","ccis":["CCI-002890"]},{"vulnId":"V-239610","ruleId":"SV-239610r877381_rule","severity":"medium","ruleTitle":"The SLES for vRealize must implement cryptographic mechanisms to protect the confidentiality of nonlocal maintenance and diagnostic communications, when used for nonlocal maintenance sessions.","description":"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.\n\nNonlocal 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. \n\nThis 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).\n\nThe SLES for vRealize can meet this requirement through leveraging a cryptographic module.","checkContent":"Check the SSH daemon configuration for allowed MACs:\n\n# grep -i macs /etc/ssh/sshd_config | grep -v '^#' \n\nIf no lines are returned, or the returned MACs list contains any MAC other than \"hmac-sha1\", this is a finding.","fixText":"Edit the SSH daemon configuration and remove any MACs other than \"hmac-sha1\". If necessary, add a \"MACs\" line.\n\n# sed -i \"/^[^#]*MACs/ c\\MACs hmac-sha1\" /etc/ssh/sshd_config","ccis":["CCI-003123"]},{"vulnId":"V-239611","ruleId":"SV-239611r877380_rule","severity":"high","ruleTitle":"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.","description":"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.","checkContent":"Check the SSH daemon configuration for DoD-approved encryption to protect the confidentiality of SSH remote connections by performing the following commands:\n\nCheck the Cipher setting in the \"sshd_config\" file.\n\n# grep -i Ciphers /etc/ssh/sshd_config  | grep -v '#' \n\nThe output must contain either none or any number of the following algorithms:\n\naes128-ctr, aes256-ctr.\n\nIf the output contains an algorithm not listed above, this is a finding.\n\nExpected Output:\nCiphers aes256-ctr,aes128-ctr","fixText":"Update the Ciphers directive with the following command: \n\n# sed -i \"/^[^#]*Ciphers/ c\\Ciphers aes256-ctr,aes128-ctr\" /etc/ssh/sshd_config\n\nSave and close the file. Restart the sshd process: \n\n# service sshd restart","ccis":["CCI-002450"]},{"vulnId":"V-239612","ruleId":"SV-239612r916422_rule","severity":"high","ruleTitle":"The SLES for vRealize must protect the confidentiality and integrity of transmitted information.","description":"Without protection of the transmitted information, confidentiality and integrity may be compromised because unprotected communications can be intercepted and either read or altered. \n\nThis 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. \n\nProtecting 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.","checkContent":"Check the SSH daemon configuration for DoD-approved encryption to protect the confidentiality of SSH remote connections by performing the following commands:\n\nCheck the Cipher setting in the \"sshd_config\" file.\n\n# grep -i Ciphers /etc/ssh/sshd_config  | grep -v '#' \n\nThe output must contain either none or any number of the following algorithms:\n\naes128-ctr, aes256-ctr.\n\nIf the output contains an algorithm not listed above, this is a finding.\n\nExpected Output:\nCiphers aes256-ctr,aes128-ctr","fixText":"Update the Ciphers directive with the following command: \n\n# sed -i \"/^[^#]*Ciphers/ c\\Ciphers aes256-ctr,aes128-ctr\" /etc/ssh/sshd_config\n\nSave and close the file. Restart the sshd process: \n\n# service sshd restart","ccis":["CCI-002418"]},{"vulnId":"V-239613","ruleId":"SV-239613r878122_rule","severity":"high","ruleTitle":"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).","description":"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. \n\nUse 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.\n\nAlternative 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.","checkContent":"Check the SSH daemon configuration for allowed MACs:\n\n# grep -i macs /etc/ssh/sshd_config | grep -v '^#' \n\nIf no lines are returned, or the returned MACs list contains any MAC other than \"hmac-sha1\", this is a finding.","fixText":"Edit the SSH daemon configuration and remove any MACs other than \"hmac-sha1\". If necessary, add a \"MACs\" line. \n\n# sed -i \"/^[^#]*MACs/ c\\MACs hmac-sha1\" /etc/ssh/sshd_config","ccis":["CCI-002421"]},{"vulnId":"V-239614","ruleId":"SV-239614r852611_rule","severity":"medium","ruleTitle":"The SLES for vRealize must implement non-executable data to protect its memory from unauthorized code execution.","description":"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.\n\nExamples of attacks are buffer overflow attacks.","checkContent":"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:\n\n# grep -i \"execute\" /var/log/boot.msg\n\nThe 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.\n\nTo activate this support, the \"noexec=on\" kernel parameter must be specified at boot time. Check for a message with the following command:\n\n# grep –i \"noexec\" /var/log/boot.msg\n\nThe message: \"Kernel command line: <boot parameters> noexec=on\" will be written to the boot log when properly appended to the \"/boot/grub/menu.lst\" file.\n\nIf non-executable program stacks have not been configured, this is a finding.","fixText":"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.","ccis":["CCI-002824"]},{"vulnId":"V-239615","ruleId":"SV-239615r852612_rule","severity":"medium","ruleTitle":"The SLES for vRealize must implement address space layout randomization to protect its memory from unauthorized code execution.","description":"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.\n\nExamples of attacks are buffer overflow attacks.","checkContent":"Verify \"randomize_va_space\" has not been changed from the default \"1\" setting.\n\n# sysctl kernel.randomize_va_space\n\nIf the return value is not \"kernel.randomize_va_space = 1\", this is a finding.","fixText":"Run the following command:\n\n#sysctl kernel.randomize_va_space=1","ccis":["CCI-002824"]},{"vulnId":"V-239616","ruleId":"SV-239616r852613_rule","severity":"medium","ruleTitle":"The SLES for vRealize must shut down the information system, restart the information system, and/or notify the system administrator when anomalies in the operation of any security functions are discovered.","description":"If anomalies are not acted upon, security functions may fail to secure the system. \n\nSecurity 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.\n\nNotifications provided by information systems include messages to local computer consoles, and/or hardware indications, such as lights.\n\nThis capability must take into account operational requirements for availability for selecting an appropriate response. The organization may choose to shut down or restart the information system upon security function anomaly detection.","checkContent":"Check the syslog configuration file for remote syslog servers:\n\n# cat /etc/syslog-ng/syslog-ng.conf | grep logserver\n\nIf no line is returned, or the \"logserver\" is commented out, this is a finding.","fixText":"Edit the syslog configuration file and add an appropriate remote syslog server:\n\nIn 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:\n\n# \n# Enable this and adopt IP to send log messages to a log server. \n# \n#destination logserver { udp(\"10.10.10.10\" port(514)); };\n#log { source(src); destination(logserver); };","ccis":["CCI-002702"]},{"vulnId":"V-239617","ruleId":"SV-239617r662302_rule","severity":"medium","ruleTitle":"The SLES for vRealize must generate audit records when successful/unsuccessful attempts to access security objects occur.","description":"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.\n\nAudit records can be generated from various components within the information system (e.g., module or policy filter).","checkContent":"To verify that auditing is configured for system administrator actions, run the following command: \n\n# auditctl -l | grep \"watch=/etc/sudoers\"\n\nThe result should return a rule for sudoers, such as: \n\nLIST_RULES: exit,always watch=/etc/sudoers perm=wa key=sudoers\n\nIf there is no output, this is a finding.","fixText":"At a minimum, the audit system should collect administrator actions for all users and \"root\". Add the following to the \"/etc/audit/audit.rules\" file: \n\n-w /etc/sudoers -p wa -k sudoers\n\nOR\n\n# /etc/dodscript.sh","ccis":["CCI-000172"]},{"vulnId":"V-239618","ruleId":"SV-239618r662305_rule","severity":"medium","ruleTitle":"The SLES for vRealize must generate audit records when successful/unsuccessful attempts to access categories of information (e.g., classification levels) occur.","description":"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.\n\nAudit records can be generated from various components within the information system (e.g., module or policy filter).","checkContent":"Verify the SLES for vRealize produces audit records by running the following command to determine the current status of the \"auditd\" service:\n\n# service auditd status\n\nIf the service is enabled, the returned message must contain the following text:\n\nChecking for service auditd                running\n\nIf the service is not running, this is a finding.","fixText":"Enable the \"auditd\" service by performing the following commands:\n\n# chkconfig auditd on\n# service auditd start","ccis":["CCI-000172"]},{"vulnId":"V-239619","ruleId":"SV-239619r662308_rule","severity":"medium","ruleTitle":"The SLES for vRealize must generate audit records when successful/unsuccessful attempts to modify privileges occur.","description":"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.\n\nAudit records can be generated from various components within the information system (e.g., module or policy filter).","checkContent":"To determine if SLES for vRealize is configured to audit calls to the \"chmod\" system call, run the following command: \n\n# auditctl -l | grep syscall | grep chmod\n\nIf the system is configured to audit this activity, it will return several lines, such as: \n\nLIST_RULES: exit,always arch=3221225534 (0xc000003e) auid=0 syscall=chmod,fchmod,chown,fchown,fchownat,fchmodat\nLIST_RULES: exit,always arch=3221225534 (0xc000003e) auid>=500 (0x1f4) auid!=-1 (0xffffffff) syscall=chmod,fchmod,chown,fchown,fchownat,fchmodat\nLIST_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\n\nIf no lines are returned, this is a finding.","fixText":"At a minimum, the audit system should collect file permission changes for all users and \"root\". Add the following to the \"/etc/audit/audit.rules\" file: \n\n-a always,exit -F arch=b64 -S chmod -F auid=0\n-a always,exit -F arch=b64 -S chmod -F auid>=500 -F auid!=4294967295\n-a always,exit -F arch=b32 -S chmod\n\nOR\n\n# /etc/dodscript.sh","ccis":["CCI-000172"]},{"vulnId":"V-239620","ruleId":"SV-239620r662311_rule","severity":"medium","ruleTitle":"The SLES for vRealize must generate audit records when successful/unsuccessful attempts to modify security objects occur.","description":"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.\n\nAudit records can be generated from various components within the information system (e.g., module or policy filter).","checkContent":"To verify that auditing is configured for system administrator actions, run the following command: \n\n# auditctl -l | grep \"watch=/etc/sudoers\"\n\nThe result should return a rule for sudoers, such as: \n\nLIST_RULES: exit,always watch=/etc/sudoers perm=wa key=sudoers\n\nIf there is no output, this is a finding.","fixText":"At a minimum, the audit system should collect administrator actions for all users and root. Add the following to the \"/etc/audit/audit.rules\" file: \n\n-w /etc/sudoers -p wa -k sudoers\n\nOR\n\n# /etc/dodscript.sh","ccis":["CCI-000172"]},{"vulnId":"V-239621","ruleId":"SV-239621r662314_rule","severity":"medium","ruleTitle":"The SLES for vRealize must generate audit records when successful/unsuccessful attempts to modify categories of information (e.g., classification levels) occur.","description":"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.\n\nAudit records can be generated from various components within the information system (e.g., module or policy filter).","checkContent":"Verify the SLES for vRealize produces audit records by running the following command to determine the current status of the \"auditd\" service:\n\n# service auditd status\n\nIf the service is enabled, the returned message must contain the following text:\n\nChecking for service auditd                running\n\nIf the service is not running, this is a finding.","fixText":"Enable the \"auditd\" service by performing the following commands:\n\n# chkconfig auditd on\n# service auditd start","ccis":["CCI-000172"]},{"vulnId":"V-239622","ruleId":"SV-239622r662317_rule","severity":"medium","ruleTitle":"The SLES for vRealize must generate audit records when successful/unsuccessful attempts to delete privileges occur.","description":"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.\n\nAudit records can be generated from various components within the information system (e.g., module or policy filter).","checkContent":"To determine if SLES for vRealize is configured to audit calls to the \"chmod\" system call, run the following command: \n\n# auditctl -l | grep syscall | grep chmod\n\nIf the system is configured to audit this activity, it will return several lines, such as: \n\nLIST_RULES: exit,always arch=3221225534 (0xc000003e) auid=0 syscall=chmod,fchmod,chown,fchown,fchownat,fchmodat\nLIST_RULES: exit,always arch=3221225534 (0xc000003e) auid>=500 (0x1f4) auid!=-1 (0xffffffff) syscall=chmod,fchmod,chown,fchown,fchownat,fchmodat\nLIST_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\n\nIf no lines are returned, this is a finding.","fixText":"At a minimum, the SLES for vRealize audit system should collect file permission changes for all users and root. Add the following to the \"/etc/audit/audit.rules\" file: \n\n-a always,exit -F arch=b64 -S chmod -F auid=0\n-a always,exit -F arch=b64 -S chmod -F auid>=500 -F auid!=4294967295\n-a always,exit -F arch=b32 -S chmod\n\nOR\n\n# /etc/dodscript.sh","ccis":["CCI-000172"]},{"vulnId":"V-239623","ruleId":"SV-239623r662320_rule","severity":"medium","ruleTitle":"The SLES for vRealize must generate audit records when successful/unsuccessful attempts to delete security levels occur.","description":"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.\n\nAudit records can be generated from various components within the information system (e.g., module or policy filter).","checkContent":"Verify the SLES for vRealize produces audit records by running the following command to determine the current status of the \"auditd\" service:\n\n# service auditd status\n\nIf the service is enabled, the returned message must contain the following text:\n\nChecking for service   auditd   running\n\nIf the service is not running, this is a finding.","fixText":"Enable the \"auditd\" service by performing the following commands:\n\n# chkconfig auditd on\n# service auditd start","ccis":["CCI-000172"]},{"vulnId":"V-239624","ruleId":"SV-239624r662323_rule","severity":"medium","ruleTitle":"The SLES for vRealize must generate audit records when successful/unsuccessful attempts to delete security objects occur.","description":"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.\n\nAudit records can be generated from various components within the information system (e.g., module or policy filter).","checkContent":"To verify that auditing is configured for system administrator actions, run the following command: \n\n# auditctl -l | grep \"watch=/etc/sudoers\"\n\nThe result should return a rule for sudoers, such as: \n\nLIST_RULES: exit,always watch=/etc/sudoers perm=wa key=sudoers\n\nIf there is no output, this is a finding.","fixText":"At a minimum, the SLES for vRealize audit system should collect administrator actions for all users and root. Add the following to the \"/etc/audit/audit.rules\" file: \n\n-w /etc/sudoers -p wa -k sudoers\n\nOR\n\n# /etc/dodscript.sh","ccis":["CCI-000172"]},{"vulnId":"V-239625","ruleId":"SV-239625r662326_rule","severity":"medium","ruleTitle":"The SLES for vRealize must generate audit records when successful/unsuccessful logon attempts occur.","description":"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.\n\nAudit records can be generated from various components within the information system (e.g., module or policy filter).","checkContent":"The message types that are always recorded to the \"/var/log/audit/audit.log\" file include \"LOGIN\", \"USER_LOGIN\", \"USER_START\", \"USER_END\" among others and do not need to be added to audit.rules.\n\nThe log files \"/var/log/faillog\", \"/var/log/lastlog\", and \"/var/log/tallylog\" must be protected from tampering of the login records:\n\n# egrep \"faillog|lastlog|tallylog\" /etc/audit/audit.rules\n\nIf \"/var/log/faillog\", \"/var/log/lastlog\", and \"/var/log/tallylog\" entries do not exist, this is a finding.","fixText":"Ensure the auditing of logins by modifying the \"/etc/audit/audit.rules\" file to contain:\n\n-w /var/log/faillog -p wa\n-w /var/log/lastlog -p wa\n-w /var/log/tallylog -p wa\n\nOR\n\n# /etc/dodscript.sh","ccis":["CCI-000172"]},{"vulnId":"V-239626","ruleId":"SV-239626r662329_rule","severity":"medium","ruleTitle":"The SLES for vRealize must generate audit records for privileged activities or other system-level access.","description":"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.\n\nAudit records can be generated from various components within the information system (e.g., module or policy filter).","checkContent":"To verify that auditing of privileged command use is configured, run the following command to find relevant setuid programs: \n\n# find / -xdev -type f -perm -4000 -o -perm -2000 2>/dev/null\n\nRun the following command to verify entries in the audit rules for all programs found with the previous command: \n\n# grep path /etc/audit/audit.rules\n\nIt 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.","fixText":"At a minimum, the SLES for vRealize audit system should collect the execution of privileged commands for all users and \"root\". To find the relevant setuid programs: \n\n# find / -xdev -type f -perm -4000 -o -perm -2000 2>/dev/null\n\nThen, 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: \n\n-a always,exit -F path=[SETUID_PROG_PATH] -F perm=x -F auid>=500 -k privileged\n\nOR\n\n# /etc/dodscript.sh","ccis":["CCI-000172"]},{"vulnId":"V-239627","ruleId":"SV-239627r662332_rule","severity":"medium","ruleTitle":"The SLES for vRealize audit system must be configured to audit the loading and unloading of dynamic kernel modules.","description":"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. \n\nAudit records can be generated from various components within the information system (e.g., module or policy filter).","checkContent":"Determine if \"/sbin/insmod\" is audited:\n\n# cat /etc/audit/audit.rules | grep \"/sbin/insmod\"\n\nIf the result does not start with \"-w\" and contain \"-p x\", this is a finding.","fixText":"Add the following to the \"/etc/audit/audit.rules\" file in order to capture kernel module loading and unloading events:\n\n-w /sbin/insmod -p x\n\nOR\n\n# /etc/dodscript.sh","ccis":["CCI-000172"]},{"vulnId":"V-239628","ruleId":"SV-239628r662335_rule","severity":"medium","ruleTitle":"The SLES for vRealize must generate audit records showing starting and ending time for user access to the system.","description":"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.\n\nAudit records can be generated from various components within the information system (e.g., module or policy filter).","checkContent":"The message types that are always recorded to the \"/var/log/audit/audit.log\" file include \"LOGIN\", \"USER_LOGIN\", \"USER_START\", \"USER_END\" among others and do not need to be added to audit.rules.\n\nThe log files \"/var/log/faillog\", \"/var/log/lastlog\", and \"/var/log/tallylog\" must be protected from tampering of the login records:\n\n# egrep \"faillog|lastlog|tallylog\" /etc/audit/audit.rules\n\nIf \"/var/log/faillog\", \"/var/log/lastlog\", and \"/var/log/tallylog\" entries do not exist, this is a finding.","fixText":"Ensure the auditing of logins by modifying the \"/etc/audit/audit.rules\" file to contain:\n\n-w /var/log/faillog -p wa\n-w /var/log/lastlog -p wa\n-w /var/log/tallylog -p wa\n\nOR\n\n# /etc/dodscript.sh","ccis":["CCI-000172"]},{"vulnId":"V-239629","ruleId":"SV-239629r662338_rule","severity":"medium","ruleTitle":"The SLES for vRealize must generate audit records when concurrent logons to the same account occur from different sources.","description":"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.\n\nAudit records can be generated from various components within the information system (e.g., module or policy filter).","checkContent":"The message types that are always recorded to the \"/var/log/audit/audit.log\" file include \"LOGIN\", \"USER_LOGIN\", \"USER_START\", \"USER_END\" among others and do not need to be added to audit.rules.\n\nThe log files \"/var/log/faillog\", \"/var/log/lastlog\", and \"/var/log/tallylog\" must be protected from tampering of the login records:\n\n# egrep \"faillog|lastlog|tallylog\" /etc/audit/audit.rules\n\nIf \"/var/log/faillog\", \"/var/log/lastlog\", and \"/var/log/tallylog\" entries do not exist, this is a finding.","fixText":"Ensure the auditing of logins by modifying the \"/etc/audit/audit.rules\" file to contain:\n\n-w /var/log/faillog -p wa\n-w /var/log/lastlog -p wa\n-w /var/log/tallylog -p wa\n\nOR\n\n# /etc/dodscript.sh","ccis":["CCI-000172"]},{"vulnId":"V-239630","ruleId":"SV-239630r662341_rule","severity":"medium","ruleTitle":"The SLES for vRealize must generate audit records when successful/unsuccessful accesses to objects occur.","description":"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.\n\nAudit records can be generated from various components within the information system (e.g., module or policy filter).","checkContent":"Verify the SLES for vRealize produces audit records by running the following command to determine the current status of the \"auditd\" service:\n\n# service auditd status\n\nIf the service is enabled, the returned message must contain the following text:\n\nChecking for service auditd                running\n\nIf the service is not running, this is a finding.","fixText":"Enable the \"auditd\" service by performing the following commands:\n\n# chkconfig auditd on\n# service auditd start","ccis":["CCI-000172"]},{"vulnId":"V-239631","ruleId":"SV-239631r662344_rule","severity":"medium","ruleTitle":"The SLES for vRealize audit system must be configured to audit failed attempts to access files and programs.","description":"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.","checkContent":"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:\n\n# cat /etc/audit.rules /etc/audit/audit.rules | grep -e \"-a exit,always\" | grep -e \"-S creat\" | grep -e \"-F exit=-EPERM\"\n\n# cat /etc/audit.rules /etc/audit/audit.rules | grep -e \"-a exit,always\" | grep -e \"-S creat\" | grep -e \"-F exit=-EACCES\"\n\nThere must be both an \"-F exit=-EPERM\" and \"-F exit=-EACCES\" for each access syscall. If not, this is a finding.","fixText":"Edit the audit.rules file and add the following line(s) to enable auditing of failed attempts to access files and programs:\n\n-a exit,always -F arch=b64 -S creat -F exit=-EPERM\n-a exit,always -F arch=b64 -S creat -F exit=-EACCES\n-a exit,always -F arch=b32 -S creat -F exit=-EPERM\n-a exit,always -F arch=b32 -S creat -F exit=-EACCES","ccis":["CCI-000172"]},{"vulnId":"V-239632","ruleId":"SV-239632r662347_rule","severity":"medium","ruleTitle":"The SLES for vRealize audit system must be configured to audit failed attempts to access files and programs.","description":"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.","checkContent":"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:\n\n# cat /etc/audit.rules /etc/audit/audit.rules | grep -e \"-a exit,always\" | grep -e \"-S open\" | grep -e \"-F exit=-EPERM\"\n\n# cat /etc/audit.rules /etc/audit/audit.rules | grep -e \"-a exit,always\" | grep -e \"-S open\" | grep -e \"-F exit=-EACCES\"\n\nThere must be both an \"-F exit=-EPERM\" and \"-F exit=-EACCES\" for each access syscall. If not, this is a finding.","fixText":"Edit the audit.rules file and add the following line(s) to enable auditing of failed attempts to access files and programs:\n\n-a exit,always -F arch=b64 -S open -F exit=-EPERM\n-a exit,always -F arch=b64 -S open -F exit=-EACCES\n-a exit,always -F arch=b32 -S open -F exit=-EPERM\n-a exit,always -F arch=b32 -S open -F exit=-EACCES","ccis":["CCI-000172"]},{"vulnId":"V-239633","ruleId":"SV-239633r662350_rule","severity":"medium","ruleTitle":"The SLES for vRealize audit system must be configured to audit failed attempts to access files and programs.","description":"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.","checkContent":"Verify auditd is configured to audit failed file access attempts. There must be an audit rule for each of the access syscalls logging all failed accesses (-F success=0)\n\n# cat /etc/audit.rules /etc/audit/audit.rules | grep -e \"-a exit,always\" | grep -e \"-S openat\" | grep -e \"-F success=0\"\n\nThere must be an audit rule for each of the access syscalls logging all failed accesses (-F success=0). If not, this is a finding.","fixText":"Edit the audit.rules file and add the following line(s) to enable auditing of failed attempts to access files and programs:\n\n-a exit,always -F arch=b64 -S openat -F success=0\n-a exit,always -F arch=b32 -S openat -F success=0","ccis":["CCI-000172"]},{"vulnId":"V-239634","ruleId":"SV-239634r662353_rule","severity":"medium","ruleTitle":"The SLES for vRealize audit system must be configured to audit failed attempts to access files and programs.","description":"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.","checkContent":"Verify auditd is configured to audit failed file access attempts. There must be an audit rule for each of the access syscalls logging all failed accesses (-F success=0)\n\n# cat /etc/audit.rules /etc/audit/audit.rules | grep -e \"-a exit,always\" | grep -e \"-S truncate\" | grep -e \"-F success=0\"\n\nThere must be an audit rule for each of the access syscalls logging all failed accesses (-F success=0). If not, this is a finding.","fixText":"Edit the audit.rules file and add the following line(s) to enable auditing of failed attempts to access files and programs:\n\n-a exit,always -F arch=b64 -S truncate -F success=0\n-a exit,always -F arch=b32 -S truncate -F success=0","ccis":["CCI-000172"]},{"vulnId":"V-239635","ruleId":"SV-239635r662356_rule","severity":"medium","ruleTitle":"The SLES for vRealize audit system must be configured to audit failed attempts to access files and programs.","description":"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.","checkContent":"Verify auditd is configured to audit failed file access attempts. There must be an audit rule for each of the access syscalls logging all failed accesses (-F success=0)\n\n# cat /etc/audit.rules /etc/audit/audit.rules | grep -e \"-a exit,always\" | grep -e \"-S ftruncate\" | grep -e \"-F success=0\"\n\nThere must be an audit rule for each of the access syscalls logging all failed accesses (-F success=0). If not, this is a finding.","fixText":"Edit the audit.rules file and add the following line(s) to enable auditing of failed attempts to access files and programs:\n\n-a exit,always -F arch=b64 -S ftruncate -F success=0\n-a exit,always -F arch=b32 -S ftruncate -F success=0","ccis":["CCI-000172"]},{"vulnId":"V-239636","ruleId":"SV-239636r662359_rule","severity":"medium","ruleTitle":"The SLES for vRealize audit system must be configured to audit user deletions of files and programs.","description":"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.","checkContent":"To determine if SLES for vRealize is configured to audit calls to the \"unlink\" system call, run the following command: \n\n# auditctl -l | grep syscall | grep unlink | grep -v unlinkat\n\nIf the system is configured to audit this activity, it will return several lines. To determine if the system is configured to audit calls to the \"unlinkat\" system call, run the following command: \n\n# auditctl -l | grep syscall | grep unlinkat\n\nIf the system is configured to audit this activity, it will return several lines. To determine if the system is configured to audit calls to the \"rename\" system call, run the following command: \n\n# auditctl -l | grep syscall | grep rename | grep -v renameat\n\nIf the system is configured to audit this activity, it will return several lines. To determine if the system is configured to audit calls to the \"renameat\" system call, run the following command: \n\n# auditctl -l | grep syscall | grep renameat\n\nIf the system is configured to audit this activity, it will return several lines. If no line is returned, this is a finding.","fixText":"Edit the audit.rules file and add the following line(s) to enable auditing of deletions of files and programs:\n\n-a always,exit -F arch=b64 -S unlink -S unlinkat -S rename -S renameat -F auid=0\n-a always,exit -F arch=b64 -S unlink -S unlinkat -S rename -S renameat -F auid>=500 -F auid!=4294967295\n-a always,exit -F arch=b32 -S unlink -S unlinkat -S rename -S renameat -F auid=0\n-a always,exit -F arch=b32 -S unlink -S unlinkat -S rename -S renameat -F auid>=500 -F auid!=4294967295","ccis":["CCI-000172"]},{"vulnId":"V-239637","ruleId":"SV-239637r662362_rule","severity":"medium","ruleTitle":"The SLES for vRealize audit system must be configured to audit file deletions.","description":"If the SLES for vRealize 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.","checkContent":"Check SLES for vRealize audit configuration to determine if file and directory deletions are audited:\n\n# cat /etc/audit.rules /etc/audit/audit.rules | grep -e \"-a exit,always\" | grep -i \"rmdir\"\n\nIf no results are returned or the results do not contain \"-S rmdir\", this is a finding.","fixText":"Add the following to the \"/etc/audit/audit.rules\" file in order to capture file and directory deletion events:\n\n-a always,exit -F arch=b64 -S rmdir -S rm\n-a always,exit -F arch=b32 -S rmdir -S rm","ccis":["CCI-000172"]},{"vulnId":"V-239638","ruleId":"SV-239638r662365_rule","severity":"medium","ruleTitle":"Audit logs must be rotated daily.","description":"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.","checkContent":"Check for a logrotate entry that rotates audit logs.\n\n# ls -l /etc/logrotate.d/audit\n\nIf it exists, check for the presence of the daily rotate flag:\n\n# egrep \"daily\" /etc/logrotate.d/audit\n\nThe command should produce a \"daily\" entry in the logrotate file for the audit daemon. \n\nIf the daily entry is missing, this is a finding.","fixText":"Create or edit the \"/etc/logrotate.d/audit\" file and add the daily entry, such as:\n\n/var/log/audit/audit.log {\ncompress\ndateext\nrotate 15\ndaily\nmissingok\nnotifempty\ncreate 600 root root\nsharedscripts\npostrotate\n/sbin/service auditd restart 2> /dev/null > /dev/null || true\nendscript\n}","ccis":["CCI-000172"]},{"vulnId":"V-239639","ruleId":"SV-239639r662368_rule","severity":"medium","ruleTitle":"The SLES for vRealize must generate audit records for all direct access to the information system.","description":"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.\n\nAudit records can be generated from various components within the information system (e.g., module or policy filter).","checkContent":"The message types that are always recorded to the \"/var/log/audit/audit.log\" file include \"LOGIN\", \"USER_LOGIN\", \"USER_START\", \"USER_END\" among others and do not need to be added to audit.rules.\n\nThe log files \"/var/log/faillog\", \"/var/log/lastlog\", and \"/var/log/tallylog\" must be protected from tampering of the login records:\n\n# egrep \"faillog|lastlog|tallylog\" /etc/audit/audit.rules\n\nIf \"/var/log/faillog\", \"/var/log/lastlog\", and \"/var/log/tallylog\" entries do not exist, this is a finding.","fixText":"Ensure the auditing of logins by modifying the \"/etc/audit/audit.rules\" file to contain:\n\n-w /var/log/faillog -p wa\n-w /var/log/lastlog -p wa\n-w /var/log/tallylog -p wa\n\nOR\n\n# /etc/dodscript.sh","ccis":["CCI-000172"]},{"vulnId":"V-239640","ruleId":"SV-239640r662371_rule","severity":"medium","ruleTitle":"The SLES for vRealize must generate audit records for all account creations, modifications, disabling, and termination events.","description":"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.\n\nAudit records can be generated from various components within the information system (e.g., module or policy filter).","checkContent":"Determine if execution of the \"usermod\" and \"groupmod\" executable are audited:\n\n# auditctl -l | egrep '(usermod|groupmod)'\n\nIf either \"useradd\" or \"groupadd\" are not listed with a permissions filter of at least \"x\", this is a finding.\n\nDetermine if execution of the \"userdel\" and \"groupdel\" executable are audited:\n\n# auditctl -l | egrep '(userdel|groupdel)'\n\nIf either \"userdel\" or \"groupdel\" are not listed with a permissions filter of at least \"x\", this is a finding.\n\nDetermine if execution of \"useradd\" and \"groupadd\" are audited:\n\n# auditctl -l | egrep '(useradd|groupadd)'\n\nIf either \"useradd\" or \"groupadd\" are not listed with a permissions filter of at least \"x\", this is a finding.\n\nDetermine if execution of the passwd executable is audited: \n\n# auditctl -l | grep \"/usr/bin/passwd\" \n\nIf \"/usr/bin/passwd\" is not listed with a permissions filter of at least \"x\", this is a finding.\n\nDetermine if \"/etc/passwd\", \"/etc/shadow\", \"/etc/group\", and \"/etc/security/opasswd\" are audited for writing:\n\n# auditctl -l | egrep '(/etc/passwd|/etc/shadow|/etc/group|/etc/security/opasswd)'\n\nIf any of these are not listed with a permissions filter of at least \"w\", this is a finding.","fixText":"Configure execute auditing of the \"usermod\" and \"groupmod\" executables. Add the following to the \"/etc/audit/audit.rules\" file:\n\n-w /usr/sbin/usermod -p x -k usermod\n-w /usr/sbin/groupmod -p x -k groupmod\n\nConfigure execute auditing of the \"userdel\" and \"groupdel\" executables. Add the following to the \"/etc/audit/audit.rules\" file:\n\n-w /usr/sbin/userdel -p x -k userdel\n-w /usr/sbin/groupdel -p x -k groupdel\n\nConfigure execute auditing of the \"useradd\" and \"groupadd\" executables. Add the following to audit.rules:\n\n-w /usr/sbin/useradd -p x -k useradd\n-w /usr/sbin/groupadd -p x -k groupadd\n\nConfigure execute auditing of the \"passwd\" executable. Add the following to audit.rules:\n\n-w /usr/bin/passwd -p x -k passwd\n\nConfigure write auditing of the \"passwd\", \"shadow\", \"group\", and \"opasswd\" files. Add the following to the \"/etc/audit/audit.rules\" file:\n\n-w /etc/passwd -p wa -k passwd\n-w /etc/shadow -p wa -k shadow\n-w /etc/group -p wa -k group\n-w /etc/security/opasswd -p wa -k opasswd\n\nRestart the auditd service:\n\n# service auditd restart\n\nOR\n\n# /etc/dodscript.sh","ccis":["CCI-000172"]},{"vulnId":"V-239641","ruleId":"SV-239641r662374_rule","severity":"medium","ruleTitle":"The SLES for vRealize must generate audit records for all kernel module load, unload, and restart actions, and also for all program initiations.","description":"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.\n\nAudit records can be generated from various components within the information system (e.g., module or policy filter).","checkContent":"Determine if \"/sbin/insmod\" is audited:\n\n# cat /etc/audit/audit.rules | grep \"/sbin/insmod\"\n\nIf the result does not start with \"-w\" and contain \"-p x\", this is a finding.","fixText":"Add the following to \"/etc/audit/audit.rules\" in order to capture kernel module loading and unloading events:\n\n-w /sbin/insmod -p x\n\nOR\n\n# /etc/dodscript.sh","ccis":["CCI-000172"]},{"vulnId":"V-239642","ruleId":"SV-239642r878123_rule","severity":"medium","ruleTitle":"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.","description":"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.","checkContent":"Check the SSH daemon configuration for allowed MACs:\n\n# grep -i macs /etc/ssh/sshd_config | grep -v '^#' \n\nIf no lines are returned, or the returned MACs list contains any MAC other than \"hmac-sha1\", this is a finding.","fixText":"Edit the SSH daemon configuration and remove any MACs other than \"hmac-sha1\". If necessary, add a \"MACs\" line. \n\n# sed -i \"/^[^#]*MACs/ c\\MACs hmac-sha1\" /etc/ssh/sshd_config","ccis":["CCI-002450"]},{"vulnId":"V-239643","ruleId":"SV-239643r852615_rule","severity":"medium","ruleTitle":"The SLES for vRealize must, at a minimum, off-load interconnected systems in real time and off-load standalone systems weekly.","description":"Information stored in one location is vulnerable to accidental or incidental deletion or alteration.\n\nOff-loading is a common process in information systems with limited audit storage capacity.","checkContent":"Check the syslog configuration file for remote syslog servers:\n\n# cat /etc/syslog-ng/syslog-ng.conf | grep logserver\n\nIf no line is returned, or the \"logserver\" is commented out, this is a finding.","fixText":"Edit the syslog configuration file and add an appropriate remote syslog server:\n\nIn 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:\n\n# \n# Enable this and adopt IP to send log messages to a log server. \n# \n#destination logserver { udp(\"10.10.10.10\" port(514)); };\n#log { source(src); destination(logserver); };","ccis":["CCI-001851"]},{"vulnId":"V-239644","ruleId":"SV-239644r662383_rule","severity":"medium","ruleTitle":"The SLES for vRealize must prevent the use of dictionary words for passwords.","description":"If SLES for vRealize system allows the user to select passwords based on dictionary words, then this increases the chances of password compromise by increasing the opportunity for successful guesses and brute-force attacks.","checkContent":"Check \"/etc/pam.d/common-password\" for \"pam_cracklib\" configuration:\n\n# grep pam_cracklib /etc/pam.d/common-password*\n\nIf \"pam_cracklib\" is not present, this is a finding.\n\nEnsure the passwd command uses the common-password settings.\n\n# grep common-password /etc/pam.d/passwd\n\nIf 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.","fixText":"Edit \"/etc/pam.d/common-password\" and configure \"pam_cracklib\" by adding a line such as \"password requisite pam_cracklib.so\".","ccis":["CCI-000366"]},{"vulnId":"V-239645","ruleId":"SV-239645r662386_rule","severity":"medium","ruleTitle":"The SLES for vRealize must prevent the use of dictionary words for passwords.","description":"If SLES for vRealize allows the user to select passwords based on dictionary words, then this increases the chances of password compromise by increasing the opportunity for successful guesses and brute-force attacks.","checkContent":"Verify the module \"pam_cracklib.so\" is present. \n\nProcedure: \n\n# ls /lib/security/\n \nConfirm that \"pam_cracklib.so\" is present in the directory listing. \n\nIf \"pam_cracklib.so\"  is not present, this is a finding.\n\nVerify the file \"/etc/pam.d/common-password\" is configured.\n\nProcedure: \n\n# grep pam_cracklib /etc/pam.d/common-password*\n\nIf a line containing \"password required pam_cracklib.so\" is not present, this is a finding.","fixText":"Configure SLES for vRealize to prevent the use of dictionary words for passwords.\n\nEdit the file \"/etc/pam.d/common-password\". Configure \"common-password\" by adding a line such as: \n\npassword  required pam_cracklib.so\n\nSave the changes made to the file \"/etc/pam.d/common-password\".","ccis":["CCI-000366"]},{"vulnId":"V-239646","ruleId":"SV-239646r662389_rule","severity":"medium","ruleTitle":"The SLES for vRealize must prevent the use of dictionary words for passwords.","description":"If SLES for vRealize allows the user to select passwords based on dictionary words, then this increases the chances of password compromise by increasing the opportunity for successful guesses and brute-force attacks.","checkContent":"Verify the \"passwd\" command uses the \"common-password\" settings.\n\nProcedure:\n\n# grep common-password /etc/pam.d/passwd\n\nIf 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.","fixText":"Configure SLES for vRealize to prevent the use of dictionary words for passwords. Procedure:\n\nEdit the file \"/etc/pam.d/passwd\". Configure \"passwd\" by adding a line such as: \n\npassword include common-password\n\nSave the changes made to the file.","ccis":["CCI-000366"]},{"vulnId":"V-239647","ruleId":"SV-239647r662392_rule","severity":"medium","ruleTitle":"The SLES for vRealize must enforce a delay of at least 4 seconds between logon prompts following a failed logon attempt.","description":"Limiting the number of logon attempts over a certain time interval reduces the chances that an unauthorized user may gain access to an account.","checkContent":"Check the value of the \"FAIL_DELAY\" variable and the ability to use it:\n\n# grep FAIL_DELAY /etc/login.defs \n\nThe following result should be displayed:\n\nFAIL_DELAY 4\n\nIf the value does not exist, or is less than \"4\", this is a finding.\n\nCheck for the use of \"pam_faildelay\":\n\n# grep pam_faildelay /etc/pam.d/common-auth*\n\nThe following result should be displayed:\n\n/etc/pam.d/common-auth:auth optional pam_faildelay.so\n\nIf the \"pam_faildelay.so\" module is not listed or is commented out, this is a finding.","fixText":"Add the \"pam_faildelay\" module and set the \"FAIL_DELAY\" variable.\n\nEdit the \"/etc/login.defs\" file and set the value of the \"FAIL_DELAY\" variable to \"4\" or more.\n\nEdit \"/etc/pam.d/common-auth\" and add a \"pam_faildelay\" entry if one does not exist, such as: \n\nauth optional pam_faildelay.so","ccis":["CCI-000366"]},{"vulnId":"V-239648","ruleId":"SV-239648r662395_rule","severity":"medium","ruleTitle":"The SLES for vRealize must enforce a delay of at least 4 seconds between logon prompts following a failed logon attempt.","description":"Limiting the number of logon attempts over a certain time interval reduces the chances that an unauthorized user may gain access to an account.","checkContent":"Verify the SLES for vRealize enforces a delay of at least \"4\" seconds between logon prompts following a failed logon attempt.\n\nReview the file \"/etc/login.defs\" and verify the parameter \"FAIL_DELAY\" is a value of \"4\" or greater. \n\nProcedure:\n\n# grep FAIL_DELAY /etc/login.defs\n\nThe typical configuration looks something like this: \n\nFAIL_DELAY    4\n\nIf the parameter \"FAIL_DELAY\" does not exists, or is less than \"4\", this is a finding.","fixText":"Configure SLES for vRealize to enforce a delay of at least \"4\" seconds between logon prompts following a failed logon attempt. \n\nSet the parameter \"FAIL_DELAY\" to a value of \"4\" or greater. \n\nEdit the file \"/etc/login.defs\". Set the parameter \"FAIL_DELAY\" to a value of \"4\" or greater. \n\nThe typical configuration looks something like this: \n\nFAIL_DELAY    4\n\nSave the changes made to the file.","ccis":["CCI-000366"]},{"vulnId":"V-239649","ruleId":"SV-239649r662398_rule","severity":"medium","ruleTitle":"The SLES for vRealize must enforce a delay of at least 4 seconds between logon prompts following a failed logon attempt.","description":"Limiting the number of logon attempts over a certain time interval reduces the chances that an unauthorized user may gain access to an account.","checkContent":"Verify SLES for vRealize enforces a delay of at least \"4\" seconds between logon prompts following a failed logon attempt.\n\nVerify the use of the \"pam_faildelay\" module.\n\nProcedure:\n\n# grep pam_faildelay /etc/pam.d/common-auth*\n\nThe typical configuration looks something like this:\n\n#delay is in micro seconds\nauth    required    pam_faildelay.so    delay=4000000\n\nIf the line is not present, this is a finding.","fixText":"Configure SLES for vRealize to enforce a delay of at least \"4\" seconds between logon prompts following a failed logon attempt with the following command:\n\n# sed -i \"/^[^#]*pam_faildelay.so/ c\\auth required pam_faildelay.so delay=4000000\" /etc/pam.d/common-auth-vmware.local","ccis":["CCI-000366"]},{"vulnId":"V-239650","ruleId":"SV-239650r662401_rule","severity":"medium","ruleTitle":"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.","description":"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.\n\nConfiguration 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.","checkContent":"Verify 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. \n\nIf it is not, this is a finding.","fixText":"Configure 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.","ccis":["CCI-000366"]},{"vulnId":"V-239651","ruleId":"SV-239651r662404_rule","severity":"medium","ruleTitle":"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.","description":"Setting the most restrictive default permissions ensures that when new accounts are created they do not have unnecessary access.","checkContent":"Check for the configured umask value in login.defs with the following command:\n\n# grep UMASK /etc/login.defs\n\nIf the default umask is not \"077\", this a finding.\n\nNote: If the default umask is \"000\" or allows for the creation of world-writable files this becomes a CAT I finding.","fixText":"To configure the correct UMASK setting run the following command:\n\n# sed -i \"/^[^#]*UMASK/ c\\UMASK 077\" /etc/login.defs\n\nNOTE: Setting \"UMASK 077\" will break upgrades and other possible functionality within the product. When making upgrades to the system, you will need to revert this UMASK setting to the default for the duration of upgrades and then re-apply.","ccis":["CCI-000366"]},{"vulnId":"V-258448","ruleId":"SV-258448r928863_rule","severity":"high","ruleTitle":"The version of vRealize Operations Manager 6.x SLES running on the system must be a supported version.","description":"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.\n\nOrganization-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).\n\nThis 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.\n\nThe 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).","checkContent":"vRealize Operations Manager 6.x SLES is no longer supported by the vendor. If the system is running vRealize Operations Manager 6.x SLES, this is a finding.","fixText":"Upgrade to a supported version.","ccis":["CCI-000366"]},{"vulnId":"V-258512","ruleId":"SV-258512r929628_rule","severity":"medium","ruleTitle":"Any publicly accessible connection to the SLES for vRealize must display the Standard Mandatory DoD Notice and Consent Banner before granting access to the system.","description":"Display of a standardized and approved use notification before granting access to the publicly accessible SLES for vRealize  ensures privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance.\n\nSystem use notifications are required only for access via logon interfaces with human users and are not required when such human interfaces do not exist.\n\nThe banner must be formatted in accordance with applicable DoD policy. Use the following verbiage for operating systems that can accommodate banners of 1300 characters:\n\n\"You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only.\n\nBy using this IS (which includes any device attached to this IS), you consent to the following conditions:\n\n-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.\n\n-At any time, the USG may inspect and seize data stored on this IS.\n\n-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.\n\n-This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy.\n\n-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.\"\n\nUse the following verbiage for operating systems that have severe limitations on the number of characters that can be displayed in the banner:\n\n\"I've read & consent to terms in IS user agreem't.\"","checkContent":"Check issue file to verify that it contains one of the DoD required banners. \n\n# cat /etc/issue\n\n\"You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only.\n\nBy using this IS (which includes any device attached to this IS), you consent to the following conditions:\n\n-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.\n\n-At any time, the USG may inspect and seize data stored on this IS.\n\n-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.\n\n-This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy.\n\n-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.\"\n\nUse the following verbiage for operating systems that have severe limitations on the number of characters that can be displayed in the banner:\n\n\"I've read & consent to terms in IS user agreem't.\"\n\nIf it does not, this is a finding.","fixText":"To configure SLES for vRealize to display the Standard Mandatory DoD Notice and Consent Banner, run the DoD.script with the following command as \"root\":\n\n# /etc/dodscript.sh","ccis":["CCI-001384","CCI-001385","CCI-001386","CCI-001387","CCI-001388"]},{"vulnId":"V-258513","ruleId":"SV-258513r929631_rule","severity":"medium","ruleTitle":"The SLES for vRealize audit system must be configured to audit all administrative, privileged, and security actions.","description":"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.\n\nAudit records can be generated from various components within the information system (e.g., module or policy filter).\n\nThe 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.\n\nDoD has defined the list of events for which the operating system will provide an audit record generation capability as the following: \n\n1) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels);\n\n2) 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;\n\n3) All account creations, modifications, disabling, and terminations; and \n\n4) All kernel module load, unload, and restart actions.","checkContent":"Check the auditing configuration of the system:\n\n# cat /etc/audit/audit.rules | grep -i \"auditd.conf\" \n\nIf no results are returned, or the line does not start with \"-w\", this is a finding.\n\nExpected Result:\n-w /etc/audit/auditd.conf","fixText":"Add the following lines to the \"audit.rules\" file to enable auditing of administrative, privileged, and security actions:\n\necho '-w /etc/audit/auditd.conf' >> /etc/audit/audit.rules\n\nOr run the following command to implement all logging requirements:\n\n# /etc/dodscript.sh","ccis":["CCI-000169"]},{"vulnId":"V-258514","ruleId":"SV-258514r929634_rule","severity":"medium","ruleTitle":"The SLES for vRealize audit system must be configured to audit all attempts to alter system time through adjtimex.","description":"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.\n\nAudit records can be generated from various components within the information system (e.g., module or policy filter).\n\nThe 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 SLES for vRealize is capable of generating audit records.\n\nDoD has defined the list of events for which the operating system will provide an audit record generation capability as the following: \n\n1) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels);\n\n2) 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;\n\n3) All account creations, modifications, disabling, and terminations; and \n\n4) All kernel module load, unload, and restart actions.","checkContent":"Check if SLES for vRealize system is configured to audit calls to the \"adjtimex\" system call, run the following command:\n\n# grep -w \"adjtimex\" /etc/audit/audit.rules\n\nIf SLES for vRealize 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.","fixText":"Run the following command:\n\necho '-a exit,always -F arch=b64 -S adjtimex -F auid=0' >> /etc/audit/audit.rules\necho '-a exit,always -F arch=b64 -S adjtimex -F auid>=500 -F auid!=4294967295' >> /etc/audit/audit.rules\n\nOr run the following command to implement all logging requirements:\n\n# /etc/dodscript.sh","ccis":["CCI-000169"]},{"vulnId":"V-258515","ruleId":"SV-258515r929637_rule","severity":"medium","ruleTitle":"The SLES for vRealize audit system must be configured to audit all attempts to alter system time through settimeofday.","description":"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.\n\nAudit records can be generated from various components within the information system (e.g., module or policy filter).\n\nThe 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 SLES for vRealize is capable of generating audit records.\n\nDoD has defined the list of events for which the operating system will provide an audit record generation capability as the following: \n\n1) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels);\n\n2) 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;\n\n3) All account creations, modifications, disabling, and terminations; and \n\n4) All kernel module load, unload, and restart actions.","checkContent":"Check if SLES for vRealize is configured to audit calls to the \"settimeofday\" system call, run the following command:\n\n# grep -w \"settimeofday\" /etc/audit/audit.rules\n\nIf SLES for vRealize is configured to audit this activity, it will return at least two lines containing \"-S settimeofday\" that also contain \"arch=b64\".\n\nIf no line is returned, this is a finding.","fixText":"Run the following command:\n\necho '-a exit,always -F arch=b64 -S settimeofday -F auid=0' >> /etc/audit/audit.rules\necho '-a exit,always -F arch=b64 -S settimeofday -F auid>=500 -F auid!=4294967295' >> /etc/audit/audit.rules\n\nOr run the following command to implement all logging requirements:\n\n# /etc/dodscript.sh","ccis":["CCI-000169"]},{"vulnId":"V-258516","ruleId":"SV-258516r929640_rule","severity":"medium","ruleTitle":"The SLES for vRealize audit system must be configured to audit all attempts to alter system time through stime.","description":"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.\n\nAudit records can be generated from various components within the information system (e.g., module or policy filter).\n\nThe 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 SLES for vRealize is capable of generating audit records.\n\nDoD has defined the list of events for which the SLES for vRealize will provide an audit record generation capability as the following: \n\n1) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels);\n\n2) 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;\n\n3) All account creations, modifications, disabling, and terminations; and \n\n4) All kernel module load, unload, and restart actions.","checkContent":"Check if SLES for vRealize is configured to audit calls to the \"settimeofday\" system call, run the following command:\n\n# grep -w \"stime\" /etc/audit/audit.rules\n\nIf SLES for vRealize 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.","fixText":"Run the following command:\n\necho '-a exit,always -F arch=b64 -S stime' >> /etc/audit/audit.rules\n\nOr run the following command to implement all logging requirements:\n\n# /etc/dodscript.sh","ccis":["CCI-000169"]},{"vulnId":"V-258517","ruleId":"SV-258517r929643_rule","severity":"medium","ruleTitle":"The SLES for vRealize audit system must be configured to audit all attempts to alter system time through clock_settime.","description":"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.\n\nAudit records can be generated from various components within the information system (e.g., module or policy filter).\n\nThe 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 SLES for vRealize is capable of generating audit records.\n\nDoD has defined the list of events for which the operating system will provide an audit record generation capability as the following: \n\n1) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels);\n\n2) 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;\n\n3) All account creations, modifications, disabling, and terminations; and \n\n4) All kernel module load, unload, and restart actions.","checkContent":"Check if SLES for vRealize is configured to audit calls to the \"clock_settime\" system call, run the following command:\n\n# grep -w \"clock_settime\" /etc/audit/audit.rules\n\nIf SLES for vRealize 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.","fixText":"Run the following command:\n\necho '-a exit,always -F arch=b64 -S clock_settime' >> /etc/audit/audit.rules\n\nOr run the following command to implement all logging requirements:\n\n# /etc/dodscript.sh","ccis":["CCI-000169"]},{"vulnId":"V-258518","ruleId":"SV-258518r929646_rule","severity":"medium","ruleTitle":"The SLES for vRealize audit system must be configured to audit all attempts to alter system time through /etc/localtime.","description":"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.\n\nAudit records can be generated from various components within the information system (e.g., module or policy filter).\n\nThe 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 SLES for vRealize is capable of generating audit records.\n\nDoD has defined the list of events for which the SLES for vRealize will provide an audit record generation capability as the following: \n\n1) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels);\n\n2) 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;\n\n3) All account creations, modifications, disabling, and terminations; and \n\n4) All kernel module load, unload, and restart actions.","checkContent":"To determine if SLES for vRealize is configured to audit attempts to alter time via the /etc/localtime file, run the following command: \n\n# auditctl -l | grep \"watch=/etc/localtime\"\n\nIf SLES for vRealize is configured to audit this activity, it will return a line. \n\nLIST_RULES: exit,always watch=/etc/localtime perm=wa key=localtime\n\nIf no line is returned, this is a finding.","fixText":"To configure the SLES for vRealize to audit attempts to alter time via the /etc/localtime file, run the following command:\n\necho '-w /etc/localtime -p wa -k localtime' >> /etc/audit/audit.rules\n\nOr run the following command to implement all logging requirements:\n\n# /etc/dodscript.sh","ccis":["CCI-000169"]},{"vulnId":"V-258519","ruleId":"SV-258519r929649_rule","severity":"medium","ruleTitle":"The SLES for vRealize audit system must be configured to audit all attempts to alter the system through sethostname.","description":"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.\n\nAudit records can be generated from various components within the information system (e.g., module or policy filter).\n\nThe 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 SLES for vRealize is capable of generating audit records.\n\nDoD has defined the list of events for which the SLES for vRealize will provide an audit record generation capability as the following: \n\n1) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels);\n\n2) 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;\n\n3) All account creations, modifications, disabling, and terminations; and \n\n4) All kernel module load, unload, and restart actions.","checkContent":"Check if SLES for vRealize is configured to audit calls to the \"sethostname\" system call, run the following command:\n\n# grep -w \"sethostname\" /etc/audit/audit.rules\n\nIf SLES for vRealize is configured to audit this activity, it will return at least one line. If no line is returned, this is a finding.","fixText":"Run the following command:\n\n# echo '-a exit,always -F arch=b64 -S sethostname' >> /etc/audit/audit.rules\n\nOr run the following command to implement all logging requirements:\n\n# /etc/dodscript.sh","ccis":["CCI-000169"]},{"vulnId":"V-258520","ruleId":"SV-258520r929652_rule","severity":"medium","ruleTitle":"The SLES for vRealize audit system must be configured to audit all attempts to alter the system through setdomainname.","description":"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.\n\nAudit records can be generated from various components within the information system (e.g., module or policy filter).\n\nThe 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.\n\nDoD has defined the list of events for which the SLES for vRealize will provide an audit record generation capability as the following: \n\n1) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels);\n\n2) 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;\n\n3) All account creations, modifications, disabling, and terminations; and \n\n4) All kernel module load, unload, and restart actions.","checkContent":"Check if SLES for vRealize is configured to audit calls to the \"sethostname\" system call, run the following command:\n\n# grep -w \"setdomainname\" /etc/audit/audit.rules\n\nIf SLES for vRealize is configured to audit this activity, it will return a line. If no line is returned, this is a finding.","fixText":"Run the following command:\n\n# echo '-a exit,always -F arch=b64 -S setdomainname' >> /etc/audit/audit.rules\n\nOr run the following command to implement all logging requirements:\n\n# /etc/dodscript.sh","ccis":["CCI-000169"]},{"vulnId":"V-258521","ruleId":"SV-258521r929655_rule","severity":"medium","ruleTitle":"The SLES for vRealize must be configured to audit all attempts to alter the system through sched_setparam.","description":"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.\n\nAudit records can be generated from various components within the information system (e.g., module or policy filter).\n\nThe 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.\n\nDoD has defined the list of events for which the SLES for vRealize will provide an audit record generation capability as the following: \n\n1) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels);\n\n2) 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;\n\n3) All account creations, modifications, disabling, and terminations; and \n\n4) All kernel module load, unload, and restart actions.","checkContent":"Check if SLES for vRealize is configured to audit calls to the \"sethostname\" system call, run the following command:\n\n# grep -w \"sched_setparam\" /etc/audit/audit.rules\n\nIf SLES for vRealize is configured to audit this activity, it will return a line.\n\nIf no line is returned, this is a finding.","fixText":"Run the following command:\n\necho '-a exit,always -F arch=b64 -S sched_setparam' >> /etc/audit/audit.rules\n\nOr run the following command to implement all logging requirements:\n\n# /etc/dodscript.sh","ccis":["CCI-000169"]},{"vulnId":"V-258522","ruleId":"SV-258522r929658_rule","severity":"medium","ruleTitle":"The SLES for vRealize must be configured to audit all attempts to alter the system through sched_setscheduler.","description":"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.\n\nAudit records can be generated from various components within the information system (e.g., module or policy filter).\n\nThe 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.\n\nDoD has defined the list of events for which the SLES for vRealize will provide an audit record generation capability as the following: \n\n1) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels);\n\n2) 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;\n\n3) All account creations, modifications, disabling, and terminations; and \n\n4) All kernel module load, unload, and restart actions.","checkContent":"Check if SLES for vRealize is configured to audit calls to the \"sethostname\" system call, run the following command:\n\n# grep -w \"sched_setscheduler\" /etc/audit/audit.rules\n\nIf SLES for vRealize is configured to audit this activity, it will return a line. If no line is returned, this is a finding.","fixText":"Run the following command:\n\necho '-a exit,always -F arch=b64 -S sched_setscheduler' >> /etc/audit/audit.rules\n\nOr run the following command to implement all logging requirements:\n\n# /etc/dodscript.sh","ccis":["CCI-000169"]},{"vulnId":"V-258523","ruleId":"SV-258523r929661_rule","severity":"medium","ruleTitle":"The SLES for vRealize must be configured to audit all attempts to alter /var/log/faillog.","description":"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.\n\nAudit records can be generated from various components within the information system (e.g., module or policy filter).\n\nThe 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.\n\nDoD has defined the list of events for which the SLES for vRealize will provide an audit record generation capability as the following: \n\n1) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels);\n\n2) 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;\n\n3) All account creations, modifications, disabling, and terminations; and \n\n4) All kernel module load, unload, and restart actions.","checkContent":"Verify that attempts to alter the log files /var/log/faillog are audited:\n\n# egrep \"faillog\" /etc/audit/audit.rules\n\nIf \"-w /var/log/faillog -p wa\" entry does not exist, this is a finding.","fixText":"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:\n\necho '-w /var/log/faillog -p wa' >> /etc/audit/audit.rules\n\nOr run the following command to implement all logging requirements:\n\n# /etc/dodscript.sh","ccis":["CCI-000169"]},{"vulnId":"V-258524","ruleId":"SV-258524r929664_rule","severity":"medium","ruleTitle":"The SLES for vRealize must be configured to audit all attempts to alter /var/log/lastlog.","description":"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.\n\nAudit records can be generated from various components within the information system (e.g., module or policy filter).\n\nThe 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.\n\nDoD has defined the list of events for which the SLES for vRealize will provide an audit record generation capability as the following: \n\n1) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels);\n\n2) 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;\n\n3) All account creations, modifications, disabling, and terminations; and \n\n4) All kernel module load, unload, and restart actions.","checkContent":"Verify that attempts to alter the log files /var/log/lastlog are audited:\n\n# egrep \"lastlog\" /etc/audit/audit.rules\n\nIf \"-w /var/log/lastlog -p wa\" entry does not exist, this is a finding.","fixText":"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:\n\necho '-w /var/log/lastlog -p wa' >> /etc/audit/audit.rules\n\nOr run the following command to implement all logging requirements:\n\n# /etc/dodscript.sh","ccis":["CCI-000169"]},{"vulnId":"V-258525","ruleId":"SV-258525r929667_rule","severity":"medium","ruleTitle":"The SLES for vRealize must be configured to audit all attempts to alter /var/log/tallylog.","description":"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.\n\nAudit records can be generated from various components within the information system (e.g., module or policy filter).\n\nThe 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.\n\nDoD has defined the list of events for which the SLES for vRealize will provide an audit record generation capability as the following: \n\n1) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels);\n\n2) 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;\n\n3) All account creations, modifications, disabling, and terminations; and \n\n4) All kernel module load, unload, and restart actions.","checkContent":"Verify that attempts to alter the log files /var/log/tallylog are audited:\n\n# egrep \"tallylog\" /etc/audit/audit.rules\n\n\nIf \"-w /var/log/tallylog -p wa\" entry does not exist, this is a finding.","fixText":"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:\n\necho '-w /var/log/tallylog -p wa' >> /etc/audit/audit.rules\n\nOr run the following command to implement all logging requirements:\n\n# /etc/dodscript.sh","ccis":["CCI-000169"]}]}